Ernstige beveiliging: Browser-in-the-browser-aanvallen - pas op voor vensters die dat niet zijn!

Onderzoekers van dreigingsinformatiebedrijf Group-IB schreven zojuist een intrigerende waargebeurd verhaal over een irritant eenvoudige maar verrassend effectieve phishing-truc die bekend staat als BeetjeB, kort voor browser-in-de-browser.

Je hebt waarschijnlijk al eerder gehoord van verschillende soorten X-in-the-Y-aanvallen, met name: MitM en MitB, kort voor manipulator in het midden en manipulator-in-de-browser.

Bij een MitM-aanval positioneren de aanvallers die u willen misleiden zich ergens 'in het midden' van het netwerk, tussen uw computer en de server die u probeert te bereiken.

(Ze bevinden zich misschien niet letterlijk in het midden, geografisch of qua hop, maar MitM-aanvallers zijn ergens langs de route, aan beide uiteinden niet goed.)

Het idee is dat in plaats van in te breken op uw computer of op de server aan de andere kant, ze u ertoe verleiden om in plaats daarvan verbinding met hen te maken (of opzettelijk uw netwerkpad manipuleren, dat u niet gemakkelijk kunt controleren zodra uw pakketten uitgaan van je eigen router), en dan doen ze alsof ze de andere kant zijn – een kwaadaardige proxy, zo je wilt.

Ze geven je pakketten door aan de officiële bestemming, snuffelen erin en spelen er misschien onderweg mee, ontvangen dan de officiële antwoorden, die ze kunnen bekijken en aanpassen voor een tweede keer, en ze aan je teruggeven alsof je' d end-to-end verbonden, precies zoals u had verwacht.

Als u geen end-to-end encryptie zoals HTTPS gebruikt om zowel de vertrouwelijkheid (geen snuffelen!) detecteren, dat iemand anders uw digitale brieven tijdens het transport heeft opengestoomd en ze daarna opnieuw verzegelt.

Aan één kant aanvallen

A MitB aanval is bedoeld om op een vergelijkbare manier te werken, maar om het probleem veroorzaakt door HTTPS te omzeilen, wat een MitM-aanval veel moeilijker maakt.

MitM-aanvallers kunnen niet gemakkelijk interfereren met verkeer dat is versleuteld met HTTPS: ze kunnen niet snuffelen in uw gegevens, omdat ze niet over de cryptografische sleutels beschikken die door elk uiteinde worden gebruikt om deze te beschermen; ze kunnen de versleutelde gegevens niet wijzigen, omdat de cryptografische verificatie aan elk uiteinde dan alarm zou slaan; en ze kunnen zich niet voordoen als de server waarmee u verbinding maakt, omdat ze niet het cryptografische geheim hebben dat de server gebruikt om zijn identiteit te bewijzen.

Een MitB-aanval is daarom meestal gebaseerd op het sluipen van malware eerst op uw computer.

Dat is over het algemeen moeilijker dan op een bepaald moment gewoon het netwerk aan te boren, maar het geeft de aanvallers een enorm voordeel als ze het kunnen beheren.

Dat komt omdat, als ze zichzelf rechtstreeks in uw browser kunnen invoegen, ze uw netwerkverkeer kunnen zien en wijzigen voordat uw browser het versleutelt voor verzending, wat elke uitgaande HTTPS-beveiliging opheft, en nadat uw browser het heeft gedecodeerd op de terugweg, waardoor de versleuteling die door de server wordt toegepast om zijn antwoorden te beschermen, teniet wordt gedaan.

Hoe zit het met een BitB?

Maar hoe zit het met een BeetjeB aanval?

Browser-in-de-browser is een hele mondvol, en het bedrog dat ermee gemoeid is, geeft cybercriminelen lang niet zoveel macht als een MitM- of een MitB-hack, maar het concept is voor het hoofd slaand eenvoudig, en als je te veel haast hebt, is het verrassend gemakkelijk om ervoor te vallen.

Het idee van een BitB-aanval is om te creëren wat lijkt op een pop-upbrowservenster dat veilig door de browser zelf is gegenereerd, maar dat in feite niets meer is dan een webpagina die in een bestaand browservenster is weergegeven.

Je zou kunnen denken dat dit soort bedrog gedoemd zou zijn te mislukken, simpelweg omdat alle inhoud op site X die zich voordoet van site Y te komen, in de browser zelf wordt weergegeven als afkomstig van een URL op site X.

