SSH honeypot: nincs támadás?

Fórumok

Sziasztok,

úgy döntöttem, hogy játszom egyet: építettem egy SSH honeypotot ami minden jelszót és SSH kulcsot beenged és bevágja egy hálózat nélküli Docker containerbe. (Igen, ismerem a biztonsági oldalát, ezen kívül is vannak még védelmi mechanizmusok.)

A honeypot mindent fejlegyez, bináris szinten a különböző adatstreameket is, de végig fésülve kb két napnyi adatot, szinte kizárólag ilyeneket látok:


{"timestamp":"2019-03-14T00:58:54.679","sessionId":"LgnlsPWXPJUzMzBhRad1NxjIRXQ7SEvZaP1MG2MOjfw","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:5127","username":"admin","password":"admin"}}

Ezen kívül semmi. Nem kért shellt, nem küldött parancsot, semmi. Vagyis csak végig próbálják a jelszavakat, de semmit nem csinálnak vele. Ez miért lehet? Mi értelme ennek?

Köszönöm

Hozzászólások

Gondolom későbbi DDOS támadáshoz ez is elég :)

Miért jó ilyet csinálni?
Nézed, hogy hol tart a világ plusz foglalod a támadók erőforrásait, vagy miért?

Egy példa: Felteszel egy honeypot-ot egy(az összes) belső hálózati LAN-ba. És ha megtörnek egy gépet kívülről, és már benn vannak a LAN-ban el fognak kezdeni felderíteni pl. nmap-al hová lehet tovább lépni ssh/samba/rdp akármi protokollon. Ekkor ugye egy portscannel betalálnak a honeypotra is. És megy a riasztás a SIEM-be, vagy akár tűzfal szabály, switch port letiltás akármi lehet belőle.

Tipp #1: Én ha kormány/ddos célpont/cloudflare lennék, akkor folyamatosan scannelném az ipv4 címeket könnyen törhető célpontok után kutatva hogy esetleges támadás esetén ezeket a címeket blokkoljam.
Tipp #2: Valószínű van aki abból csinál pénzt, hogy felderíti ezeket a könnyű célpontokat és eladja a listát másoknak

ezek csak sima botok amik aldozatot keresnek. van egy ip lista (vagy csak lepkednek vegig a tartomanyokon), es nezik mibe lehet belepni. aztan lesz egy "hasznalhato gepek listaja", amit a rosszfiu elad vagy felhasznal tovabbi tamadaskor. nem egy ember es nem egyfelekeppen keresik az aldozatot.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Gyanítom az adott zombi gép csak ssh törési feladatot kapott, a sikeres belépéseket pedig vissza jelenti a központi rendszernek valami proxyn vagy más zombi gépen keresztül, aztán az majd kiadja a parancsot valamelyik másik zombinak később hogy az adott ip/login adatokkal álljon neki új zombikat gyártani.

Lehet hogy honeypot-nak érzékeli a bot, ha elsőre be tud jutni? False pozitív találatnál veszi és eldobja mint potenciális végpont.
Azóta volt másik próbálkozás?

Igen, volt olyan amelyik nemi elteressel ugyanazzal a usernevvel/jelszoval belepett tobbszor is:


{"timestamp":"2019-03-14T08:04:59.464","sessionId":"wmf22qayquHfcN8qzd+9kSARpVRQn3x7+Goqlv7y9xI","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:63031","username":"admin","password":"admin"}}
{"timestamp":"2019-03-14T11:20:18.892","sessionId":"cosCR-5tU3MnOAs89zdnhKUKvfVu0tfDDODNOuSKwFw","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:44877","username":"admin","password":"admin"}}
{"timestamp":"2019-03-14T15:34:35.429","sessionId":"nb7D+J+tmlc6bBncP7q68JF+Hn8CRS0EVSPOgaU2RUw","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:62626","username":"admin","password":"admin"}}
{"timestamp":"2019-03-14T06:37:58.961","sessionId":"D-S9j16WFlkI2isBXvfxvoq7l9WtwwDeN2dJzNlcP4g","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:37202","username":"admin","password":"admin"}}
{"timestamp":"2019-03-14T12:07:29.906","sessionId":"9fS3YEv4-ORAtdgkZu9DC+bGC8chQg5JzAsFHWmT2So","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:40883","username":"admin","password":"admin"}}
{"timestamp":"2019-03-14T13:36:41.45","sessionId":"Lt-NXiVfB3IZ6OfVMRQESDiixVXkgVrdE3WZpknbWAc","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:21716","username":"admin","password":"admin"}}
{"timestamp":"2019-03-14T09:50:36.28","sessionId":"ltn4OVC3MZlzqprZjHdHVc0eEWTFnUPI+GNw2f1s6CY","streamType":"EVENT","data":{"type":"login","ipAddress":"/195.3.147.49:6928","username":"admin","password":"admin"}}

A sorok nincsenek sorrendben sajnos.

--
Pásztor János

Ami meg erdekes: eleg sok bejelentkezes van "pi" usernevvel. Gondolom rpi-kre vadasznak, csak nem tudom miert.

--
Pásztor János

triviális a magyarázat: a gyári Raspbian lemezképen a nonroot de sudoer júzer neve pi a jelszava meg raspberry.

sok kis nokedli meg anélkül akasztja rá a világhálóra hogy ezt megváltoztatná, SSH meg ugye nyitva a huszonkettesen.

IIRC volt egy Monero bányász botnet ami kizárólag raspberryket fertőzött ezt a logikát követve.

"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."

Biztonság, de tök más téma:

Tudtok olyan browser plugin-ról ami azt figyeli egy oldal forrásában, hogy az authentikáció alatt van-e kliens oldali hash képzés?

Tehát, hogy plain textbe megy-e a jelszó az adott oldalon.

Ilyenről nem tudok, de ha létezne, akkor azért elég sok módszerrel át lehetne verni.

Nem HTTPS-es oldalon ne adj meg jelszót és kész! Ha HTTP, akkor úgyis buktad MITM lehetősége miatt, kivétel ha OTP-t (vagy tokent) használsz, de akkor is csak akkor, ha minden művelethez szükséges és biztonságos csatornán kapod a jóváhagyandó műveletet. De akkor meg mi értelme? Visszakanyarodtunk a HTTPS-hez :) Bár elméletben kiírhatna egy QR kódot, amiben benne van a művelet, majd beolvasod telefonnal és így látod a műveletet és annak a hash-ét írod alá és ezt adod meg mondjuk egy formon, így HTTP-n is lehet az oldal. Persze az időt is bele kell kódolni, hogy ne lehessen ismételni.

Nem ertem az egeszet. Mitol jobb az, ha hashselve kuldod? A WWW MD5 auth (amit SIP-nel is alkalmaznak) ugy mukodik, hogy kapsz egy noncet (mindig valtozik), amivel hashseled a jelszot es az megy el a szerver fele (csak a hash). A szerver ezutan a maganal clear textben tarolt jelszot szinten hashseli a nonceszal es ha egyezes van, akkor authentikal. Nesze neked hash!

Szerk:
Ráadásul azt sem tudod megállapítani, hogy a jelszó biztonságosan hashselve van elküldve. Lehet hogy szimmetrikus vagy nyílvános kulcsú titkosítással küldi el a script vagy direkt valami gyenge hasht alkalmaznak, hogy vissza lehessen fejteni. Ezt egy program nem tudja eldönteni.

Ha már jelszót kell megadni egy nem saját adminisztráció alatt lévő felületen (tehát nem nálad old fel valamit), akkor már eleve nincs biztonságban. Ezért használnak komolyabb helyeken tokent, SSH esetén PKI-t, HTTPS-en kliens oldali tanúsítványt, stb.. Ugye ezeket is fel kell oldani valami jelszóval vagy/és biometrikusan, de akkor már a te eszközöd biztonsága számít.

Annyiban jobb lenne, hogy ha a szerver vagy a http proxy biztonsága sérül és pl. logolni tudja valaki a https lekérdezéseket, akkor csak a hashelt jelszóhoz férne hozzá. (persze ez esetben megtehetné, hogy módosítja a hashelő js-t, de ez esetben a lebukás esélye nagyobb)

Jelenleg a pl. cloudflare elvileg megtehetné, hogy az összes rajta átfolyó jelszót lementi. Ha a jelszavak hashelve mennének át, akkor csak aktív javascript módosítás után.

Ja értem. Ha kizárjuk a MITM módosítást, akkor valóban lehet értelme.
Ekkor ha:
- találunk clear textben jelszót, akkor állíthatjuk hogy a jelszavunk nincs biztonságban, ha a csatornát 3rd party dekódolni tudja
- ha nem találunk clear textben jelszót, akkor semmit sem tudunk jelszavunk biztonságáról

Biztonság az nem 0/1 skálán mozog. Nem is olyan régen még standard volt, hogy titkosítás nélkül, http-n utazik a jelszó.

