Toon posts:

Ransomware integration layer

Pagina: 1
Acties:

  • Smartbikers
  • Registratie: April 2020
  • Laatst online: 10:03
Hi,

Uit nieuwsgierigheid ben Ik op zoek naar informatie of en hoe ransomware zich kan verspreiden via een integratielaag.

Als je bijvoorbeeld een applicatie hebt die relatiegegevens uit een crm systeem nodig heeft dan wordt er via de integratielaag een service aangeroepen die uiteindelijk een relatieID retourneert. Als er Ransomware in die applicatie is binnen getreden kan het dan via een integratielaag zich verspreiden naar het crm systeem of lukt dat niet omdat er geen bestandjes heen en weer gaan?

Iemand een idee waar dit soort informatie beschikbaar is ?

  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

Smartbikers schreef op vrijdag 17 december 2021 @ 14:36:
Hi,

Uit nieuwsgierigheid ben Ik op zoek naar informatie of en hoe ransomware zich kan verspreiden via een integratielaag.

Als je bijvoorbeeld een applicatie hebt die relatiegegevens uit een crm systeem nodig heeft dan wordt er via de integratielaag een service aangeroepen die uiteindelijk een relatieID retourneert. Als er Ransomware in die applicatie is binnen getreden kan het dan via een integratielaag zich verspreiden naar het crm systeem of lukt dat niet omdat er geen bestandjes heen en weer gaan?

Iemand een idee waar dit soort informatie beschikbaar is ?
Basically werkt ransomware middels het encrypten van bestanden. Via jouw integratielaag vindt inderdaad geen bestandsoverdracht plaats, maar het kan nog steeds een vector zijn voor voor het verspreiden van de ransomware. Als jouw integratielaag namelijk lek is, kun je met de credentials van de eindgebruiker (die al gehackt is) elevated privileges verkrijgen op de server waar die integratielaag draait. En zodoende dus de data op die server gijzelen

QnJhaGlld2FoaWV3YQ==


  • kodak
  • Registratie: Augustus 2001
  • Laatst online: 05-02 21:58

kodak

FP ProMod
Het verspreiden van ransomware is aan dezelfde regels gebonden als gewone malware. Mogelijkheid om ergens gegeven (malware) te plaatsen, wijzigen of verwijderen hangt af van de mogelijkheden om dat uit te kunnen voeren. Dat kan dus zowel via ontworpen functionaliteiten daarvoor zijn, of via onbedoelde beveiligingslekken.

In het voorbeeld dat je geeft kan het bijvoorbeeld zijn dat het niet de bedoeling is dat een (besmette) applicatie of wie dan ook de service opdrachten probeert te geven om foute code uit te voeren, maar als de service onveilig ontworpen is of gebruik maakt van andere software die voor problemen kan zorgen, dan kan het dus alsnog zijn dat het foute code gaat uitvoeren.
Een heel bekende situatie is bijvoorbeeld het kunnen uitvoeren van sql-opdrachten om de database en dus gegevens aan te passen. En een recent voorbeeld van onveilige situaties is als de service gebruik maakt van log4j, dat onbedoeld toch tekst gaat beschouwen als code die uitgevoerd moet worden en in vervelende gevallen zo code kan uitvoeren dat de opdracht geeft om ransomware te downloaden en uit te voeren op het systeem van de service of waar die service van afhankelijk is.
Je kan ook kijken naar de gevolgen van bestaande encryptie. Als een client gegevens mag corrigeren op de service dan kan je bijvoorbeeld denken aan een situatie dat een client besmet is, gegevens ophaalt en versleutelde gegevens als correctie terug kan sturen.
En aangezien een laag meestal afhankelijk is van een andere laag kan je vast ook wel bedenken wat de gevolgen kunnen zijn als de client en de service niet besmet zijn, maar iemand anders wel het verkeer voor die laag kan aanpassen.

  • oak3
  • Registratie: Juli 2010
  • Laatst online: 06-02 20:51
Als het gaat om misbruik maken van kwetsbaarheden, dan zijn er vaak heel veel mogelijkheden. M.b.t een integratielaag zal je je met name moeten richten op mogelijke kwetsbaarheden van de api laag (zie bijvoorbeeld OWASP of Log4j) of onveilig omgaan met authenticatiegegevens, bijvoorbeeld het gebruik van een service account.

De praktijk is echter heel anders. Ransomware aanvallen die misbruik maken van een integratielaag komen m.i. niet voor. Het zijn toch vooral meer traditionele stappen als phishing, brute force op een rdp of een grote bekende kwetsbaarheden in Exchange, Firewalls of iets als Log4j.

