Kirjaudu

Uutiskirje

Rekisteröidy Sektoriin ja tilaa itsellesi joko aamuisin tai iltaisin ilmestyvä uutiskirje sähköpostiisi.

Keskiviikko, 22.10.2003

Top 20 haavoittuvuudet verkottuneissa tietokoneissa

Yhdysvaltojen, Kanadan ja Iso-Britannian turvallisuusministeriöt ovat yhdessä SANS-tietoturvainstituutin kanssa määritelleet kaksikymmentä yleisintä haavoittuvuutta verkottuneissa tietokoneissa. Windows-, Unix- ja Linux-haavoittuvuuksien Top20-lista edustaa kansainvälistä näkemystä siitä, mitkä kriittiset haavoittuvuudet tietokoneista tulisi paikata, jotta saavutetaan hyväksytty minimitietoturvataso.

SANS on julkaissut Top10-listaa haavoittuvuuksista vuosittain jo kolmen vuoden ajan. Uusi Top20-lista on käytännössä vain Windows- ja Unix/Linux-haavoittuvuuslistojen yhdistetty versio. SANS-instituutin mukaan ylivoimaisesti suurin osa vuosittain tehtävistä tietoturvahyökkäyksistä kohdistuu listalla mainittuihin haavoittuvuuksista kärsiviin palveluihin. SANS antaa verkkopalvelussaan myös ohjeita, miten Top20-listan haavoittuvuuksilta voi suojatua tai ainakin haavoittuvuusalttiutta voi pienentää.

Yleisimmät haavoittuvuudet Windows-järjestelmissä liittyvät:
1) Internet Information Server (IIS) -palvelinohjelmistoon
2) Microsoft SQL Server -tietokantaohjelmistoon
3) käyttäjäautentikaatioon ja salasanoihin
4) Internet Explorer -selaimeen
5) etäkäyttöpalveluihin (Windows Remote Access Services)
6) datan käsittelykomponentteihin (Data Access Components - MDAC)
7) Windows Scripting Host toiminnallisuuteen
8) Outlook ja Outlook Express -sähköpostiohjelmiin
9) P2P-tiedostonjako-ohjelmiin
10) SNMP-verkonhallintaprotokollaan


Yleisimmät haavoittuvuudet Unix/Linux-järjestelmissä liittyvät:
1) BIND-nimipalvelinohjelmistoon
2) RPC-etäprosedoorikutsuihin
3) Apache-webpalvelinohjelmistoon
4) käyttäjäautentikaatioon ja salasanoihin
5) salaamattomiin verkkopalveluihin (mm. telnet, ftp)
6) Sendmail-sähköpostipalvelinohjelmistoon
7) SNMP-verkonhallintaprotokollaan
8) SecureShell (SSH) -etäkäyttöohjelmistoon
9) vääriin NIS/NFS-palvelujen asetuksiin
10 openSSL-salauskirjastoon

Lue juttu oma, 22.10.2003 00:06. Lähde: SANS, ComputerWorld
Rekisteröidy ja kirjaudu sisään, jos haluat kommentoida.

Kommentit ( 6 uutta / 6 )
pistettä.
Näytä vain kommentit joilla on vähintään
RPC windowsissa
Anonyymi kommentoija, 23.10.2003 10:49:45
Pisteet: 0
Niin pisti ihan ihmetyttämään miksei tuolla Windows-listalla ole tuota RPC mainittu. Eikös nämä uusimmat madot ole iskenyt juuri sinne puolelle? Vai johtuuko tämä jostain muusta? Sanokaa nyt joku viisas tähän jotain.
heko Re: RPC windowsissa
heko, 23.10.2003 12:23:05
Pisteet: 0
Niin pisti ihan ihmetyttämään miksei tuolla Windows-listalla ole tuota RPC mainittu. Eikös nämä uusimmat madot ole iskenyt juuri sinne puolelle? Vai johtuuko tämä jostain muusta? Sanokaa nyt joku viisas tähän jotain.
W5: Windows Remote Access Services: [...] Remote Procedure Calls
--
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
Datamike Luulin turvallisiksi
Datamike, 22.10.2003 09:01:43
Pisteet: +1
Tuo Windows lista nyt ei ollut mikään ihme, enkä yllättynyt siitäkään että unix/linux listakin löytyi, mutta tosta ko. listasta pisti silmään apache, ssh, ja openssl; luulin näitä turvallisisiksi. Erityisesti ssh ja openssl yllättivät. Käytän itse hyvin paljon ssh:ta, mistä oli sellainen mielikuva että kyseessä on erityisen turvallinen softa. Oma host ei edes salli muun käyttöä ja pomo sanoo että turha yrittää meidänkään palvelimelle ilman ssh:ta. Ssl:ä taas näkee siellä ja täällä, taitaa jopa Sektorikin käyttää tossa salatussa kirjautumisessa juuri ssl-salausta.

