Nie do końca powtarzalny JBroFuzz

Czasami przychodzi taki czas, że trzeba przyglądnąć się wykorzystywanym narzędziom, zapoznać się z nowościami, być może coś usprawnić, zmienić. Dzisiaj usiłowałem dokładniej przyjrzeć się JBroFuzz 2.1. Zamiast możliwości zobaczyłem głównie problemy i “ciekawostki”... Muszę sprawdzić jeszcze dokładnie kiedy problemy występują. Ja spotkałem się z nimi pod Windows Vista, ale na drugim komputerze z Windows XP części z nich nie udało mi się odtworzyć.

Drobna niedogodność

Pierwsza sprawa nie jest może krytyczna, ale do kategorii ciekawostek należy ją zaliczyć. Z obserwacji zachowania narzędzia wygląda jakby JBroFuzz uznawał, że serwer zakończył odpowiedź wtedy, gdy zamyka on połączenie z klientem. Tylko, że serwer nie zawsze połączenie zamyka, JBroFuzz czeka prawie w nieskończoność (ta nieskończoność nie jest tak odległa, w praktyce tylko do czasu ustalonego jako time-out , czyli domyślnie jakieś 7 sekund) i nie widzi odpowiedzi serwera. Rozwiązanie tej niedogodności jest stosunkowo proste, wystarczy dopisać do żądania taki nagłówek:

Connection: close

Prawda, że proste? Szkoda tylko, że nie zauważyłem tego w dokumentacji, a i błąd zgłaszany w tym przypadku przez JBroFuzz jest co najmniej mylący:

An IO Error occured: socket closed.

This could also be a Connection Timeout, try increasing the value under Preferences –> Fuzzing

Ten problem akurat udało mi się odtworzyć pod Windows XP. Problemów, które opisałem niżej – już nie. Szczerze mówiąc ciężko mi określić z czego może wynikać ta różnica. Na obu systemach zainstalowana jest Java w tej samej, najbardziej aktualnej wersji.

Bardziej uciążliwy problem

Opisany wyżej problem to jednak tylko drobna niedogodność w porównaniu z tym, na co natknąłem się później. A wszystko (chyba) przez te różne sekwencje oznaczające koniec linii. Czasem jest to CRLF, czasem CR, czasem LF...

Typowy przypadek użycia wygląda dla mnie tak, że kopiuję z Fiddlera do JBroFuzz żądanie, które chcę fuzzować. Prawdopodobnie tu znakiem końca linii jest CRLF, w końcu to Windows. Patrząc na nagłówki w Fiddlerze jest to nawet na pewno CRLF, bo w widoku HEX występuje sekwencja 0d 0a. Problem polega na tym, że w domyślnej konfiguracji na komputerze, na którym obserwuję problem JBroFuzz przekształca CRLF na CRCRLF, ponieważ:

Ponieważ akurat tam już jest jedno CR na koniec otrzymuje się sekwencję CRCRLF. Wygląda to mniej więcej tak (ze zwrzutu ruchu sieciowego):

GET / HTTP/1.1

Host: bootcamp.threats.pl

X-Test: ABCXD

Connection: close

A patrząc w HEX:

00000000 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0d GET / HT TP/1.1.. 00000010 0a 48 6f 73 74 3a 20 62 6f 6f 74 63 61 6d 70 2e .Host: b ootcamp. 00000020 74 68 72 65 61 74 73 2e 70 6c 0d 0d 0a 58 2d 54 threats. pl...X-T 00000030 65 73 74 3a 20 41 42 43 58 44 0d 0d 0a 43 6f 6e est: ABC XD...Con 00000040 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f 73 65 0d 0d nection: close.. 00000050 0a 0d 0d 0a ....

Zwracam uwagę na sekwencję 0d 0d 0a, czyli właśnie CRCRLF, o której mówiłem wcześniej.

