Lis
12

URL Redirection, a Google

autor: p____h  //  ::easy::, Security

URL Redirection to patrząc z poziomu security technika dość niepożądana. Wykorzystując zaufanie do danej witryny, możemy przemycić w którymś z parametrów adres do zewnętrznej strony (ze złośliwym oprogramowaniem, czy nawet wersją stworzoną przez phisingerów). Byłoby nadużyciem, gdybym stwierdził, że popularna wyszukiwarka Google bugi typu URL Redirection ma – ale na pewno warto przyjrzeć się pewnemu, bardzo podobnemu do niego mechanizmowi.


Odkąd w Google pojawiło się wyszukiwanie w czasie rzeczywistym i wyniki wyświetlają się jeszcze przed kliknięciem w „Szukaj”, chyba większość zapomniała o buttonie „Szczęśliwy traf” [„I’m Feeling Lucky” w wersji oryginalnej]. Po kliknięciu przenosiło nas na pierwszą w wynikach stronę, która pasowała do wpisanego przez nas zapytania. Wyłączmy obługę JavaScript (i tym samym wyszukiwanie w czasie rzeczywistym) w naszej przeglądarce i spróbujmy się przyjrzeć co tak naprawdę wysyłane jest do serwera.
GET /search?sclient=psy-ab&hl=pl&site=&source=hp&q=microsoft&btnI=Szcz%C4%99%C5%9Bliwy+traf HTTP/1.1
Okazuje się, że za przekierowanie odpowiada parametr btnI. Zerknijmy jeszcze dla pewności:
http://google.pl/search?q=microsoft&btnI
Rzeczywiście, przenosi nas na odpowiednią stronę. Oczywiście zapytanie w parametrze q można próbować zamaskować, chociażby za pomocą URL Encodingu: /search?q=%6d%69%63%72%6f%73%6f%66%74&btnI.

Czyżby okazało się, że wystarczy stworzyć stronę, na którą chcemy przekierować i wypozycjonować ją pod jakimiś finezyjnymi słowami (tak, aby w jak najszybszy sposób osiągnąć pierwszą pozycję w wyszukiwarce pod daną frazą)? Okazuję się, że jest jeszcze jeden warunek. Parametr btnI nie zawsze zadziała, gdy będziemy przekazywać go bezpośrednio przez link. Kliknijcie tutaj. Powinno przenieść nas na bloga, którego właśnie czytasz… a nie przeniosło. A teraz kliknijcie w tym miejscu. Tym razem zadziałało.

Co się właściwie stało? Zrobiłem dość sporo testów i okazuje się, że przenoszeni będziemy tylko na strony, których PageRank jest większy niż 2. W pozostałych przypadkach sprawdzany jest wartość HTTP_REFERER (klikając w I’m Feeling Lucky jest on ustawiony na adres wyszukiwarki Google). Wygląda na to, że oprócz wypozycjonowania strony na pierwsze miejsce należy zapewnić jej PageRank o wartości przynajmniej 3. Czy da się to zrobić szybko? To już pytanie do ludzi zajmujących się SEO (w tym black-SEO). Niezależnie od odpowiedzi ja i tak dmuchałbym na zimne i wysyłał btnI metodą POST.

  

11 komentarzy to “URL Redirection, a Google”

  • „Wygląda na to, że oprócz wypozycjonowania strony na pierwsze miejsce należy zapewnić jej PageRank o wartości przynajmniej 3”
    Albo ustawic Referer na google, a przecież referer da się zmienić łatwo.

  • referer da się zmienić łatwo

    Tu się zgodzę, da się zmienić łatwo – ale pomyśl i powiedz w jaki sposób chcesz zmienić go w sposób niezauważalny. Intruz, który będzie chciał podesłać Ci tego typu link poprosi Cię najpierw o ustawienie http_referera?

  • Może np. zrobić stronę, na której umieści takie linki do google z przekierowaniem i na tej stronie napisać skrypt, który zmieni referer: header(‚Referer: http://google.pl‚);

  • OK, tylko, że po kliknięciu w link na tej stronie http_referer ulegnie zmianie (jego wartością nie będzie już to co ustawiliśmy, a adres strony, z której kliknęliśmy link) – stąd bez ingerencji użytkownika nie ma to prawa zadziałać (a zmuszenie kogoś, aby nieświadomie zmienił http_referer jest w tym przypadku raczej niebanalnym zadaniem)

  • @granatnik
    Mam wrażenie, że pomyliłeś Request Header z Response Header. Funkcja header() w PHP ustawia Response Header, a p____h pisze w swoim artykule o Request Header.

    Ad meritum
    Zachęcam do rzucenia okiem na stronkę Google Vulnerability Reward Program (http://www.google.com/about/corporate/company/rewardprogram.html), a konkretniej na ten fragment (zaznaczenie moje):

    –CYTAT–
    URL redirection

    URL redirection is considered a vulnerability by some members of the security community. The most prevalent argument made in support of this view is that some users, when presented with a carefully crafted link, may be duped into thinking that they will be taken to a trusted page – and will be not be attentive enough to examine the contents of the address bar after the navigation takes place.

    That said, it is important to recognize that *the address bar is the only reliable content origin indicator available in modern browsers* – and therefore, the behavior that would enable URL redirection attacks is inherently unsafe. The panel believes that any user who could be misled by a URL redirector can also be tricked without relying on any particular trusted website to act as a relying party; eliminating URL redirectors will not change this outlook appreciably.

    […]
    –KONIEC CYTATU–

    I faktycznie, powinno patrzeć się na adres strony po przejściu na nią, a nie na status bar, nazwę linku, etc. Zresztą, historycznie patrząc, była masa sposobów na „spoofowanie”/”obfuskowanie” linku na które nieuważni userzy się „nabierali”, np (od najtrywialniejszych):

    http://good.com
    http://good.com
    http://good.com@evil.com
    http://0x12345678/good.com
    http://good.com
    http://good.com
    etc…

    Są również sytuacje w których link najzwyczajniej w świecie nic nie mówi (np. w przypadku tzw url shortenerów).

    Tak więc nie o to chodzi, że redirectory są jakieś złe czy coś, tylko że linkowi i tak nie należy ufać 🙂

  • O, widzę że system komentarzy zinterpretował niektóre moje linki. Interesujące 🙂
    Anyway, w drugim przykładzie a href zawierał akcje onclick= która miała przekierowywać do evil.com

  • Warto jeszcze pamiętać o oryginalnej (już poprawionej) podatności w silniku JAVA, który wykorzystując OpenRedir mógł doprowadzić do ujawnienia Cookies:

    http://sla.ckers.org/forum/read.php?2,35422,page=1#msg-35454

  • Błąd ciekawy – i pewnie znalazłoby się jeszcze kilka pozycji w bugtraqu, które warto podlinkować – ale w tym poście skupiłem się głównie na zjawisku, które zauważyłem sam ;>
    Anyway, dzięki za link, bo nie spotkałem się jeszcze z tą podatnością (a może spotkałem, tylko nie pamiętam, błąd był poprawiony ok. rok temu ;>)

  • Hmm, skoro już tak uogólniamy, to przypomniało mi się pewne (wydawałoby się wzorcowe) zabezpieczenie przed open redirect, którym się bawiłem.
    Wyglądało na to, że programista ładnie stablicował sobie listę dozwolonych URL’i (whitelist), a przy linkach typu:
    http://good.com/?url=http://evil.com
    , wypluwał komunikat:
    Uwaga, strona próbuję przekierować Cię na http://evil.com

    Celem ataku było ominięcie zabezpieczenia i przekierowanie na stronę spoza whitelisty.
    Okazało się, że zrobić da się to mniej-więcej tak:
    http://good.com/?url=http://<script>window.location="http://evil.com"</script>

    Chyba każdy domyśli się, czemu to zadziałało ;>. Piszę „mniej-więcej”, bo opis trochę uprościłem (jak znajdę czas, to może opiszę trochę dokładniej jak to wyglądało w jakimś poście).

Dodaj komentarz

*

Audio-CAPTCHA