Nie śmiej się dziadku z cudzego wypadku. CashBill się śmiał i sam tak miał

Życie jest najlepszym nauczycielem, a nauczki pojawiają się znienacka jak rozpędzony TIR na Twoim pasie wyskakujący zza zakrętu. Takiej nauki doświadcza własnie firma CashBill, która wczoraj śmiała się z Przelewy24.

Kilka dni temu opisaliśmy problemy z bezpieczeństwem wtyczek sklepowych, oferowanych przez platformę Przelewy24. Błędy znajdujące się w kilku z nich umożliwiały dostęp do danych zapisanych w bazach kontrahentów firmy a także dowolne modyfikowanie statusów zamówień złożonych w sklepach z nich korzystających. Okazuje się, że wtyczki konkurencji też nie są pozbawione błędów.

Niezbyt mądra reakcja CashBilla

Jeden z konkurentów Przelewy24, firma CashBill, postanowił zakpić z niefortunnej wpadki konkurencji wrzucając poniższy obrazek.

Jest to mocna aluzja do nocnej akcji Przelewy24, które ciężko pracowały, by naprawić błędy i jak najszybciej powiadomić swoich klientów o problemach. Tymczasem kilkanaście godzin po wpisie CashBilla jeden, z naszych czytelników, Mateusz, znalazł we wtyczce CashBilla dla platformy Magento trywialne błędy, pozwalające każdemu użytkownikowi na zmienianie statusów transakcji – zarówno swoich, jak i cudzych. Można było zatem zarówno oznaczyć wszystkie transakcje jako opłacone czy np. wszystkie anulować. Był to zatem błąd tej samej kategorii co te, które wcześniej znaleziono w platformie Przelewy24.

Mateusz w nocy z soboty na niedzielę przekazał zgłoszenie problemu „dyżurnemu programiście”, który kilka godzin później nawiązał kontakt ze zgłaszającym. W poniedziałek o 14:50 firma przekazała Mateuszowi, że zgłoszenie trafiło dalej i kolejny kontakt nastąpi, gdy zostanie przeprowadzona wnikliwa analiza. Kontakt nigdy nie nastąpił. Po kilku dniach okazało się, że na stronie jest już nowa wtyczka, a jej pliki posiadają znaczniki czasu wskazujące na modyfikację w poniedziałek około południa. Na stronie firmy nie znaleźliśmy też żadnej informacji o błędzie.

Krótka analiza błędu

Problemy znajdowały się w pliku

app/code/community/Platnosci/Cashbill/controllers/CashbillController.php

W serwisie Diffchecker znajdziecie porównanie kodu starej i nowej wersji wtyczki. Jak tłumaczy Mateusz, głównym problemem było zaimplementowanie logiki zmiany statusu zamówienia w publicznym kontrolerze w akcjach, które były publiczne, ale nie sprawdzały sygnatury transakcji. Należała do nich funkcja ustawiająca status zamówienia – zatem wpisanie odpowiedniego wywołania do przeglądarki mogło zmienić status z „oczekującego” na „zapłacone”. W funkcji zabrakło także sprawdzenia sygnatury (sprawdzanej na wcześniejszym etapie, omijanym przez bezpośrednio wywołanie). Co więcej, parametr „id” transakcji był pobierany z żądania GET – zatem można było zmienić status dowolnej transakcji, nie tylko swojej.

Aktualizacja 2017-11-13

Dotarło do nas oświadczenie firmy CashBill, które zamieszczamy w całości:

Informujemy, że opisany na łamach Państwa serwisu post na Facebooku był z naszej strony jedynie żartobliwym nawiązaniem do zaistniałej sytuacji. Nie mamy w zwyczaju pisania źle o konkurencji, a do błędów umiemy się przyznać. Nasza wtyczka do Magento nie była przygotowana przez naszych programistów, ale bierzemy za nią pełną odpowiedzialność – tak, był problem i został usunięty. Partnerów korzystających z tej wtyczki poinformowaliśmy o nowej, bezpiecznej :) wersji, którą można już pobrać z naszej strony.

Informujemy jednocześnie, że w wyniku opisanego błędu nie wyciekły żadne dane i żadna transakcja nie została błędnie autoryzowana/anulowana. Z wdzięczności za pomoc w rozwiązaniu problemu ufundowaliśmy książki o bezpieczeństwie aplikacji. Chcielibyśmy przekazać je osobom najbardziej zaangażowanym. Jedną z książek zostawimy dla siebie!

Popularna tendencja

Przy okazji ostatniej ogromnej wpadki OVH odezwały się kolejne firmy, które za dobry pomysł uznały podpieranie się porażkami konkurencji. Niektóre w prywatnej korespondencji (dlatego nie wskazujemy nazwy):

inne za to publicznie:

Do pociągu z logo #awariaOVH wsiadały nawet firmy z innych branż:

If your employer just went bankrupt because of #ovhdown you can always find a new one at @bulldogjob ? #AlwaysLookOnTheBrightSideOfLife

— Bulldogjob (@bulldogjob) November 9, 2017

Nauka płynąca z tego doświadczenia

Wszystkim autorom kodu, który obsługuje transakcje finansowe a nie przeszedł bardzo solidnego audytu bezpieczeństwa w renomowanej firmie (a najlepiej w dwóch) polecamy jak najszybsze zorganizowanie takiego procesu. Dlaczego jeden audyt nie wystarczy? Widzieliśmy ostatnio wyniki eksperymentu, w którym dwóch solidnych specjalistów sprawdzało niezależnie od siebie ten sam kod źródłowy. Każdy z nich znalazł inne błędy. Jeśli zatem Wasz kod dotyka pieniędzy, to nie oszczędzajcie na jego audycie – a oszczędzicie sobie wstydu a klientom kłopotu.

Bezpieczeństwo to jedna z wielu branż, w której można bardzo szybko uczyć się na błędach konkurencji. Zamiast się zatem z nich śmiać, warto sprawdzić swoje własne podwórko, ponieważ podobne kategorie błędów czy ataków często łatwo przenoszą się między firmami, branżami czy krajami. Dlatego tak ważne jest by każda szanująca się firma obserwowała  rynek i na bieżąco śledziła najważniejsze incydenty, a następnie je analizowała i weryfikowała, czy mogły się pojawić także we własnej infrastrukturze.

Jeśli nie macie ludzi i czasu, by śledzić najważniejsze wiadomości na rynku, to możemy pomóc – od kilkunastu miesięcy dostarczamy kilku firmom regularne raporty (zarówno tygodniowe jak i miesięczne), opisujące wszystko, co ważnego stało się w ostatnim czasie w branży bezpieczeństwa – w przekroju ogólnym lub sektorowym. Możecie w ten sposób zarówno weryfikować swoją wiedzę na temat istniejących ataków jak i budować świadomość bezpieczeństwa w zespołach administratorów. Lektura historii cudzych wpadek bywa bardzo pouczająca. Jeśli jesteście zainteresowani regularnym otrzymywaniem takich raportów to wystarczy do nas napisać.