How to use DalFox’s Fun Options (if found notify , custom grepping)

As you can see from my blog and tweet, I recently full-change(new project…) my XSpear and created an XSS Scanning tool called DalFox. Today, I’m going to share some tips for using DalFox. 제 블로그나 트윗을 본다면 알겠지만, 최근 XSpear를 갈아엎고 DalFox라는 XSS Scanning 도구를 만들었습니다.

오늘은 DalFox를 사용할 떄 참고할만한 팁 몇가지를 공유하려고 합니다.

Usage of DalFox

Dalfox has many options. Use it appropriately according to your situation and needs!

    _..._
  .' .::::.   __   _   _    ___ _ __ __
 :  :::::::: |  \ / \ | |  | __/ \\ V /
 :  :::::::: | o ) o || |_ | _( o )) (
 '. '::::::' |__/|_n_||___||_| \_//_n_\
   '-.::''

Parameter Analysis and XSS Scanning tool based on golang
Finder Of XSS and Dal is the Korean pronunciation of moon. @hahwul

Usage:
  dalfox [command]

Available Commands:
  file        Use file mode(targets list or rawdata)
  help        Help about any command
  pipe        Use pipeline mode
  url         Use single target mode
  version     Show version

Flags:
  -b, --blind string            Add your blind xss (e.g -b https://hahwul.xss.ht)
      --config string           Using config from file
  -C, --cookie string           Add custom cookie
      --custom-payload string   Add custom payloads from file
  -d, --data string             Using POST Method and add Body data
      --delay int               Milliseconds between send to same host (1000==1s)
      --found-action string     If found weak/vuln, action(cmd) to next
      --grep string             Using custom grepping file (e.g --grep ./samples/sample_grep.json)
  -H, --header string           Add custom headers
  -h, --help                    help for dalfox
      --only-discovery          Only testing parameter analysis
  -o, --output string           Write to output file
      --output-format string    -o/--output 's format (txt/json/xml)
  -p, --param string            Only testing selected parameters
      --proxy string            Send all request to proxy server (e.g --proxy http://127.0.0.1:8080)
      --silence                 Not printing all logs
      --timeout int             Second of timeout (default 10)
      --user-agent string       Add custom UserAgent
  -w, --worker int              Number of worker (default 40)

Case study1 - Using pipelining

Many Bounty Hunters want to automate their work processes and easily find vulnerabilities. I’m also of the same class, and to make it a little easier, DalFox was basically developed considering Pipeline. Until now, we are going to support 3 types of scan modes (‘url’, ‘file’ and ‘pipe’) and support a slightly unique type of scan mode for Stored XSS in the future.

많은 바운티헌터들은 자신의 작업 과정을 자동화하고, 쉽게 취약점을 찾고싶어합니다. 저 또한 같은 부류이고, 이를 조금 더 쉽게하기 위해서 DalFox는 기본적으로 Pipeline을 고려하여 개발했습니다. 현재까진 총 3가지 방식의 스캔 모드(url, file, pipe)를 지원하고 있고 추후에는 Stored XSS를 위해서 조금 독특한 형태의 스캔 모드를 지원하려고 합니다.

file        Use file mode(targets list or rawdata)
pipe        Use pipeline mode
url         Use single target mode

First of all, url and file are options that use a from other tools, so I’ll talk about only pipe lightly. 우선 url이나 file은 다른 도구도 많이 사용하는 옵션이니 pipe에 대해서 가볍게 이야기해보겠습니다.

When you operate DalFox in pipe mode, the basic input is set to stdin . So you can get the input value through the pipeline from other tools. The format of the input value used here is an url list divided based on the opening letter, which is the same as the file option.

pipe 모드로 DalFox를 동작시키면 기본적인 input이 stdin 으로 설정됩니다. 그래서 다른 툴로부터 pipeline을 통해 입력값을 받을 수 있습니다. 여기서 사용하는 입력값의 포맷은 개행문자를 기반으로 나뉜 url list이고 이는 file 옵션과 동일합니다.

echo "https://www.hahwul.com" | dalfox pipe

there is a pipeline like below. 약간의 머리를 쓰면, 아래와 같은 파이프라인을 구성할 있습니닷

cat targets_list | waybackurls | grep "=" | grep -v "png\|jpg\|js\|css\|gif\|txt" | qsreplace | dalfox pipe --blind https://your.blind.xss.site --worker 5 > dalfox_result

One thing I want to talk about here is the number of walkers. As you already know, gallang has high concurrency and very fast speed due to the goroutine and gochannel. DalFox basically generates and tests 40 workers, and pipelines can have a lot of input, which is extremely rare, but can also occupy the maximum number of sockets per process supported by the OS. So I think we need to adjust the walker of the right line. (Of course, it is okay to use the default or more for fewer targets or single scans)

여기서 하나 이야기하고 싶은건 워커의 갯수인데요, 이미 알시겠지만 golang은 고루틴으로 인해 동시성이 높고 속도도 굉장히 빠릅니다. DalFox는 기본적으로 40개의 Worker를 생성해서 테스트하는데, pipeline의 경우 input이 굉장히 많을 수 있어서 극히 드물지만 OS에서 지원하는 프로세스 당 소켓의 최대 수를 점유할수도 있습니다. 그래서 적당한 선의 워커 조정은 필수입니다. (물론 타겟이 적거나 단일 스캔의 경우 기본값 or 그 이상을 사용해도 무방하죠)

Below is a way to check with ‘ulimit’, so please refer to it. (‘ulimit -a’ or ‘ulimit -n’) 아래는 ulimit으로 확인할 수 있는 방법이니 참고해주세요. (ulimit -a or ulimit -n)

ulimit -a
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         0
-m: resident set size (kbytes)      unlimited
-u: processes                       30504
-n: file descriptors                1024
-l: locked-in-memory size (kbytes)  16384
-v: address space (kbytes)          unlimited
-x: file locks                      unlimited
-i: pending signals                 30504
-q: bytes in POSIX msg queues       819200
-e: max nice                        0
-r: max rt priority                 0
-N 15:                              unlimited

Case study2 - Notify slack using --found-action option

The second is the ‘–found-action’ option. This option allows you to specify commands to perform immediately if they are selected during scanning or detected in the Verify DOM logic. There are many cases, but notify is representative.

두번째는 --found-action 옵션입니다. 이 옵션은 스캐닝중에 Reflected 되거나, Verify DOM 로직에서 탐지된 경우 바로 수행할 명령을 지정할 수 있습니다. 여러가지 케이스가 있겠지만, 대표적으로 활용할 수 있는게 Notify입니다.

It has indicators ‘@@query@’, ‘@@target@@’, and ‘@@type@@’ when the actual command is executed, it is replaced and used in the following pattern.

기본적으로 @@query@@ , @@target@@ , @@type@@ 란 지시자를 가지고있고, 이는 실제 명령이 실행될 때 아래와 같은 패턴으로 치환되서 사용되고 있죠.

@@query@@ : attack query
 + e.g: https://www.hahwul.com?q="><script~~blahblah
@@target@@ : target site
 + e.g: https://www.hahwul.com
@@type@@ : WEAK / VULN

So you can create a Bash script that can handle slack, and you can configure notify in this command line.

그래서 slack을 처리할 수 있는 bash 스크립트를 하나 만들고, 이런 형태로 notify를 구성할 수 있습니다.

dalfox url http://testphp.vulnweb.com/listproducts.php\?cat\=123\&artist\=123\&asdf\=ff --found-action "./samples/sample_found_action.sh @@query@@ @@type@@"

slack.sh code is below.I think I would have reflected it in the samples after posted this post. 아래는 slack.sh이고, 이 글이 업로드될 때 쯤이면 내가 samples에 반영했을 것 같습니다. (반영했죠!)

# @@query@@ : https://www.hahwul.com?q="><script~~blahblah
# @@target@@ : https://www.hahwul.com
# @@type@@ : WEAK / VULN
# slack.sh @@query@@ @@type@@

query=$1
type=$2
if [ $type = "VULN" ]
then
  curl -X POST --data-urlencode "payload={\"channel\": \"#your channel\", \"username\": \"DalFox\", \"text\": \"[Verify]\n$query\", \"icon_emoji\": \"fox\"}" https://hooks.slack.com/services/your/secret_slack_url
else
  curl -X POST --data-urlencode "payload={\"channel\": \"#your channel\", \"username\": \"DalFox\", \"text\": \"[Reflected]\n$query\", \"icon_emoji\": \":fox:\"}" https://hooks.slack.com/services/your/secret_slack_url
fi

다만 스크립트에 약간 버그가 있네요….ㅜㅜ

Case study3 - Grepping custom pattern

The third option is Grepping, ‘–grep’. To begin with, the purpose of creating this option is that the XSS scanning tool is intended for XSS detection, but it can actually be useful in finding other vulnerabilities. So I thought it would be nice to provide the user with a custom response grab, so I made this function.

세번째는 Grepping, --grep 옵션입니다. 이 옵션을 만든 취지를 먼저 이야기하자면, XSS 스캐닝 도구는 XSS 탐지를 목적으로 만들지만, 실제로 다른 취약점을 찾는데 유용하게 쓰일 수 있습니다. 그러다보니, 사용자에게 custom 하게 response grep을 할 수 있게 제공해주면 좋겠다라는 생각이 들었고, 그래서 만든 기능입니다.

Basically, SSTI and some patterns (SSL Private key detection, etc.) are included as built-in. In addition, you can refer to external pattern json in the form of ‘–grep=JSON_FILE’. I’ll just scan the hackone report page included S3 address for example.

기본적으로 SSTI와 일부 패턴(SSL Private key 탐지 등)은 Built-in으로 들어가 있습니다. 이외에도 --grep=JSON_FILE 같은 형태로 외부의 패턴 json을 참조할 수 있습니다. 예시를들기 쉽게 s3 주소가 있는 페이지를 그냥 스캔해보죠.

dalfox url --grep samples/sample_grep.json https://hackerone.com/reports/57505

If there is Regex that can identify s3 in the grep json given as an option at this time, it can be detected as follows.

이 때 옵션으로 준 grep json에 s3를 식별할 수 있는 Regex가 있다면… samples/sampel_grep.json

{
 "sample pattern":"phoenix.html",
 "amazonaws_url": "s3\\.amazonaws.com[/]+|[a-zA-Z0-9_-]*\\.s3\\.amazonaws.com",
 "slack_webhook": "https://hooks.slack.com/services/T[a-zA-Z0-9_]{8}/B[a-zA-Z0-9_]{8}/[a-zA-Z0-9_]{24}"
}

아래와 같이 스캔 중 탐지할 수 있습니다.

Conclusion

I think there are still a lot of functions that are lacking, and there are a lot of functions that need to be added. Obviously, it’s better than the XSpear I made before, so I thought it would be a little bit helpful for your happy bugbounty life. Use it well and additional functional comments and bug reports are always welcome!

아직 부족한 기능도 많고, 추가해야할 기능도 많다고 생각합니다. 분명히 예전에 만든 XSpear 보다는 비교도 안되게 좋기 때문에 취약점을 찾는데 있어 조금이나마 도움이 될거란 생각이 드네요. 기능추가 의견이나 버그제보는 언제나 환영이야!