image

DigiNotar-hacker lekte per ongeluk IP-adres

woensdag 31 oktober 2012, 14:39 door Redactie, 10 reacties

De aanvaller die vorig jaar bij de Nederlandse SSL-uitgever DigiNotar wist in te breken, heeft mogelijk per ongeluk zijn IP-adres gelekt, dat naar een Iraanse DSL-aansluiting leidde. Dat staat in het eindrapport over de digitale inbraak bij DigiNotar dat Fox-IT onlangs aan het ministerie van Binnenlandse Zaken en Koninkrijksrelaties opleverde. Volgens het ministerie bevat het eindrapport geen andere inzichten of conclusies ten opzichte van het interim rapport, dat vorig jaar verscheen.

Wel geeft het veel gedetailleerdere informatie over de inbraak bij DigiNotar, gebaseerd op het forensisch onderzoek dat Fox-IT op de logbestanden van DigiNotar heeft gedaan. Zo wordt duidelijk dat de aanvaller op 17 juni 2011 voor het eerst toegang tot het netwerk kreeg. Via verschillende machines in het netwerk kreeg de aanvaller uiteindelijk toegang tot het Office-net.

Internet Explorer
De aanvaller gebruikte verschillende manieren om zijn sporen te verbergen. Zo gebruikte hij ongeautoriseerde 'custom' tools om het verkeer voor poort 3389 (Remote desktop) via poort 443 (HTTPS) te laten lopen. Via de tunnels maakte de aanvaller verbinding met de machines in de Office-net en Secure-net netwerksegmenten.

Voor de Remote Desktop-sessies gebruikte de aanvaller een grafische user-interface, namelijk Internet Explorer. Dat blijkt uit gecachte versies van settings.aspx in de tijdelijke internetbestanden map op de harde schijf. "Deze sporen bewijze dat Internet Explorer is gebruikt in een grafische omgeving door de aanvaller."

IP-adres
De meeste IP-adressen die de onderzoekers aantroffen zijn waarschijnlijk als proxy gebruikt. "Het ware IP-adres van de aanvaller is mogelijk per ongeluk onthuld, toen hij verbinding met de hoofd-webserver zonder het gebruik van een proxy maakte", zo staat in het rapport. Het IP-adres leidde uiteindelijk naar een DSL-gebruiker in Iran.

Reacties (10)
31-10-2012, 14:56 door Anoniem
Lekker cryptische omschrijving; RDP over poort 443 is niets bijzonders en maar wat moet ik me bij "IE als grafische interface" voorstellen ?
31-10-2012, 15:44 door ernie
Misschien gebruikte hij een ActiveX RDP client plugin voor IE:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383019%28v=vs.85%29.aspx

Niet heel erg bijzondere info lijkt me. Behalve als er meer info over de browser is gecached, dan valt er wellicht nog wat te fingerprinten.
31-10-2012, 15:46 door Anoniem
Is er ook een text-mode IE dan?
31-10-2012, 15:48 door Anoniem
Nog steeds zijn er 6 Diginotar certificaten actief in Firefox 16 (opties>geavanceerd>certificaten) Ik ben geen specialist naar moet hier niet eens naar gekeken worden door de programmeurs van Firerfox!?

J. Otterspoor
31-10-2012, 17:52 door ernie
@J. Otterspoor: Het hele browser trust model (vertrouwensmodel) is op dit moment onvoldoende veilig, aangezien de integriteit wordt bepaald door de zwakste schakel, en zolang o.a. allerlei (vage) root CA's in browsers standaard worden vertrouwd, moet je op dit moment haast wel extra tools/plugins gebruiken om echt een beetje veilig gevoelige taken te kunnen verrichten (internetbankieren e.d.), al helemaal als je publieke en/of matig beveiligde (draadloze) netwerken gebruikt.

Al eerder genoemd op deze site is de CertificatePatrol plugin voor Firefox die, als je je er even in verdiept (kan verwarrend zijn voor beginners), al een hoop extra veiligheid kan bieden.

Nog een Firefox-plugin die ik een tijdje naar tevredenheid heb gebruikt heb is Perspectives. Ook wellicht de moeite waard om eens te checken.

Zolang browsers standaard bakken (er bestaan rond de 650 volgens een analyse van het EFF SSL Observatory!) met CA's haast blind vertrouwen is mijns inziens het browser trust model kapot, vertrouw ik op losse tools/plugins en is het maar gewoon wachten tot dit probleem (enigzins) is aangepakt; kwestie van tijd.
31-10-2012, 18:31 door Anoniem
Door Anoniem: Nog steeds zijn er 6 Diginotar certificaten actief in Firefox 16 (opties>geavanceerd>certificaten) Ik ben geen specialist naar moet hier niet eens naar gekeken worden door de programmeurs van Firerfox!?
In IceWeasel 16.0.2 (Firefox op Debian) zie ik alleen de Diginotar Extended Validation CA. Als ik daar op "Edit trust" klik blijkt geen van de mogelijke toepassingen aangevinkt te zijn, wat bij andere certificaten wel het geval is. Ondanks zijn aanwezigheid kan het daardoor niet gebruikt worden om websites (of emailgebruikers of softwaremakers) te identificeren. Ik zou nagaan of bij jou alle vinkjes eveneens uitstaan, en zo niet dan zou ik ze zelf uitzetten.