Ha kliens oldalon hashelődik a jelszó, akkor biztosak lehetünk benne, hogy nem clear text-ben (vagy md5-el hashelve) tárolódik a szerveren, egyébként csak meg kell bízni a szolgáltatást nyújtó cég becsület szavában.

Igazából nem látom hátrányát, hogy így a kliens oldalon hashelődjenek a jelszavak. (max egy kis extra cpu tekerés bejelentkezéskor)

"Ha kliens oldalon hashelődik a jelszó" -> ebben soha nem lehetünk biztosak (korábban írtam miért), tehát a mondat második feléről sem tudunk semmit
"egyébként csak meg kell bízni a szolgáltatást nyújtó cég becsület szavában." -> így is csak ennyit tehetsz, ugyanis ő bármikor cserélheti a szkriptet

"Igazából nem látom hátrányát, hogy így a kliens oldalon hashelődjenek a jelszavak."
Azért a sémán kicsit változtatni kell. Mert akkor a szerver oldalon hashB(hashA(jelszó,saltA),saltB),saltA,saltB lesz. A kliens oldalnak el kell küldeni saltA-t, hogy tudja generálni hashA(jelszó,saltA)-t és elküldeni a szervernek. Ezzel persze nem zártuk ki, hogy 3rd party ne tudjon belépni a szolgáltatásba, mert hashA(jelszó,saltA)-t ismerheti a támadó, ami elég az azonosításhoz, de tény hogy magát a jelszót, így nem látja és nem tudja felhasználni esetleg más helyen. Ha még bonyolítjuk és egy nonce-t is keverünk hozzá (és MITM módosítás lehetőségét kizárjuk), akkor még azonosításra sem tudja később felhasználni.

De hiába is ez az értekezés, mert minden a szolgáltatást nyújtó cégen múlik.

A szerveroldalon tárolhatod akárhogy a jelszót, meg a kliensen is lehet próbálkozni, de onnantól, hogy egy csomóan elmentik a kedvenc appjukban, már veszett történet bármi. Levelező fiók fronton a következőket láttuk:

- Jött a klasszikus dictionary próbálkózás, ahol mondjuk az alma@ fiókba az alma és alma123 szerű jelszavakkal próbáltak, és persze ügyes felhasználók sikerült is belépni. Láttunk olyan szervert, ahol a levelezést beállítóknak sikerült eleve ilyen remekül felvenni a jelszavakat. Aztán kaptak jelszópolicyt a nyakukba, illetve a rossz jelszavas fiókok letiltását, mert anélkül ezek szerint nem megy.

- A legnagyobb a sláger a kliens appokban tárolt jelszavak kinyerése és valamilyen zombigépekről rögtön utána a spammelés indítása. Gondolom a böngészős jelszavakat ugyanúgy kigyűjtik, ha az ember belementi, mint egy levelező kliensbelit. Innentől maga a kód és a jelszótárolás a feje tetejére is állhat, akkor is meg fogják szerezni a támadni szándékozók és pont a kliensről.

Hash ügyben leírták, hogy kevés hash-elve küldeni a jelszót, illetve nem szerencsés. Jelenleg ott járunk, hogy egy salted sha512-nél gyengébb, de lehet már az is, elég hamar visszafejthető. Látok olyan levelező szervert is, ahol DES-től (igen) kezdve van mindenféle jelszó hash. Hiába írtak a felhasználóknak, akkor esetleg pattintsanak egy új jelszót, mert jó lenne nem a 10+ éveset használni, a 200+ kövületből olyan 10-en reagáltak a 2.-3. email környékén (látszott a hash változás, meg a módosítás ideje).

Miért ne tudnák? Megjegyzik az előző N darab jelszavad hash-ét, a jelszóváltáskor meg végigfutnak rajta és megnézik, ugyanazzal az algoval/salttal/beállításokkal ugyanarra mappel-e az új jelszó...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Kliensoldalon elkészíted a jelszót (ezt most 'abc123'-nak fogom nevezni), abból számolódik egy hash. Aztán számolsz hasht megadott patternek alapján, például:

'abc123'1 (tehát kivédjük a következőt: az előző jelszavad az volt, hogy 'abc1231', és most 'abc123'-at akarsz megadni)
'abc123'12
'abc123'123
'abc123'999

és visszafelé is:

'abc12' (tehát kivédjük a következőt: az előző jelszavad 'abc12' volt, és most 'abc123'-at akarsz megadni)
'abc1'

...és így tovább, a lehetőségek végtelenek. Majd elküldöd a szervernek az összes hasht, és a szerver eldönti, hogy ez a hash megegyezik-e valamely tiltott hash-sel ('kiskutyafüle' után '12kiskutyafüle123', de akár 'Kiskutyafüle123' is lehet - már amennyiben egy ilyen patternt is írtál). Fontos megjegyezni, hogy ha időbeli sorrendben ilyen jelszavaid voltak:

'abc'
'kiskutyafüle'
'mustáros_fagyi'
'xyz'

és most szeretnél egy 'abc123'-at, akkor kliensként fogalmad sem lesz róla, hogy a pattern alapján elkészített, majd beküldött 'abc' hasht a szerver el fogja-e dobni, ezért muszáj kiszámolni, és valóban beküldeni elbírálásra.

(disclaimer: soha nem készítettem még ilyen rendszert, és nem hinném, hogy a gyakorlati életben hasznos lenne egyáltalán)

----------------------------------
szélsőségesen idealista, fősodratú hozzászólás

Na akkor sorban:
* lentebb már megbeszéltétek, hogy semmi értelme nincs, mert innentől kezdve az auth tokened a hash lesz és simán működik a pass-the-hash (lásd még: Windows-os authentikáció)
* ha ezt te az oldal _forrásában_ akarod megnézni, akkor alaphangon meg kell oldanod a megállási problémát (megáll-e egyáltalán a JS kód, ami a form submitkor lefut) és fel kell ismerned _minden_ hash algoritmust (md*, sha*, bcrypt, ...), kapcsolódó módszert (salting, nonce használata, ...), hash reprezentációt (bináris, hexa ASCII, ...) stb. (sok sikert)
* ha mondjuk a kicsit vállalhatóbb megoldást csinálod és a form submitjakor kezded figyelni, hogy az elküldött form-on van-e jelszó mező, aminek az értéke szerepel-e a mezők között... már előrébb vagy, de ezt is triviális átvágni (pl. hozzácsapom a jelszót a usernévhez és kivágom a jelszó mezőt valamelyik event handlerben)

És ezzel az egésszel annyit értél el, hogy minden belépéskor kapsz egy figyelmeztetést, hogy jajúristenmindnmeghalunkplaintext!!!négy! (pl. hupolni se tudnál :( ), mert én pl. nem is tudnék mondani olyan oldalt fejből, ahol ne a plaintext jelszó menne át (illetve egyet igen, valamelyik géniusz kitalálta, hogy egy HTTPS felett kiszolgált oldalon zseniális lesz az oldal forrásában kiküldeni egy RSA kulcsot, amivel lekódolja a kliens oldali JS a jelszót submitkor - már ha lefut, mert a plaintext jelszót is elfogadja a rendszer, de még ha nem is fogadná el, akkor sincs semmi értelme, mivel 1) fix kulcsot használ és 2) HTTPS felett megy, tehát aki a plaintext jelszót látta volna, az tudja módosítani a kulcsot, mielőtt kiadja a sajátjára és tudja a plaintext jelszót is MITM-özni... de gondolom valaki jó sokat fizetett ezért a feature-ért, hogy ki lehessen pipálni, hogy de milyen ügyes crypto-t használ a rendszer...).

Szerk.: sőt, kifejezetten káros is lehet a biztonságra, mivel innentől kezdve nem tudnál betartatni a jelszó erősségére vonatkozó előírásokat.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Lentebb is meg lett beszélve, hogy lenne értelme: passzív MITM ellen véd, illetve a cég így bizonyíthatná, hogy nem clear text-ben tárolja a jelszavakat.

> sőt, kifejezetten káros is lehet a biztonságra, mivel innentől kezdve nem tudnál betartatni a jelszó erősségére vonatkozó előírásokat.

Ezt (remélhetőleg) minden oldal eddig is kliens oldalon végezte, így nem lenne változás.

passzív MITM ellen véd,

Ez a megtörik a proxy-t use case? Ha igen, akkor továbbra sem védett semmi ellen, mert a tényleges auth token ott van a támadó kezében.

illetve a cég így bizonyíthatná, hogy nem clear text-ben tárolja a jelszavakat.

Ez az egyetlen "előnye" (csak vedd hozzá az _implementációval_ járó összes hátrányt)...

Ezt (remélhetőleg) minden oldal eddig is kliens oldalon végezte, így nem lenne változás.

Wut? És a kliens oldal küldött egy flaget, hogy "égre-földre esküszöm, hogy igaz minden előírás a jelszóra" és a szerver ezt (értsd: felhasználói inputot) simán elfogadta? Vagy ezt így hogy?

