Microsoft: aanvallers SolarWinds waren al in oktober 2019 actief
De aanvallers die erin slaagden om een backdoor aan de software van softwarebedrijf SolarWinds toe te voegen waren hier al in oktober 2019 mee aan het experimenteren, zo stelt Microsoft. De backdoor werd aan verschillende updates voor het Orion Platform van SolarWinds toegevoegd, waarmee organisaties hun it-omgeving kunnen monitoren en beheren.
Volgens SolarWinds wisten aanvallers tussen maart en juni van dit jaar meerdere digitaal gesigneerde updates van een backdoor te voorzien, die in een dll-bestand van de software aanwezig was. Deze updates werden door 18.000 klanten van het bedrijf geïnstalleerd. Bij het starten van de software wordt zo ook de backdoor in het dll-bestand geladen. De backdoor wordt echter pas na twee weken actief, vermoedelijk om zo detectie te ontlopen.
Ook voert de backdoor verschillende controles uit om er zeker van te zijn dat het om een echt netwerk gaat en geen testsysteem. Tevens wordt er getest op de aanwezigheid van analysesoftware, waaronder WireShark en Autoruns. De backdoor verzamelt informatie over het systeem en stuurt die terug naar de aanvallers. Die beoordelen het slachtoffer en kunnen vervolgens via de backdoor aanvullende malware installeren en het netwerk van de aangevallen organisatie verder compromitteren.
De aanval begint met het toevoegen van de backdoor aan het dll-bestand van SolarWinds. "De aanvallers moesten een geschikte plek in dit dll-bestand zien te vinden om hun code aan toe te voegen. In het ideale scenario zouden ze een plek kiezen in een onderdeel dat periodiek wordt aangeroepen, zodat de kwaadaardige code gegarandeerd altijd actief is", zegt Microsoft in een analyse van de backdoor.
En die locatie werd ook gevonden. Door een kleine aanpassing, die volgens Microsoft eenvoudig over het hoofd kon worden gezien, kon de backdoor worden aangeroepen. "Op het eerste gezicht lijkt de code in dit dll-bestand normaal en wekt geen argwaan, wat een deel van de reden kan zijn waarom de toegevoegde kwaadaardige code maandenlang niet werd opgemerkt, zeker wanneer de code van dit dll-bestand niet vaak wordt bijgewerkt", aldus Microsoft.
De grote vraag blijft hoe SolarWinds werd gecompromitteerd en hoelang de aanvallers toegang tot de ontwikkelomgeving van het bedrijf hadden. Volgens SolarWinds kregen de aanvallers toegang tot het Orion 'software build system' en konden zo de backdoor aan de updates toevoegen. "Het feit dat het gecompromitteerde bestand digitaal is gesigneerd, suggereert dat de aanvallers toegang tot de softwareontwikkeling of distributiepijplijn van het bedrijf hadden", stelt Microsoft. "Aanwijzingen suggereren dat deze aanvallers zo vroeg als oktober 2019 bezig waren met het testen van hun mogelijkheid om code aan lege classes toe te voegen."
Volgens Microsoft werd de backdoor dan ook in een vroeg stadium toegevoegd, nog voor de uiteindelijke fases van de software build, waarbij de gecompileerde code digitaal wordt gesigneerd. Zodoende werd ook het dll-bestand met de backdoor digitaal gesigneerd en kon zo geprivilegieerde acties uitvoeren en niet opvallen. Uiteindelijk werd de backdoor ontdekt door securitybedrijf FireEye, dat ook via de SolarWinds-software werd gecompromitteerd.
Maar hier is het wel te vinden:
https://blog.reversinglabs.com/blog/sunburst-the-next-level-of-stealth
SolarWinds.Orion.Core.BusinessLayer.dll Version: 2019.4.5200.8890 Timestamp: Thu Oct 10 13:26:39 2019
software automatisch van een backdoor voorzien wordt zodat klanten die software build tools bij Microsoft downloaden
en lokaal gebruiken om software te compileren automatisch al die backdoors in huis hebben zonder dat ze zo'n extern
product als solarwinds gebruiken.
Ken Thompon schreef daar in 1984 al over.
#sockpuppet
Ken Thompon schreef daar in 1984 al over.
Het gaat over Solar Winds niet over Microsoft.
De supply chain is voor elk naar binnen gehaalde software een probleem. Open of closed en welke leverancier maakt niets uit.
Dijkstra heeft daar vele notities aan gewijd. Het bewijs dat de code correct is is gebaseerd op aannames waar je niet kijkt.
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD288.html (1970)
Leren we hier echt wat van of gaan we rustig weer onverdroten voort op de ingeslagen weg?
Ik vrees wel eens slechts voor het laatste. De mens is een gewoontedier, ergo.
Dus software en software updates signeren met digitale handtekeningen,
die alleen gebaseerd zijn op hash-functies, zoals Sphincs256.
Het FP-en-mogelijk-FP-dilemma hou je ook hiermee beter mee onder controle.
Nu geeft het protectie- en detectie-software alleen maar een slechte naam.
Check en contra-check en voortgezette backdoor-detectie.
luntrus
Hoe meer ontwikkelaars, hoe groter de codebase en hoe minder strakke reviews, hoe groter de kans dat een geheime dienst en/of slimme cybercriminelen kwaadaardige code aan gedistribueerde software kunnen toevoegen. Ik vraag me bij Microsoft niet af of dit kan, maar wanneer dit gebeurt - als dit al niet is gebeurd.
Los van dit alles is dit het zoveelste bewijs dat virusscanners onbekende malware, zelfs na een jaar, niet detecteren - maar dat FireEye pas argwaan kreeg toen vanaf een onbekend IP-adres een VPN-verbinding werd opgezet. Ofwel de aanvallers hebben nog zeer weinig gebruik gemaakt van hun backdoor(s), ofwel zeer veel partijen waarvan je mag verwachten dat zij hun monitoring goed voor elkaar hebben, hebben dat niet.
Ik vermoed dat laatste, want vooral Windows systemen veroorzaken "in rust" al zoveel netwerkverkeer met zeer veel verschillende servers (met de vaagste domeinnamen, m.i. een grote faal van Microsoft) dat het bijna onmogelijk is om daar kwaadaardig verkeer (anders dan met servers van Microsoft of hun CDN-partners) tussen te kunnen ontwaren.
Ken Thompon schreef daar in 1984 al over.
Het gaat over Solar Winds niet over Microsoft.
Je hebt de implicatie gemist . Anoniem 12:40 speculeert dat een hack _bij_ Microsoft gebruikt zou kunnen worden om Visual Studio en de MS ontwikkeltools aan te passen zodat iedereen die deze tools gebruikt vanzelf (ook) malware mee levert.
De hint 'Ken Thomp(s)on' 1984 - zegt dat duidelijk genoeg . Dat slaat op 'Reflections on Trusting Trust' van Ken Thompson uit 1984 , over een een backdoor in de C compiler die een backdoor bij login introduceerde, en de backdoor her-introduceerde als de C compiler zichzelf van (schone) source compileerde.
Veel av-distributies lopen compleet achter de feiten aan (in zekere zin doen ze dat altijd al in vele gevalle, bij 0-days en zo. Zeker ook bij sommige generieke software detecties).
Dan wemelt het ook nog eens van de echte of vermeende valse positieven. Dat kan ze ook niet altijd aangerekend worden. Bijvoorbeeld als een cloudboer weer eens nieuwe geobfusceerde code inzet tegen anti-anti-bot-code voor een track-dienst (Dit is echt een waar zich steeds herhalend kat- en muisspel).
En verder is de vraag: Staat het in "het lijstje van de week" wat betreft de detecties? Verder wat doet de eind-afnemer zelf eraan of ermee? (SNYK, snort, security officers, beleid).
Er zijn er ook die ook rustig verouderde detecties blijven tonen, McAfee is wat dat aangaat berucht.
Anderen gooiden al lang de handdoek in de ring, kijk naar Comodo.
En andere solutions bemoeien zich weer met dingen ten dienste van hun core-business,
zoals Virus Total als het iedereen door hoepeltjes laten springen ten behoeve van don't-be-evil-Google).
Verder is het ook vaak arbitrair, wat er voor dat moment in de definities is opgenomen is.
Dat is dan ook maar een fractie van alle traceerbare narigheid online.
Dan is verder de meeste malware zeer kortdurend aanwezig en komt persistente maware,
(langer dan 1000 uur online, zeg maar) zelden voor of is gewoon intentioneel bulletproof gelanceerd door malcreanten.
Ik zit 14 jaar in de website security en fouten-jagen en ik heb weinig echte verbeteringen in deze situatie gezien.
Ik heb daarbij aardig wat av-T-shirtjes en beta-programmaatjes versleten.
Meer en meer zie je ook av geregeerd worden door de advertentie-communicatie & managment-poot van het bedrijf en gaan voor het volstoppen van de eindgebruikers/klanten met zo veel mogelijk bloat aan toeters en bellen.
Dit terwijl de echte core business steeds verder "verwaterd".
We zijn echt aan de g*den en farao's overgeleverd of hoe je "de globale bovenbazen van thans" zou moeten noemen.
Wie zorgt thans voor de juiste exodus naar "het av-land van melk en honing" bij uitstek ;)?
Ik ken het wereldje van binnen uit en er is sprake van een status quo.
Ook al zitten officieren van Europol overal binnen en wordt het nog zo mooi gepresenteerd voor de buitenwereld en aan de slapende massa's. En natuurlijk geldt: "Wiens brood men eet, diens woord men spreekt" (voor MS & Goggles in strikte zin geldt dat vast en zeker of zoals Vlamingen zeggen, zeker en vast).
luntrus
De hint 'Ken Thomp(s)on' 1984 - zegt dat duidelijk genoeg . Dat slaat op 'Reflections on Trusting Trust' van Ken Thompson uit 1984 , over een een backdoor in de C compiler die een backdoor bij login introduceerde, en de backdoor her-introduceerde als de C compiler zichzelf van (schone) source compileerde.
Als je de notitie uit 1970 zou begrijpen dan is de kern dat je de compiler moet vertrouwen om je eigen code te evalueren.
Omdat de compiler een black box voor de programmeur is is die indien gekaapt de kwetsbaarheid waar je blind voor bent.
Ken heeft hem in zijn notitie uitgewerkt, maar komt op hetzelfde neer.
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
"The moral is obvious. You can't trust code that you did not totally create yourself. ... No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detect."
Leg hem naast:
"And when programmers have to erect their "computational edifices" on such shaky foundations, it is hardly amazing that they regard full confidence in the correctness of one's program as a ridiculous presumption. In the old days one of the most fundamental properties of automatic computers was that by means of one's program one could keep complete control over what was going to happen."
Best grapping om ze zo naast elkaar te zien. Let eens op de omgeving en compilers waar ze het over hebben.
https://blogs.microsoft.com/on-the-issues/2020/12/17/cyberattacks-cybersecurity-solarwinds-fireeye/
“Like other SolarWinds customers, we have been actively looking for indicators of this actor and can confirm that we detected malicious SolarWinds binaries in our environment, which we isolated and removed. We have not found evidence of access to production services or customer data. Our investigations, which are ongoing, have found absolutely no indications that our systems were used to attack others.”
Maar later wordt door andere partijen o.a. Azure Active Directory en Microsoft Office 365 genoemd.
https://portswigger.net/daily-swig/microsoft-falls-prey-to-solarwinds-supply-chain-cyber-attacks
https://www.crn.com/news/security/microsoft-s-role-in-solarwinds-breach-comes-under-scrutiny
Het is niet duidelijk wie nu gelijk heeft.
Linux ondernemingen gebruiken geen antivirus (alleen op een samba share of mailserver om windows gebruikers tegemoet te komen). Een monitor agent mag alleen maar leesrechten hebben en alleen communiceren met de master via een geencrypte verbinding. Andere acties en netwerkverbindingen opzetten moet worden verboden. RRD files eventueel wel weg kunnen schrijven op een aparte plek zonder executie rechten etc. De master of de master van de master moet natuurlijk ook beperkte rechten hebben (in principe alleen maar data ophalen van de remote agent en het doen van alerts op een ro filesysteem (voor de monitor user) en webserver). Zo hebben backdoorwijzigingen in de agent geen schijn van kans om iets anders te kunen doen dan lokaal resources monitoren. Het zelfde geldt voor backup software. Met SELinux kan je dit allemaal inregelen (al is de leercurve best hoog) met windows blijkbaar niet gezien het feit dat Microsoft ook is gehackt of het kan wel en is MS slachtoffer geworden van haar eigen arrogantie.
Je moet de rechten van applicaties inperken! Al helemaal van de gesloten supply chain. Van de open source alternatieven moet de code wijzigingen/review goed in de gaten worden gehouden.
Duh... Dat geldt voor de hele gebruikte softwarestack. Tot de microcode aan toe. Je onderbouwt hiermee eigenlijk het grote belang van open source software.
Van de open source alternatieven moet de code wijzigingen/review goed in de gaten worden gehouden.
Precies en gelukkig is dat onmiddellijk en volledig inzichtelijk door publiek versiebeheer. No secrets there.
Duh... Dat geldt voor de hele gebruikte softwarestack. Tot de microcode aan toe. Je onderbouwt hiermee eigenlijk het grote belang van open source software.
Van de open source alternatieven moet de code wijzigingen/review goed in de gaten worden gehouden.
Precies en gelukkig is dat onmiddellijk en volledig inzichtelijk door publiek versiebeheer. No secrets there.
De benodigde inspanning om iets wat slecht zichtbaar is toch te herkennen is onmogelijk op te brengen.
Het enige wat er op zit is om de ketens en stacks minimaal te maken.
Niet van alles erbij halen omdat het wel eens handig zou kunnen zijn maar basale geverifieerde functionaliteit met een minimum van wat echt nodig is. Met hardening vind je niet voor niets terug dat alles wat niet nodig is ook echt te verwijderen / buiten gebruik te zetten. Open source is wat dat betreft een valkuil door de misvattingen.
Je ziet zo vaak hard gecodeerde passwords en alles onder root draaien omdat het dan (snel klaar) werkt.
De bezuinigingen op informatieveiligheid werpt wrange vruchten af.
Duh... Dat geldt voor de hele gebruikte softwarestack. Tot de microcode aan toe. Je onderbouwt hiermee eigenlijk het grote belang van open source software.
Van de open source alternatieven moet de code wijzigingen/review goed in de gaten worden gehouden.
Precies en gelukkig is dat onmiddellijk en volledig inzichtelijk door publiek versiebeheer. No secrets there.
Nope, open source software is het enige idee dat tot een oplossing leidt.
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.
