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
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.
vergeet je maar even?
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.
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).
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.
Veilig he, dat Linux. Totaal geen aanvallen.
actief is, waarvan de gevolgen nog onbekend zijn of
meevallen voor de infrastructuur. De gevolgen lokaal kunnen
echter wel ernstig zijn.
behoorlijk matige vertaling.
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 .
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.
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!
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.
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.
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.
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.
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.
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.
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
Deze posting is gelocked. Reageren is niet meer mogelijk.
IT Security Officer
Utrecht heeft jou nodig! Als Information Security Officer vertaal je beleid naar technische uitvoering. Dit is cruciaal voor het waarborgen van de informatiebeveiliging van onze inwoners. Je krijgt de kans om betrokken te zijn bij complexe projecten met de nieuwste technologieën en kunt jouw stempel drukken op innovatie. Solliciteer nu!
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.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.