Dus de grote vraag, wil je een theoretische benadering. Dan is er veel mogelijk met allerlei rand gevallen. Wil je weten hoe in het de praktijk werkt, dan is het misbruiken van api's zeer onwaarschijnlijk, tenzij je de deur wagenwijd open zet. Voor praktijk gevallen kun je ook eens hier kijken: https://thedfirreport.com/

  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

oak3 schreef op woensdag 29 december 2021 @ 14:36:
...De praktijk is echter heel anders. Ransomware aanvallen die misbruik maken van een integratielaag komen m.i. niet voor. Het zijn toch vooral meer traditionele stappen als phishing, brute force op een rdp of een grote bekende kwetsbaarheden in Exchange, Firewalls of iets als Log4j...
Denk dat je hiermee een vals gevoel van veiligheid creëert.
De initiële binnenkomst is inderdaad vaak via phishing of een lek in je netwerk.
Maar de moderne ransomware gaat dan niet meteen je bestanden encrypten. Die gaat op zoek naar alle bekende vulnerabilities in je hele netwerk. En pas als die vulnerabilities allemaal uitgeprobeerd zijn, op alle servers en workstations in je netwerk, worden de bestanden geëncrypt. En dan ook de bestanden op al je servers en workstations. Dat kan meer dan een maand later zijn dan je initiële besmetting.
En ransomware is niet zo kritisch hoor; als die een vulnerability in je integration layer vindt, wordt die ook misbruikt

QnJhaGlld2FoaWV3YQ==


  • remco_k
  • Registratie: April 2002
  • Laatst online: 07-02 20:44

remco_k

een cassettebandje was genoeg

Smartbikers schreef op vrijdag 17 december 2021 @ 14:36:
Hi,

Uit nieuwsgierigheid ben Ik op zoek naar informatie of en hoe ransomware zich kan verspreiden via een integratielaag.
...
Iemand een idee waar dit soort informatie beschikbaar is ?
Ja, dat kan en daar is recent rondom 10 december best grote paniek over uitgebroken (code rood, zeg maar.) Verschillende mensen die in de IT werken, waaronder ik, hebben rondom die dag een paar uur extra gewerkt.) én hebben we daar het laatste nog niet over gezien, gehad en gehoord. Sommige zaken zijn in de kiem gesmoord. Maar dat lukt lang niet overal. Soms omdat mensen de impact zwaar onderschatten. Wij (de IT knakkers) zullen het hier over jaren nog steeds over hebben dat dit plaatsvond.

Ik doel op de al eerder genoemde Log4J kwetsbaarheid. Dat is m.i. het ultieme voorbeeld waar jij om vraagt. Het is recent, het is echt, het is super link geweest (en is het nog steeds).

Een Youtube filmpje die haarfijn even uitlegt en laat zien hoe groot dat probleem eigenlijk is en hoe kinderlijk eenvoudig het is om de kwetsbaarheid te misbruiken: YouTube: CVE-2021-44228 - Log4j - MINECRAFT VULNERABLE! (and SO MUCH MORE)
Nou gaat dat over Minecraft. Maar je raadt het al: het gaat uiteraard niet alleen over minecraft.

Nou zal er bij het retourneren van een relatieID niet direct zo'n groot probleem veroozaakt kunnen worden. Als dat wel zo is, dan was het probleem er al eerder.
Maar stel, jouw CRM heeft server en/of clientside last van deze Log4J kwetsbaarheid. En stel dat de initiele besmetting al is gebeurd (b.v. door phising / een gebruiker die malware heeft gestart).
Als een relatieID wordt geretourneerd, zit daar vaak wat metadata bij. Een naam, beschrijving, comments en b.v. een relatie code.
En stel dat zowel de server als de client de relatie code via Log4J in het log zetten als gelukte zoek actie, maar in die relatie code werd al eerder door de malware zo'n jndi code string gezet. In alle relatie records... Dan gaat verspreiding in je systeem heel erg hard. En dit is je praktijkvoorbeeld van spreiding via een integratielaag. Dat is geen spannende Starwars serie, maar realiteit die sinds 10 december bekend is gemaakt.
Em dan hebben we het nu alleen nog maar over een hele bekende/beruchte kwetsbaarheid. Maar zo bestaan er dus honderden kleine en grote gaten waar ransomware handig gebruik van probeert te maken.

[Voor 28% gewijzigd door remco_k op 30-12-2021 02:11]

Alles kan stuk.
Goedkoop SHOUTcast stream hosting? Snel online, geen setup kosten. www.digiplay.nl


  • remco_k
  • Registratie: April 2002
  • Laatst online: 07-02 20:44

remco_k

een cassettebandje was genoeg