Waarom er een certificaat is achtergebleven weet ik niet, maar ik kan me voorstellen dat het idee is dat als je er een certificaart-foutmelding krijgt bij een website je zo kan zien dat het wel met een origineel diginotar-certificaat ondertekend is, al is dat gecompromitteerd, en dat je dan vervolgens zelf kan besluiten of je dat voor die site wel of niet vertrouwt.

Ik heb geen idee waarom jij zes Diginotar-certificaten ziet en ik maar een. Heb je jouw Firefox al bijgewerkt naar 6.0.2?
31-10-2012, 20:41 door Anoniem
"Zo gebruikte hij ongeautoriseerde 'custom' tools". Door wie hadden die tools dan geautoriseerd moeten worden?
31-10-2012, 20:44 door yobi
Aardig dat ze de concurrentie ook veel werk gunnen:
* Regularly have the security of your infrastructure and systems therein tested by penetration
testers. Do not always use the same team to perform penetration tests.

Een aardig lijstje voor iedereen met een bedrijf op internet:

Additional measures, point by point:
* Air gap vital systems as much as possible, to make sure that they are physically separated on a
network level from untrusted networks such as the Internet.
* Update all software products on all systems with the latest patches as often as possible.
Subscribe to relevant mailing lists or use dedicated patch management software to support this
process.
* Harden all systems. Do not rely on default settings. Make sure that the most critical systems are
only being used for the critical processes that they are intended for. By limiting the amount of
services on any given system, the attack surface for an attacker is limited.
* Regularly have the security of your infrastructure and systems therein tested by penetration
testers. Do not always use the same team to perform penetration tests.
* Monitor your systems and network and make sure that anomalies trigger notifications to the
appropriate employee(s).
* Use data that can be accumulated by the OCSP responder to check if unknown serials are being
validated.
* Separate vital logging services from the systems that perform other vital functions. In an
infrastructure where secure logging is vital, a logging server can be placed behind a unidirectional
security gateway.
* Ensure forensic readiness so that, for example, all events that are relevant for an incident
response team are logged, that events from multiple systems can be correlated, that a balance is
found in advance between business continuity and potential evidence gathering, that roles and
reporting structures are defined for and communicated to all employees and external parties that
take part in incident response before an incident takes place and that a feedback loop is created
to learn from incidents in the past.
02-11-2012, 17:29 door Anoniem
Door yobi: Aardig dat ze de concurrentie ook veel werk gunnen:
* Regularly have the security of your infrastructure and systems therein tested by penetration
testers. Do not always use the same team to perform penetration tests.

Een aardig lijstje voor iedereen met een bedrijf op internet:

Additional measures, point by point:
* Air gap vital systems as much as possible, to make sure that they are physically separated on a
network level from untrusted networks such as the Internet.
* Update all software products on all systems with the latest patches as often as possible.
Subscribe to relevant mailing lists or use dedicated patch management software to support this
process.
* Harden all systems. Do not rely on default settings. Make sure that the most critical systems are
only being used for the critical processes that they are intended for. By limiting the amount of
services on any given system, the attack surface for an attacker is limited.
* Regularly have the security of your infrastructure and systems therein tested by penetration
testers. Do not always use the same team to perform penetration tests.
* Monitor your systems and network and make sure that anomalies trigger notifications to the
appropriate employee(s).
* Use data that can be accumulated by the OCSP responder to check if unknown serials are being
validated.
* Separate vital logging services from the systems that perform other vital functions. In an
infrastructure where secure logging is vital, a logging server can be placed behind a unidirectional
security gateway.
* Ensure forensic readiness so that, for example, all events that are relevant for an incident
response team are logged, that events from multiple systems can be correlated, that a balance is
found in advance between business continuity and potential evidence gathering, that roles and
reporting structures are defined for and communicated to all employees and external parties that
take part in incident response before an incident takes place and that a feedback loop is created
to learn from incidents in the past.

+1 and repeat:
Volgens mij is dat een hogere normering die nodig is om uitvoerende CA-certificering te verkrijgen ;)
30-11-2012, 17:06 door Anoniem
Is dit dan hetzelfde IP adres 212.95.136.18 als van de Comodo hack?

http://2011.appsecusa.org/p/authenticity.pdf

Zie slide 14 en 15 waarin te vinden is dat de Comodo / Diginotar hacker op zoek was naar sslsniff.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.