SolarWinds repareert bug waarbij hardcoded credentials in broncode stonden

SolarWinds heeft een bugfix doorgevoerd voor zijn Web Help Desk waarmee het voor aanvallers mogelijk was in te loggen op het systeem via inloggegevens die hardcoded in de software stonden.

SolarWinds schrijft op een supportpagina dat het een hotfix heeft uitgebracht voor een bug in Web Help Desk 12.8.3 HF1 en ouder. Dat is een ticket- en ondersteuningssysteem voor beheerders van SolarWinds-producten. In die software bleek een bug te zitten die wordt getrackt als CVE-2024-28987. Die draait om 'een credential' die hardcoded in de software stond. Het is niet duidelijk om wat voor credentials het gaat, zoals een gebruikersnaam en/of wachtwoord of bijvoorbeeld een api- of access token. SolarWinds zegt dat het in ieder geval mogelijk was voor een aanvaller om daarmee toegang te krijgen tot een systeem en vervolgens tot data.

De hotfix, 12.8.3 HF2, bevat ook meteen een fix voor een bug in de helpdesktool die eerder deze week bekend werd. Dat is CVE-2024-28986, een bug in de Java Deserialization-functionaliteit waarmee het voor een aanvaller mogelijk was code uit te voeren op een hostmachine. De ontdekker ervan zegt dat het gedaan kon worden zonder geauthenticeerd te zijn, maar SolarWinds zegt dat laatste niet te hebben kunnen reproduceren. Het bedrijf zegt dat het desondanks verstandig is voor beheerders om de patch door te voeren.

De Amerikaanse Cybersecurity & Infrastructure Security Agency, CISA, voegde die tweede bug vorige week toe aan zijn lijst met bekende exploits. Dat betekent dat die kwetsbaarheid in de praktijk wordt misbruikt, maar de instantie deelt daar geen details over. Het enige dat de CISA zegt, is dat onbekend is of het lek voor ransomwarecampagnes wordt gebruikt.

Reacties (40)

[wildhagen]

Sorry hoor, maar credentials hardcoded in een applicatie(code) opnemen, dat is geen fout meer, dan is er echt niet goed nagedacht. En is dit niet naar voren gekomen bij een (interne) pre-release codereview?

Dit soort dingen kon je 20 jaar geleden al niet maken, maar anno 2024 is het echt uit den boze om password in je code op te nemen. Doe het dan op zijn allerminst encrypted.

Dit soort berichten zijn killing voor het vertrouwen in je produkt. Zoals men zegt: vertrouwen komt te voet, maar vertrekt per paard. Het is heel makkelijk om met dit soort acties het vertrouwen van je klanten te verliezen. Het terugwinnnen ervan is een heel stuk lastiger.

[Reactie gewijzigd door wildhagen op 23 augustus 2024 17:04]

[Blokker_1999]

Dat het gebeurd is niet zo vreemd. Veel code wordt initieel opgezet met minder goed identity management. Dat het zo tot productie is kunnen komen is wel een grote fout en had inderdaad opgemerkt moeten worden in de processen die je code van development tot helemaal in productie moeten brengen. Code reviews bestaan met een reden, al zijn er nog te veel mensen die daar veel te vlot over willen gaan

[Buitenaerts]

Wij hebben gewoon een verschil tussen debug en production environment, als je lokaal de applicatie in debug modus draait wordt de 2fa check bijvoorbeeld over geslagen. Maar het is onmogelijk om dit te over te slaan op productie. Hier is gewoon iemand niet handig bezig geweest.

[benjidotsh]

Er is m.i. een verschil tussen code initieel opzetten met minder goede identity management en credentials in de code bewaren. Als je met versiebeheer zit, waar ik nu wel van uitga, dan schiet je jezelf, ongeacht de fase van het project, in de voet want dan wilt dat zeggen dat deze credentials vereeuwigd worden in de code.

[supersnathan94]

Ja maar ff. Iets als SonarQube schreeuwt moord en brand als je ook maar iets wat lijkt op een cred in je code hebt. Is echt niet oké als je dat dan nog naar Productie weet te krijgen. Dan zijn er meer processen stuk en is code review niet het probleem.

Je mist dan gewoon een harde quality gate in je integration pipeline.

[djwice]

Dat moet je dan wél hebben en gebruiken.

Ik ken een niet klein project dat 3.5 jaar zonder deed (ook zonder automatische tests) en pas daarna (er kwam iemand bij met een sterke mening hierover) begon met SonarQube en automatische testen.

Dat praat de situatie niet goed, het verbaast mij ook. Het is niet dat het moeilijk is de best practices te vinden en er zijn behoorlijk wat handleidingen voor beschikbaar.
Maar iets met "geen tijd want de deadline" (blinde vlek/ kleppen voor de kop die er voor zorgt dat je juist later klaar bent omdat je de bugs veel later pas vindt).

[Reactie gewijzigd door djwice op 25 augustus 2024 18:25]

[Tweeks]

Ik zou verwachten dat een beetje IT bedrijf credentials ten minste in een settings/environment file zou opnemen. Dat is minimale effort en zorgt er voor dat je codebase schoon blijft. Een PR of automatische check met bijv. SonarQube zou dit moeten ondervangen.

[mjtdevries]

En dat vertrouwen was al niet zo hoog na die hack een paar jaar geleden...

Wel handig dat ze een naam hebben die lekker opvalt. Dan onthoud je beter dat die toko al eerder slecht in het nieuws kwam.

[Djordjo]

Toch verkoopt Lenovo nog behoorlijk wat laptops..

[laurxp]

maar anno 2024 is het echt uit den boze om password in je code op te nemen. Doe het dan op zijn allerminst encrypted.

Hashed - en salted. Encryptie is bij wachtwoorden een bijzonder slecht idee.

[benjidotsh]

In de context van wachtwoorden van gebruikers: akkoord
In de context van credentials: dan kan je er niet veel meer mee doen

[CH4OS]

Dit soort dingen kon je 20 jaar geleden al niet maken, maar anno 2024 is het echt uit den boze om password in je code op te nemen. Doe het dan op zijn allerminst encrypted.

Secrets sla je op buiten de applicatiecode. Het heeft er echt absoluut niets te zoeken, ook 20 jaar geleden niet. Het maakt dat de applicatie een stuk minder flexibel is dan je zou willen, zeker als de applicatie multi-tenant is bijvoorbeeld, of, wat hier waarschijnlijker is, scalable moet zijn. Dit is echt zware nalatigheid geweest.Ik zou echt op zoek gaan naar degene die dit toegevoegd heeft als die nog bij het bedrijf werkt (kans lijkt me namelijk ook wel klein hierop) en echt een zeer hartig woordje spreken willen, minimaal. Dit is van het kaliber de sleutel onder de deurmat "verstoppen".

[magnifor]

Dat krijg je door al die project managers en stakeholders die met een paar buzz worden weten te overtuigen dat ze zogenaamd verstand van zaken hebben maar het enige wat ze goed kunnen is…lullen, voor de rest geen technische kennis of wat dan ook. En vaak als programmeur ben je machteloos tegen dat soort volk want zijn meestal heel adrem waardoor je geen speld tussen krijgt.

En het ergste is dat die project managers nog meer verdienen ook dan de daadwerkelijke vakmensen.

[jorisporis]

Zo beeld ik het me ook precies in! Zo herkenbaar. Exact hetzelfde meegemaakt. Passwords hardcoded in de code en als je dat meld word er meteen aangevallen "heb je niks beters te doen" Door een of andere kwibus die je nog nooit een ontwikkelomgeving hebt zien openen. Code reviews zijn niet nodig. Een keer klikken om te zien of het werkt en klaar.
Dit soort incidenten horen bij een bepaalde werkcultuur die niet compatibel is met safety en security.

[jcbvm]

Sorry maar als programmeur bepaal ik echt wel zelf hoe ik de code opbouw. Kan een manager wel gaan steigeren, maar ga je dan maar half werk leveren? Dan kan die manager echt iemand anders gaan zoeken.

[FPSUsername]

En is dit niet naar voren gekomen bij een (interne) pre-release codereview?

Dit soort fouten zullen heel gauw doorkomen bij kleine bedrijven. Wat is code review? Dat doen kleine bedrijven niet vaak. Vervolgens wordt het bedrijf groot en raakt niemand legacy zooi aan "omdat het werkt".

