Fat-client hack

Update 26 – De Hack –januari 2016

Dit keer in rubriek De Hack geeft security consultant Thijs Hodiamont een heldere uitleg over het onderzoeken van fat-clients.

Recentelijk hebben we de kans gehad om in opdracht van een SaaS-ontwikkelaar de door hen ontwikkelde fat-client te onderzoeken op kwetsbaarheden. Dit artikel beschrijft dat proces en de uitdagingen die hierbij komen kijken.

Madison Gurkha voert regelmatig onderzoeken uit op een zogenaamde fat-client. Het onderzoeksdoel: het vaststellen van het niveau van technische IT-beveiliging, wijkt niet af van onze gangbare onderzoeken op webapplicaties. Echter, de manier van onderzoeken is wel degelijk anders en is vaak arbeidsintensiever dan een meer gangbaar grey-box-onderzoek.

Definitie
Het begrip ‘fat-client’ is, zoals bij veel termen in IT, relatief/subjectief/aan inflatie onderhevig (haal door wat niet van toepassing is). Voor dit artikel hanteren we de volgende definitie:‘Een applicatie die is ontworpen volgens een client-server-model en daarbij ook een niettriviaal deel van de functionaliteit delegeert aan de client.’ Fat-clients komen voor in de vorm van bijvoorbeeld Java-applets, .NETapplicaties en C++-applicaties. In de praktijk zien we vaak applicaties voor specifieke bedrijfsprocessen die veelal gerelateerd zijn aan betalingen en/of vermogensbeheer. Een ander kenmerk is dat deze fat-clients vaak niet via het internet gebruikt worden maar enkel via een intern netwerk of een VPN-verbinding. Dit is echter geen gouden regel want Java-applets vormen daar weer een uitzondering op.

Onderzoeksmethoden
De traditionele manier van onderzoeken die we toepassen op webapplicaties, door het uitvoeren van een man-in-the-middle (MitM)-aanval op het netwerkverkeer tussen client en server, heeft zijn beperkingen. Fat-clients maken vaak gebruik van niet-standaardprotocollen, beschermen de communicatie of maken gebruik van andere mitigerende maatregelen om de beveiliging te waarborgen. Het onderzoeken van een fat-client is vaak een combinatie van de volgende drie methoden:

1. MitM
Inspecteren van communicatie tussen client en server. In enkele gevallen zijn er nog steeds opties om verkeer te manipuleren en daarmee security controls te omzeilen. De communicatie tussen client en server geeft ook inzicht in de interne werking van de fat-client. Deze informatie kan gebruikt worden in andere aanvallen.

2. Disassembly/decompilatie
Het disassemblen en/of decompileren van de fat-client. Bij Java-applets en .NET-applicaties is het over het algemeen triviaal om deze applicaties te decompileren tot leesbare broncode. Met deze broncode kunnen we de interne werking van de fat-client onderzoeken met als doel kwetsbaarheden te vinden en security controls te omzeilen. Ontwikkelaars kunnen maatregelen nemen om decompilatie te voorkomen of lastiger te maken, maar een aanvaller met meer tijd kan hier omheen werken.

3. Debugging
Het debuggen van een draaiende applicatie stelt ons in staat om de mechanismen van de applicatie te gebruiken. Wanneer een applicatie bijvoorbeeld de communicatie ondertekent met een cryptografische hash (controlecijfer) dan kunnen we het bericht aanpassen voordat het ondertekend wordt. Client-side controles en autorisaties kunnen op deze wijze ook omzeild worden. Het grote nadeel van deze methode is dat de moeilijkheidsgraad van zeer gemakkelijk (Java-applets) tot zeer moeilijk (C++) gaat. Ontwikkelaars kunnen maatregelen nemen om debuggen te bemoeilijken, maar een aanvaller met meer tijd zal in staat zijn deze maatregelen te omzeilen.

Het onderzoeken van een fat-client, of een willekeurig stuk software, met behulp van bovenstaande methoden noemen we ‘reverse engineering’.

Casus
Een aantal jaar geleden hebben we in opdracht van de klant een onderzoek uitgevoerd op een SaaS-applicatie, in de vorm van een fat-client van ontwikkelaar ACME (fictieve naam). Uit dit onderzoek waarbij we gebruik hebben gemaakt van de traditionele MitM-methode, kwamen een aantal bevindingen naar voren. De gevonden kwetsbaarheden stelden een aanvaller in staat om door het verkeer tussen de fat-client en de backend te manipuleren, gegevens van andere klanten in te zien, te wijzigen en te verwijderen. Ook was het mogelijk om SQL-queries die door de fat-client werden opgesteld aan te passen met als resultaat willekeurige informatie uit de achterliggende database. Het resultaat van dit onderzoek is destijds door de klant teruggekoppeld aan ACME waarna een gepatchte versie van de software werd opgeleverd. Een heronderzoek, in beperkte tijd, toonde aan dat alle risico’s gemitigeerd waren.

Afgelopen jaar benaderde ACME ons direct om naar aanleiding van het eerder uitgevoerde onderzoek een nieuw onderzoek uit te laten voeren. Met de resultaten van dit onderzoek wilde zij aan haar klanten kunnen aantonen dat de door hun ontwikkelde SaaS-oplossing geen kwetsbaarheden bevat. De SaaS-applicatie betreft een Java-applet waarvan gebruikers met verschillende functierollen gebruik kunnen maken. Ook het rollen-, rechten- en gebruikersbeheer wordt via een Java-applet uitgevoerd.

