Deserialization
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Serialisering word verstaan as die metode om 'n objek in 'n formaat te omskep wat bewaar kan word, met die bedoeling om óf die objek te stoor óf dit as deel van 'n kommunikasieproses oor te dra. Hierdie tegniek word algemeen gebruik om te verseker dat die objek op 'n later tydstip weer geskep kan word, terwyl sy struktuur en toestand behou word.
Deserialisering, aan die ander kant, is die proses wat serialisering teenwerk. Dit behels die neem van data wat in 'n spesifieke formaat gestruktureer is en dit terug te bou in 'n objek.
Deserialisering kan gevaarlik wees omdat dit potensieel aanvallers toelaat om die geserialiseerde data te manipuleer om skadelike kode uit te voer of om onverwagte gedrag in die toepassing te veroorsaak tydens die objekheropbouproses.
In PHP word spesifieke magiese metodes gebruik tydens die serialisering en deserialisering prosesse:
__sleep
: Word aangeroep wanneer 'n objek geserialiseer word. Hierdie metode moet 'n lys van die name van alle eienskappe van die objek wat geserialiseer moet word, teruggee. Dit word algemeen gebruik om hangende data te bevestig of soortgelyke opruimtake uit te voer.
__wakeup
: Word genoem wanneer 'n objek gedeserialiseer word. Dit word gebruik om enige databasisverbindinge wat tydens serialisering verlore gegaan het, te hersteld en ander herbeginningstake uit te voer.
__unserialize
: Hierdie metode word in plaas van __wakeup
(as dit bestaan) aangeroep wanneer 'n objek gedeserialiseer word. Dit bied meer beheer oor die deserialisering proses in vergelyking met __wakeup
.
__destruct
: Hierdie metode word aangeroep wanneer 'n objek op die punt staan om vernietig te word of wanneer die skrip eindig. Dit word tipies gebruik vir opruimtake, soos om lêerhandvatsels of databasisverbindinge te sluit.
__toString
: Hierdie metode laat 'n objek toe om as 'n string behandel te word. Dit kan gebruik word om 'n lêer te lees of ander take gebaseer op die funksie-aanroepe binne dit, wat effektief 'n teksuele voorstelling van die objek bied.
As jy na die resultate kyk, kan jy sien dat die funksies __wakeup
en __destruct
aangeroep word wanneer die objek gedeserialiseer word. Let daarop dat jy in verskeie tutorials sal vind dat die __toString
funksie aangeroep word wanneer daar probeer word om 'n attribuut te druk, maar blykbaar gebeur dit nie meer nie.
Die metode __unserialize(array $data)
word in plaas van __wakeup()
aangeroep as dit in die klas geïmplementeer is. Dit stel jou in staat om die objek te deserialiseer deur die geserialiseerde data as 'n array te verskaf. Jy kan hierdie metode gebruik om eienskappe te deserialiseer en enige nodige take uit te voer tydens deserialisering.
Jy kan 'n verduidelikte PHP voorbeeld hier lees: https://www.notsosecure.com/remote-code-execution-via-php-unserialize/, hier https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf of hier https://securitycafe.ro/2015/01/05/understanding-php-object-injection/
Jy kan die PHP autoload funksionaliteit misbruik om arbitrêre php-lêers en meer te laai:
PHP - Deserialization + Autoload ClassesAs jy om een of ander rede 'n waarde as 'n verwysing na 'n ander waarde wat geserialiseer is wil serialiseer, kan jy:
PHPGGC kan jou help om payloads te genereer om PHP deserialisasies te misbruik.
Let daarop dat jy in verskeie gevalle nie 'n manier sal kan vind om 'n deserialisasie in die bronnekode van die toepassing te misbruik nie, maar jy mag dalk die kode van eksterne PHP-uitbreidings kan misbruik.
So, as jy kan, kyk na die phpinfo()
van die bediener en soek op die internet (en selfs op die gadgets van PHPGGC) vir moontlike gadgets wat jy kan misbruik.
As jy 'n LFI gevind het wat net die lêer lees en nie die php-kode binne-in uitvoer nie, byvoorbeeld deur funksies soos file_get_contents(), fopen(), file() of file_exists(), md5_file(), filemtime() of filesize(). Jy kan probeer om 'n deserialisasie te misbruik wat plaasvind wanneer 'n lêer gelees word met die phar protokol. Vir meer inligting, lees die volgende pos:
phar:// deserializationWanneer die objek ontpikkel word, sal die funksie __reduce__ uitgevoer word. Wanneer dit misbruik word, kan die bediener 'n fout teruggee.
Voor jy die omseil tegniek nagaan, probeer om print(base64.b64encode(pickle.dumps(P(),2)))
te gebruik om 'n objek te genereer wat versoenbaar is met python2 as jy python3 gebruik.
Vir meer inligting oor ontsnapping uit pickle jails kyk:
Bypass Python sandboxesDie volgende bladsy bied die tegniek aan om 'n onveilige deserialisering in yamls python biblioteke te misbruik en eindig met 'n hulpmiddel wat gebruik kan word om RCE deserialisering payload te genereer vir Pickle, PyYAML, jsonpickle en ruamel.yaml:
Python Yaml DeserializationJS het nie "magiese" funksies soos PHP of Python wat net geskep word om 'n objek te genereer nie. Maar dit het 'n paar funksies wat gereeld gebruik word selfs sonder om hulle direk aan te roep soos toString
, valueOf
, toJSON
.
As jy 'n deserialisering misbruik kan jy hierdie funksies kompromitteer om ander kode uit te voer (potensieel prototype besoedeling misbruik) en jy kan arbitrêre kode uitvoer wanneer hulle aangeroep word.
Nog 'n "magiese" manier om 'n funksie aan te roep sonder om dit direk aan te roep is deur 'n objek te kompromitteer wat deur 'n async funksie (belofte) teruggegee word. Want, as jy daardie teruggegee objek in 'n ander belofte met 'n eienskap genaamd "then" van tipe funksie transformeer, sal dit uitgevoer word net omdat dit deur 'n ander belofte teruggegee word. Volg hierdie skakel vir meer inligting.
__proto__
en prototype
besoedelingAs jy meer oor hierdie tegniek wil leer kyk na die volgende tutoriaal:
NodeJS - __proto__ & prototype PollutionHierdie biblioteek laat jou toe om funksies te serialiseer. Voorbeeld:
Die serialiseerde objek sal soos volg lyk:
You can see in the example that when a function is serialized the _$$ND_FUNC$$_
flag is appended to the serialized object.
Inside the file node-serialize/lib/serialize.js
you can find the same flag and how the code is using it.
Soos wat jy in die laaste stuk kode kan sien, as die vlag gevind word word eval
gebruik om die funksie te deserialiseer, so basies word gebruikersinvoer binne die eval
funksie gebruik.
Egter, net om 'n funksie te serialiseer sal dit nie uitvoer nie aangesien dit nodig sou wees dat 'n deel van die kode y.rce
aanroep in ons voorbeeld en dit is hoogs onwaarskynlik.
In elk geval, jy kan net die geserialiseerde objek wysig deur 'n paar hakies by te voeg om die geserialiseerde funksie outomaties uit te voer wanneer die objek gedeserialiseer word.
In die volgende stuk kode let op die laaste hakie en hoe die unserialize
funksie die kode outomaties sal uitvoer:
Soos voorheen aangedui, sal hierdie biblioteek die kode na _$$ND_FUNC$$_
kry en dit uitvoer met behulp van eval
. Daarom, om kode outomaties uit te voer, kan jy die funksie skepping deel en die laaste haakie verwyder en net 'n JS oneliner uitvoer soos in die volgende voorbeeld:
U kan hier vind verdere inligting oor hoe om hierdie kwesbaarheid te benut.
'n Opmerklike aspek van funcster is die ontoeganklikheid van standaard ingeboude voorwerpe; hulle val buite die toeganklike omvang. Hierdie beperking voorkom die uitvoering van kode wat probeer om metodes op ingeboude voorwerpe aan te roep, wat lei tot uitsonderings soos "ReferenceError: console is not defined"
wanneer opdragte soos console.log()
of require(something)
gebruik word.
Ten spyte van hierdie beperking, is dit moontlik om volle toegang tot die globale konteks, insluitend alle standaard ingeboude voorwerpe, te herstel deur 'n spesifieke benadering. Deur die globale konteks direk te benut, kan 'n mens hierdie beperking omseil. Byvoorbeeld, toegang kan hergestel word met die volgende snit:
Vir meer inligting lees hierdie bron.
Die serialize-javascript pakket is eksklusief ontwerp vir serialiseringdoeleindes, en het geen ingeboude deserialisering vermoëns nie. Gebruikers is verantwoordelik om hul eie metode vir deserialisering te implementeer. 'n Direkte gebruik van eval
word voorgestel deur die amptelike voorbeeld vir deserialisering van geserialiseerde data:
As hierdie funksie gebruik word om objekte te deserialiseer, kan jy dit maklik misbruik:
Vir meer inligting lees hierdie bron.
In die volgende bladsye kan jy inligting vind oor hoe om hierdie biblioteek te misbruik om arbitrêre opdragte uit te voer:
In Java, word deserialisering terugroepe uitgevoer tydens die proses van deserialisering. Hierdie uitvoering kan deur aanvallers uitgebuit word wat kwaadwillige payloads saamstel wat hierdie terugroepe aktiveer, wat kan lei tot die potensiële uitvoering van skadelike aksies.
Om potensiële serialisering kwesbaarhede in die kodebasis te identifiseer, soek vir:
Klasse wat die Serializable
-koppelvlak implementeer.
Gebruik van java.io.ObjectInputStream
, readObject
, readUnshare
funksies.
Gee ekstra aandag aan:
XMLDecoder
wat gebruik word met parameters gedefinieer deur eksterne gebruikers.
XStream
's fromXML
metode, veral as die XStream weergawe minder as of gelyk aan 1.46 is, aangesien dit vatbaar is vir serialisering probleme.
ObjectInputStream
gekoppel aan die readObject
metode.
Implementering van metodes soos readObject
, readObjectNodData
, readResolve
, of readExternal
.
ObjectInputStream.readUnshared
.
Algemene gebruik van Serializable
.
Vir swart bok toetsing, soek vir spesifieke handtekeninge of "Magic Bytes" wat java geserialiseerde objekte aandui (wat afkomstig is van ObjectInputStream
):
Heksadesimale patroon: AC ED 00 05
.
Base64 patroon: rO0
.
HTTP antwoordkoppe met Content-type
ingestel op application/x-java-serialized-object
.
Heksadesimale patroon wat vorige kompressie aandui: 1F 8B 08 00
.
Base64 patroon wat vorige kompressie aandui: H4sIA
.
Weblêers met die .faces
uitbreiding en die faces.ViewState
parameter. Om hierdie patrone in 'n webtoepassing te ontdek, moet dit 'n ondersoek uitlok soos gedetailleerd in die pos oor Java JSF ViewState Deserialisering.
As jy wil leer hoe 'n Java Deserialized exploit werk, moet jy kyk na Basic Java Deserialization, Java DNS Deserialization, en CommonsCollection1 Payload.
Jy kan kyk of daar enige toepassing geïnstalleer is met bekende kwesbaarhede.
You could try to check all the libraries known to be vulnerable and that Ysoserial can provide an exploit for. Or you could check the libraries indicated on Java-Deserialization-Cheat-Sheet. You could also use gadgetinspector to search for possible gadget chains that can be exploited. When running gadgetinspector (after building it) don't care about the tons of warnings/errors that it's going through and let it finish. It will write all the findings under gadgetinspector/gadget-results/gadget-chains-year-month-day-hore-min.txt. Please, notice that gadgetinspector won't create an exploit and it may indicate false positives.
Using the Burp extension gadgetprobe you can identify which libraries are available (and even the versions). With this information it could be easier to choose a payload to exploit the vulnerability.
Read this to learn more about GadgetProbe.
GadgetProbe is focused on ObjectInputStream
deserializations.
Using Burp extension Java Deserialization Scanner you can identify vulnerable libraries exploitable with ysoserial and exploit them.
Read this to learn more about Java Deserialization Scanner.
Java Deserialization Scanner is focused on ObjectInputStream
deserializations.
You can also use Freddy to detect deserializations vulnerabilities in Burp. This plugin will detect not only ObjectInputStream
related vulnerabilities but also vulns from Json an Yml deserialization libraries. In active mode, it will try to confirm them using sleep or DNS payloads.
You can find more information about Freddy here.
Serialization Test
Not all is about checking if any vulnerable library is used by the server. Sometimes you could be able to change the data inside the serialized object and bypass some checks (maybe grant you admin privileges inside a webapp). If you find a java serialized object being sent to a web application, you can use SerializationDumper to print in a more human readable format the serialization object that is sent. Knowing which data are you sending would be easier to modify it and bypass some checks.
The main tool to exploit Java deserializations is ysoserial (download here). You can also consider using ysoseral-modified which will allow you to use complex commands (with pipes for example).
Note that this tool is focused on exploiting ObjectInputStream
.
I would begin om die "URLDNS" payload voor 'n RCE payload te gebruik om te toets of die inspuiting moontlik is. Anyway, note that maybe the "URLDNS" payload is not working but other RCE payload is.
Wanneer jy 'n payload vir java.lang.Runtime.exec() skep, kan jy nie spesiale karakters soos ">" of "|" gebruik om die uitvoer van 'n uitvoering te herlei nie, "$()" om opdragte uit te voer of selfs argumente aan 'n opdrag deur spasies geskei te gee (jy kan echo -n "hello world"
doen, maar jy kan nie python2 -c 'print "Hello world"'
doen nie). Om die payload korrek te kodeer, kan jy hierdie webblad gebruik.
Voel vry om die volgende skrip te gebruik om alle moontlike kode-uitvoering payloads vir Windows en Linux te skep en dit dan op die kwesbare webblad te toets:
Jy kan gebruik https://github.com/pwntester/SerialKillerBypassGadgetCollection saam met ysoserial om meer exploits te skep. Meer inligting oor hierdie hulpmiddel in die skyfies van die praatjie waar die hulpmiddel voorgestel is: https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next_slideshow=1
marshalsec kan gebruik word om payloads te genereer om verskillende Json en Yml serialisering biblioteke in Java te exploiteer.
Om die projek te compileer, moes ek byvoeg hierdie afhangklikhede aan pom.xml
:
Installeer maven, en compileer die projek:
Lees meer oor hierdie Java JSON-biblioteek: https://www.alphabot.com/security/blog/2020/java/Fastjson-exceptional-deserialization-vulnerabilities.html
As jy 'n paar ysoserial payloads wil toets, kan jy hierdie webapp uitvoer: https://github.com/hvqzao/java-deserialize-webapp
Java gebruik baie serialisering vir verskeie doeleindes soos:
HTTP versoeke: Serialisering word wyd gebruik in die bestuur van parameters, ViewState, koekies, ens.
RMI (Remote Method Invocation): Die Java RMI-protokol, wat heeltemal op serialisering staatmaak, is 'n hoeksteen vir afstandkommunikasie in Java-toepassings.
RMI oor HTTP: Hierdie metode word algemeen gebruik deur Java-gebaseerde dik kliënt webtoepassings, wat serialisering vir alle objekkommunikasies benut.
JMX (Java Management Extensions): JMX benut serialisering om objekten oor die netwerk te stuur.
Pasgemaakte Protokolle: In Java is die standaardpraktyk om rou Java-objekte oor te dra, wat in komende eksploitvoorbeelde demonstreer sal word.
'n Klas wat Serializable
implementeer, kan enige objek binne die klas wat nie serialiseerbaar moet wees nie, as transient
implementeer. Byvoorbeeld:
Serializable
moet implementeerIn scenario's waar sekere objekte die Serializable
-koppelvlak moet implementeer weens klas hiërargie, is daar 'n risiko van onbedoelde deserialisering. Om dit te voorkom, verseker dat hierdie objekte nie-deserialiseerbaar is deur 'n final
readObject()
-metode te definieer wat konsekwent 'n uitsondering gooi, soos hieronder getoon:
Aanpassing van java.io.ObjectInputStream
is 'n praktiese benadering om deserialisering prosesse te beveilig. Hierdie metode is geskik wanneer:
Die deserialisering kode is onder jou beheer.
Die klasse wat verwag word vir deserialisering is bekend.
Oorheers die resolveClass()
metode om deserialisering tot slegs toegelate klasse te beperk. Dit voorkom deserialisering van enige klas behalwe dié wat eksplisiet toegelaat is, soos in die volgende voorbeeld wat deserialisering tot die Bicycle
klas beperk:
Gebruik van 'n Java Agent vir Sekuriteitsverbetering bied 'n terugvaloplossing wanneer kode-modifikasie nie moontlik is nie. Hierdie metode geld hoofsaaklik vir swartlys van skadelike klasse, met 'n JVM parameter:
Dit bied 'n manier om deserialisering dinamies te beveilig, ideaal vir omgewings waar onmiddellike kodeveranderinge onprakties is.
Kyk na 'n voorbeeld in rO0 deur Contrast Security
Implementering van Serialisering Filters: Java 9 het serialisering filters bekendgestel via die ObjectInputFilter
koppelvlak, wat 'n kragtige mekanisme bied om kriteria te spesifiseer waaraan serialiseerde objekte moet voldoen voordat dit gedeserialiseer word. Hierdie filters kan globaal of per stroom toegepas word, wat 'n fyn beheer oor die deserialisering proses bied.
Om serialisering filters te gebruik, kan jy 'n globale filter stel wat op alle deserialisering operasies van toepassing is of dit dinamies vir spesifieke strome konfigureer. Byvoorbeeld:
Benutting van Eksterne Biblioteke vir Verbeterde Sekuriteit: Biblioteke soos NotSoSerial, jdeserialize, en Kryo bied gevorderde funksies vir die beheer en monitering van Java deserialisering. Hierdie biblioteke kan addisionele lae van sekuriteit bied, soos om klasse te witlys of swartlys, geserialiseerde objek te analiseer voordat deserialisering plaasvind, en om pasgemaakte serialiseringstrategieë te implementeer.
NotSoSerial onderskep deserialiseringprosesse om die uitvoering van onbetroubare kode te voorkom.
jdeserialize stel die analise van geserialiseerde Java-objekte in staat sonder om hulle te deserialiseer, wat help om potensieel kwaadwillige inhoud te identifiseer.
Kryo is 'n alternatiewe serialiseringraamwerk wat fokus op spoed en doeltreffendheid, en bied konfigureerbare serialiseringstrategieë wat sekuriteit kan verbeter.
Deserialisering en ysoserial praat: http://frohoff.github.io/appseccali-marshalling-pickles/
Java en .Net JSON deserialisering papier: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf, praat: https://www.youtube.com/watch?v=oUAeWhW5b8c en skywe: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf
Deserialisering CVE's: https://paper.seebug.org/123/
Vind uit wat JNDI Inspuiting is, hoe om dit te misbruik via RMI, CORBA & LDAP en hoe om log4shell te ontgin (en voorbeeld van hierdie kwesbaarheid) op die volgende bladsy:
JNDI - Java Naming and Directory Interface & Log4ShellDie Java Boodskapdiens (JMS) API is 'n Java boodskap-georiënteerde middleware API vir die stuur van boodskappe tussen twee of meer kliënte. Dit is 'n implementering om die produsent-verbruiker probleem te hanteer. JMS is 'n deel van die Java Platform, Enterprise Edition (Java EE), en is gedefinieer deur 'n spesifikasie wat by Sun Microsystems ontwikkel is, maar wat sedertdien deur die Java Gemeenskapsproses gelei is. Dit is 'n boodskapstandaard wat aansoekkomponente gebaseer op Java EE toelaat om boodskappe te skep, te stuur, te ontvang en te lees. Dit stel die kommunikasie tussen verskillende komponente van 'n verspreide aansoek in staat om losweg gekoppel, betroubaar en asynchrone te wees. (Van Wikipedia).
Daar is verskeie produkte wat hierdie middleware gebruik om boodskappe te stuur:
So, basies is daar 'n klomp dienste wat JMS op 'n gevaarlike manier gebruik. Daarom, as jy genoeg regte het om boodskappe na hierdie dienste te stuur (gewoonlik sal jy geldige akrediteer nodig hê) kan jy in staat wees om kwaadwillige geserialiseerde objek te stuur wat deur die verbruiker/subscriber gedeserialiseer sal word. Dit beteken dat in hierdie ontginning al die kliënte wat daardie boodskap gaan gebruik, besmet sal raak.
Jy moet onthou dat selfs al is 'n diens kwesbaar (omdat dit onveilig gebruikersinvoer deserialiseer) jy steeds geldige gadgets moet vind om die kwesbaarheid te ontgin.
Die hulpmiddel JMET is geskep om verbinding te maak en hierdie dienste aan te val deur verskeie kwaadwillige geserialiseerde objek te stuur wat bekende gadgets gebruik. Hierdie ontginnings sal werk as die diens steeds kwesbaar is en as enige van die gebruikte gadgets binne die kwesbare aansoek is.
JMET praat: https://www.youtube.com/watch?v=0h8DWiOWGGA
In die konteks van .Net, werk deserialisering ontginnings op 'n manier soortgelyk aan dié wat in Java gevind word, waar gadgets ontgin word om spesifieke kode tydens die deserialisering van 'n objek uit te voer.
Die bronkode moet ondersoek word vir voorkomste van:
TypeNameHandling
JavaScriptTypeResolver
Die fokus moet wees op serialiseerders wat toelaat dat die tipe deur 'n veranderlike onder gebruikersbeheer bepaal word.
Die soektog moet teiken op die Base64-gecodeerde string AAEAAAD///// of enige soortgelyke patroon wat op die bediener-kant gedeserialiseer kan word, wat beheer oor die tipe wat gedeserialiseer moet word, toelaat. Dit kan insluit, maar is nie beperk tot nie, JSON of XML strukture wat TypeObject
of $type
bevat.
In hierdie geval kan jy die hulpmiddel ysoserial.net gebruik om die deserialisering ontginnings te skep. Sodra jy die git-repositori afgelaai het, moet jy die hulpmiddel saamstel met Visual Studio byvoorbeeld.
As jy wil leer oor hoe ysoserial.net sy ontginning skep kan jy hierdie bladsy nagaan waar die ObjectDataProvider gadget + ExpandedWrapper + Json.Net formatter verduidelik word.
Die hoofopsies van ysoserial.net is: --gadget
, --formatter
, --output
en --plugin
.
--gadget
word gebruik om die gadget aan te dui wat misbruik gaan word (gee die klas/funksie wat tydens deserialisering misbruik gaan word om opdragte uit te voer).
--formatter
, word gebruik om die metode aan te dui om die ontginning te serialiseer (jy moet weet watter biblioteek die agterkant gebruik om die payload te deserialiseer en dieselfde gebruik om dit te serialiseer)
--output
word gebruik om aan te dui of jy die ontginning in raw of base64 gegecodeer wil hê. Let daarop dat ysoserial.net die payload sal kodeer met UTF-16LE (kodeering wat standaard op Windows gebruik word) so as jy die raw kry en dit net van 'n linux-konsol kodeer, kan jy 'n paar kodeering-kompatibiliteitsprobleme hê wat die ontginning sal verhinder om behoorlik te werk (in HTB JSON box het die payload in beide UTF-16LE en ASCII gewerk, maar dit beteken nie dit sal altyd werk nie).
--plugin
ysoserial.net ondersteun plugins om ontginnings vir spesifieke raamwerke soos ViewState te vervaardig.
--minify
sal 'n kleiner payload bied (indien moontlik)
--raf -f Json.Net -c "anything"
Dit sal al die gadgets aandui wat met 'n gegewe formatter (Json.Net
in hierdie geval) gebruik kan word
--sf xml
jy kan 'n gadget aandui (-g
) en ysoserial.net sal soek na formatters wat "xml" bevat (hoofdlettergevoelig)
ysoserial voorbeelde om ontginnings te skep:
ysoserial.net het ook 'n baie interessante parameter wat help om beter te verstaan hoe elke exploit werk: --test
As jy hierdie parameter aandui, sal ysoserial.net die exploit plaaslik probeer, sodat jy kan toets of jou payload korrek sal werk.
Hierdie parameter is nuttig omdat jy, as jy die kode hersien, stukke kode soos die volgende een (van ObjectDataProviderGenerator.cs) sal vind:
Dit beteken dat om die eksploit te toets, die kode serializersHelper.JsonNet_deserialize sal aanroep.
In die vorige kode is kwesbaar vir die ontploffing wat geskep is. So as jy iets soortgelyks in 'n .Net-toepassing vind, beteken dit waarskynlik dat daardie toepassing ook kwesbaar is.
Daarom laat die --test
parameter ons toe om te verstaan watter stukke kode kwesbaar is vir die deserialisasie-ontploffing wat ysoserial.net kan skep.
Kyk na hierdie POST oor hoe om te probeer om die __ViewState parameter van .Net te ontplof om arbitraire kode uit te voer. As jy alreeds die geheime wat deur die slagoffer masjien gebruik word, ken, lees hierdie pos om te weet hoe om kode uit te voer.
Om die risiko's wat met deserialisasie in .Net geassosieer word, te verminder:
Vermy om datastrome toe te laat om hul objektipe te definieer. Gebruik DataContractSerializer
of XmlSerializer
wanneer moontlik.
Vir JSON.Net
, stel TypeNameHandling
op None
: %%%TypeNameHandling = TypeNameHandling.None%%%
Vermy om JavaScriptSerializer
met 'n JavaScriptTypeResolver
te gebruik.
Beperk die tipes wat gedeserialiseer kan word, verstaan die inherente risiko's met .Net tipes, soos System.IO.FileInfo
, wat die eienskappe van bediener lêers kan verander, wat moontlik tot ontkenning van diensaanvalle kan lei.
Wees versigtig met tipes wat riskante eienskappe het, soos System.ComponentModel.DataAnnotations.ValidationException
met sy Value
eienskap, wat uitgebuit kan word.
Beheer tipe-instansiasie veilig om te voorkom dat aanvallers die deserialisasie-proses beïnvloed, wat selfs DataContractSerializer
of XmlSerializer
kwesbaar maak.
Implementeer witlysbeheer met 'n pasgemaakte SerializationBinder
vir BinaryFormatter
en JSON.Net
.
Bly ingelig oor bekende onveilige deserialisasie-gadgets binne .Net en verseker dat deserializers nie sulke tipes instansieer nie.
Isolateer potensieel riskante kode van kode met internettoegang om te voorkom dat bekende gadgets, soos System.Windows.Data.ObjectDataProvider
in WPF-toepassings, aan onbetroubare databronne blootgestel word.
Java en .Net JSON deserialisasie papier: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf, praat: https://www.youtube.com/watch?v=oUAeWhW5b8c en skyfies: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf
In Ruby word serialisering gefasiliteer deur twee metodes binne die marshal biblioteek. Die eerste metode, bekend as dump, word gebruik om 'n objek na 'n byte-stroom te transformeer. Hierdie proses word serialisering genoem. Omgekeerd word die tweede metode, load, gebruik om 'n byte-stroom terug na 'n objek te herstel, 'n proses bekend as deserialisering.
Vir die beveiliging van geserialiseerde objekte, gebruik Ruby HMAC (Hash-Based Message Authentication Code), wat die integriteit en egtheid van die data verseker. Die sleutel wat vir hierdie doel gebruik word, word in een van verskeie moontlike plekke gestoor:
config/environment.rb
config/initializers/secret_token.rb
config/secrets.yml
/proc/self/environ
Ruby 2.X generiese deserialisering na RCE gadget ketting (meer inligting in https://www.elttam.com/blog/ruby-deserialization/):
Other RCE chain to exploit Ruby On Rails: https://codeclimate.com/blog/rails-remote-code-execution-vulnerability-explained/
Soos verduidelik in hierdie kwesbaarheidsverslag, as 'n gebruiker ongesuiwerde invoer by die .send()
metode van 'n ruby objek kom, laat hierdie metode toe om enige ander metode van die objek met enige parameters aan te roep.
Byvoorbeeld, om eval aan te roep en dan ruby kode as tweede parameter sal toelaat om arbitrêre kode uit te voer:
Boonop, as slegs een parameter van .send()
deur 'n aanvaller beheer word, soos in die vorige skrywe genoem, is dit moontlik om enige metode van die objek aan te roep wat nie argumente benodig nie of waarvan die argumente standaardwaardes het.
Vir hierdie doel is dit moontlik om al die metodes van die objek te enumerate om 'n paar interessante metodes te vind wat aan daardie vereistes voldoen.
Hierdie tegniek is geneem uit hierdie blogpos.
Daar is ander Ruby-biblioteke wat gebruik kan word om voorwerpe te serialiseer en wat dus misbruik kan word om RCE te verkry tydens 'n onveilige deserialisering. Die volgende tabel toon sommige van hierdie biblioteke en die metode wat hulle van die gelaaide biblioteek noem wanneer dit nie-geserialiseer is (funksie om te misbruik om RCE te verkry basies):
Biblioteek | Invoergegewens | Kick-off metode binne klas |
Marshal (Ruby) | Binêr |
|
Oj | JSON |
|
Ox | XML |
|
Psych (Ruby) | YAML |
|
JSON (Ruby) | JSON |
|
Basiese voorbeeld:
In die geval van die poging om Oj te misbruik, was dit moontlik om 'n gadget klas te vind wat binne sy hash
funksie to_s
sal aanroep, wat spesifikasie sal aanroep, wat fetch_path sal aanroep wat dit moontlik gemaak het om 'n ewekansige URL op te haal, wat 'n groot detektor van hierdie soort onsuiwer deserialisasie kwesbaarhede bied.
Boonop is daar gevind dat met die vorige tegniek 'n gids ook in die stelsel geskep word, wat 'n vereiste is om 'n ander gadget te misbruik om dit in 'n volledige RCE te transformeer met iets soos:
Kontroleer vir meer besonderhede in die oorspronklike pos.
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)