Maanantai, 25.2.2002
Poliisi tutkii laajaa tietomurtosarjaa
Poliisi pidätti kaksi 18-vuotiaista helsinkiläistä miestä viime tiistaina epäiltynä Suomen tähän asti laajimmasta tietomurtorikoksesta. Nuorukaisten epäillään tunkeutuneen noin 140 000 yrityksen ja yhteisön tietojärjestelmiin Suomessa ja ulkomailla. Pidätyksen yhteydessä poliisi takavarikoi kotietsinnässä epäiltyjen tietokoneet.
Ylen tv-uutisten mukaan epäillyt ovat murtautuneet Suomessa lukuisten tunnettujen yritysten tietojärjestelmiin ja mm. muuttaneen Internet-sivuja ja lukeneet sähköposteja. Suomessa asianomistajia on tuhansia, joten vahingonkorvausvaatimukset saattavat nousta erittäin suuriin lukemiin. Poliisin tutkinta koskee vain kolmen kuukauden ajanjaksoa viime vuoden loppupuolelta lähtien.
Nuorukaisten motiivina oli jännityksen hankinnan lisäksi tietoturva-alan ammattilaisten huijaaminen sekä arvostuksen saaminen kräkkeripiireissä. Rikoksen toteutustavasta ei ole vielä kerrottu yksityiskohtia, mutta varmaa on, että suuressa osassa tietomurtoja on käytetty apuna skriptejä, jotka automaattisesti käyvät läpi palvelimista löytyviä reikiä.
K2, 25.2.2002 00:37. Lähde: YLE
Muita aiheeseen liittyviä uutisia
Anonyymi kommentoija, 25.2.2002 01:16:23
Tuntuu vähän siltä kun yle olisi ottanut yhteyttä nimeltä mainitsemattomiin tietoturvaasiantuntijoihin, jotka ovat puolestaan maalailleet kuvia saatanasta seinille. Tosin pitää kai niidenkin yritysten työntekijöiden ansaita rahaa vuokraan ja ruokaan.
Anonyymi kommentoija, 25.2.2002 01:59:12
heko, 25.2.2002 05:01:39
CERT VU#13877 ja #945216 ovat exploitattavimmat (vaikka edellisenkin alkuehdot ovat verraten tiukat kovin laajaan skripteillä exploittamiseen); #19124 vaatii lokaalin tunnuksen, #596287 vaatii massiivista verkon ja laskentakapasiteetin kuormitusta, #684820 on man-in-the-middle, #850440 on Solaris-spesifinen ja vaatii sniffausta, #737451 vaatii, että salasanalla disabloidulla tunnuksella on (eksplisiittisesti muutettu) validi shelli, #363181 vaatii X-enabloidun yhteyden ja että _palvelin_ haluaa oikeuden asiakkaan X:ään, #565052 vaatii sniffausta, #786900 vaatii korruptoitunutta DNS:ää, #25309 vaatii asiakkaan eksplisiittisesti vaativan RC4-salausta ja hyökkääjän pääsevän käsiksi istuntoon, #315308 samoin (ja lisäksi vain viimeistä blokkia streamissa voi muuttaa), #797027 koskee melko vähän käytettyä OpenSSH:n versiota ja sallii vain tiettyjen PAM-spesifisten resurssirajoitusten kiertämisen, #118892 on #363181:n toisinto ssh.com:n ssh:lle, #665372 vaatii sniffausta ja on käytettävissä rajoitetun ajan, #905795 vaatii, että olemassaoleva private key on tiedossa (tai tyhjä!?), #655259 vaatii legitiimin pääsyn koneeseen, #40327 ja #157447 on UseLogin-spesifisiä ja vaativat legitiimin pääsyn koneeseen.
Näistä mikään ei vaikuta olevan skripteillä exploitattavissa 140 000 kohteeseen; skripteillä voidaan toki yrittää murtautua 140 000 kohteeseen ja saada aikaan lokientryjä. Heikoimpana linkkinä pidetään yleisesti CRC:tä, (#13877 ja #945216), ja näitä yritetään myös aktiivisimmin exploitata. Osa näiden reikien ympärillä pyörivästä kohusta johtuu juuri niiden exploittausyrityksistä, jotka tuottavat verraten paljon liikennettä ja lokientryjä silloinkin, kun ne eivät onnistu. SSH1-protokollan ja erityisesti RC-algoritmien disabloimisesta on puhuttu nyt n. neljä vuotta, ja suurin osa toiminnassa olevista implementaatiosta myös mahdollistaa tuon disabloinnin tai vaatii eksplisiittisen enabloinnin http://www.openssh.org/usage/ssh-stats.html). Järjestelmän päivityskään ei vaadi kuin palvelinpään päivityksen (kaikki järjelliset asiakassoftat osaavat muitakin kuin CRC-pohjaisia salauksia), joka ei maksa useimmissa tapauksissa (lue: maksaa yrityksille, jotka pyörittävät SSH-daemonia ei-vapaassa käyttöjärjestelmässä ja jotka eivät halua käyttää OpenSSH:ta, n. 500 dollaria / palvelin) kuin vähän aikaa.
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
rosmo, 25.2.2002 14:13:29
"I love deadlines, especially the whooshing sound they make as they go by."
heko, 25.2.2002 20:23:39
Puhuin "RC-_algoritmeista_" viitaten ssh.com:n parjattuun ssh1:n RC4:ään (openssh:n ARC4 / ARCFOUR ("alleged rc4") on varsin kelvollinen RC4-yhteensopiva implementaatio), ja "CRC-pohjaisella _salauksesta_" viitaten nimenomaan ssh1-protokollan toimintaan, johon liittyy crc:hen pohjautuva pakettien integriteetin tarkistus. Kumpaakaan ei kannata IMO käyttää jos sen vaan voi välttää. (SSH1:ssä ei siis ole vaihtoehtoa CRC:n käytölle sinällään, mutta myöhemmissä versioissa on paikattu aiempien CRC-versioiden onkelmia; ja tietysti SSH1:n voi disabloida kokonaan; RC4 taas on kokonaan CRC:stä riippumattakin varsin kehnosti toteutettu).
Salausalgoritmeihin CRC32 ei tietenkään kuulu mutta esim. SSH1:n funktionaalisuuteen se minusta kyllä erottomattomasti; datan on oltava sekä "autentikoitua" että "eheää".
ssh1:n RC4 oli ensimmäinen algoritmi, jonka myötä CRC:n ongelmia ylipäätään tajuttiin ruveta ihmettelemään (siinä on kyllä CRC:stä riippumattomiakin ongelmia). Sittemmin toinen crc-pohjainen ongelma havaittiin ssh1:n IDEAssa. OpenSSH:n mitään versiota nämä RC4- ja IDEA-spesifit ongelmat eivät oikeastaan koskekaan, koska kumpaakaan algoritmia ei koskaan hyväksytty OpenSSH:hon, toisin kuin ssh.com:n SSH1:een (edellisen implementaatio todettiin turvattomaksi, jälkimmäinen taas on patentoitu). IDEA ja RC4 eivät ole fiksuja algoritmeja pitää yllä SSH1:ssä, jos ko. protokollaa ja ssh.com:n implementaatiota ylipäätään tarvitsee.
Sittemmin ssh1/CRC havaittiin ongelmalliseksi kaikissa ssh1:n tukemissa cfb- ja cbc-modeissa käytetyissä block cipher algoritmeissa (== des, 3des, blowfish, idea eli kaikki muut kuin rc4, joka on stream cipher-pohjainen; en tajua, miksi alkuperäinen core sdi:n deattack-teksti väittää, että sitä voisi käyttää c{fb,bc}-modessa..). Palvelimen ja asiakkaan välissä oleva osapuoli saattaa käyttäen hyväkseen tiettyjä CRC32:n heikkouksia tietyillä edellytyksillä kiertää salauksen.
Core-SDI kehitti tätä varten ns. deattackin, joka valitettavasti toi enemmän murheita muassaaan kuin alkuperäinen CRC32-reikä (joka oli murrettavissa vain tietyin edellytyksin) itsessään. Se sisälsi ylivuodon, joka mahdollistaa paljon vapaammissa olosuhteissa komentojen suorittamisen SSH1-palvelimessa SSH1-daemonia ajavan käyttäjän (yleensä root) oikeuksin.
SSH:n protokolla kaksi ei ole koskaan ollut riippuvainen CRC:sta, koska siinä käytetään ykköstä vahvempaa ratkaisua tarkistukseen (MAC).
OpenSSH 2.3.0 ja SSH 2.4.0 ovat paikanneet deattackin reiän, ja noita versioita vastaan on olemassa vain lähinnä - itsepintaisia - huhuja murtautumisesta SSH1:n läpi. Aiemmatkaan versiot ssh2:sta eivät ole exploitattavissa jos ei ssh1:ta pidä lainkaan päällä.
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
rosmo, 26.2.2002 16:04:22
En ole aivan varma mikä tuo ARCFOUR-ongelma SSH1:ssa on?
SSH-palvelimien roottailu siis perustuu tuon deattack-osion reikään, joka tehtiin korjaamaan tuota ongelmaa. Onneksi OpenSSH:n myötä ei ole juuri syytä käyttää kaupallisia SSH-palvelinsoftia.
"I love deadlines, especially the whooshing sound they make as they go by."
heko, 27.2.2002 12:33:41
Unixeissa tavalliset ``cksum'' ja ``sum''-utilityt käyttävät yleensä hyväkseen nimenomaan crc:ta (joka löytyy myös POSIX.2:sta, vaikka ensimmäiset AT&T:lta perityt implementaatiot käyttivät heikompaa tarkistusalgoritmia), mutta nykyään suositeltavampi tapa on kyllä md5 (vielä suositeltavampi lienee sha1, mutta siitä ei löydy kovin monesta järjestelmästä ainakaan komentorivityökalua). (Man-sivulta: ``Do not use cksum or sum to detect hostile binary modifications. An attacker can trivially produce backdoored daemons which have the same CRC as the standard versions. Use a cryptographic checksum (such as MD5) instead.'')
SSH1:n RC4:llä salattua dataa on kohtuullisen helppo ulkopuolisen murtaa, jos saa kaapattua ja toistettua yhteyden http://www.kb.cert.org/vuls/id/565052); kaapatun yhteyden saa toistettua http://www.kb.cert.org/vuls/id/665372); ja paketteja pystyy muokkaamaan ilman että CRC huomaa sitä http://www.kb.cert.org/vuls/id/25309). Viimeinen on siis spesifinen RC4/CRC-yhdistelmälle.
http://www.ssh.com/products/ssh/cert/vulnerability...
RC4 on defaulttina disabloitu uudemmista ssh, inc.:nkin versioista protokollan 1 kanssa, ja RC4:n disabloiminen vanhoissa versioissa on ssh, inc.:n omakin suositus.
"ARC4:n" ja "RC4:n" eroissa täytyy myöntää olleeni siinä mielessä väärässä (ja tarkemmin ajatellen luonnollisesti olen, koska alkuperäinen ssh ei vapaana voinut käyttää rsa:n implementaatiota), että ssh.inc ei koskaan ole käyttänyt RSA:n kauppasalaisuudeksi luokittelemaa alkuperäistä RC4:ää, vaan Usenetista 95 poimittua "arc4:ää". OpenSSH käyttää toista ARC4-implementaatiota OpenSSL:n läpi (OpenSSL:n implementaatio väittää pohjautuvansa '94 nyyssipostaukseen, ja koodia tutkailemalla vaikuttaa kovasti erilaiselta kuin ainakin SSH:n alunperin käyttämä, tosin OpenSSL:n koodin lukeminen sen optimoinnin tason takia on välillä vähän ikävää). Itse asiasta eli RC4-implementaation soveltuvuudesta ssh1:n kanssa käytettäväksi olin sen sijaan sentään käsittääkseni oikeassa.
Sekoittaakseen asioita lisää OpenBSD-OpenSSH käyttää ARC4:ää yhteyden salauksen lisäksi satunnaislukujen generoimiseen RandomStaten sijaan arc4randomia, joka taas on arc4:n läpi ajettu satunnaislukugeneraattori. Tämä arc4 on taas "Applied Cryptography"-opuksesta johdettu OpenBSD:n C-kirjaston implementaatio, jota on vielä arc4randomia varten muutettu niin, että se ottaa huomioon tilaa initialisoidessaan ajan.
OpenSSH ei ole koskaan tukenut RC4:n käyttöä protokollan yksi kanssa (.inc:n implementaatio poistettiin parissa ekassa revisiossa ennen ensimmäistä julkaisua) - ei nykyisissäkään versioissa ("Ciphers" on ssh2-spesifinen optio). (Klaientissa koodi on tosin hieman hassua, kutsutaan ciphers_valid()ia ja jos se palauttaa NULLin, cipher on validi ssh1-cipheri; muuten asetetaan options.cipher = SSH_CIPHER_ILLEGAL :- )
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
heko, 26.2.2002 10:46:39
Erityisesti tuossa artikkelissa miellytti se, että deraadt julkisti vihdoin, että seuraavan Solariksen version mukana kulkee myös OpenSSH:sta johdettu SSH-implementaatio. Ainakaan itse en muista aiheesta vielä muualta kuulleeni. Eräässäkin konferenssissa ihmeteltiin, miksei sitä löydy Solariksesta vieläkään defaulttina (vaikka sen sunfreewaresta saakin helposti, olettaen tietysti että koneeseen on root-oikeudet).
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
Anonyymi kommentoija, 25.2.2002 07:19:06
Vai nykyäänkö on top-50-listat siitäkin, keiden skriptit käy häkkäämässä automaattisesti jonkun firman webistä etusivun. Missä siitä on se hauska...
.samuli
Anonyymi kommentoija, 25.2.2002 11:07:28
Anonyymi kommentoija, 25.2.2002 16:10:23
Siis, mitä tunkeutumista se on jos mun tekemä mato tai vastaava viritys käy haistelemassa joitain portteja. Ennen se oli häkkeröintikin oikea harrastus kun modeemilla piippailtiin suoraan mainframeen.
.samuli
Anonyymi kommentoija, 25.2.2002 08:33:33
Anonyymi kommentoija, 25.2.2002 16:16:26
Anonyymi kommentoija, 25.2.2002 16:41:10
Suosittelen asioiden selvittämistä ennen kuin kirjoittaa tollaisia lapsuksia tänne Sektoriinkaan!
Anonyymi kommentoija, 28.2.2002 09:21:14
Suosittelen asioiden selvittämistä ennen kuin kirjoittaa tollaisia lapsuksia tänne Sektoriinkaan!
Anonyymi kommentoija, 26.2.2002 10:08:46
wolvie, 25.2.2002 17:41:29
Anonyymi kommentoija, 25.2.2002 12:15:48
Artikkeli ei ole kovin asiantunteva mutta kyllä siitä selviää että scriptikidit taas asialla :)
Anonyymi kommentoija, 26.2.2002 13:49:29
Datamike, 25.2.2002 14:42:54
Anonyymi kommentoija, 26.2.2002 03:10:33
Suoemn rikoslaki 38 sanoo näin:
8 § (21.4.1995/578) Tietomurto. Joka käyttämällä hänelle kuulumatonta käyttäjätunnusta taikka turvajärjestelyn muuten murtamalla oikeudettomasti tunkeutuu tietojärjestelmään, jossa sähköisesti tai muulla vastaavalla teknisellä keinolla käsitellään, varastoidaan tai siirretään tietoja, taikka sellaisen järjestelmän erikseen suojattuun osaan, on tuomittava tietomurrosta sakkoon tai vankeuteen enintään yhdeksi vuodeksi.
heko, 26.2.2002 22:52:36
Asialla on tietysti se valitettava toinenkin puoli: ylläpitäjinähän monissa yrityksissä on vähemmän juuri ylläpitoon ammattitaitonsa hankkinutta porukkaa, joka usein hoitaa järjestelmiä vain sivutoimisesti. En minäkään missään vaiheessa ole hinkunut ylläpitämään yhtään mitään järjestelmiä, mutta kummasti vain jonkun on niitäkin asioita ollut välillä pakko aika pitkäänkin hoitaa.
Järjestelmäylläpito ei muutenkaan ole varsinaisesti mitään herkkua - urakehitysnäkymät eivät useinkaan ole huimat; työajat voivat olla ikään kuin implisiittisesti "sulle voi soittaa milloin vaan jos kotikoneen näyttö on rikki" eikä kellään käy edes mielessä että ehkäpä haluaisit viettää sunnuntai-iltasi jotenkin muuten; työ voi olla väliin luonteeltaan melko puuduttavaa; ja ennen kaikkea muilta saatu arvostus - jopa "samalla alalla olevien" esim. ohjelmoijien - on väliin sitä sun tätä. Ja kun oikeasti ammattitaitoisista ylläpitäjistä on muutenkin pulaa, miten voi odottaa, että niitä tällä tavalla palkittuun työhön jonottaisi innoissaan päivittelemään SSH-daemoneita?
Usein tietoturvan ajatellaan rajoittuvan jonkin simppelin palomuurin hoitamiseen ja sähköpostivirusten skannaamiseen. Ajatellaan, että riittää, kun hoitaa ne turvattomimpien softien reiät "ensin" - eihän nyt turvallisuussyistä alunperin kehitetyssä softassa voi samantasoisia ongelmia olla!
Lisäksihän teon järjestelmällisestä toistamisesta pitkän ajanjakson aikana tuomitaan tietenkin suurempi rangaistus kuin yhdestä yksittäisestä kerrasta (vaikkei sakko kasvakaan esim. kahdesta kerrasta kaksinkertaiseksi).
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
Anonyymi kommentoija, 27.2.2002 01:07:05
raccoon, 26.2.2002 15:29:10
Minä en voi ymmärtää tätä.
Sananlasku kertoo, että tyhmyydestä rangaistaan. Tässäkin tapauksessa 'mukavalla' tavalla, oikein isän kädestä! Mahtaa heppuja ottaa nuppiin.
Anonyymi kommentoija, 3.3.2002 05:55:01