20:53
6/10/2011

Pewien internauta chciał poinformować American Express o błędach bezpieczeństwa jakie znalazł w ich serwisie. Niestety, nie był w stanie z nikim się skontaktować (kontakt telefoniczny i tradycyjna poczta “nie wydały mu się dobrym sposobem komunikacji”). Postanowił więc, że błąd opisze na swoim blogu. Zadziałało… po 16 godzinach.

American Express, jak zgłosić błąd?

Zanim jednak Niklas Femerstrand zdecydował się na full disclosure i opublikowanie szczegółów błędu na swoim blogu, zapytał American Express o możliwość kontaktu przez Twittera. Tam dowiedział się, że jeśli nie jest klientem, to nie może wysłać im e-maila ;)

A na czym polegał błąd? Pod adresem https://www.americanexpress.com/us/admin/ znajdowały się ciekawe dane (dostępne bez uwierzytelnienia):

American Express Admin

American Express Admin

Ale nie myślcie, że developerzy American Express to patałachy! O nie! Oni się zabezpieczyli… Jak? Wykluczając powyższy URL w pliku robots.txt

User-agent: *
Disallow: /us/admin/
Disallow: /us/heroes/
Allow:

To nie koniec. Narzędzia do debugowania były dostępne dla każdego (parametr ?debug=true) i dziurawe — pozwalały na XSS w dowolnej części serwisu.

Przy okazji, kiedy inny internauta zadzwonił do American Express i zgłosił w/w błąd bezpośrednio, usłyszał, że nie musi się niczym przejmować, bo wszystkie dane są bezpieczne ponieważ są przesyłane przez HTTPS… Double facepalm? ;-)

Responsible Disclosure

Naiwność developerów American Express to jedno, ale podejście Niklasa to drugie. Telefon to zły sposób na zgłoszenie błędu!? Oczekiwanie, że zgłoszenie incydentu bezpieczeństwa zostanie przyjęte przez Twittera? Nieumiejętność znalezienia kontaktu w bazie WHOIS? Mamy dziwne wrażenie, że ktoś tu po prostu chciał publicznie pokrytykować American Express (krytyka jak najbardziej zasadna, ale sposób pozostawia trochę do życzenia). Zdecydowanie polecamy podejście Responsible Disclosure.

P.S. Jak widać nie tylko Polacy lubują się w głębokim ukryciu. Na naszych szkoleniach z atakowania i ochrony webaplikacji często pokazujemy przykłady całkiem sporych, serwisów, które pomimo wielu zgłoszeń dalej udostępniają swoje panele administracyjne lub inne funkcje debuggowania całemu światu… I to chyba prędko się nie zmieni…

Przeczytaj także:

16 komentarzy

Dodaj komentarz
  1. Nie no, zaraz. Napisałeś, że jak zadzwonił, to mu powiedzieli, że wszystko spoko, luzik. Jak chciał wysłać mejla, to mu powiedzieli, że skoro nie jest klientem, to nie może. Więc co tu się dziwić, że mu się cierpliwość wyczerpała i opisał sprawę na blogu? Ja rozumiem, że zacytowane przez Ciebie słowa “nie wydały mu się dobrym sposobem komunikacji” były efektem nieudanych prób wykorzystania wspomnianych kanałów, a nie z góry powziętą rezygnacją. Nie tak?

    • Przy okazji, kiedy *inny* internauta zadzwonił do American Express…

    • Qlawy, racja, mój błąd! Tak, czy owak, trudno tłumaczyć takie rzeczy przez telefon. No i jeśli nasz bloger wiedział o tym telefonie zanim napisał notkę, to wciąż – w moim przekonaniu – usprawiedliwia to jego niechęć do tej formy kontaktu.

  2. Ehh. znowu olewanie.. czemu ludzie tacy są ? Jakby nie olewali nie było by tylu problemów :/

  3. Już myślałem, że błąd z robots.txt jest czysto teoretyczny, a tu takie zaskoczenie, i to jeszcze w tak “poważnej” firmie.
    To jest ten szczebel co logowanie w js na jednym z serwisów gov.pl jakieś 2 lata temu.

  4. Przypuszczam, że autorowi artykułu chodziło o stare dobre wysłanie zgłoszenia na security@domena (dodam, że mejl wysłany na ten adres nie jest “odbijany”, więc prawdopodobnie adres istnieje), admin@domena, abuse@domena i bugs@domena – z doświadczenia mogę powiedzieć, że ten pierwszy adres zazwyczaj działa.
    Pytanie więc, czy Niklas faktycznie puścił bug report na te mejle, czy może zaczął od telefonu do supportu (support zazwyczaj nie ma pojęcia co to “security vulnerability”, ani kontaktu do devów) czy twittera (pół biedy, że nie blipa).
    Ale cóż, może Niklas chciał iść FD, a może security@ nie wpadło mu do głowy. Zdarza się.

  5. przypomina się stare porzekadło: “jesteś jak American Express – nikt cię nie akceptuje” :)

  6. A ja jestem ciekaw, czy ktoś jest w stanie powiedzieć co właściwie widać na tym screenie.

  7. To pewnie ciekawy dzień mieli w tym American Express ;-)

  8. Nie znam się, ale jak rozumiem poprzez ten plik robots.txt admin chciał zablokować pojawienie się strony w Google (i innych) ale z uwagi, że każdy może plik robots.txt przeczytać wklepując jego adres, to zdradził gdzie i jak głęboko ukryte są te ważne dane, wiec każdy mógł je ręcznie otworzyć?

    • Dokładnie.

    • tak, jest dokładnie jak napisałeś :)

  9. Raczej – wiedzieli że strona nie jest zabezpieczona to ukryli ją przed wyszukaniem w google. Pudrowanie gangreny.

  10. Z tego co się orientuję, do ukrywania katalogów przed wścibską publicznością służą pliki .htaccess a nie robots.txt!

    • .htaccess jest jakimś pomysłem, natomiast osobiście nie lubię tego rozwiązania – raczej jestem zwolennikiem trzymania panelu admina w innym miejscu (aka w innej domenie, etc), chociaż czasem ofc opcje są ograniczone.
      Również, przy migracji z apache na inne serwery http czasem się zapomni o konwersji jakiegoś tam .htaccess na odpowiednik wykorzystywany w innym serwerze i bug gotowy.

  11. American Express to nawet nie potrafi podać swojego adresu pocztowego na wyciągu. Weź takim później wyślij przelew jeśli bank wymaga jego podania :)

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.