De uitdaging
De fat-client (de Java-applet) bevat de functionaliteit voor alle rollen en bepaalt op basis van de informatie van de backend welke informatie en/of functionaliteit weergegeven mag worden. Een gebruiker met beperkte rechten zal minder functionaliteit zien dan een beheerder.

De uitdaging: hoe krijg ik als aanvaller met rechten van een normale gebruiker toegang tot de functionaliteit van een beheerder? Dit gaat over verticale autorisaties. Daarnaast maakt een SaaS-applicatie veelal gebruik van een gedeelde omgeving. Hoe kan een aanvaller met de rechten van klant A toegang krijgen tot de gegevens van klant B? Dit noemen we horizontale autorisaties.

In de eerste fase van een onderzoek zijn dit de twee punten waar we op focussen.

Onderzoek
We starten het onderzoek met het inspecteren van het verkeer tussen de fat-client en de backend. Wanneer we aanpassingen maken in het verkeer, bijvoorbeeld het aanpassen van een identifier voor een organisatie, volgt er direct een foutmelding. Nadere inspectie laat zien dat de berichten van de fat-client een checksum/controlecijfer bevatten op basis van het cryptografische SHA256- algoritme. Met behulp van dit controlecijfer kan de backend vaststellen of het bericht tussentijds is aangepast. Bovendien wordt een foutmelding gegenereerd als het meegestuurde controlecijfer niet overeenkomt met het berekende controlecijfer. Een MitM-aanval wordt hiermee voor een zeer groot deel gemitigeerd. Daarmee is onze interesse gewekt want we zien geen verschil in de berichtenstructuur ten opzichte van de ‘kwetsbare’ fat-client zoals die de eerste keer is onderzocht.

Omdat het een Java-applet betreft hebben we de mogelijkheid om deze met publiekelijk beschikbare tools als JD-GUI te decompileren tot leesbare code. Een publiekelijk beschikbare tool voor .NET-applicaties is ILSpy. Voor C/ C++-applicaties moet een aanvaller terugvallen op decompilers als Hex-Rays Decompiler (commercieel) of Snowman (open-source).

We besluiten de Java-applet te decompileren met behulp van JD-GUI om de logica van de fat-client te kunnen achterhalen. Wanneer een gebruiker inlogt krijgt de fat-client van de backend te horen welke rol de gebruiker heeft en bij welke organisatie de gebruiker hoort. De rolinformatie wordt door de fatclient gebruikt om functionaliteit wel of niet te tonen. De organisatie-informatie wordt in ieder request naar de backend meegezonden. Wanneer de gebruiker zijn dashboard wil zien zal het verzoek aan de backend zijn: ‘Geef me het dashboard voor organisatie A’. Als we het dashboard van organisatie ‘B’ willen inzien moeten we ‘A’ dus aanpassen naar ‘B’. Dit kunnen we doen door onze eigen client te schrijven of door de fat-client te debuggen en de waarde ‘A’ aan te passen naar ‘B’ voordat het controlecijfer berekend wordt. Met behulp van Eclipse, een Java IDE, debuggen we de applet en passen we de waarde aan. De backend honoreert ons verzoek en we krijgen het dashboard van organisatie ‘B’ te zien. Hiermee is ontbrekende horizontale autorisatie aangetoond.

Vervolgens testen we nog een aantal andere handelingen zoals het toevoegen van gebruikers aan andere organisaties en het inzien van transacties van andere organisaties. Bij alle handelingen ontbreekt de horizontale autorisatiecontrole. In de broncode van de backend die tijdens het onderzoek is aangeleverd zien we bovendien dat er geen verticale autorisatiecontroles zijn geïmplementeerd. Hierdoor kan een normale gebruiker bijvoorbeeld mutaties op andere gebruikers met een administratieve rol uitvoeren. Ook nu is het mogelijk om SQL-queries aan te passen en hiermee informatie te verzamelen. Op basis van onze bevindingen concluderen we dat ACME na ons initiële onderzoek enkel een controlecijfer heeft toegevoegd op de berichten tussen de fat-client en de backend en dat de gehele applicatie nog steeds kwetsbaar is.

Hoe nu verder?
ACME heeft met behulp van onze input een hoop aanpassingen gedaan, waardoor de backend nu niet langer impliciet aanneemt dat de invoer van de fat-client vertrouwd is. Bij ieder verzoek moeten er zowel horizontale als verticale autorisatiecontroles worden gedaan. Onze onderzoeken hebben laten zien dat dit ook echt nodig was en dat het niet voldoende is om een controlecijfer voor de berichten te gebruiken. Tevens is alle SQLfunctionaliteit verplaatst naar zogenaamde ‘prepared statements’ in de backend. Dit alles resulteerde in een arbeidsintensieve klus voor ACME.

Fat-clients zijn, voor zover wij kunnen bepalen, op dit moment nog een ondergeschoven kindje omdat het aanvalsoppervlak vaak klein is. Ze worden dikwijls op een intern netwerk gebruikt door een beperkte groep mensen en de klanten zijn vaak niet op de hoogte van de mogelijke kwetsbaarheden in dit soort software. Gecombineerd met het feit dat de onderzoeken arbeidsintensiever zijn dan ‘normale’ applicatie-onderzoeken leidt dat ertoe dat bedrijven ervoor kiezen om deze fat-clients niet te laten onderzoeken. Hopelijk hebben we u aan het denken gezet.

@Secura 2018
Webdesign Studio HB / webdevelopment Medusa