Tja, je zou je als bedrijf voor moeten schamen om zo'n amateur fout te maken.

[xxs]

Zoiets is geen bug maar een stupiditeit van de hoogste orde.

[reutulus]

Inderdaad, een bug heeft impact op de werking. Dit is gewoon een gigantische security vulnerability.

[naaitsab]

Bedrijven downplayen graag dit soort nieuws tot een 'bug'. Nieuws dat je bedrijf weer een misser op security heeft gemaakt doet het niet zo goed bij de aandeelhouders en klanten.

Jammer dat technisch georiënteerde media als Tweakers hierin mee gaat en het niet markeert zoals het inderdaad zou moeten zijn. Een security vulnerability/flaw.

[Kabouterplop01]

vind ik ook; zoiets is moedwillig... Echter of het moedwillig is vergeten is een tweede.
Daar gaan we nooit achter komen.

offtopic:
het zou een prima excercise zijn, om m.b.v. codereview dit soort zaken uit de code te trekken

[olafmol]

Oei, dan gaan er wat cruciale dingen qua Q&A niet goed in je dev/engineering processen.

[well0549]

Precies, een beetje credential scan in je DevOps pipeline moet dit kunnen vinden....

Schandalig dat ze die tools blijkbaar niet gebruiken..

Ik zou die software meteen verbieden als overheid. Hier zitten gegarandeerd nog bergen ellende in....

[Dreamvoid]

Ik mag hopen dat de apps van een bedrijf als Solarwinds nergens meer draait waar security belangrijk is?

Je zag hetzelfde bij Zoom, razendsnel populair geworden maar bleek zo lek als een mandje, en alle security-georienteerde bedrijven zijn rap overgeschakeld op MS Teams of Cisco Webex.

[Madshark]

Ik mag hopen dat de apps van een bedrijf als Solarwinds nergens meer draait waar security belangrijk is?

Het zal je verbazen. Zelfs sinds die enorme blunder, waarvan sommigen spreekt over de grootste hack/breach aller tijden, zie ik het nog steeds dagelijks geïmplementeerd worden.
Blijkbaar zit er een heel goed sales netwerk achter, met aardige commissies.

[schumi2004]

Mag hopen dat je sowieso niets van Solarwinds draait, wat een rommel is dat.

[LongTimeAgo]

Solarwinds mag zich 'eigenlijk' niet meer dit soort foutjes veroorloven.
De Hack in 2020 heeft voor velen een best wel zure nasmaak gegeven.

[RobVI]

Hoe is het opnemen van inloggegevens in de broncode een bug?

[SVMartin]

Ik dacht: "ach, net weer een partijtje overgenomen (maar dan nog steeds hun verantwoordelijkheid niet genomen)". Maar nee:

https://thwack.solarwinds...-solarwinds-web-help-desk

Dat was al 12 jaar geleden.. ik had al niet zo'n hoge pet van ze, maar dit verdient een faillissement.

[3raser]

Dat klinkt alsof er een (moedwillige) backdoor in de software zat en dat die nu is uitgelekt.

[!GN!T!ON]

Never attribute to malice that which is adequately explained by stupidity.

[dasiro]

je vergeet optie 3:
"all of the above"

[EiT]

Zit die “bug” dan ook in N-Central?

[well0549]

Is geen bug....

Maar een gigantische stommiteit....

Titel van artikel mag ook wel anders.....

Debielen bij solarwinds blijven doorgaan met hun stommiteiten

[Reactie gewijzigd door well0549 op 23 augustus 2024 17:23]

[EiT]

Daarom staat het tussen “”.

[SuperPietje]

N-Central is niet meer van SolarWinds

[sdv2906]

Klinkt als een feature wat nog niet af was:

“Er is klacht van een (million paying dollar) klant en dit moet nu worden uitgeleverd!”

“Eh, maar het is nog niet volledig uitgewerkt, laat staan getest.”

“Werkt het Happy Path scenario?”

“Ja, maar…”

“Dat is genoeg, nu uitleveren. Volgende week fixen we de bugs wel.”

[well0549]

Bull, dit mag al niet door de ontwikkel staat komen. De pipeline moet gaan barfen en omdat dat niet gebeurd is zegt nog dat al genoeg over hun ontwikkel proces

[zenith]

En dat in 2024