Hacking Party Sopot
W październiku 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 obdył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 (admin / admin), 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. Takim 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 WiFi 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.
Autor: Speednet Sp. z o.o.