Remélhetőleg kliens oldalon azonnali feedbacket adott a usernek és elmondta, mi a baj, de utána a szerver leellenőrizte és nem hitt el semmit bemondásra a kliensnek. Mert amelyik oldal _bármit_ elhisz bemondásra, az máshol is el fog, és törhető lesz.

(de egyébként is: valaki linkeljen már egy oldalt, amelyik jelszavakat kliens oldalon hashel)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> Ez a megtörik a proxy-t use case? Ha igen, akkor továbbra sem védett semmi ellen, mert a tényleges auth token ott van a támadó kezében.

Az adott oldalra valóban beléphetnek, de hashelés nélkül az összes oldalra beléphetnek, ahol az user ezt a jelszót használta. Szerintem nyugodtan feltételezhetjük, hogy az userek 90+%-a ugyanazt a jelszót használja a legtöbb oldalra. A jelszó hashelt tárolásának is ez az egy oka van.

> Wut? És a kliens oldal küldött egy flaget, hogy "égre-földre esküszöm, hogy igaz minden előírás a jelszóra" és a szerver ezt (értsd: felhasználói inputot) simán elfogadta? Vagy ezt így hogy?

Ha valaki gyenge jelszót akar használni, és ezért hajlandó a kliens oldali javascriptet megváltoztatni...hát legyen. Egyébként használhatja "1q2w3e4r5t" -t is jelszónak ami valószínű megfelel a legtöbb oldal előírásának mégis egy dictionary based attack esetén ott lesz az első 50 próbálkozásban.

Az adott oldalra valóban beléphetnek, de hashelés nélkül az összes oldalra beléphetnek, ahol az user ezt a jelszót használta. Szerintem nyugodtan feltételezhetjük, hogy az userek 90+%-a ugyanazt a jelszót használja a legtöbb oldalra. A jelszó hashelt tárolásának is ez az egy oka van.

Fasza, de eléggé szűk a köre a hash algóknak (és jó esetben a randombt.hu nem talál ki saját kriptót... ugyebár). Vagyis ha ugyanazt a jelszót használja, akkor lesz kb. 5 kategóriányi oldal, amik közül az egyik kategóriába (ahol ugyanaz a hash van) a törött proxyból kiszedett "már-nem-jelszó-de-újra-jelszó"-val be lehet lépni.

Ha a leakelt jelszavak újrafelhasználása ellen akarsz védekezni, akkor használj jelszókezelőt és mindenhol random jelszót. Vagy mindenhol TFA-t/MFA-t. Vagy valami id szolgáltatót (google, facebook, ...).

--

Egyébként abban kiegyezhetünk, hogy a G legalább időnként figyel arra, hogy távolról védhető legyen az auth rendszere, igaz? Akkor ők miért plaintext jelszót küldenek loginkor, ha "dehátahasheltbiztonságosabb"?
És továbbra is: tudtok akár csak egy oldalt mondani, ami kliensoldalon hasheli a jelszót?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem kell tobb hash algoritmust hasznalni ahhoz, hogy kulonbozzon.

De, különben az egyetlen különbség a salt lehet. Így meg oda kéne adnod a fiók-specifikus salt-ot a kliensnek, ezzel leakelve azt az infót, hogy az a fiók használt -> csökkent a biztonság (Innentől ügye nem állíthatod, hogy hibás felhasználóinév _vagy_ jelszó) [vagy site-specifikus salt, de az meg bad practice, mert az így leakelt tábla utána (site-specifikus, de akkor is) szivárvány táblával törhető]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

szerintem meg csak gyujtogetik, esetleg eladjak.
webmail-eken talalkoztam olyannal, hogy egyszercsak elkezdtek spammelni 1-1 accountrol minden elojel nelkul, majd a logokat visszakeresve kiderult hogy 2-4 hettel korabban beleptek mar egy orosz ip-rol egyszer es 1db teszt mailt kuldtek, benne az user jelszavaval. ott is ez lehetett, hogy az egyik banda hozzafereseket gyujtott, majd eladta azt egy masiknak, aki hetekkel kesobb elkezdett spammelni vele (tok mas ip-rol es orszagbol).

Nekem is elment rá egy csomó időm, mire sikerült működőképessé tenni, de ahogy elnézem, most nem stimmel valami, mert a weboldalon én teszt belépésem az utolsó, amit még éjfél után csináltam. Azóta semmi.
Most tettem egy próbát megint: szépen be is engedett, tehát az a rész működik. Kiváncsi leszek, a weboldalon is meg fog-e jelenni.