Pierwszy raz z opisem ataku HTTP Referer Spoofing spotkałem się w 2008 roku na łamach magazynu Linux+. Paweł Szcześniak opisał, jak za pomocą tej metody możemy wstrzykiwać odnośniki do agresywnej strony w innych systemach statystycznych w celu zwiększenia pozycji SEO – z oryginałem publikacji, który został udostępniony za darmo przez wydawcę możemy zapoznać się tutaj. Rozważmy teraz, jakie inne konsekwencje może nam przynieść taki atak – oraz czy istnieje możliwość jego dostosowania do dzisiejszych systemów statystycznych.

Dzisiaj używając Google Dorków również możemy znaleźć listę systemów opartych o Webalizer (site*.*.*/webalizer intitle:"Usage Statistics"), czy AWStats (allinurl:"awstats.pl?config=") i wstrzykiwać w te systemy “szkodliwe” linki. Na początek naszym celem będzie udoskonalenie metody przedstawionej przez Pawła, ponieważ wysyłanie tych samych żądań z tego samego adresu IP, z tym samym user agent może spowodować, że nasz link nie zostanie zauważony w systemie statystycznym choćbyśmy wysłali na raz 1000 żądań – może zostać ono zakwalifikowane jako jedno unikalne. Dlatego do naszego eksperymentu będziemy potrzebować dwie listy. Pierwszą będzie lista serwerów proxy, która zapewni nam różne adresy IP. Drugą będzie lista ciągów aplikacji klienckich. Posiadając te dwie listy możemy je ze sobą połączyć i użyć podczas demonstracyjnego ataku.

Lista otwartych serwerów HTTP proxy nie jest trudna do zdobycia. Wystarczy wpisać w wyszukiwarkę: Free proxy list, aby otrzymać listę do ściągnięcia. Oczywiście mimo bardzo dużej ilości adresów IP ich jakość pozostawia wiele do życzenia. Większość z nich nie obsługuje jeszcze HTTPS, który jest już standardem, o HTTP/2 nie wspominając. Bardzo duża część z nich również staje się nieresponsywna nawet po nawiązaniu połączania, a te które działają są wpisane na listę blokad np. w takich serwisach jak Cloudflare, za którym chowa się już większość witryn. Na szczęście część z tych niedogodności możemy pokonać poprzez ustawienie odpowiednich limitów czasowych na różne etapy połączeń czy wymuszenie korzystania z protokołu HTTP 1.1. Możemy również zainwestować niedużą kwotę i uzyskać “bardziej” jakościową listę, ale to również nie daje nam gwarancji, że część z jej adresów nie znajduje się na listach blokad, z których korzystają WAF‘y. Demonstracyjną listę agentów liczącą 10.000 pozycji możemy ściągnąć z serwisu WhatIsMyBrowser. Stwórzmy teraz prosty skrypt, który wykorzysta powyższe listy. Na początku musimy przygotować je jako dane wejściowe:

# Dodajemy znak potoku "|" na końcu każdego wpisu z adresem IP:
sed 's/$/|/' freeproxy.txt > ips.txt
# Łączymy dwa pliki w jeden "obok siebie":
paste ips.txt useragents.txt > all.txt
# Ucinamy listę w miejscu, gdzie tylko łączą się adresy IP i User Agent:
cat all.txt | grep '|' > filtered.txt
# Usuwamy białe znaki po potoku "|"
sed 's/|[[:space:]]/|/' filtered.txt > fullset.txt

Po tych zabiegach powinniśmy otrzymać listę w formacie:

118.172.207.XXX:8080|Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) ...
183.89.154.X:8080|Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) ...
77.94.123.XX:43205|Mozilla/5.0 (X11; Linux x86_64) ...
193.178.249.XXX:5836|Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) ...
88.255.217.XX:8080|Mozilla/5.0 (iPhone; CPU iPhone OS 8_2 like Mac OS X) ...

Sam skrypt – referer.sh – jest bardzo prosty i bazuje na potężnym narzędziu do komunikacji HTTP – curl:

#!/bin/bash

file="set.txt"

while IFS="|" read -r ip useragent
do
  curl -v --connect-timeout 5.0 -m 10.0 -x "https://$ip" -A "$useragent" \
  -e "https://elemelek.pl/elemelek.html" -L -s --http1.1 $1 > /dev/null
done < "$file"

Iterując przez połączoną listę adresów IP proxy oraz identyfikatorów agentów łączymy się za każdym razem z tym samym celem poprzez różne serwery proxy i wysyłamy inny ciąg dla aplikacji klienta:

root@darkstar:~# ./refferer.sh https://statspoisoning.pl/

Na ile atak jest skuteczny? Otóż testowym celem była strona, którą chronił wspomniany dostawca WAF - zestaw danych wejściowych składał się z 8098 pozycji - tylko 319 dotarło do logów, które system statystyczny przeliczył w kolejnym dniu. Pozwoliło to wskoczyć zatrutej pozycji na trzecie miejsce. Im większy ruch na atakowanej stronie tym trudniej jest się przebić do TOP 10 w sekcji Referer. Przykład ataku bazował na "ułomnych" systemach statystyk, które analizują tylko logi serwerów WWW. Co z bardziej zaawansowanymi systemami, które bazują na plikach ciasteczek oraz skryptach JS? Cóż w tym wypadku wystarczy zastąpić curl, czymś bardziej przeglądarkowym:

chrome --headless --disable-gpu --user-agent="Mozilla/5.0 (X11; Linux x86_64)" \
--proxy-server=http://X.X.X.X:8000 --screenshot --window-size=1280,1696 \
https://nfsec.pl/

Podsumowując: Atak HTTP Referer Spoofing możemy wykorzystać do zatruwania fałszywymi wpisami publiczne dostępne systemy statystyczne - pozycjonując w nich naszą stronę. W skrajnych przypadkach możemy doprowadzić do sytuacji, w której osoby przeglądające statystyki zaintrygowane nową pozycją "generującą" duży ruch na stronie klikną w odnośnik, który będzie prowadził do spreparowanej strony atakującej jej przeglądarkę.

Więcej informacji: Zasada Polecającego, Tere fere Referer(e)