oak3 schreef op woensdag 29 december 2021 @ 14:36:
De praktijk is echter heel anders. Ransomware aanvallen die misbruik maken van een integratielaag komen m.i. niet voor. Het zijn toch vooral meer traditionele stappen als phishing, brute force op een rdp of een grote bekende kwetsbaarheden in Exchange, Firewalls of iets als Log4j.
Juist bij de Log4J kwetsbaarheid kan een integratie laag een meer dan goed verspreidingsmechanisme zijn voor allerlei shit die je niet wilt.

Alles kan stuk.
Goedkoop SHOUTcast stream hosting? Snel online, geen setup kosten. www.digiplay.nl


  • oak3
  • Registratie: Juli 2010
  • Laatst online: 06-02 20:51
Brahiewahiewa schreef op donderdag 30 december 2021 @ 00:58:
[...]

Denk dat je hiermee een vals gevoel van veiligheid creëert.
De initiële binnenkomst is inderdaad vaak via phishing of een lek in je netwerk.
Maar de moderne ransomware gaat dan niet meteen je bestanden encrypten. Die gaat op zoek naar alle bekende vulnerabilities in je hele netwerk. En pas als die vulnerabilities allemaal uitgeprobeerd zijn, op alle servers en workstations in je netwerk, worden de bestanden geëncrypt. En dan ook de bestanden op al je servers en workstations. Dat kan meer dan een maand later zijn dan je initiële besmetting.
En ransomware is niet zo kritisch hoor; als die een vulnerability in je integration layer vindt, wordt die ook misbruikt
Dit is precies waarom ik gelinkt heb naar the DFIR report. Ransomware aanvallers gaan niet op zoek naar alle kwetsbaarheden in je netwerk, ze misbruiken bekende kwetsbaarheden om verhoogde rechten te krijgen. Soms om direct toegang te krijgen tot een Domain Controller (printernightmare) en vaak via het dumpen van credentials op een server waar ze toegang hebben. Hiervoor worden ook vaak zaken misbruikt als wachtwoorden in platte tekst en hergebruikte wachtwoorden.

Ik wil zeker geen vals gevoel van veiligheid creëren, maar veel mensen zien Ransomware dreigingen in de grootste edge cases, terwijl Ransomware aanvallers vooral misbruik maken van slechte basis hygiëne, soms in combinatie met grote 0-days. Een integratielaag beschouw ik normaliter als een edge case. Behalve als er een bekende vulnerability in zit zoals Log4j. Maar dan heeft het m.i. weinig meer te maken met de specifieke functie van een integratielaag, maar meer dat het iets is wat toevallig Log4j gebruikt.

Is het onmogelijk, zeker niet. Gebeurd het in de praktijk? Ik heb er nog geen voorbeelden van gezien en volg het op de voet. Ik vind de nuance erg belangrijk omdat ik te vaak zie dat organisaties de basis hygiëne niet op orde hebben, maar ineens wel super veel aandacht hebben voor een edge case als een integratielaag. De TS geeft helaas niet aan wat de achtergrond van de vraag is, maar dit is de reden van mijn nuance.
Smartbikers schreef op vrijdag 17 december 2021 @ 14:36:
Als er Ransomware in die applicatie is binnen getreden kan het dan via een integratielaag zich verspreiden naar het crm systeem of lukt dat niet omdat er geen bestandjes heen en weer gaan?
Voor de duidelijkheid, Ransomware is niet iets 'magisch' of virus-achtig dat zich aan bits en bytes kan hechten en zich automatisch verspreid. Ook is het tegenwoordig vaak geen (wormable) malware meer. Het zijn hackers die kwetsbaarheden misbruiken en standaard (systeembeheer) tools inzetten om hun doelen te bereiken. En ransomware zelf is vaak gewoon een executabele die wordt gestart op veel systemen tegelijk.

[Voor 13% gewijzigd door oak3 op 30-12-2021 09:17]


  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

oak3 schreef op donderdag 30 december 2021 @ 09:08:
[...]
De TS geeft helaas niet aan wat de achtergrond van de vraag is, maar dit is de reden van mijn nuance.
[...]
Denk dat wij het al eens waren en dat het gebrek aan achtergrond een schijnbare tegenstelling heeft veroorzaakt.

Kort door de bocht zeg jij: "maak je niet zo druk om edge cases want er is op het gebied van basis hygiëne nog vreselijk veel te winnen". Terwijl ik er a priori vanuit ging dat TS z'n basis hygiëne al op orde heeft en nu onderzoek aan het doen is naar de volgende verdedigingslinie.

QnJhaGlld2FoaWV3YQ==

Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee