A Bash "Shellshock" sebezhetőség publikálása és aktív kihasználása óta

Titkosítás, biztonság, privát szféra

ellenőriztem, hogy a felügyeletem alatt lévő rendszerek érintettek-e, patcheltem (kézimunka)
12% (37 szavazat)
ellenőriztem, hogy a felügyeletem alatt lévő rendszerek érintettek-e, patcheltem (gyártó/szolgáltató által biztosított módon)
51% (152 szavazat)
ellenőriztem, hogy a felügyeletem alatt lévő rendszerek érintettek-e, még nincs konzerv-patch, várom a kiadását
2% (7 szavazat)
ellenőriztem, hogy a felügyeletem alatt lévő rendszerek érintettek-e, szerintem nem érintettek
2% (5 szavazat)
ellenőriztem, hogy a felügyeletem alatt lévő rendszerek érintettek-e, a gyártó/provider szerint nem érintettek
0% (1 szavazat)
próbáltam ellenőrizni, de a gyártó/provider még nem foglalkozott a problémával
0% (1 szavazat)
próbáltam ellenőrizni, de a gyártó/provider láthatóan nem érti a problémát, ami kiderült az általa kiadott hirdetményből
0% (0 szavazat)
nincs energiám ezzel foglalkozni (majd úgyis auto-update-el a rendszer)
9% (27 szavazat)
nincs energiám ezzel foglalkozni (majd valamikor kézzel updatelek, ha lesz patch, az is felmegy)
7% (21 szavazat)
egyéb / leírom / csak az eredmény érdekel / nem érdekel az egész
16% (49 szavazat)
Összes szavazat: 300

( siposa v | 2014. 09. 30., k – 08:40 )

(*) A BsaaS alapú rendszereken ellenőriztem, a többinél extra teherbírású rugós felfüggesztéseket alkalmaztam alacsony viszkozitású kenőanyaggal.

( Gyuszk v | 2014. 09. 30., k – 08:42 )

Csak saját használatú rendszereken (saját, munkahelyi, vps) van bash, így azokon a gyártó (Ubuntu, Debian, Arch) által biztosított update-eket felpakoltam, és kész.

--
arch,debian,windows,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

( manfreed (nem ellenőrzött) | 2014. 09. 30., k – 09:00 )

Van egy vps-em, oda felment a frissítés, és igazából ennyit tudok a dologról. Sajnos nem értek annyira hozzá amennyire szeretnék, és néhány stackexchange beszélgetésen kívül nem igazán találtam olyan leírást, ami nem a pánikkeltésről szól, vagy nem olyanoknak, akik ezen a szakterületen mozognak, szóval fogalmam sincs, hogy egyáltalán lett volna okom aggódni, vagy mi lett volna, ha nem frissítek.

( Dwokfur v | 2014. 09. 30., k – 09:05 )

ellenőriztem, hogy a felügyeletem alatt lévő rendszerek érintettek-e, patcheltem (gyártó/szolgáltató által biztosított módon ÉS kézimunka)

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( wyx v | 2014. 09. 30., k – 10:03 )

" felügyeletem alatt lévő rendszerek érintettek-e"

Fene tudja, felügyeletem alatt vannak e...

( szgabor | 2014. 09. 30., k – 10:05 )

A szerver előtti tűzfalra L7-be --> (/bin/bash -c), ráirányuló forgalom esetén DROP.

Uh, neked nem nagyon sikerült megérteni ennek a sebezhetőségnek a hátterét...

Még ha menne is "/bin/bash" string a hálózati forgalomban a hiba kihasználása során (de nem megy), akkor is elég lenne nálad két karakterrel kibővíteni az exploit payloadját, hogy bypassolva legyen a "védelmed": /bin/./bash

HTH

Nem a hibát akarom javítani, nem is tudnám, hanem addig meg akarom úszni a feltörést amíg ki nem javítják. Egyébként köszi a tippet, most már marad a (bash). Lehet variálni. Ha más módszert is találok (és még nem sikeres a próba) kap az is egy szabályt. Egyébként feljebb írtam hogy nálam edig hogy próbálkoztak.