Apache:sta en sinänsä yllättynyt, kyseessähän on softa jonka tehokkuuden määrittää täysin ylläpitäjän kyvykkyys. Mutta jos tällaisissa softissa, joita on aina pitänyt turvallisina, on suuria tietoturvaaukkoja, niin mikä eteen. Miten tällaiseen pitäisi suhtautua. Onko mikään enää turvallista?
"Given enough eyeballs, all bugs are shallow."
Re: Luulin turvallisiksi
Anonyymi kommentoija, 22.10.2003 10:01:12
Pisteet: +1
öytyi, mutta tosta ko. listasta pisti silmään apache, ssh, ja openssl; luulin näitä turvallisisiksi. Erityisesti ssh ja openssl yllättivät. Käytän itse hyvin paljon ssh:ta, mistä oli sellainen mielikuva että kyseessä on erityisen turvallinen softa.
Tokihan salattu liikenne on turvallisempaa kuin salaamaton. Kuitenkin nyt vähän aika sitten openssh palvelinohjelmistosta löytyi haavoittuvuus, jonka kautta onnistui pääkäyttäjänä sisäänkirjautuminen ilman salasanaa. Eli vaikka itse yhteys olisikin turvallinen, ne ohjelmat ei välttämäti ole.
Lisäksi käyttäjiä pitäisi muistuttaa siitä että sokeasti ei kannata luottaa salauksiin, on vain ajan kysymys milloin ne saadaan murrettua. Joko lievän haavoittuvuuden takia tai raa'an voiman avulla.
feenix Re: Luulin turvallisiksi
feenix, 22.10.2003 09:13:36
Pisteet: +1
(Tämäkin lista on melkolailla ikivanha, mutta hyvä että tuli tännekin vihdoinkin. Ensimmäisessä näkemässäni versiossa WSH oli kylläkin UNIX-puolelle laitettu ;)

Tuo Windows lista nyt ei ollut mikään ihme, enkä yllättynyt siitäkään että unix/linux listakin löytyi, mutta tosta ko. listasta pisti silmään apache, ssh, ja openssl; luulin näitä turvallisisiksi. Erityisesti ssh ja openssl yllättivät. Käytän itse hyvin paljon ssh:ta, mistä oli sellainen mielikuva että kyseessä on erityisen turvallinen softa.
Ei, esimerkiksi openssh:ssa on ollut vähän väliä jotain vikoja, eikä kaikkia kai vieläkään ole korjattu "oikein", kunhan on estetty. Yksi ongelma tuossa on openssl, joka myöskin on vähän niin ja näin tehty (kryptausta jatkuvasti työssään käyttävä ystäväni pitää tuota yhtenä huonoimmista kryptototeutuksista...). Myös itse ssh-protokollassa on ollut puutteita, jotka ovat aiheuttaneet ainakin teoreettisia ongelmia.

Apache:sta en sinänsä yllättynyt, kyseessähän on softa jonka tehokkuuden määrittää täysin ylläpitäjän kyvykkyys. Mutta jos tällaisissa softissa, joita on aina pitänyt turvallisina, on suuria tietoturvaaukkoja, niin mikä eteen. Miten tällaiseen pitäisi suhtautua. Onko mikään enää turvallista?
Ei ole, eikä ole ikinä ollutkaan. Se on ensimmäinen asia joka tietoturvaa mietittäessä pitää ottaa huomioon. Kaikissa ohjelmissa on puutteita. Kaikki voidaan murtaa, jos käytettävissä on rajattomasti resursseja ja varsinkin aikaa. Siksi pyritäänkin vain sellaiseen tietoturvaan, jonka murtaminen järjellisessä ajassa on hyvin hankalaa. Muutenhan käyttäisimme äärettömän hitaita kryptauksia, muutamaa miljoonaa bittiä avaimissa jne. Se ei vain tällä hetkellä ole järkevää, kun pienemmätkin avaimet vaativat konetehoa vuosiksi ja data monesti on vuosien päästä jo vanhentunutta. Ja tietysti ollaan jo siinä vaiheessa menty metsään, jos huippusalaista tietoa on päässyt edes kryptattuna muiden käsiin.

Apachen turvattomuutta lisää myös monet lisämodulit, joissa voi olla aukkoja ja näihinhän itse Apachen tekijät eivät voi paneutua. (kunhan paneutuisivat edes tekemään Apachesta itsestään sellaisen, ettei se vain segfaulttaile jos jokin on vähänkin pielessä...)

Sinänsä lista on selkeästi koottu reikien vakavuuksien mukaan. SQL Serverissä ei kauheasti reikiä ole ollut, mutta vakavuus on eri asia.
Lada Mikä mättää
Lada, 22.10.2003 03:22:52
Pisteet: 0
"Top20-lista edustaa kansainvälistä näkemystä siitä, mitkä kriittiset haavoittuvuudet tietokoneista tulisi paikata, jotta saavutetaan hyväksytty minimitietoturvataso."
Viimeinen sana minimitietoturvataso, tarkoittaneee varmaan kun uusin versio/uusin päivitys on asennettu, silloin saavutetaan minimi. En mitenkään halua olla ikävä asian suhteen. Mutta kun puhutaan niinkin kriittisestä asiata, kuin käyttöjärjestelmä, tietokoneista jotka ovat "kaikkialla kaiken aikaa, kaikkien kanssa" erästä suomalaista firmaa siteeraten.
Ei pitäisi olla mahdollista, että joku pääsee sanomaan valtaosan koneista olevan minimitietoturvatason ylittävällä tasolla.

Miksi näin on ei varmaankaan, huomatkaa mututuntua, johdu pelkästään softista vaan enneminkin käyttäjistä.
Eli uskon vakaasti, kokemukseni pohjalta, vian ja minimitietoturvatason alapuolisen olevan selkänojan ja näppäimistön välissä.

... korjaan päivällä öistä ajatusvirtaani jos tulee jotain pahasti mietittyä pieleen.