Eén blik op de adresbalk maakt duidelijk dat er tegen je wordt gelogen en dat waar je ook naar kijkt waarschijnlijk een phishing-site is.

Vijand voorbeeld, hier is een screenshot van de example.com website, genomen in Firefox op een Mac:

Als aanvallers je naar een nepsite lokken, val je misschien voor de beelden als ze de inhoud nauwkeurig kopiëren, maar de adresbalk zou verraden dat je niet op de site was die je zocht.

Bij een Browser-in-the-Browser-zwendel is het doel van de aanvaller daarom om een ​​normale pagina dat lijkt op het web site en inhoud je verwacht, compleet met de raamdecoratie en de adresbalk, zo realistisch mogelijk nagebootst.

In zekere zin gaat een BitB-aanval meer over kunst dan over wetenschap, en het gaat meer over webdesign en het managen van verwachtingen dan over netwerkhacking.

Als we bijvoorbeeld twee op het scherm geschraapte afbeeldingsbestanden maken die er zo uitzien ...

...dan HTML zo simpel als wat je hieronder ziet...

<html>
   <body>
      <div>
         <div><img src='./fake-top.png'></div>
         <p>
         <div><img src='./fake-bot.png'></div>
      </div>
   </body>
</html>

... maakt wat lijkt op een browservenster in een bestaand browservenster, zoals dit:

In dit zeer eenvoudige voorbeeld zullen de drie macOS-knoppen (sluiten, minimaliseren, maximaliseren) linksboven niets doen, omdat het geen besturingssysteemknoppen zijn, maar foto's van knoppen, en de adresbalk in wat lijkt op een Firefox-venster kan niet worden aangeklikt of bewerkt, omdat het ook gewoon een screenshot.

Maar als we nu een IFRAME toevoegen aan de HTML die we hierboven hebben laten zien, om valse inhoud op te zuigen van een site die niets te maken heeft met example.com, soortgelijk…

<html>
   <body>
      <div>
         <div><img src='./fake-top.png' /></div>   
         <div><iframe src='https:/dodgy.test/phish.html' frameBorder=0 width=650 height=220></iframe></div>
         <div><img src='./fake-bot.png' /></div>
      </div>
   </body>
</html>

...je moet toegeven dat de resulterende visuele inhoud eruitziet precies zoals een zelfstandig browservenster, ook al is het eigenlijk een webpagina in een ander browservenster.

De tekstinhoud en de klikbare link die u hieronder ziet, zijn gedownload van de dodgy.test HTTPS-link in het bovenstaande HTML-bestand, dat deze HTML-code bevat:

<html>
   <body style='font-family:sans-serif'>
      <div style='width:530px;margin:2em;padding:0em 1em 1em 1em;'>
         <h1>Example Domain</h1>

         <p>This window is a simulacrum of the real website,
         but it did not come from the URL shown above.
         It looks as though it might have, though, doesn't it?

         <p><a href='https://dodgy.test/phish.click'>Bogus information...</a>
      </div>
   </body>
</html>

Door de grafische inhoud die de HTML-tekst bovenaan en achter zich laat, lijkt het alsof de HTML echt afkomstig is example.com, dankzij de screenshot van de adresbalk bovenaan:

De kunstgreep is duidelijk als je het nepvenster op een ander besturingssysteem bekijkt, zoals Linux, omdat je een Linux-achtig Firefox-venster krijgt met een Mac-achtig "venster" erin.

De neppe "window dressing"-componenten vallen echt op als de afbeeldingen die ze werkelijk zijn:

Zou je ervoor vallen?

Als je ooit schermafbeeldingen van apps hebt gemaakt en de schermafbeeldingen later in je fotoviewer hebt geopend, durven we te wedden dat je jezelf op een gegeven moment hebt misleid om de afbeelding van de app te behandelen alsof het een actieve kopie is van de app zelf.

We durven te wedden dat je in je leven op een app-in-een-app-afbeelding hebt geklikt of erop hebt getikt, en dat je je afvroeg waarom de app niet werkte. (Ok, misschien heb je dat niet, maar we hebben het zeker, tot op het punt van echte verwarring.)

Als u in een fotobrowser op een app-screenshot klikt, loopt u natuurlijk heel weinig risico, omdat de klikken of tikken gewoon niet doen wat u verwacht - u kunt inderdaad lijnen op de afbeelding bewerken of krabbelen in plaats van.

Maar als het gaat om een browser-in-de-browser In plaats daarvan kunnen verkeerd geadresseerde klikken of tikken in een gesimuleerd venster gevaarlijk zijn, omdat u zich nog steeds in een actief browservenster bevindt, waar JavaScript in het spel is en waar links nog steeds werken...

... je bent gewoon niet in het browservenster dat je dacht, en je bent ook niet op de website die je dacht.

Erger nog, elk JavaScript dat in het actieve browservenster wordt uitgevoerd (dat afkomstig is van de oorspronkelijke bedrieglijke site die u hebt bezocht) kan een deel van het verwachte gedrag van een echt pop-upvenster van een browser simuleren om realisme toe te voegen, zoals het slepen, het formaat wijzigen en meer.

Zoals we aan het begin al zeiden, als je wacht op een echt pop-upvenster en je ziet iets dat lijkt op een pop-upvenster, compleet met realistische browserknoppen plus een adresbalk die overeenkomt met wat je verwachtte, en je hebt een beetje haast...

... we kunnen volledig begrijpen hoe u het nepvenster verkeerd kunt herkennen als een echt venster.

Getarget op Steam-spellen

In de Groep-IB onderzoek we hierboven vermeldden, de echte BinB-aanval die de onderzoekers ontdekten, gebruikte Steam Games als lokaas.

Een legitiem ogende site, ook al had je er nog nooit van gehoord, zou je de kans bieden om plaatsen te winnen bij een aankomend speltoernooi, bijvoorbeeld...

... en toen de site zei dat er een apart browservenster verscheen met een Steam-inlogpagina, presenteerde het in plaats daarvan echt een browser-in-de-browser nepvenster.

De onderzoekers merkten op dat de aanvallers niet alleen BitB-trucs gebruikten om gebruikersnamen en wachtwoorden te achterhalen, maar ook probeerden Steam Guard-pop-ups te simuleren die ook om tweefactorauthenticatiecodes vroegen.

Gelukkig toonden de screenshots die door Group-IB werden gepresenteerd aan dat de criminelen die ze in dit geval tegenkwamen niet erg voorzichtig waren met de kunst- en ontwerpaspecten van hun oplichterij, dus de meeste gebruikers zagen de vervalsing waarschijnlijk.

Maar zelfs een goed geïnformeerde gebruiker die haast heeft, of iemand die een browser of besturingssysteem gebruikt die hij niet kent, zoals bij een vriend thuis, heeft de onnauwkeurigheden misschien niet opgemerkt.

Ook zouden meer kieskeurige criminelen vrijwel zeker realistischere nep-inhoud bedenken, op dezelfde manier dat niet alle e-mailoplichters spelfouten maken in hun berichten, waardoor mogelijk meer mensen hun toegangsgegevens weggeven.

Wat te doen?

Hier zijn drie tips:

• Browser-in-the-Browser-vensters zijn geen echte browservensters. Hoewel ze misschien lijken op vensters op besturingssysteemniveau, met knoppen en pictogrammen die er net zo uitzien als de echte deal, gedragen ze zich niet als besturingssysteemvensters. Ze gedragen zich als webpagina's, want dat zijn ze. Als je verdacht bent, probeer het verdachte venster buiten het hoofdvenster van de browser te slepen dat het bevat. Een echt browservenster zal zich onafhankelijk gedragen, dus u kunt het buiten en buiten het oorspronkelijke browservenster plaatsen. Een nep-browservenster wordt "opgesloten" in het echte venster waarin het wordt weergegeven, zelfs als de aanvaller JavaScript heeft gebruikt om zoveel mogelijk echt uitziend gedrag te simuleren. Dit zal snel verraden dat het deel uitmaakt van een webpagina, en geen echt venster op zich.
• Onderzoek verdachte ramen zorgvuldig. Realistisch spotten met het uiterlijk van een besturingssysteemvenster in een webpagina is gemakkelijk slecht te doen, maar moeilijk om goed te doen. Neem die extra paar seconden om te zoeken naar veelbetekenende tekenen van vervalsing en inconsistentie.
• Geef het bij twijfel niet uit. Wees op uw hoede voor sites waarvan u nog nooit hebt gehoord en die u niet kunt vertrouwen, die plotseling willen dat u inlogt via een site van derden.

Wees nooit gehaast, want als u de tijd neemt, is de kans veel kleiner dat u ziet wat u ziet denken is er in plaats van wat te zien wat eigenlijk? is er.

In drie woorden: Stoppen. Denken. Aansluiten.

---

Uitgelichte afbeelding van foto van app-venster met afbeelding van foto van Magritte's "La Trahison des Images" gemaakt via Wikipedia.

---