Hi hackers and bugbounty hunters 😁
CI/CD is a key topic in DevOps, DevSecOps. I’m also working on DevSecOps, so I’ve been thinking about it a lot and testing it. Meanwhile, I thought it would be okay to use CI concept in Recon. CI/CD는 DevOps, DevSecOps에서 가장 핵심적인 주제가 되는 내용입니다. 저 또한 일적으론 DevSecOps에 대한 부분도 하고 있기 때문에 자주 고민하고, 테스트해보고 있는데요. 그러던 중 Recon에 CI 개념을 사용해봐도 괜찮을 것 같은 생각이 들었습니다.
Todays, CI for Recon! 그래서 오늘은 Recon에서 CI를 적용했던 이야기에 대해 공유드릴까 합니다.
It literally means continuous integration. This refers to an automated process that periodically builds and integrates source code into testing, repo, etc. according to specific events, such as code changes and periodic settings. 이름 그대로 지속적인 통합을 의미합니다. 코드 변경, 주기적인 설정 등 특정 이벤트에 따라 소스코드를 주기적으로 빌드하고 테스트, Repo(git 등)에 통합하는 자동화 프로세스를 의미합니다.
Personally for BugBounty, make and use a lot of tools, and we accumulate data. In my case, I wanted to combine multiple devices and the results of the testing server and MacBook’s different results.
So I used CI concept for continuous bugbounty data integration. 개인적으로 버그바운티를 위해서(자주하지는 않지만) 여러가지 도구를 만들어서 사용하고, 데이터를 누적하는데요. 저의 경우 여러 디바이스를 사용하고 테스팅 서버의 결과와 맥북에 다른 결과가 있어서 이를 통합하고 싶은 생각은 있었습니다.
그래서 지속적인 버그바운티 데이터 통합을 위해서 CI 개념을 붙여봤습니다.
When triggered largely by a specific event(add new target, and weekly?), it has a structure that uses the existing Recon tool to analyze, add the results in github and tell me with Slack.
우선 저의 니즈는 확실했고, 기존에 사용하던 도구와 pipeline을 CI/CD 도구에 이식하기 시작했습니다. 가장 커뮤니티가 활발하고 많이 사용되는 Jenkins를 택했고 저희 recon 도구와 slack까지 이어지는 그림을 그렸습니다.
Jenkins + My private app + Slack notify
크게 특정 이벤트에서 트리거가 되면, 기존에 사용하던 Recon 도구를 이용해서 분석하고, 결과를 github에 반영 및 slack으로 알려주는 구조를 가집니다.
First of all, we will create one item for each Recon, so make one item to use as a template. 우선 매번 Recon 마다 하나의 item을 만들어줄거라 Template로 사용할 item을 하나 만들어줍니다.
Connect to Git repo for integration of Recon results. Recon 결과의 통합을 위해서 Git repo를 연결해줍니다.
Then run the Recon tool. I think you can put the shell script according to the tool you are using. At this time, the important thing is to use the git publisher to reflect the results to git, but it is said that the -am
option should be given, such as git commit -am 'msg'
.
그다음 Recon 도구를 실행해줍니다. 여러분들이 사용하시는 도구에 맞게 Shell script를 넣어주시면 될 것 같습니다. 이 때 중요한건 결과를 git에 반영하기 위해서 git publisher를 사용하는데 git commit -am 'msg'
같이 -am
옵션을 줘야한다고 하네요.
Finally, the result is reflected on github through the Git publisher, and a plugin is applied to notify with Slack. 마지막으로 Git publisher를 통해 결과를 github에 반영하고, Slack으로 notify 줄 수 있도록 플러그인을 적용해줍니다.
Run
Finish notify
Result
Honestly, it was a project I did for fun, but it was nice that the result was more satisfying than I thought. I think continually integrating analytical data can be of great help in finding better results.
솔직히 재미삼아 해본 프로젝트인데, 생각보다 결과가 만족스러워서 좋았습니다. 지속적으로 분석 데이터를 통합시킨다는게, 조금 더 나은 결과를 찾는데 큰 도움이 될 수 있다고 생각합니다.
I added parameter options and integrated them into one project. It can be used like a scanner. 나중에는 매개변수 옵션을 추가하고, 한개의 프로젝트로 통합시켰습니다. 이로써 스캐너처럼 사용할 수 있네요.
code
if [ ! -d bugbounty/$TARGET; ]; then
mkdir bugbounty/$TARGET;
fi
cd bugbounty/$TARGET;
export PATH=$PATH:/var/lib/jenkins/go/bin;
~/go/bin/D.E.V.I init;
touch s_target.txt
touch w_target.txt
if [ -n $STARGET ] ; then
echo "$STARGET" > s_target.txt
fi
if [ -n $WTARGET ] ; then
echo "$WTARGET" > w_target.txt
fi
~/go/bin/D.E.V.I recon;
git add --all;
git commit -am "update";
And two weeks later, I changed the structure to Pipeline using Jenkinsfile. (Because it’s easier to control the entire flow with shell pipeline and groovy script than logic of go app)