Teoretycznie problem można rozwiązać przy pomocy ustawienia konfiguracyjnego dostępnego w Options – > Preferences –> Fuzzing przez odznaczenie opcji Use “\n” insteand of “\r\n” (...) , wówczas żądanie jest wysyłane prawidłowo:

00000000 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a GET / HT TP/1.1.. 00000010 48 6f 73 74 3a 20 62 6f 6f 74 63 61 6d 70 2e 74 Host: bo otcamp.t 00000020 68 72 65 61 74 73 2e 70 6c 0d 0a 58 2d 54 65 73 hreats.p l..X-Tes 00000030 74 3a 20 41 42 43 58 44 0d 0a 43 6f 6e 6e 65 63 t: ABCXD ..Connec 00000040 74 69 6f 6e 3a 20 63 6c 6f 73 65 0d 0a 0d 0a tion: cl ose....

W tym wypadku nie ma już sekwencji 0d 0d 0a, zamiast tego jest prawidłowa sekwencja 0d 0a. Problem rozwiązany? No nie zupełnie...

Weźmy takie żądanie, które chcemy fuzzować:

GET / HTTP/1.1 Host: bootcamp.threats.pl X-Test: ABCXD Connection: close

Chcę, by fuzzer znak X w wartości nagłówka X-Test zastąpił kolejnymi znakami z alfabetu. Zaznaczam więc odpowiednie miejsce, dodaję fuzzer, a JBroFuzz wysyła radośnie takie żądanie:

GET / HTTP/1.1 Host: bootcamp.threats.pl X-Test: AyCXD Connection: close

Coś mi się nie trafiło? Zamiast X zaznaczyłem B? A może to JBroFuzz ma problemy z liczeniem znaków? Zwracam uwagę, że w tym przypadku przesunięcie to dwa znaki “w lewo”. Akurat tak, jakby przy liczeniu JBroFuzz się pomylił o dwa znaki z sekwencji \r\n, które są wcześniej dwie, bo fuzzowane miejsce znajduje się w trzeciej linii. Obserwacja ta może być łatwo zweryfikowana. Dodając jeszcze jedną linię przed nagłówkiem X-Test uzyskuje się przesunięcie o trzy znaki w lewo:

GET / HTTP/1.1 Host: bootcamp.threats.pl X-Pad: xxx X-Test: zBCXD Connection: close

Ten błąd w liczeniu akurat nie jest zależny od włączenia/wyłączenia opcji mówiącej o traktowaniu znaków końca linii. Nie mam obecnie tyle samozaparcia, by poszukać odpowiedniego fragmentu kodu i zobaczyć z czego konkretnie ten problem wynika...

Czy ktoś też tak ma

Ciekawy jestem, czy ktoś może potwierdzić moje obserwacje? Czy ktoś może odtworzyć opisane przeze mnie problemy na Windows Vista/7? A może ktoś obserwuje podobne zachowania pod Windows XP? A jak JBroFuzz radzi sobie z innymi niż Windows systemami operacyjnymi?

Fuzzer powinien być powtarzalny. Chodzi o to, by dla tych samych warunków początkowych zawsze wykonywał takie same testy. Nie jest dobra sytuacja, w której narzędzie czasem coś znajduje, a czasami nie, lub w której realizowane testy zależą od wysokości słońca nad horyzontem. JBroFuzz zaskoczył mnie jeszcze w inny sposób – czasami działa, a czasami nie. Mogę zagwarantować, że sytuacja, w której narzędzie nagle tchórzliwie odmawia współpracy należy do jednych z bardziej irytujących. Do czasu, gdy nie uda mi się osiągnąć takiego stanu, że JBroFuzz zawsze robi to, co od niego chcę i dokładnie tak jak tego chcę, nie wejdzie on do grupy “podstawowych” narzędzi... Nad zgłoszeniem błędu pomyślę, jeśli będę miał pełniejszy obraz tego kiedy opisane tu problemy się pojawiają.

Oryginał tego wpisu dostępny jest pod adresem Nie do końca powtarzalny JBroFuzz

Autor: Paweł Goleń