Hi, hackers and bugbounty hunters 👋🏼

Today I’m going to talk about my new XSS tool, DalFox. I’m sure there are a lot of bugs because it’s still under development, but I’m going to talk it lightly now because it’s somewhat functional and has a critical bug fixed!

정말 오랜만에 글을 쓰는 것 같네요. 변명을 늘여놓자면, 글을 쓸 시간에 개발을 하다보니 많이 손을 못댔습니다. 오늘은 제 새로운 XSS Scanning 도구인 Dalfox에 대해 이야기하려고 합니다.

https://github.com/hahwul/dalfox

What is DalFox

It is a tool that analyzes parameters and scans XSS just like the existing XSpear. Most of the key feature of existing specs are inherited, and the new version addresses chronic slow speed and detection issues of detection. And… there was a big change from Ruby to Go.

기존 XSpear와 동일하게 파라미터를 분석하고 XSS를 스캐닝하는 도구입니다. 기존 스펙의 대다수 기능은 그대로 승계하고, 고질적인 속도 문제와 탐지 문제를 해결한 버전입니다. 그리고. Ruby에서 Go로 바뀌는 대대적 변화가 있었구요.

This is Key features 가장 중요한 기능이 되는 부분은 아래와 같습니다.

• 파라미터 분석에 따른 페이로드 옵티마이징 (Payload Optimization according to parameter analysis)
• 추상화를 통해 코드 삽입 위치를 분석하고, 종류에 맞는 페이로드 사용 (Analyse the location of code insertion through abstraction and use Payload for the type)
• DOM 기반 검증로직 (DOM-based verification logic)
• Pipeline 지원 (Pipeline support)

(What you see in git is the most accurate.)

Optimazation & Abstraction

Existing XSpear used multiple testing queries, DalFox has a Badchar-based payload verification logic. This selects the query to use for the actual test based on the data obtained from the parameter testing. And we talked about the abstraction concept above, which eventually divides the code into HTML and Script areas, as shown below, identifies the injected location and uses the payload according to the location.

기존 XSpear가 다수의 테스팅 쿼리를 사용했다면, DalFox는 철저히 Badchar 기반의 페이로드 검증 로직을 가집니다. 그래서 파라미터 테스팅에서 얻어진 데이터를 기반으로 실제 테스팅에 사용할 쿼리를 선택합니다. 그리고 위에서 추상화 개념을 이야기했는데, 결국 아래 그림과 같이 코드를 HTML 영역과 Script 영역으로 나누고, 인젝션된 위치를 파악한 후 위치에 따른 페이로드를 사용합니다. (왜냐면.. 실제로 테스팅할때도 javascript 내부 삽입된 코드에 탈출 구문을 제외한 html를 잘 사용하진 않죠)

DalFox checked HTML, Javascript, Attribute

DOM Verify

For XSpear, the Selenium driver has verified that the alert actually occurs. This is a sure way to find it, but calling the headless browser is a very slow task. The system is overloaded, especially if you want to verify a huge number of data.

XSpear의 경우 Selenium driver를 통해 실제로 alert이 발생하는지 검증했습니다. 이는 확실하게 찾을 수 있는 방법이지만, headless browser를 호출하는건 굉장히 느린 작업입니다. 특히나 엄청나게 많은 수의 데이터를 검증하려면 시스템의 과부화도 많이 걸리죠.

So at DalFox, we boldly threw away Selenium, and we changed it to a DOM-based verification method. If you think the actual object is inserted, you can think of it as Verify. Verified parameters do not need to be tested further, so the remaining payload queues will be passed(not testing).

그래서 DalFox에선 과감하게 Selenium을 버리고, DOM 기반으로 검증하는 방식으로 바꿨습니다. 실제 Object가 삽입됬다고 판단하면 Verify를 준다고 생각하시면 됩니다. Verify된 파라미터는 추가로 더 테스팅할 필요가 없으니 나머지 페이로드 큐는 패스히구요.

Pipeline

On DalFox, I paid a little more attention to the part where I got the factor value (io, file, arg) or log output so that I could fit into the pipeline in general. Basically, scan logging provides a variety of data, such as code views and actual payloads, but print only attack query it out if you with a pipeline option.

DalFox로 오면서, 전반적으로 Pipeline에 끼워들어갈 수 있도록 인자값을 받는 부분(io, file, arg)이나 log output 부분에 조금 더 신경을 썼습니다. 기본적으로 스캔 로깅에선 Code view나 실제 페이로드 등 여러가지 데이터를 제공해주지만, pipeline으로 출력을 했을 경우엔 페이로드만 찍힐 수 있도록 한 부분도 이런 고민의 결과 중 하나죠.

So, just simple pipeline tip :D 아무튼 그래서.. 이제 아래와 같은 형태로 명령 구성이 가능합니다.

cat target_list | waybackurls -no-subs | grep "https://" | grep -v "png\|jpg\|css\|js\|gif\|txt" | grep "=" | qsreplace | qsreplace -a | dalfox -pipe -blind https://hahwul.xss.ht

Finally

작년부터 ruby=>go로 메인 언어를 바꾸고 있었고, 드디어 제가 가진 가장 큰(외부에 오픈된 것 중) 프로젝트를 변경하게 되었네요. 아직 버그가 많이 있겠지만, 사용해보시고 좋은 의견이나 버그가 있다면 git issue로 등록해주세요. 그리고 마지막으로 이름에 대한 이야기를 하자면, DalFox에서 Dal은 달입니다. (and Dal of DalFox is the Korean pronunciation of moon.)

// and Fox = Finder of XSS, Haha happy hacking!