Szerk.: A wget parancsot is eltávolítottam biztos ami biztos.

Ne tévesszen meg, hogy néhány balfasz script kiddie olyan lekéréseket küld, amiben szerepel a "/bin/bash"...

Egyébként is a feltörést így nem tudod megúszni, mivel láthatólag korábban látott mintákat próbálsz utólag kiszűrni. Itt nem működik az esemény utáni tabletta. Ha feltörhető ilyen módon a rendszered, akkor már feltörték. Most már hiába szűröd utólag.

A hiba kihasználásához meg nem kell feltétlenül a bash külön meghívása. Az erratasec scannere sem hívja meg: 


[25/Sep/2014:09:20:59 +0200] "GET / HTTP/1.0" 400 305 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"

A wget helyett meg szintén használhat bármi mást a támadó, ahogy a fentebbi példa is mutatja. Ha a ping megérkezik a támadóhoz, akkor tudni fogja, hogy kihasználható a hiba és előbb fogja megkerülni az L7 szűrésedet, mint te feleszmélnél a logok bogarászásából (remélem most nem állsz neki a ping stringet is szűrni, mert pont azt próbálom megértetni veled, hogy nincs értelme :).

Az olyan trükkökről már nem is beszélve, hogy a szűréseden át fognak menni a /bin/bash hívások továbbra is, ha néhány bytera fregmentált (és akár más sorrendben a géped felé továbbított) csomagokban utazik a payload.

Szóval ez a szűrés részedről csak a biztonság illúziója.

( Huncraft v | 2014. 09. 30., k – 12:26 )

Miert, van mar patch, ami az osszes eddig ismert CVE-t befoltozza? :)
-> CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ez alapján már van olyan amelyik mindegyiket elvileg foltozza:
https://access.redhat.com/solutions/1207723
Bár az, hogy az elmúlt 3 napban senki nem talált újabbat még számomra nem jelenti azt, hogy nem is fognak :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( Jason v | 2014. 09. 30., k – 14:39 )

egyéb: másik team foglalkozik ezzel.

( kroozo v | 2014. 09. 30., k – 14:49 )

A kollégák, akikhez beestek ezek, tekergetik a rendszereinket. Ami saját, azt tudtommal megpeccselik (nyilván ez függvénye annak, hogy most épp van e működő patch, vagy a CVEk állnak nyerésre), ami nem a mi kezünkben van, arra ha jól tudom folyamatban van a patch releaselése.

Mondjuk minket személy szerint nem nagyon érint, azokon a nodeokon, ahol tömegeknek van shellje ott eleve egy restricted shell van, és nem lehet remote commanddal megkerülni sshn, webes izék meg nem hivogatnak ilyesmit CGIn. Igazából szerintem egy kissé túl van ez lihegve sok esetben.

( hrgy84 | 2014. 09. 30., k – 15:44 )

A tamogatott rendszereket kizarolag a gyarto altal biztositott modon patchelem a teljes erteku tamogatas megorzese erdekeben, a mar nem tamogatott/outdated rendszereket megprobalom eloszor kulso (megbizhato) 3rdparty csomagokkal frissiteni, ha nem megy, akkor "kezzel" megpatchelem (de ilyenkor is probalok a rendszer csomagkezelojevel egyuttmukodni).
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( gee v | 2014. 09. 30., k – 16:04 )

Az általam felügyelt rendszerek egy részéhez már nem jönnek biztonsági javítások ki.

Jó lenne rendszert frissíteni valamikor, de mivel több éve nem sikerült ehhez időpontot egyeztetni, nem számítok arra, hogy most majd hirtelen sikerül.

( uid_6846 | 2014. 10. 01., sze – 13:25 )

Váratlanul kiderült, hogy mostmár (a megmondóemberek szavajárása alapján) nemcsak "Microfos"/"Winfos" létezik, hanem a felborogatható árnyékszékek lajstromába "Fingux" és "fOS X" rendszerek is feliratkoztak.

( sigellef | 2014. 10. 05., v – 14:39 )

Ellenőriztem, és rájöttem, hogy ez nem bug, hanem egy hasznos képessége (volt) a bash-nak...

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba