Deserialization
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Serialization inafahamika kama njia ya kubadilisha kitu kuwa katika muundo ambao unaweza kuhifadhiwa, kwa nia ya ama kuhifadhi kitu hicho au kukituma kama sehemu ya mchakato wa mawasiliano. Mbinu hii hutumiwa mara nyingi kuhakikisha kwamba kitu kinaweza kuundwa tena baadaye, ikihifadhi muundo na hali yake.
Deserialization, kinyume chake, ni mchakato unaopinga serialization. Inahusisha kuchukua data ambayo imeundwa katika muundo maalum na kuijenga tena kuwa kitu.
Deserialization inaweza kuwa hatari kwa sababu inaweza kuruhusu washambuliaji kubadilisha data iliyosaralishwa ili kutekeleza msimbo mbaya au kusababisha tabia isiyotarajiwa katika programu wakati wa mchakato wa ujenzi wa kitu.
Katika PHP, mbinu maalum za kichawi hutumiwa wakati wa mchakato wa serialization na deserialization:
__sleep
: Inaitwa wakati kitu kinaposaralishwa. Mbinu hii inapaswa kurudisha orodha ya majina ya mali zote za kitu ambazo zinapaswa kusaralishwa. Inatumika mara nyingi kuhifadhi data inayosubiri au kufanya kazi za usafi zinazofanana.
__wakeup
: Inaitwa wakati kitu kinaposaralishwa. Inatumika kurejesha uhusiano wowote wa database ambao unaweza kuwa umepotea wakati wa serialization na kufanya kazi nyingine za kuanzisha tena.
__unserialize
: Mbinu hii inaitwa badala ya __wakeup
(ikiwa inapatikana) wakati kitu kinaposaralishwa. Inatoa udhibiti zaidi juu ya mchakato wa deserialization ikilinganishwa na __wakeup
.
__destruct
: Mbinu hii inaitwa wakati kitu kinakaribia kuharibiwa au wakati script inamalizika. Inatumika kawaida kwa kazi za usafi, kama kufunga mikono ya faili au uhusiano wa database.
__toString
: Mbinu hii inaruhusu kitu kutendewa kama string. Inaweza kutumika kwa kusoma faili au kazi nyingine kulingana na wito wa kazi ndani yake, ikitoa kwa ufanisi uwakilishi wa maandiko wa kitu.
Ikiwa utaangalia matokeo, utaona kwamba kazi __wakeup
na __destruct
zinaitwa wakati kitu kinapokuwa deserialized. Kumbuka kwamba katika mafunzo kadhaa utaona kwamba kazi __toString
inaitwa unapojaribu kuchapisha sifa fulani, lakini kwa wazi hiyo haifanyiki tena.
Njia __unserialize(array $data)
inaitwa badala ya __wakeup()
ikiwa imeanzishwa katika darasa. Inakuruhusu kuunserialize kitu kwa kutoa data iliyosainiwa kama array. Unaweza kutumia njia hii kuunserialize mali na kufanya kazi zozote muhimu wakati wa deserialization.
Unaweza kusoma mfano wa PHP ulioelezewa hapa: https://www.notsosecure.com/remote-code-execution-via-php-unserialize/, hapa https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf au hapa https://securitycafe.ro/2015/01/05/understanding-php-object-injection/
Unaweza kutumia kazi ya autoload ya PHP kupakia faili za php zisizo na mpangilio na zaidi:
PHP - Deserialization + Autoload ClassesIkiwa kwa sababu fulani unataka kuunda thamani kama kiungo kwa thamani nyingine iliyoundwa unaweza:
PHPGGC inaweza kukusaidia kuunda payloads za kutumia PHP deserializations.
Kumbuka kwamba katika kesi kadhaa huwezi kupata njia ya kutumia deserialization katika msimbo wa chanzo wa programu lakini unaweza kuwa na uwezo wa kutumia msimbo wa nyongeza za PHP za nje.
Hivyo, ikiwa unaweza, angalia phpinfo()
ya seva na tafuta mtandaoni (hata kwenye gadgets za PHPGGC) baadhi ya gadgets zinazoweza kutumiwa.
Ikiwa umepata LFI inayosoma tu faili na sio kutekeleza msimbo wa php ndani yake, kwa mfano kwa kutumia kazi kama file_get_contents(), fopen(), file() au file_exists(), md5_file(), filemtime() au filesize(). Unaweza kujaribu kutumia deserialization inayotokea wakati wa kusoma faili kwa kutumia itifaki ya phar. Kwa maelezo zaidi soma chapisho lifuatalo:
phar:// deserializationWakati kitu kinapokuwa unpickle, kazi __reduce__ itatekelezwa. Wakati inatumika, seva inaweza kurudisha kosa.
Kabla ya kuangalia mbinu ya kupita, jaribu kutumia print(base64.b64encode(pickle.dumps(P(),2)))
ili kuunda kitu ambacho kinapatana na python2 ikiwa unatumia python3.
Kwa maelezo zaidi kuhusu kutoroka kutoka pickle jails angalia:
Bypass Python sandboxesUkurasa ufuatao un presenting mbinu ya kudhulumu deserialization isiyo salama katika yamls maktaba za python na kumaliza na chombo ambacho kinaweza kutumika kuunda RCE deserialization payload kwa Pickle, PyYAML, jsonpickle na ruamel.yaml:
Python Yaml DeserializationJS haina "magic" functions kama PHP au Python ambazo zitatekelezwa tu kwa ajili ya kuunda kitu. Lakini ina functions ambazo zinatumika mara kwa mara hata bila kuziita moja kwa moja kama toString
, valueOf
, toJSON
.
Ikiwa unatumia deserialization unaweza kuathiri hizi functions ili kutekeleza code nyingine (kwa uwezekano wa kudhulumu prototype pollutions) unaweza kutekeleza code isiyo na mipaka wanapoitwa.
Njia nyingine "magic" ya kuita function bila kuikalia moja kwa moja ni kwa kuathiri kitu ambacho kinarejeshwa na function ya async (ahadi). Kwa sababu, ikiwa unabadilisha hicho kitu kinachorejeshwa kuwa ahadi nyingine yenye sifa inayoitwa "then" ya aina function, itatekelezwa tu kwa sababu inarejeshwa na ahadi nyingine. Fuata kiungo hiki kwa maelezo zaidi.
__proto__
na uchafuzi wa prototype
Ikiwa unataka kujifunza kuhusu mbinu hii angalia tutorial ifuatayo:
NodeJS - __proto__ & prototype PollutionMaktaba hii inaruhusu kusawazisha kazi. Mfano:
The serialised object will looks like: kitu kilichosawazishwa kitaonekana kama:
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.
As you may see in the last chunk of code, if the flag is found eval
is used to deserialize the function, so basically user input if being used inside the eval
function.
However, just serialising a function won't execute it as it would be necessary that some part of the code is calling y.rce
in our example and that's highly unlikable.
Anyway, you could just modify the serialised object adding some parenthesis in order to auto execute the serialized function when the object is deserialized.
In the next chunk of code notice the last parenthesis and how the unserialize
function will automatically execute the code:
Kama ilivyosemwa awali, maktaba hii itapata msimbo baada ya _$$ND_FUNC$$_
na itau tekeleza kwa kutumia eval
. Hivyo, ili kujiendesha kiotomatiki msimbo unaweza kufuta sehemu ya uundaji wa kazi na mabano ya mwisho na kuendesha tu JS oneliner kama katika mfano ufuatao:
You can find here further information kuhusu jinsi ya kutumia udhaifu huu.
Jambo muhimu kuhusu funcster ni ukosefu wa upatikanaji wa vitu vya ndani vilivyojengwa; vinatoka nje ya upeo unaopatikana. Kikomo hiki kinazuia utekelezaji wa msimbo unaojaribu kuita mbinu kwenye vitu vya ndani, na kusababisha makosa kama "ReferenceError: console is not defined"
wakati amri kama console.log()
au require(something)
zinapotumika.
Licha ya kikomo hiki, urejeleaji wa upatikanaji kamili wa muktadha wa kimataifa, ikiwa ni pamoja na vitu vyote vya ndani vilivyojengwa, inawezekana kupitia njia maalum. Kwa kutumia muktadha wa kimataifa moja kwa moja, mtu anaweza kupita kikomo hiki. Kwa mfano, upatikanaji unaweza kurejelewa kwa kutumia kipande kifuatacho:
Kwa maelezo zaidi soma chanzo hiki.
Kifurushi cha serialize-javascript kimeundwa mahsusi kwa ajili ya kusawazisha, hakina uwezo wowote wa kujisawazisha. Watumiaji wanawajibika kutekeleza njia zao za kujisawazisha. Matumizi ya moja kwa moja ya eval
yanapendekezwa na mfano rasmi wa kujisawazisha data iliyosawazishwa:
Ikiwa kazi hii inatumika ku-deserialize vitu unaweza kuifanyia matumizi kwa urahisi:
Kwa maelezo zaidi soma chanzo hiki.
Katika kurasa zifuatazo unaweza kupata taarifa kuhusu jinsi ya kutumia vibaya maktaba hii ili kutekeleza amri zisizo na mipaka:
Katika Java, kurejelewa kwa deserialization hufanyika wakati wa mchakato wa deserialization. Utendaji huu unaweza kutumiwa na washambuliaji wanaounda payload mbaya zinazochochea kurejelewa hizi, na kusababisha utekelezaji wa vitendo vya hatari.
Ili kubaini uwezekano wa udhaifu wa serialization katika msimbo, tafuta:
Madarasa yanayotekeleza interface ya Serializable
.
Matumizi ya java.io.ObjectInputStream
, readObject
, readUnshare
kazi.
Zingatia kwa makini:
XMLDecoder
inayotumika na vigezo vilivyofafanuliwa na watumiaji wa nje.
Njia ya fromXML
ya XStream
, hasa ikiwa toleo la XStream ni sawa na au chini ya 1.46, kwani linaweza kuwa na matatizo ya serialization.
ObjectInputStream
iliyoambatanishwa na njia ya readObject
.
Utekelezaji wa njia kama readObject
, readObjectNodData
, readResolve
, au readExternal
.
ObjectInputStream.readUnshared
.
Matumizi ya jumla ya Serializable
.
Kwa upimaji wa sanduku la nyeusi, tafuta sahihi maalum au "Magic Bytes" zinazotambulisha vitu vilivyopangwa vya java (vinavyotokana na ObjectInputStream
):
Mchoro wa hexadecimal: AC ED 00 05
.
Mchoro wa Base64: rO0
.
Vichwa vya majibu ya HTTP vyenye Content-type
vilivyowekwa kuwa application/x-java-serialized-object
.
Mchoro wa hexadecimal unaoashiria kufungwa kabla: 1F 8B 08 00
.
Mchoro wa Base64 unaoashiria kufungwa kabla: H4sIA
.
Faili za wavuti zenye kiambishi cha .faces
na parameter ya faces.ViewState
. Kugundua mifumo hii katika programu ya wavuti inapaswa kusababisha uchunguzi kama ilivyoelezwa katika post kuhusu Java JSF ViewState Deserialization.
Ikiwa unataka kujifunza jinsi unavyofanya kazi kwa Java Deserialized exploit unapaswa kuangalia Msingi wa Java Deserialization, Java DNS Deserialization, na CommonsCollection1 Payload.
Unaweza kuangalia kama kuna programu yoyote iliyosakinishwa yenye udhaifu unaojulikana.
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 start using the "URLDNS" payload before a RCE payload to test if the injection is possible. Anyway, note that maybe the "URLDNS" payload is not working but other RCE payload is.
Wakati wa kuunda payload kwa java.lang.Runtime.exec() huwezi kutumia herufi maalum kama ">" au "|" kuhamasisha matokeo ya utekelezaji, "$()" kutekeleza amri au hata kupitisha hoja kwa amri zilizotenganishwa na nafasi (unaweza kufanya echo -n "hello world"
lakini huwezi kufanya python2 -c 'print "Hello world"'
). Ili kuandika payload kwa usahihi unaweza kutumia ukurasa huu.
Jihadharini kutumia skripti ifuatayo kuunda payloads zote zinazowezekana za utekelezaji wa msimbo kwa Windows na Linux kisha uzijaribu kwenye ukurasa wa wavuti ulio hatarini:
You can use https://github.com/pwntester/SerialKillerBypassGadgetCollection pamoja na ysoserial kuunda exploits zaidi. More information about this tool in the slides of the talk where the tool was presented: https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next_slideshow=1
marshalsec inaweza kutumika kuunda payloads za kutumia maktaba tofauti za Json na Yml serialization katika Java.
In order to compile the project I needed to add this dependencies to pom.xml
:
Sakinisha maven, na jenga mradi:
Soma zaidi kuhusu maktaba hii ya Java JSON: https://www.alphabot.com/security/blog/2020/java/Fastjson-exceptional-deserialization-vulnerabilities.html
Ikiwa unataka kujaribu baadhi ya payloads za ysoserial unaweza kuendesha hii webapp: https://github.com/hvqzao/java-deserialize-webapp
Java inatumia serialization nyingi kwa madhumuni mbalimbali kama:
HTTP requests: Serialization inatumika sana katika usimamizi wa vigezo, ViewState, cookies, nk.
RMI (Remote Method Invocation): Protokali ya Java RMI, ambayo inategemea kabisa serialization, ni msingi wa mawasiliano ya mbali katika programu za Java.
RMI juu ya HTTP: Njia hii inatumika mara nyingi na programu za wavuti za Java zenye mteja mzito, zikitumika serialization kwa mawasiliano yote ya vitu.
JMX (Java Management Extensions): JMX inatumia serialization kwa kutuma vitu kupitia mtandao.
Protokali za Kijadi: Katika Java, mazoea ya kawaida yanahusisha usafirishaji wa vitu vya Java vya asili, ambavyo vitadhihirishwa katika mifano ijayo ya exploit.
Darasa linalotekeleza Serializable
linaweza kutekeleza kama transient
kitu chochote ndani ya darasa ambacho hakipaswi kuwa serializable. Kwa mfano:
Katika hali ambapo vitu fulani lazima vitekeleze interface ya Serializable
kutokana na mfuatano wa darasa, kuna hatari ya deserialization isiyo ya makusudi. Ili kuzuia hili, hakikisha vitu hivi havitakavyoweza deserializable kwa kufafanua njia ya final
readObject()
ambayo kila wakati inatupa kosa, kama inavyoonyeshwa hapa chini:
Kubadilisha java.io.ObjectInputStream
ni njia ya vitendo ya kulinda michakato ya deserialization. Njia hii inafaa wakati:
Msimbo wa deserialization uko chini ya udhibiti wako.
Madarasa yanayotarajiwa kwa deserialization yanajulikana.
Pitia resolveClass()
ili kupunguza deserialization kwa madarasa yaliyoruhusiwa tu. Hii inazuia deserialization ya darasa lolote isipokuwa yale yaliyoruhusiwa wazi, kama katika mfano ufuatao unaopunguza deserialization kwa darasa la Bicycle
pekee:
Kutumia Java Agent kwa Kuongeza Usalama inatoa suluhisho la akiba wakati mabadiliko ya msimbo hayawezekani. Njia hii inatumika hasa kwa kuorodhesha madarasa hatari, kwa kutumia parameter ya JVM:
Inatoa njia ya kulinda deserialization kwa njia ya kidinamik, inayofaa kwa mazingira ambapo mabadiliko ya haraka ya msimbo hayawezekani.
Angalia mfano katika rO0 by Contrast Security
Kutekeleza Filters za Serialization: Java 9 ilianzisha filters za serialization kupitia ObjectInputFilter
interface, ikitoa mekanizma yenye nguvu ya kufafanua vigezo ambavyo vitu vilivyohifadhiwa vinapaswa kukutana navyo kabla ya deserialization. Filters hizi zinaweza kutumika kwa kiwango cha ulimwengu au kwa kila mtiririko, ikitoa udhibiti wa kina juu ya mchakato wa deserialization.
Ili kutumia filters za serialization, unaweza kuweka filter ya kimataifa inayotumika kwa shughuli zote za deserialization au kuikamilisha kwa njia ya kidinamik kwa mitiririko maalum. Kwa mfano:
Kutatua Maktaba za Nje kwa Usalama Ulioimarishwa: Maktaba kama NotSoSerial, jdeserialize, na Kryo hutoa vipengele vya juu vya kudhibiti na kufuatilia deserialization ya Java. Maktaba hizi zinaweza kutoa tabaka za ziada za usalama, kama vile kuorodhesha au kuzuia madarasa, kuchambua vitu vilivyohifadhiwa kabla ya deserialization, na kutekeleza mikakati ya kawaida ya serialization.
NotSoSerial inakabili mchakato wa deserialization ili kuzuia utekelezaji wa msimbo usioaminika.
jdeserialize inaruhusu uchambuzi wa vitu vilivyohifadhiwa vya Java bila kuviweka tena, kusaidia kubaini maudhui yanayoweza kuwa na madhara.
Kryo ni mfumo mbadala wa serialization unaosisitiza kasi na ufanisi, ukitoa mikakati ya serialization inayoweza kubadilishwa ambayo inaweza kuimarisha usalama.
Mazungumzo ya Deserialization na ysoserial: http://frohoff.github.io/appseccali-marshalling-pickles/
Mazungumzo kuhusu gadgetinspector: https://www.youtube.com/watch?v=wPbW6zQ52w8 na slaidi: https://i.blackhat.com/us-18/Thu-August-9/us-18-Haken-Automated-Discovery-of-Deserialization-Gadget-Chains.pdf
Karatasi ya Marshalsec: https://www.github.com/mbechler/marshalsec/blob/master/marshalsec.pdf?raw=true
Karatasi ya deserialization ya Java na .Net JSON : https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf,** mazungumzo: https://www.youtube.com/watch?v=oUAeWhW5b8c na slaidi: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf
CVE za Deserialization: https://paper.seebug.org/123/
Pata kile ni JNDI Injection, jinsi ya kuitumia kupitia RMI, CORBA & LDAP na jinsi ya kutumia log4shell (na mfano wa vuln hii) katika ukurasa ufuatao:
JNDI - Java Naming and Directory Interface & Log4ShellAPI ya Java Message Service (JMS) ni API ya Java inayolenga ujumbe kwa kutuma ujumbe kati ya wateja wawili au zaidi. Ni utekelezaji wa kushughulikia tatizo la mtengenezaji-mtumiaji. JMS ni sehemu ya Jukwaa la Java, Toleo la Biashara (Java EE), na ilifafanuliwa na kiwango kilichotengenezwa katika Sun Microsystems, lakini ambayo tangu wakati huo imeongozwa na Mchakato wa Jamii ya Java. Ni kiwango cha ujumbe kinachoruhusu vipengele vya programu vinavyotegemea Java EE kuunda, kutuma, kupokea, na kusoma ujumbe. Inaruhusu mawasiliano kati ya vipengele tofauti vya programu iliyosambazwa kuwa na uhusiano wa kulegea, wa kuaminika, na wa asynchronic. (Kutoka Wikipedia).
Kuna bidhaa kadhaa zinazotumia middleware hii kutuma ujumbe:
Hivyo, kimsingi kuna huduma nyingi zinazotumia JMS kwa njia hatari. Kwa hivyo, ikiwa una mamlaka ya kutosha kutuma ujumbe kwa huduma hizi (kawaida utahitaji akidi halali) unaweza kuwa na uwezo wa kutuma vitu vya hatari vilivyohifadhiwa ambavyo vitakuwa vikiwekwa tena na mtumiaji/mwandikaji. Hii inamaanisha kwamba katika utekelezaji huu wateja wote watakaotumia ujumbe huo wataambukizwa.
Unapaswa kukumbuka kwamba hata kama huduma ina udhaifu (kwa sababu inafanya deserialization ya pembejeo za mtumiaji kwa njia isiyo salama) bado unahitaji kutafuta vifaa halali ili kutumia udhaifu huo.
Zana JMET ilitengenezwa ili kuunganisha na kushambulia huduma hizi kwa kutuma vitu kadhaa vya hatari vilivyohifadhiwa kwa kutumia vifaa vilivyofahamika. Utekelezaji huu utafanya kazi ikiwa huduma bado ina udhaifu na ikiwa mojawapo ya vifaa vilivyotumika iko ndani ya programu iliyo hatarini.
Mazungumzo ya JMET: https://www.youtube.com/watch?v=0h8DWiOWGGA
Katika muktadha wa .Net, matumizi ya udhaifu wa deserialization yanafanya kazi kwa njia inayofanana na zile zinazopatikana katika Java, ambapo vifaa vinatumika kutekeleza msimbo maalum wakati wa deserialization ya kitu.
Msimbo wa chanzo unapaswa kuchunguzwa kwa matukio ya:
TypeNameHandling
JavaScriptTypeResolver
Kipaumbele kinapaswa kuwa kwa serializers zinazoruhusu aina kuamuliwa na variable chini ya udhibiti wa mtumiaji.
Utafutaji unapaswa kulenga mfuatano wa herufi wa Base64 AAEAAAD///// au muundo wowote wa kufanana ambao unaweza kufanywa deserialization upande wa seva, ukitoa udhibiti juu ya aina itakayowekwa tena. Hii inaweza kujumuisha, lakini si kuishia kwenye, muundo wa JSON au XML unaoonyesha TypeObject
au $type
.
Katika kesi hii unaweza kutumia zana ysoserial.net ili kuunda matumizi ya udhaifu wa deserialization. Mara tu unaposhusha hifadhi ya git unapaswa kuunda zana hiyo kwa kutumia Visual Studio kwa mfano.
Ikiwa unataka kujifunza kuhusu jinsi ysoserial.net inavyounda matumizi yake unaweza kuangalia ukurasa huu ambapo inafafanuliwa gadget ya ObjectDataProvider + ExpandedWrapper + Json.Net formatter.
Chaguzi kuu za ysoserial.net ni: --gadget
, --formatter
, --output
na --plugin
.
--gadget
inatumika kuashiria gadget ya kutumia (onyesha darasa/funzo litakalotumika wakati wa deserialization kutekeleza amri).
--formatter
, inatumika kuashiria njia ya kuhifadhi matumizi (unahitaji kujua ni maktaba gani inayotumiwa na nyuma ili kuunda payload na utumie ile ile kuifanya).
--output
inatumika kuashiria ikiwa unataka matumizi katika raw au base64 iliyohifadhiwa. Kumbuka kwamba ysoserial.net itakuwa inaweka payload kwa kutumia UTF-16LE (encoding inayotumiwa kwa kawaida kwenye Windows) hivyo ikiwa unapata raw na kuifanya tu kutoka kwenye console ya linux unaweza kuwa na matatizo ya ufanisi wa encoding ambayo yatakuzuia matumizi kufanya kazi vizuri (katika sanduku la HTB JSON payload ilifanya kazi katika UTF-16LE na ASCII lakini hii haimaanishi itafanya kazi kila wakati).
--plugin
ysoserial.net inasaidia plugins kuunda matumizi ya udhaifu kwa mifumo maalum kama ViewState
--minify
itatoa payload ndogo (ikiwa inawezekana)
--raf -f Json.Net -c "chochote"
Hii itaonyesha vifaa vyote vinavyoweza kutumika na formatter iliyotolewa (`Json.Net katika kesi hii)
--sf xml
unaweza kuonyesha gadget (-g
) na ysoserial.net itatafuta formatters zinazojumuisha "xml" (bila kujali herufi kubwa au ndogo)
Mifano ya ysoserial kuunda matumizi:
ysoserial.net ina parameta ya kuvutia sana inayosaidia kuelewa vizuri jinsi kila exploit inavyofanya kazi: --test
Ikiwa utaashiria parameta hii ysoserial.net itajaribu exploit kwa ndani, ili uweze kujaribu kama payload yako itafanya kazi vizuri.
Parameta hii ni ya msaada kwa sababu ukikagua msimbo utapata vipande vya msimbo kama ifuatavyo (kutoka ObjectDataProviderGenerator.cs):
Hii inamaanisha kwamba ili kujaribu exploit, msimbo utaita serializersHelper.JsonNet_deserialize
In the code ya awali ina udhaifu kwa exploit iliyoundwa. Hivyo ikiwa utapata kitu kinachofanana katika programu ya .Net inamaanisha kwamba labda programu hiyo ina udhaifu pia.
Kwa hivyo --test
parameter inatupa uwezo wa kuelewa ni vipande vipi vya msimbo vina udhaifu kwa exploit ya deserialization ambayo ysoserial.net inaweza kuunda.
Angalia hii POST kuhusu jinsi ya kujaribu ku exploit parameter ya __ViewState ya .Net ili kutekeleza msimbo wa kiholela. Ikiwa tayari unajua siri zinazotumiwa na mashine ya mwathirika, soma hii post kujua jinsi ya kutekeleza msimbo.
Ili kupunguza hatari zinazohusiana na deserialization katika .Net:
Epuka kuruhusu mitiririko ya data kufafanua aina zao za vitu. Tumia DataContractSerializer
au XmlSerializer
inapowezekana.
Kwa JSON.Net
, weka TypeNameHandling
kuwa None
: %%%TypeNameHandling = TypeNameHandling.None%%%
Epuka kutumia JavaScriptSerializer
na JavaScriptTypeResolver
.
Punguza aina ambazo zinaweza ku deserialized, ukielewa hatari zilizopo na aina za .Net, kama System.IO.FileInfo
, ambayo inaweza kubadilisha mali za faili za seva, na hivyo kusababisha mashambulizi ya kukatiza huduma.
Kuwa makini na aina zenye mali hatari, kama System.ComponentModel.DataAnnotations.ValidationException
yenye mali yake ya Value
, ambayo inaweza kutumika vibaya.
Dhibiti kwa usalama uundaji wa aina ili kuzuia washambuliaji kuathiri mchakato wa deserialization, na kufanya hata DataContractSerializer
au XmlSerializer
kuwa na udhaifu.
Tekeleza udhibiti wa orodha nyeupe kwa kutumia SerializationBinder
maalum kwa BinaryFormatter
na JSON.Net
.
Kuwa na habari kuhusu vifaa vya deserialization visivyo salama vilivyojulikana ndani ya .Net na kuhakikisha deserializers hazizalishi aina kama hizo.
Tenga msimbo wenye hatari kutoka kwa msimbo wenye ufikiaji wa mtandao ili kuepuka kufichua vifaa vilivyojulikana, kama System.Windows.Data.ObjectDataProvider
katika programu za WPF, kwa vyanzo vya data visivyoaminika.
Karatasi ya deserialization ya Java na .Net : https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf,** mazungumzo: https://www.youtube.com/watch?v=oUAeWhW5b8c na slaidi: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf
Katika Ruby, serialization inarahisishwa na mbinu mbili ndani ya maktaba ya marshal. Mbinu ya kwanza, inayojulikana kama dump, inatumika kubadilisha kitu kuwa mtiririko wa byte. Mchakato huu unajulikana kama serialization. Kinyume chake, mbinu ya pili, load, inatumika kurudisha mtiririko wa byte kuwa kitu, mchakato unaojulikana kama deserialization.
Ili kulinda vitu vilivyotolewa, Ruby inatumia HMAC (Hash-Based Message Authentication Code), kuhakikisha uadilifu na ukweli wa data. Funguo inayotumika kwa kusudi hili inahifadhiwa katika moja ya maeneo kadhaa yanayowezekana:
config/environment.rb
config/initializers/secret_token.rb
config/secrets.yml
/proc/self/environ
Ruby 2.X generic deserialization to RCE gadget chain (maelezo zaidi katika 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/
Kama ilivyoelezwa katika ripoti hii ya udhaifu, ikiwa ingizo la mtumiaji lisilo safishwa linawasiliana na njia ya .send()
ya kitu cha ruby, njia hii inaruhusu kuita njia nyingine yoyote ya kitu hicho kwa vigezo vyovyote.
Kwa mfano, kuita eval na kisha msimbo wa ruby kama parameter ya pili kutaruhusu kutekeleza msimbo wa kiholela:
Zaidi ya hayo, ikiwa tu parameter moja ya .send()
inadhibitiwa na mshambuliaji, kama ilivyotajwa katika andiko la awali, inawezekana kuita njia yoyote ya kitu ambacho hakihitaji hoja au ambazo hoja zake zina thamani za default.
Kwa hili, inawezekana kuhesabu njia zote za kitu ili kupata baadhi ya njia za kuvutia ambazo zinakidhi mahitaji hayo.
Teknolojia hii ilichukuliwa kutoka kwenye chapisho la blogi hii.
Kuna maktaba nyingine za Ruby ambazo zinaweza kutumika kuunda vitu na hivyo zinaweza kutumika vibaya kupata RCE wakati wa deserialization isiyo salama. Jedwali lifuatalo linaonyesha baadhi ya maktaba hizi na njia wanayoita ya maktaba iliyopakuliwa kila wakati inapoondolewa (kazi ya kutumia vibaya kupata RCE kimsingi):
Maktaba
Data ya ingizo
Njia ya kuanzisha ndani ya darasa
Marshal (Ruby)
Binary
_load
Oj
JSON
hash
(darasa linahitaji kuwekwa kwenye hash(mchoro) kama ufunguo)
Ox
XML
hash
(darasa linahitaji kuwekwa kwenye hash(mchoro) kama ufunguo)
Psych (Ruby)
YAML
hash
(darasa linahitaji kuwekwa kwenye hash(mchoro) kama ufunguo)
init_with
JSON (Ruby)
JSON
json_create
([tazama maelezo kuhusu json_create mwishoni](#table-vulnerable-sinks))
Mfano wa msingi:
Katika kesi ya kujaribu kutumia Oj, ilikuwa inawezekana kupata darasa la gadget ambalo ndani ya kazi yake ya hash
litaita to_s
, ambayo itaita spec, ambayo itaita fetch_path ambayo ilikuwa inawezekana kuifanya ipate URL ya nasibu, ikitoa detector bora wa aina hizi za udhaifu wa deserialization zisizofanyiwa usafi.
Zaidi ya hayo, iligundulika kwamba kwa mbinu ya awali folda pia inaundwa katika mfumo, ambayo ni hitaji la kutumia gadget nyingine ili kubadilisha hii kuwa RCE kamili na kitu kama:
Check for more details in the original post.
Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)