Hacking Party Sopot
W minionym tygodniu, dzięki niesamowitym zbiegom okoliczności oraz wsparciu ze strony Ateny, odbyła sie w Sopocie konferencja pt. “Hacking Party”.
Prelegentem był Michał Sajdak. Na początku opowiedział historię powstania konferencji. “Hacking Party”, jak nazwa wskazuje, na początku odbywało się w stylu warsztatowym – całodzienne warsztaty w grupie 30-40 osób. Michał chciał jednak przekazywać więcej wiedzy, a równocześnie zwiększyć ilość uczestników i tak “Hacking Party” przerodziło się w konferencję. Druga edycja, która odbyła się w zeszłym roku w Krakowie, zgromadziła ponad 300 osób.
Ta mini-konferencja, jakby prolog do tegorocznej edycji w Krakowie, była podzielona na 2 części: “Testy bezpieczeństwa – teoria a praktyka” i “Hackowanie IoT”. Obie równie interesujące.
Testy bezpieczeństwa – teoria a praktyka
Często zdarza się, że konfigurujemy serwer pod daną aplikację, a później o nim zapominamy. Albo dorzucamy różne interfejsy webowe (np. do podglądu bazy). Potencjalna osoba szukająca dziur w całym, może skorzystać np. ➔ z wyszukiwarki Reverse IP, aby sprawdzić czy faktycznie na danej maszynie mamy tylko jedną, dedykowaną aplikację, czy może ktoś o czymś zapomniał.
Potencjalną luką w bezpieczeństwie mogą też być rózne pozostałości po testach funkcjonalnych aplikacji. Zostawione testowe konta, zostawienie katalogów .git/.svn albo pozostawienie zakomentowanych danych testowych na produkcji ( ➔ How I could hack internet bank accounts of Danish largest bank in a few minutes).
Natomiast jeśli tworzymy API, powinniśmy pamiętać, żeby nie tylko sprawdzić poprawność tokena, ale również czy Klient ma na pewno dostęp do danych, które zostały przekazane. W innym wypadku może się okazać, że zrobi ➔ przelew z dowolnego konta w banku na własne.
Zostawienie debuggera na produkcji bardzo ułatwia życie programistom i pozwala testować aplikację na prawdziwych danych oraz ruchu. Ale w ten sposób może wyciec spora ilość danych ( ➔ Patreon w 2015 roku stracił ~ 15 GB).
Na koniec – pamiętajmy, aby wyłączać wszelkie nieużywane przez nas usługi oraz rozszerzenia. W innym wypadku może się okazać, że mamy dziurę, która dostępna jest od… 18 lat. Takim przykładem jest ➔ Shellshock, gdzie przez sprytnie ustawionego User-Agent podczas requestu, można było wgrać shella jeśli tylko korzystaliśmy z CGI. W przypadku rozszerzeń chyba najpopularniejszym przypadkiem jest zostawienie domyślnych ustawień dla XML w naszym web-serverze (np. jBoss / Tomcat). Z tego powodu otwieramy furtkę na ➔ XXE (XML eXternal Entities).
Hackowanie IoT
Urządzeń IoT (Internet of Things) jest coraz więcej, a wszystkie mają dostęp do Internetu. Często oparte są o system Linux wraz z odpowiednią konsolą administracyjną (routery, kamery IP itp.). I najczęściej dziurawe są wspomniane panele. Najpopularniejszym przykładem jest zostawienie kodu używanego w produkcji w urządzeniu docelowym – Archer C2, który miał zostawiony backdoor w programie httpd, przez który ➔ można było wgrać dowolny program (automatyczny wget, chmod +x, oraz wykonanie). I można to było zrobić bez żadnego uwierzytelnienia. W kilkanaście minut można było zdobyć dostep do shella, do którego nie ma dostępu nawet właściciel urządzenia. W urządzeniach TP-Link niestety wadliwie był zabezpieczany również dostęp do panelu administracyjnego. Niektóre żądania były “podpisane” tylko nagłówkiem Referrer zamiast Basic-Auth. W ten sposób można było w kilku miejscach zmienić konfigurację urządzenia lub uruchamiać polecenia w powłoce.
Konkurencyjne D-Linki również nie są bez skazy. W urządzeniach DSP-W215 bez problemu można było wykorzystać błąd przepełnienia buforu i uzyskać władzę nad urządzeniem.
Dlatego pamiętajmy, aby w czasie produkcji urządzenia lub oprogramowania pamiętać o stosownym zabezpieczeniu transmisji, żądań, dobrych algorytmach, jak również przejrzeć pamięci dyskowe czy nie zawierają pozostałości po procesie wytwarzania. W innym wypadku ktoś może Wam ➔ za pomocą telefonu porwać… Jeepa (hasło do Wi-Fi bazujące na czasie + otwarte, źle skonstruowane usługi).
Dlaczego?
Zastanawiacie się, po co zabezpieczać domowe urządzenia? Albo przykładać większą wagę w czasie wytwarzania oprogramowania? Przecież po co komu dostęp do shella w naszym routerze? Dlatego, że za chwilę te urządzenia mogą posłużyć przeciwko Tobie – np. do wielkich, zmasowanych ataków DDoS.
Ostatnio z takim atakiem zmagało się ➔ OVH, które “przyjęło” na siebie ruch od 145 607 kamer/DVR z przeróżnych części świata i adresacji IP. Całe szczęście atakujący nie wykorzystał pełnej mocy ataku, który został przez OVH oszacowany > 1.5 Tbps.
