Internet in alarmfase geel wegens Debian OpenSSL-lek
Het Internet Storm Center heeft alarmfase geel voor het internet afgekondigd, nu er tools zijn verschenen die misbruik maken van een lek in Debian's OpenSSL-pakket. Dinsdag werd bekend dat alle SSH, SSL OpenVPN, DNSSEC sleutels die tussen september 2006 en 13 mei op Debian-gebaseerde systemen (Ubuntu, Kubuntu, etc) zijn gegenereerd, voorspelbaar zijn. De beheerder van het OpenSSL pakket had twee jaar geleden de code aangepast, met als gevolg dat voor gegenereerde sleutels maximaal 32.767 mogelijkheden zijn.
Beveiligingsonderzoeker en oprichter van het Metasploit project H.D. Moore heeft een script voor de kwetsbaarheid ontwikkeld. Daarmee kan, afhankelijk van de beschikbare rekenkracht, een aanvaller binnen een aantal uren alle mogelijke sleutels genereren. Moore had twee uur nodig voor het genereren van alle mogelijke 2048-bit RSA sleutels. In het geval van 32.767 16384-bit RSA sleutels was hij 100 uur bezig. Naast Moore zijn er ook andere brute force SSH exploits online verschenen. Deze exploits zouden een aanvaller binnen 20 minuten toegang tot kwetsbare servers moeten geven.
Alarmfase geel betekent dat er een nieuwe dreiging actief is, waarvan de gevolgen nog onbekend zijn of meevallen voor de infrastructuur. De gevolgen lokaal kunnen echter wel ernstig zijn. Gebruikers wordt daarom dringend aangeraden SSH-sleutels en SSL-certificaten opnieuw te genereren. Tevens heeft Debian een openssh-blacklist beschikbaar gesteld, waardoor SSH-servers geen kwetsbare sleutels meer accepteren. Het pakket bevat tevens een tool, ssh-vulnkey, die bestanden met zwakke sleutels zoekt. Deze tools kunnen echter ook door aanvallers worden ingezet.
Met dank aan Huub R. voor het melden van dit nieuws
Reacties (22)
16-05-2008, 10:36 door
spatieman
SSH op een andere poort laten draaien.
SSH over de firewall laten lopen, zodat alleen bepaalde
$gasten erin kunnen
SSH met kortere time out.
SSH met timedelay voor meerdere pogingen voor in loggen.
SSH over de firewall laten lopen, zodat alleen bepaalde
$gasten erin kunnen
SSH met kortere time out.
SSH met timedelay voor meerdere pogingen voor in loggen.
Door spatieman
SSH op een andere poort laten draaien.
SSH over de firewall laten lopen, zodat alleen bepaalde
$gasten erin kunnen
SSH met kortere time out.
SSH met timedelay voor meerdere pogingen voor in loggen.
SSH op een andere poort laten draaien.
SSH over de firewall laten lopen, zodat alleen bepaalde
$gasten erin kunnen
SSH met kortere time out.
SSH met timedelay voor meerdere pogingen voor in loggen.
Lapmiddel.
Gewoon de aanbevelingen van ICS opvolgen.
SSH met een certificaat (bv gegenereerd door PuTTYgen)
vergeet je maar even?
vergeet je maar even?
16-05-2008, 15:34 door
Nomen Nescio
Veilig he, dat Linux. Totaal geen aanvallen.
16-05-2008, 15:40 door
SirDice
Aangevallen worden we allemaal, dagelijks meerdere malen, (kijk maar eens goed in je logs) ongeacht welk OS je gebruikt.
Door spatieman
SSH op een andere poort laten draaien.
SSH over de firewall laten lopen, zodat alleen bepaalde
$gasten erin kunnen
SSH met kortere time out.
SSH met timedelay voor meerdere pogingen voor in loggen.
SSH op een andere poort laten draaien.
SSH over de firewall laten lopen, zodat alleen bepaalde
$gasten erin kunnen
SSH met kortere time out.
SSH met timedelay voor meerdere pogingen voor in loggen.
Er staat duidelijk op de website van Sans dat je iets anders
moet doen. Sommigen zouden eens een cursus lezen moeten volgen.
Door SirDice
Aangevallen worden we allemaal, dagelijks meerdere malen,
(kijk maar eens goed in je logs) ongeacht welk OS je
gebruikt.
Aangevallen worden we allemaal, dagelijks meerdere malen,
(kijk maar eens goed in je logs) ongeacht welk OS je
gebruikt.
Helemaal mee eens. Heb onlangs in de logs van IDS in de
router een tweetal aanvalletjes ontdekt (TCP_null).
Door SirDice
Aangevallen worden we allemaal, dagelijks meerdere malen, (kijk maar eens
goed in je logs) ongeacht welk OS je gebruikt.
Aangevallen worden we allemaal, dagelijks meerdere malen, (kijk maar eens
goed in je logs) ongeacht welk OS je gebruikt.
Niet mee eens. Dit is nu eens een typische aanval op Open Source: een 'lek'
verstopt, vol in het zicht van het publiek.
Dat is geen toeval maar een listig plan. Het lek zit er al ruim twee jaar. Naar
het lekken van dit soort informatie is veel onderzoek gedaan. Zoiets is geen
toeval maar opzet.
Door Nomen Nescio
Veilig he, dat Linux. Totaal geen aanvallen.
dat heeft nooit iemand met enige kennis van zaken gezegd. Veilig he, dat Linux. Totaal geen aanvallen.
Alarmfase geel betekent dat er een nieuwe dreiging
actief is, waarvan de gevolgen nog onbekend zijn of
meevallen voor de infrastructuur. De gevolgen lokaal kunnen
echter wel ernstig zijn.
dit leest als eenactief is, waarvan de gevolgen nog onbekend zijn of
meevallen voor de infrastructuur. De gevolgen lokaal kunnen
echter wel ernstig zijn.
behoorlijk matige vertaling.
vergelijk:
We are currently tracking a significant new threat. The
impact is either unknown or expected to be minor to the
infrastructure. However, local impact could be significant.
Users are advised to take immediate specific action to
contain the impact. (bron: http://isc.sans.org/infocon.html)
vooral dat stukje over meevallen vind ik wat matig vertaald
en het mag ook wel iets duidelijker zijn dat dat over de
inschatting en melding van isc gaat .
Redactie
Alarmfase geel betekent dat er een nieuwe dreiging actief
is, waarvan de gevolgen nog onbekend zijn of meevallen voor
de infrastructuur. De gevolgen lokaal kunnen echter wel
ernstig zijn. Gebruikers wordt daarom dringend aangeraden
SSH-sleutels en SSL-certificaten opnieuw te genereren.
met:Alarmfase geel betekent dat er een nieuwe dreiging actief
is, waarvan de gevolgen nog onbekend zijn of meevallen voor
de infrastructuur. De gevolgen lokaal kunnen echter wel
ernstig zijn. Gebruikers wordt daarom dringend aangeraden
SSH-sleutels en SSL-certificaten opnieuw te genereren.
We are currently tracking a significant new threat. The
impact is either unknown or expected to be minor to the
infrastructure. However, local impact could be significant.
Users are advised to take immediate specific action to
contain the impact. (bron: http://isc.sans.org/infocon.html)
vooral dat stukje over meevallen vind ik wat matig vertaald
en het mag ook wel iets duidelijker zijn dat dat over de
inschatting en melding van isc gaat .
Door Nomen Nescio
Veilig he, dat Linux. Totaal geen aanvallen.
Veilig he, dat Linux. Totaal geen aanvallen.
Omdat Debian/GNU-Linux open source is, gaf het mensen
de mogelijkheid de bron code te inspecteren en vond men dit
probleem dat nu is opgelost.
Bij closed source heb je geen idee of er een
probleem is dat misbruikt kan worden.
Door spatieman
SSH op een andere poort laten draaien.
SSH over de firewall laten lopen, zodat alleen bepaalde
$gasten erin kunnen
SSH met kortere time out.
SSH met timedelay voor meerdere pogingen voor in loggen.
SSH op een andere poort laten draaien.
SSH over de firewall laten lopen, zodat alleen bepaalde
$gasten erin kunnen
SSH met kortere time out.
SSH met timedelay voor meerdere pogingen voor in loggen.
hoewel het wel allemaal dingen zijn die helpen, laat je de
eigenlijke fout liggen. knap hoor!
Door Anoniem
Omdat Debian/GNU-Linux open source is, gaf het mensen
de mogelijkheid de bron code te inspecteren en vond men dit
probleem dat nu is opgelost.
Bij closed source heb je geen idee of er een
probleem is dat misbruikt kan worden.
Door Nomen Nescio
Veilig he, dat Linux. Totaal geen aanvallen.
Veilig he, dat Linux. Totaal geen aanvallen.
Omdat Debian/GNU-Linux open source is, gaf het mensen
de mogelijkheid de bron code te inspecteren en vond men dit
probleem dat nu is opgelost.
Bij closed source heb je geen idee of er een
probleem is dat misbruikt kan worden.
Het lek is twee jaar geleden er in gestopt, leuk hoor dat open source.
Bij closed source was een dergelijk lek er minder makkelijk ingekomen; het is
een erg domme fout die ruikt naar opzet. Bij closed source crypto producten
zoals die van RSA zit een certificering die het bewijsbaar veilig maakt.
Er is nog nooit een dergelijk lek gevonden in een closed source oplossing van
RSA.
17-05-2008, 17:24 door
Eghie
Door Anoniem
Het lek is twee jaar geleden er in gestopt, leuk hoor dat
open source.
Bij closed source was een dergelijk lek er minder makkelijk
ingekomen; het is
een erg domme fout die ruikt naar opzet. Bij closed source
crypto producten
zoals die van RSA zit een certificering die het bewijsbaar
veilig maakt.
Er is nog nooit een dergelijk lek gevonden in een closed
source oplossing van
RSA.
Er is nog nooit een lek daarin gevonden omdat het closedDoor Anoniem
Omdat Debian/GNU-Linux open source is, gaf het mensen
de mogelijkheid de bron code te inspecteren en vond men dit
probleem dat nu is opgelost.
Bij closed source heb je geen idee of er een
probleem is dat misbruikt kan worden.
Door Nomen Nescio
Veilig he, dat Linux. Totaal geen aanvallen.
Veilig he, dat Linux. Totaal geen aanvallen.
Omdat Debian/GNU-Linux open source is, gaf het mensen
de mogelijkheid de bron code te inspecteren en vond men dit
probleem dat nu is opgelost.
Bij closed source heb je geen idee of er een
probleem is dat misbruikt kan worden.
Het lek is twee jaar geleden er in gestopt, leuk hoor dat
open source.
Bij closed source was een dergelijk lek er minder makkelijk
ingekomen; het is
een erg domme fout die ruikt naar opzet. Bij closed source
crypto producten
zoals die van RSA zit een certificering die het bewijsbaar
veilig maakt.
Er is nog nooit een dergelijk lek gevonden in een closed
source oplossing van
RSA.
source is. Ze kunnen het een stuk moeilijk vinden, of
uberhaubt naar zoeken. Wil niet zeggen dat het er niet in zit
Dat het lek er 2 jaar geleden is ingestopt, heeft niks te
maken met zowel opensource als closed source. Alleen jammer
dat er geen alarm bellen zijn gaan rinkelen.
Overigens een certificering hoeft niet altijd vertrouwelijk
te zijn. Er zijn ook zat certificaten in de wereld die
helemaal niks bewijzen.
Oplossing voor het probleem is, upgrade OpenSSH en OpenSSL
en hergenereer alle certificaten en keys. Of gebruik OpenBSD
met OpenSSL en OpenSSH erop om dat te doen. Een mooie kans
om de certificaten en SSH structuur binnen je netwerk eens
onder de loep te nemen en eventueel te verbeteren.
Door Eghie
source is. Ze kunnen het een stuk moeilijk vinden, of
uberhaubt naar zoeken. Wil niet zeggen dat het er niet in zit
Dat het lek er 2 jaar geleden is ingestopt, heeft niks te
maken met zowel opensource als closed source. Alleen jammer
dat er geen alarm bellen zijn gaan rinkelen.
Overigens een certificering hoeft niet altijd vertrouwelijk
te zijn. Er zijn ook zat certificaten in de wereld die
helemaal niks bewijzen.
Oplossing voor het probleem is, upgrade OpenSSH en OpenSSL
en hergenereer alle certificaten en keys. Of gebruik OpenBSD
met OpenSSL en OpenSSH erop om dat te doen. Een mooie kans
om de certificaten en SSH structuur binnen je netwerk eens
onder de loep te nemen en eventueel te verbeteren.
Door Anoniem
Het lek is twee jaar geleden er in gestopt, leuk hoor dat
open source.
Bij closed source was een dergelijk lek er minder makkelijk
ingekomen; het is
een erg domme fout die ruikt naar opzet. Bij closed source
crypto producten
zoals die van RSA zit een certificering die het bewijsbaar
veilig maakt.
Er is nog nooit een dergelijk lek gevonden in een closed
source oplossing van
RSA.
Er is nog nooit een lek daarin gevonden omdat het closedDoor Anoniem
Omdat Debian/GNU-Linux open source is, gaf het mensen
de mogelijkheid de bron code te inspecteren en vond men dit
probleem dat nu is opgelost.
Bij closed source heb je geen idee of er een
probleem is dat misbruikt kan worden.
Door Nomen Nescio
Veilig he, dat Linux. Totaal geen aanvallen.
Veilig he, dat Linux. Totaal geen aanvallen.
Omdat Debian/GNU-Linux open source is, gaf het mensen
de mogelijkheid de bron code te inspecteren en vond men dit
probleem dat nu is opgelost.
Bij closed source heb je geen idee of er een
probleem is dat misbruikt kan worden.
Het lek is twee jaar geleden er in gestopt, leuk hoor dat
open source.
Bij closed source was een dergelijk lek er minder makkelijk
ingekomen; het is
een erg domme fout die ruikt naar opzet. Bij closed source
crypto producten
zoals die van RSA zit een certificering die het bewijsbaar
veilig maakt.
Er is nog nooit een dergelijk lek gevonden in een closed
source oplossing van
RSA.
source is. Ze kunnen het een stuk moeilijk vinden, of
uberhaubt naar zoeken. Wil niet zeggen dat het er niet in zit
Dat het lek er 2 jaar geleden is ingestopt, heeft niks te
maken met zowel opensource als closed source. Alleen jammer
dat er geen alarm bellen zijn gaan rinkelen.
Overigens een certificering hoeft niet altijd vertrouwelijk
te zijn. Er zijn ook zat certificaten in de wereld die
helemaal niks bewijzen.
Oplossing voor het probleem is, upgrade OpenSSH en OpenSSL
en hergenereer alle certificaten en keys. Of gebruik OpenBSD
met OpenSSL en OpenSSH erop om dat te doen. Een mooie kans
om de certificaten en SSH structuur binnen je netwerk eens
onder de loep te nemen en eventueel te verbeteren.
Nee, dat is niet de reden: er zit bewijsbaar geen lek in, dat is een kwestie van
goede software bouwen met kennis van zaken.
De certificering waar ik het over heb heeft niets te maken met certificaten maar
met de keuring van software door bijvoorbeeld NIST.
19-05-2008, 09:51 door
SirDice
Door Anoniem
Niet mee eens. Dit is nu eens een typische aanval op Open Source: een 'lek' verstopt, vol in het zicht van het publiek.
Mag maar ik heb toch gelijk. De meeste aanvallen gebeuren middels een automatisch proces (wormen, tools etc). Deze scannen volledige ranges en vuren een aanval af zodra een bepaalde open poort wordt gevonden. Dit gebeurt ongeacht het OS van het slachtoffer. Of een dergelijke aanval succes heeft of niet doet niets af aan het feit dat de aanval gebeurt. Zet, op je windows machine, voor de gein maar eens een netcat open op poort 22 en kijk wat er gebeurt.Door SirDice
Aangevallen worden we allemaal, dagelijks meerdere malen, (kijk maar eens goed in je logs) ongeacht welk OS je gebruikt.
Aangevallen worden we allemaal, dagelijks meerdere malen, (kijk maar eens goed in je logs) ongeacht welk OS je gebruikt.
Niet mee eens. Dit is nu eens een typische aanval op Open Source: een 'lek' verstopt, vol in het zicht van het publiek.
Door SirDice
automatisch proces (wormen, tools etc). Deze scannen volledige ranges en
vuren een aanval af zodra een bepaalde open poort wordt gevonden. Dit
gebeurt ongeacht het OS van het slachtoffer. Of een dergelijke aanval succes
heeft of niet doet niets af aan het feit dat de aanval gebeurt. Zet, op je windows
machine, voor de gein maar eens een netcat open op poort 22 en kijk wat er
gebeurt.
Door Anoniem
Niet mee eens. Dit is nu eens een typische aanval op Open Source: een 'lek'
verstopt, vol in het zicht van het publiek.
Mag maar ik heb toch gelijk. De meeste aanvallen gebeuren middels een Door SirDice
Aangevallen worden we allemaal, dagelijks meerdere malen, (kijk maar eens
goed in je logs) ongeacht welk OS je gebruikt.
Aangevallen worden we allemaal, dagelijks meerdere malen, (kijk maar eens
goed in je logs) ongeacht welk OS je gebruikt.
Niet mee eens. Dit is nu eens een typische aanval op Open Source: een 'lek'
verstopt, vol in het zicht van het publiek.
automatisch proces (wormen, tools etc). Deze scannen volledige ranges en
vuren een aanval af zodra een bepaalde open poort wordt gevonden. Dit
gebeurt ongeacht het OS van het slachtoffer. Of een dergelijke aanval succes
heeft of niet doet niets af aan het feit dat de aanval gebeurt. Zet, op je windows
machine, voor de gein maar eens een netcat open op poort 22 en kijk wat er
gebeurt.
Tuurlijk mag jij je gelijk hebben ;-)
Mijn punt is dat dit een typische zwakheid van open source betreft. Evenzo
ontbreekt het bij open source aan een integrale platform visie wat het zwak
maakt.
Merk op dat ik hier twee punten aanstip die op zich geen doorslaggevend
argument voor of tegen open source bieden en evenmin onderbouwen dat
open source minder veilig hoeft te zijn dan closed source. Het zijn gewoon
twee zwakke punten.
This is caused by an incorrect Debian-specific change to
the openssl package (CVE-2008-0166). As a result,
cryptographic key material may be guessable.This is caused
by an incorrect Debian-specific change to the openssl
package (CVE-2008-0166). As a result, cryptographic key
material may be guessable.
Internet in alarmfase geel, draait heel internet op Debian dan?
Overigens zit het probleem 'm in de randomizer van Debian en
staat dus in wezen los van OpenSSL enz.
Hoe willekeurig zijn de uitkomsten van computer-randomisers
echt eigenlijk? Want er bestaan veel randomizers van
verschillende kwaliteit.
the openssl package (CVE-2008-0166). As a result,
cryptographic key material may be guessable.This is caused
by an incorrect Debian-specific change to the openssl
package (CVE-2008-0166). As a result, cryptographic key
material may be guessable.
Internet in alarmfase geel, draait heel internet op Debian dan?
Overigens zit het probleem 'm in de randomizer van Debian en
staat dus in wezen los van OpenSSL enz.
Hoe willekeurig zijn de uitkomsten van computer-randomisers
echt eigenlijk? Want er bestaan veel randomizers van
verschillende kwaliteit.
Door Nomen Nescio op vrijdag 16 mei 2008 15:34
Veilig he, dat Linux. Totaal geen aanvallen.
Poep in je hoofd?Veilig he, dat Linux. Totaal geen aanvallen.
Het lek is twee jaar geleden er in gestopt, leuk hoor dat
open source.
Bij closed source was een dergelijk lek er minder makkelijk
ingekomen; het is
een erg domme fout die ruikt naar opzet. Bij closed source
crypto producten
zoals die van RSA zit een certificering die het bewijsbaar
veilig maakt.
Er is nog nooit een dergelijk lek gevonden in een closed
source oplossing van
RSA.
ook niet goed geïnformeerd........
RSA Registration Manager Cross-Site Scripting
Vulnerabilities 2007-10-30
RSA enVision "username" Cross-Site Scripting Vulnerability
2007-09-18
RSA Products Progress Server Buffer Overflow Vulnerability
2007-07-13
RSA BSAFE Unspecified Denial of Service Vulnerability
2007-05-22
RSA ACE/Agent for Web "image" Cross-Site Scripting
Vulnerability 2005-10-26
RSA Authentication Agent for Web "Redirect" Buffer
Overflow 2005-10-21
RSA Authentication Agent for Web Buffer Overflow
Vulnerability 2005-05-09
RSA Authentication Agent for Web for IIS Cross-Site
Scripting 2005-04-15
RSA ACE/Agent and URLScan Enumeration of Blocked File
Extensions 2003-08-15
RSA ACE/Agent Cross Site Scripting 2003-06-19
RSA ClearTrust Cross-Site Scripting 2003-03-17
27-05-2008, 18:01 door
sjonniev
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
