Email atomini bo'lish: kirish nazoratini chetlab o'tish uchun parserlardan foydalanish

Ba'zi veb-saytlar domenni aniqlash va egasi qaysi tashkilotga tegishli ekanligini xulosa chiqarish uchun email manzillarini parslaydi. Aynan shu naqsh email-manzil parseri nomuvofiqliklarini muhim qiladi. Email qaysi domenga yo'naltirilishini oldindan aytish oddiy bo'lishi kerak, ammo bu — hatto "to'g'ri" (valid), RFC talablariga mos manzillar uchun ham — aslida kulgili darajada qiyin.

Ushbu maqolada men sizga email parslash nomuvofiqliklarini kirishni boshqarishni chetlab o'tish (access control bypass) va hatto RCE (kodni masofadan bajarish)ga qanday aylantirish mumkinligini ko'rsataman.

Ushbu maqolaga bepul onlayn CTF ilova qilingan, shuning uchun yangi ko'nikmalaringizni darhol sinab ko'rishingiz mumkin bo'ladi.

Ushbu maqolani chop etish/yuklab olish uchun qulay PDF shaklida ham olishingiz mumkin. Shuningdek, slaydlarni Black Hatdan olishingiz mumkin.

Men ushbu ma'ruzani Black Hat va DEF CON'da taqdim etdim. Uni bu yerda tomosha qilishingiz mumkin: ma'ruza videosi

Kirish

Email manzili formatini belgilaydigan RFC hujjatlarining ba'zilari 50 yildan ortiq vaqtdan beri mavjud; ular birlashtirilib, email manzillari uchun juda ham yumshoq (cheklovlari kam) standartni hosil qilgan. Email manzillarida qo'shtirnoqli qiymatlar, izohlar (comments), escape belgilar va turli xil kodlashlar bo'lishi mumkin. Agar sizga email parserini yozish vazifasi topshirilsa, texnik jihatdan spetsifikatsiyaga amal qilishingiz kerak, lekin bu murakkablik tufayli bu og'ir ish hisoblanadi. Veb-ilovalar bu murakkablikni email parsing kutubxonalariga yuklab qo'yadi va natijada email qanday parslanayotganini o'zlari ham bilishmaydi. Bu esa ular email domenidan xavfsizlik qarorlari qabul qilishga uringanda muammolarga olib keladi.

RFC2822 ning 3.2.5 va 3.2.2-bo'limlariga qarasangiz, u qo'shtirnoqli qiymatlar va escape belgilardan foydalanishga ruxsat berishini ko'rasiz. Bular email manzilining local-part (foydalanuvchi nomi) qismida odatda ruxsat etilmagan belgilardan foydalanish imkonini beradi. Ba'zi misollar:

"@"@example.com
"\""@example.com

Birinchi misolda local-part qo'shtirnoqqa olinganligi sababli, qo'shtirnoqlar olib tashlangach, "at" (@) belgisi manzil pochta qutisi sifatida ishlatiladi. Ikkinchi misol esa qo'shtirnoqli local-part ichida escape belgilardan foydalanib, qo'sh tirnoqni pochta qutisi sifatida qanday ishlatish mumkinligini ko'rsatadi. Xuddi shu RFC ning 3.2.3-bo'limiga chuqurroq qarasak, u izohlarni (comments) qo'llab-quvvatlashini ko'ramiz. Izohlar qavslar yordamida tuziladi va ichida bo'sh joy bo'lishi, hatto ichma-ich joylashishi (nested) ham mumkin. Mana izohlardan foydalanadigan "to'g'ri" email manzillarga misollar:

(foo)user@(bar)example.com

Siz faqat alifbo-raqamli qiymatlar bilan cheklanib qolmaysiz; izoh ichiga juda ko'p turli belgilarni joylashtirishingiz mumkin. Bularning barchasi parser, ilova va mailer (pochta yuboruvchi) o'rtasida chalkashlik yaratish orqali suiiste'mol qilinishi uchun juda qulay ko'rinadi. Mening ushbu tadqiqotdagi sayohatim escape belgilar va izohlarni suiiste'mol qilib, aynan shu chalkashlikni yaratishga urinishdan boshlangan.

Email domenida chalkashlik yaratish

Buni qanday kashf etganim haqidagi hikoyamdan faxrlanmayman, lekin bu haqiqat. Men Postfix va Sendmail manba kodini debugger bilan soatlab tekshirib o'tirmadim va bunda tasodif va omadning ulushi aniq bor.

Bularning barchasi men test uchun ishlatayotgan mashinaga kirganimda boshlandi: nomsiz bir ilovani o'rnatib, uni email parsing nomuvofiqliklariga tekshira boshladim. Hech qanday natija chiqmayotgandi. Nima qilsam ham muvaffaqiyatsizlikka uchrayotgandi va tadqiqotni butunlay tashlab qo'yish haqida o'yladim. Keyin, umidsizlik ta'sirida, ilova ishlatayotgan maxsus belgilarni olib, o'z email manzilimga joyladim. Bu ilova ruxsat bergan barcha belgilar ekanligini bilardim, shuning uchun u to'g'ri (valid) bo'lishini bilardim, lekin shunchaki mailer bilan nima sodir bo'lishini ko'rmoqchi edim.

Mashinaning syslog faylini tekshirdim va noto'g'ri host haqida DSN (delivery status notification — yetkazib berish holati haqida xabarnoma) olayotganimni payqadim. Bundan hayratda qolib, chuqurroq qazishni boshladim. Sendmail nima uchun buni noto'g'ri host deb hisoblayotganini aniqlash uchun email manzilidan belgilarni birma-bir olib tashlay boshladim. Oxir-oqibat, muammo undov belgisiga (!) borib taqalishini aniqladim va tadqiqot davomida o'qigan UUCP protokoli haqida esladim.

UUCP — Internet va email paydo bo'lishidan oldin mavjud bo'lgan qadimiy protokol bo'lib, Unix To Unix Copy so'zlarining qisqartmasidir. U Unix tizimlari o'rtasida xabar yuborish imkonini bergan. U domen va foydalanuvchi qismini ajratish uchun undov belgisidan (!) foydalanadi, ammo an'anaviy email manziliga qarama-qarshi tartibda.

Bu ajablanarli edi: sof omad tufayli men joylagan belgilar backslash (\) bilan tugagan, u esa "at" belgisini escape qilgan, keyin undov belgisi manzilni UUCP manzili sifatida qabul qilgan! Mana mening kashfiyotim to'liq holida:

Asl kashfiyot:

!#$%&'*+\/=?^_`{|}~-collab\@psres.net

Tabiiyki, bu haqiqatan ham boshqa serverga borayotganiga ishonch hosil qilish uchun boshqa Collaborator domeni bilan tekshirib ko'rishim kerak edi:

oastify.com!collab\@example.com

Sendmail 8.15.2 dan foydalanilganda, yuqoridagi misol example.com ga emas, balki Collaborator domeni "oastify.com" ga boradi. Bu meni juda hayajonlantirdi, chunki bu tadqiqot haqiqatan ham biror natijaga olib kelayotganini isbotladim. Keyingi qadam shu xatti-harakatga sabab bo'lgan boshqa belgilarni topish edi, shuning uchun tezda bir SMTP fuzzer yozdim. Postfix bunday xatti-harakatga ega emasligini aniqladim — axir u xavfsizroq, to'g'rimi? Xo'sh, fuzzer yordamida Postfix 3.6.4 da bir variantni topmagunimcha shunday deb o'ylardim:

collab%psres.net(@example.com

Bu aslida example.com ga emas, balki psres.net ga boradi va yana bir qadimiy protokol — source route (manba marshruti) dan foydalanadi. Source route xat yuborish uchun serverlar zanjiridan foydalanish imkonini beradi. G'oya shuki, har bir hostni vergul bilan ajratib, oxirida yakuniy manzilni ko'rsatasiz. Bundan tashqari, "percent hack" deb ataladigan usul ham bor: bunda mailer % belgisini (yoki tanlangan boshqa belgini) "at" belgisiga aylantirib, xatni serverga yo'naltiradi. Quyidagi misol buni ko'rsatadi:

foo%psres.net@example.com
foo@psres.net

Bu jarayonda email dastlab example.com ga yuboriladi, so'ngra foiz belgisi "at" belgisiga aylantirilib, foo@psres.net ga xat yuboriladi. Vektorda aynan shu narsa sodir bo'ladi: qavs email manzilining domen qismini izohga aylantiradi (comment out), shundan so'ng Postfix local-part qismini source route sifatida qabul qilib, xatni kutilmagan manzilga yuboradi. Postfix aslida UUCP ni ham qo'llab-quvvatlaydi — bitta qavs trikidan foydalansangiz, buni keyinroq bilib oldim.

Bu topilmalar menga hali ham juda ko'p xatoliklar (bug) borligiga ishonch berdi, shuning uchun ko'proq izlashni boshladim.

Parser nomuvofiqliklari

Unicode overflowlar

Ushbu tadqiqotda hal qilishim kerak bo'lgan asosiy muammolardan biri — bloklangan belgilarni hosil qilish edi. Chunki ko'plab veb-ilovalar bir nechta "at" belgisini bloklaydi. Shu sababli unicode overflow (unicode to'lib toshishi)ni o'rganishni boshladim.

Nomsiz bir maqsadli tizimni sinab ko'rayotganimda, yuqori unicode belgilaridan foydalanilganda ular boshqa ASCII belgilarini hosil qilishini payqadim. Bu naqsh dastlab tasodifiy ko'rindi, lekin keyin nima bo'layotganini angladim. Buni PHP dagi chr() algoritmi qanday ishlashini ko'rsatadigan rasm orqali eng yaxshi tushuntirish mumkin. chr() funksiyasi butun sonli kod nuqtasi (code point) orqali belgilangan belgini qaytaradi:

Ushbu misolda PHP baytlar bo'ylab aylanib chiqadi va agar bayt noldan kichik bo'lsa, uni musbat bo'lguncha 256 ga qo'shib boradi. Keyin qiymatni 0-255 oralig'iga sig'dirish uchun modul (modulus) amalini bajaradi. Demak, agar siz 255 dan katta bayt qiymatini bersangiz, u modul amali tufayli "to'lib toshadi" (overflow) va majburan 0-255 oralig'iga tushiriladi. Unicode overflow aynan shunday ishlaydi: boshqa belgilarni hosil qilish uchun bizga faqat kod nuqtasi 255 dan katta bo'lgan belgi kerak. Buni oddiy misol bilan eng yaxshi tushuntirish mumkin:

String.fromCodePoint(0x100 + 0x40)

Yuqoridagi misolda belgi hosil qilish uchun fromCodePoint funksiyasidan foydalanaman: o'nlik sanoqda 256 ga teng bo'lgan 0x100 shestnadsatsimal qiymatini beraman, so'ngra "at" belgisining shestnadsatsimal raqami bo'lgan 0x40 ni qo'shaman. Keyin tizim PHP dagi chr() funksiyasi kabi amalni bajarganda, unicode kod nuqtasi to'lib toshadi (overflow) va 0-255 oralig'iga sig'diriladi, natijada "at" belgisi hosil bo'ladi.

Buni kashf etganimdan so'ng, nomsiz maqsadli tizimni Turbo Intruder yordamida fuzzing qila boshladim va boshqa belgilar ham xuddi shunday xatti-harakatni namoyish etayotganini payqadim. Dastlab bu tasodifiy ko'rindi, keyin esa nima bo'layotganini angladim: 0x100 overflow hosil qilish uchun ishlatsa bo'ladigan raqamlardan faqat bittasi, xolos. Agar yuqoriroq belgilardan foydalansangiz, oradagi istalgan belgidan foydalanishingiz mumkin.

String.fromCodePoint(0x100 + 0x40) // ŀ → @
String.fromCodePoint(0x1000 + 0x40) // ၀ → @
String.fromCodePoint(0x10000 + 0x40) // 𐁀 → @
...
0x10ffff

Yuqoridagi shestnadsatsimal qiymatlarning har biri overflow hosil qiladi, chunki modul amali natijasi nolga teng bo'ladi, va bu joriy maksimal unicode kod nuqtasi bo'lgan 0x10ffff gacha davom etishi mumkin. Ushbu maqsadli tizim har xil turdagi unicode belgilariga boshqa belgilarni hosil qilishga ruxsat berardi:

'✨' === '('
'✩' === ')'
'✻' === ';'
'✼' === '<'
'✽' === '='
'✾' === '>'
'❀' === '@'

Agar har bir belgi ustida 256 bo'yicha modul amalini bajarsangiz, hosil qilingan belgi kelib chiqadi:

//Mod each code point by 256
'❀'.codePointAt(0) % 256 === 0x40
String.fromCodePoint(0x40)
// @

Garchi men keng ko'lamdagi belgilarni soxtalashtirib (spoof) chiqarishga muvaffaq bo'lsam-da, ushbu texnika bilan bu nomsiz maqsadli tizimda emailni bo'la olmadim. Ammo bu faqat boshlanishi edi — men bloklangan belgilarni hosil qilish mumkinligini isbotladim. Bu menga ko'proq izlash uchun ishonch berdi.

Encoded-word

Qanchalik ko'proq izlasam, email RFC'lari shunchalik ko'proq narsa berishga tayyor ekanligini angladim. Ushbu tadqiqotdan oldin men email manzillari odatda local-part qismida nuqtalar bilan alifbo-raqamli bo'ladi deb o'ylardim. Bir necha qatlamli kodlashni amalga oshirishga imkon beradigan butun bir murakkab kodlash tizimi mavjudligini hech tasavvur ham qilmagandim. Ammo men aynan shuni kashf etdim. RFC'larni titkilab, rfc2047 va "encoded-word" ga ko'zim tushdi — bu kodlash tizimi belgilarni hex va base64 yordamida ifodalash imkonini beradi.

Kodlangan email manzilini misol sifatida ko'rib chiqsak:

" =? " belgisi encoded-word ning boshlanishini bildiradi, so'ngra charset (belgilar to'plami) ko'rsatiladi — bu misolda UTF-8. Keyin savol belgisi keyingi buyruqni ajratadi, bu "q" bo'lib, "Q-Encoding" degan ma'noni bildiradi, undan keyin yana bir savol belgisi kodlash formatining tugaganini va kodlangan ma'lumotning boshlanganini bildiradi. Q-Encoding shunchaki teng belgisi prefiksi bilan berilgan hex qiymatdir. Ushbu misolda men =41=42=43 dan foydalanaman, bu bosh harflar bilan "ABC" degani. Nihoyat, ?= kodlashning tugaganini bildiradi. Email kutubxonasi tomonidan parslanganda, email manzili ABCUSER@psres.net bo'lib chiqadi!

Ushbu ma'lumot bilan qurollanib, emaillarni shu kodlash yordamida parslaydigan real tizimlarni izlay boshladim. Bunga yordam berish uchun bunday xatti-harakatga ega bo'lgan ko'pchilik saytlarda ishlaydigan ikkita probe (tekshiruv so'rovi) o'ylab topdim:

Dastlab probe hajmini kamaytirish uchun "x" charsetidan foydalanardim, ammo ba'zi tizimlar noma'lum charsetlarni rad etib, muvaffaqiyatsizlikka uchraydi. Ko'plab saytlarni sinab ko'rgandan so'ng, ushbu ikkita probe eng ko'p uchraydigan ruxsat etilgan charsetlar ekanligini aniqladim, shuning uchun aynan shulardan foydalangan ma'qul. Payload hosil qilish uchun Collaborator dan foydalaning va yuqoridagi "collab" o'rniga hosil qilingan qiymatni qo'ying. Shundan so'ng, agar SMTP muloqotining RCPT TO buyrug'ida email bilan SMTP interaction (o'zaro ta'sir) olsangiz:

abccollab@psres.net

Bu email parseri "encoded word" yordamida emailni dekodlayotganini isbotlaydi.

Bunday xatti-harakatga ega bir qancha saytlarni topdim va ularning barchasida bitta umumiy jihat bor edi: Ruby. Ma'lum bo'lishicha, ularning barchasi 508 milliondan ortiq marta yuklab olingan "Mail" nomli bir xil Ruby Gem'idan foydalanar ekan. Manba kodini ko'zdan kechira boshladim va bu kutubxona UTF-7 ni dekodlayotganini aniqladim! O'z test muhitimda buni qayta hosil qilishga urindim:

Bu aqldan ozdiradigan holat! Endi emaillarda UTF-7 bo'lishi mumkin! Keyin miyamga bir fikr keldi: agar Q-Encoding va charsetlar mavjud bo'lsa, ikkalasini birga ishlatib bo'ladimi? Bu savolga ajablanarli javob — qat'iy ravishda ha. UTF-7 ni Q-Encoding bilan aralashtirib (blend) ishlatish mumkin!

Shundan so'ng base64 kodlash bilan o'ynay boshladim, chunki albatta "encoded-word" emaillarda uni ham qo'llab-quvvatlaydi! Kodlash turida shunchaki "q" o'rniga "b" dan foydalanish kifoya.

Yuqoridagi misolda base64 bilan kodlangan "foobar" satridan foydalanilgan, u parser tomonidan dekodlanadi. Nima o'ylayotganingizni bilaman, yoki balki bu faqat menga xosdir, lekin ha — UTF-7 va base64 bilan kodlangan ma'lumotni birga ishlatish mumkin:

Ushbu misolda UTF-7 charsetli, base64 bilan kodlangan manzil bor. Avval email parseri base64 ni dekodlaydi. Keyin email parseri UTF-7 charsetni dekodlaydi. Oxir-oqibat email foobar@psres.net ga dekodlanadi. Shu bosqichda RFC ga so'zma-so'z amal qilish haqida bir necha shubhalaringiz paydo bo'lishi mumkin. Ayniqsa, Mail kutubxonasini sinab ko'rganimda bu domen qismida ham ishlashini aytsam. Diqqat qiling, men bu yerda alifbo-raqamli qiymatlardan foydalanyapman, lekin albatta istalgan maxsus belgilarni ham kodlash mumkin.

Encoded-word bo'yicha amaliy tadqiqotlar

Github: Cloudflare "Zero Trust" bilan himoyalangan ichki tarmoqlarga kirish

Hozirgacha email domen chalkashligini yaratish va kutilmagan kodlashlarni ko'rdik, lekin endi shu bilimni real tizimlarni ekspluatatsiya qilish uchun ishlatish vaqti keldi. Men sinab ko'rgan birinchi maqsadli tizimlardan biri Github edi. Men aynan Github ga o'tdim, chunki uning Ruby'da yozilganini bilardim.

Github "encoded-word"ni qo'llab-quvvatlashini tasdiqlash uchun ilgari aytib o'tgan ikkita probe'dan foydalandim. Email Collaborator SMTP muloqotida dekodlandi! Shundan so'ng testlashni davom ettirdim. Menga kerak bo'lgan narsa "encoded-word" yordamida yana bir "at" belgisini hosil qilish edi. Avval qo'shtirnoqli local-part qiymatlari bilan o'ynay boshladim va qo'shtirnoqli qiymat ichiga xom "at" belgilarini joylashtirishga muvaffaq bo'ldim. Balki qo'shtirnoqli local-part ichida "encoded-word"dan foydalanib, qo'shtirnoqli qiymatdan chiqib, ikkita turli manzil hosil qilsam bo'larmikan? =22 (qo'sh tirnoq) va =40 ("at" belgisi) bilan tajriba qildim, lekin muvaffaqiyatga erisha olmadim.

Ushbu tadqiqotdagi muammo shundaki, ba'zan hech qanday fikr-mulohaza (feedback) olmaysiz, chunki u email validatsiyasidan o'tadi, lekin mailer'ga yetib bormasdan oldin muvaffaqiyatsizlikka uchraydi. Ipucha sifatida DNS interactionlaridan foydalanish mumkin, lekin ular ko'pincha deyarli foydasiz, chunki mailer'ga yetib bormaslik sababini aniqlay olmaysiz.

Ko'p urinishlardan so'ng SMTP muloqoti haqida o'ylay boshladim va "katta" (>) belgilarini joylashtirishga urindim. Bu yerdagi fikr shu ediki, undan SMTP muloqotidagi RCPT TO buyrug'ini tugatish uchun foydalanishim mumkin edi:

RCPT TO:<"collab@psres.net>collab"@psres.net>

Yuqoridagi misolda xom "at" belgisi va "katta" belgisiga ega qo'shtirnoqli local-part ko'rsatilgan. Endi hujum qanday shakllanishi mumkinligini ko'ra boshlaysiz. Sizda ikkita manzil bor, va "katta" belgisidan foydalanish g'oyasi SMTP muloqotida ikkinchi manzilni e'tiborsiz qoldirish imkonini beradi. Shu g'oyani miyamga mahkam o'rnatib, hujum qurish uchun kodlangan vektorlardan foydalana boshladim.

Tez orada qo'sh tirnoqlar Github uchun foydasiz ekanligini aniqladim, chunki bu doim ochiq qo'sh tirnoq qoldirib, validatsiyadan o'tmasdi. Albatta uni kodlash va escape qilishga ham urindim, lekin muvaffaqiyatsiz. Tirnoqlarni olib tashlab, "at" belgisi va "katta" belgisini hosil qilish uchun "encoded-word"dan foydalandim — bu validatsiyadan o'tdi, lekin email kelmadi. SMTP muloqoti yo'q. Hech narsa. Shu haqda o'ylab, balki emailning oxiridagi keraksiz qoldiq (junk) Mailer'ni istisno (exception) yoki validatsiya bilan muvaffaqiyatsizlikka uchratayotgandir deb o'yladim. Agar istisno yoki validatsiyadan qochadigan biror belgi kiritsam-chi? Kodlangan bo'sh joy bilan sinab ko'rdim, lekin bu ham ishlamadi, keyin kodlangan null bilan sinadim va bingo! Quyidagi email bilan interaction (o'zaro ta'sir) oldim:

Github uchun charset ahamiyatsiz, shuning uchun "x"dan foydalandim: kodlangan "at" belgisi (=40) "at"ga aylantiriladi, "katta" belgisi (=3e) RCPT TO buyrug'ini tugatadi, va nihoyat null (=00) mailer'ga undan keyingi hamma narsani e'tiborsiz qoldirishga majbur qiladi. Kodlangandan keyin to'g'ri local-part joylashtirish kerak, shuning uchun "foo"dan foydalandim — bu muvaffaqiyatli validatsiyadan o'tib, emailni bo'ladi. Shundan so'ng o'zim xohlagan istalgan email domenini tasdiqlashim (verify) mumkin edi. Test hisobimda microsoft.com, mozilla.com va github.com bilan manzillarni tasdiqlagan edim:

Bu allaqachon bug (xatolik) edi, chunki siz egalik qilmagan manzillarni tasdiqlay olmasligingiz kerak. Keyin hamkasbim James Kettle Cloudflare "Zero Trust"ni ko'rib chiqishni va uni muayyan email domenlariga ishonadigan qilib sozlash mumkinligini tekshirishni taklif qildi. Men test hisobi yaratib, sozlamalarni titkiladim va Github'dan IdP (identifikatsiya provayderi) sifatida foydalanish hamda saytga kirish huquqini aniqlash uchun email domenidan foydalanish mumkinligini aniqladim. Bu Github'ni IdP sifatida ishlatadigan ichki tarmoq yoki Zero Trust bilan himoyalangan istalgan boshqa domen bo'lishi mumkin edi.

Zendesk: Email domeni bilan himoyalangan support markazlariga kirish

Github bilan muvaffaqiyatga erishganimdan so'ng, Ruby'dan foydalanadigan va qandaydir email domen validatsiyasiga ega ilovalarni izlay boshladim. Menga ko'zga tashlangan bittasi Zendesk edi, chunki balki himoyalangan support (yordam) markaziga kirish mumkindir? Email manzillarini bo'lishga urinishdan oldin, ularning hujjatlarini ko'zdan kechirdim va support markazini yoqish, ro'yxatdan o'tishga ruxsat berish va keyin ro'yxatdan o'tishga ruxsat etilgan domenlarni tanlash kerakligini aniqladim.

Support markazi sozlangan edi va men testlashni boshladim. Github'da ishlatgan barcha hujumlarni sinab ko'rdim, lekin muvaffaqiyatsiz. Balki ular boshqa mailer yoki validatsiyadan foydalanayotgandir? Emailning qo'shtirnoqli local-part qismidan foydalanib bir nechta yangi g'oyalarni sinadim, va Collaborator'da olgan interactionlarim Github'ni sinaganimga qaraganda ko'proq umidvor ko'rindi.

Foydali deb topgan narsam — ikkita bir xil Collaborator domenidan foydalanish edi, shunda men doim interaction olardim va SMTP muloqotini o'rganib, nima o'zgartirilayotganini ko'rish mumkin edi. Men quyidagini yubordim:

Input:
=?x?q?=41=42=43collab=40psres.net=3e=20?=@psres.net

Va quyidagini oldim:

Output:
RCPT TO:<"ABCcollab@psres.net> "@psres.net>

Bu interaction menga bir qancha narsalarni aytib berdi: birinchidan, ular bosh harflarga ruxsat beradi. Ikkinchidan, ular o'zgartirilgan bo'sh joylarga ruxsat beradi, va uchinchidan, ular dekodlanganda local-part'da odatda ruxsat etilmagan qiymatlarni qo'shtirnoqqa olib qo'yayotganga o'xshaydi. Balki shu xatti-harakatni suiiste'mol qilsam bo'larmikan?

Yana ko'p urinishlardan so'ng, nihoyat biror natijaga erishdim. Parsing/validatsiyani bloklangan belgilarni o'zgartirishga, ikki karra kodlangan tirnoqlarga va ularning kodi tomonidan olib tashlanadigan belgilarni hosil qilishga aldadim, toki oxir-oqibat to'g'ri (valid) email-splitting hujumini qurdim:

Ushbu "email"dan foydalanib, support markaziga qo'yilgan cheklovlarni chetlab o'ta oldim. Ushbu hujumning kaliti — parser tomonidan dekodlanadigan ichki kodlangan tirnoqlar edi. Keyin =3c22 "kichik" belgisini hosil qiladi, u olib tashlanadi va shu orqali tirnoq to'liq bo'lib, ularning validatsiyasi/istisnolaridan o'tadi. "=3e=00" Github'da ishlatgan izlanish bilan bir xil ekanligini payqaysiz, shuning uchun ular aftidan bir xil kodning bir qismini baham ko'rishadi, lekin ularning javob berish tarzi ancha farq qildi, shu sababli hujum ancha murakkabroq bo'ldi.

Gitlab: Gitlab Enterprise serverlariga ruxsatsiz kirish

Yana Ruby'ga asoslangan yangi maqsad izlab, Gitlab'ga murojaat qildim. Ular IdP hisoblanadi va Enterprise mahsulotini taklif qiladi, shuning uchun yaxshi sinov nishoni bo'lib ko'rindi. James ilgari sinab ko'rgan Gitlab serveri bor edi, shuning uchun avval o'shani ko'rib chiqa boshladim. Uni muayyan domen bilan ro'yxatdan o'tishga ruxsat beradigan qilib sozlash mumkin edi. Bu darhol e'tiborimni tortdi. Github va Zendesk'da ishlatgan vektorlarni sinab ko'rdim, lekin ular ishlamadi. Keyin "encoded-word" bo'sh joy o'rniga pastki chiziq (underscore) ishlatishga ruxsat berishini esladim, va bu vektor hozirgacha ko'rsatganlarim orasida eng nafis (elegant) bo'ldi:

Men sozlangan Enterprise nusxasining mailer'i sifatida Postfix'dan foydalandim. Xuddi shu narsani =20 bilan ham qilish mumkin, lekin pastki chiziq faqat 1 ta belgi, va men nafis vektorlarni yaxshi ko'raman!

Demak, men domenga asoslangan ro'yxatdan o'tish cheklovlaridan foydalanadigan Gitlab Enterprise serverlariga kira olardim. Aytganimdek, Gitlab shuningdek IdP hamdir, shuning uchun veb-ilovani ham sinay boshladim. Bu yerda Enterprise hack ishlamadi. O'ylaymanki, buning sababi ular boshqa Mailer'dan foydalanishidir. Biroq, boshqa vektorni topish uchun ko'p vaqt kerak bo'lmadi. Bu vaqtga kelib ko'plab vektorlar to'plagan edim, shuning uchun barcha ma'lum vektorlar bo'ylab o'tadigan va boshqalarini ham sinab ko'radigan Turbo Intruder skriptim bor edi. U kodlangan bo'sh joydan foydalanadigan yangi vektorni topdi — bu mantiqan to'g'ri edi, chunki bu Enterprise mahsulotida ishlagan, faqat ekspluatatsiya qilish uchun boshqacha usul talab qilinardi:

Bu Github ekspluatiga juda o'xshash, lekin to'g'ri charset talab qilingan va null emas, bo'sh joy kerak bo'lgan. Diagrammada "x"dan foydalandim, lekin haqiqiy hujumda "iso-8859-1"dan foydalanasiz.

PHPMailer

Afsuski, sinab ko'rgan hamma narsani ekspluatatsiya qila olmadim va ko'plab muvaffaqiyatsizliklar bo'ldi. Har biri o'rganish jarayoni edi, lekin ushbu case study (holat tahlili)ning qiziqarli tomoni shundaki, "encoded-word" Ruby'ga asoslanmagan tizimda ham parslanib, dekodlanardi.

James ning maslahati bilan allaqachon test muhiti qurgandim, shuning uchun PHPMailer emaillarni qanday parslashini sinay boshladim. Black-box va white-box testlashning aralashmasini qildim va u "encoded-word"ni email manzilining local-part yoki domen qismida parslamasligini aniqladim. Biroq, u email manzilidan tashqarida joylashgan ism (name) qismida buni parslab, dekodlar edi!

=?utf8?q?=61=62=63?=<collab@psres.net>

Kodni tahlil qilganimda burchakli qavslar talab qilinishini aniqladim, bu esa Wordpress kabi ilovalarda ko'pincha validatsiyadan o'tmasligini anglatardi. Turli ilovalarning name (ism) parametriga payloadlar joylashtirishga urindim, lekin aynan shu kutubxonani ekspluatatsiya qila olmadim. Shunga qaramay, "encoded-word" bilan XSS (saytlararo skript ishga tushirish) payloadlarini joylashtirish mumkinligiga va bu qayerdadir ishlashiga ishonaman. Agar buni amalga oshirsangiz, iltimos men bilan bog'laning — bu haqda eshitishni juda xohlardim.

Punycode

Biz allaqachon kirishni boshqarish (access control)ni chetlab o'tish uchun email parslashni qanday boshqarish mumkinligini ko'rib chiqdik. Ammo keling, masalani biroz uzoqroqqa olib boraylik. Agar email manzili RCE (Remote Code Execution — kodni masofadan bajarish)ga erishish uchun qurolga aylantirilsa-chi? Ushbu bo'limda Punycode hujumlari va Joomla'ni qanday ekspluatatsiya qilganim haqida gaplashamiz.

Punycode nima?

Punycode — joriy DNS tizimida unicode belgilarini ifodalash usuli. Punycode har doim xn-- bilan boshlanib, undan keyin defis va alifbo-raqamli belgilar keladi. ASCII bo'lmagan belgilar bu belgilarni ifodalaydigan maxsus algoritm yordamida kodlanadi. Algoritm Unicode belgilar ketma-ketligini faqat ASCII belgilardan foydalanadigan ifodaga aylantiradi. Algoritm shuni belgilaydiki, kiritilgan ma'lumotdagi unicode belgilarini hosil qilmaydigan ASCII belgilar odatda o'zgarishsiz chiqishga qo'shiladi. Masalan, münchen.com domeni quyidagi Punycode ketma-ketligi bilan kodlanadi.

xn--mnchen-3ya.com

Punycode ishlash tabiatining o'zi uni sinashni qiyinlashtiradi, chunki algoritm ishlash tarzi tufayli bitta belgini o'zgartirish butun chiqishga va belgi pozitsiyasiga ta'sir qilishi mumkin. Bizga kerak bo'lgan narsa — kodlangan qiymat dekodlanganda zararli belgilarni hosil qilish, va buni amalga oshirish katta muammo. Quyidagi misollarda bitta bayt o'zgartirilganda unicode belgisining pozitsiyasi qanday o'zgarishini ko'rishingiz mumkin.

foo@xn--mnchen-2ya.com → foo@ümnchen.com
foo@xn--mnchen-3ya.com → foo@münchen.com
foo@xn--mnchen-4ya.com → foo@mnüchen.com
foo@xn--mnchen-5ya.com → foo@mncühen.com

Buzilgan Punycode

Bu haqda Wikipedia'da hammasini o'qib chiqqanimdan so'ng, online Punycode konvertoriga havolani bosdim. Konvertor IDN PHP kutubxonasidan foydalanardi, va men turli Punycode manzillarini sinab ko'ra boshladim. Agar boshida ikkita nol ishlatilsa, kutilmagan belgilarni hosil qilish mumkinligini aniqladim:

Input:
psres.net.com.xn--0049.com.psres.net

Output:
psres.net.com.,.com.psres.net

Bu buzilgan (malformed) Punycode yaratishga birinchi muvaffaqiyatli urinishim edi. Kirishda "xn--0049" Punycode qiymati bor, u nuqsonli kutubxona tufayli vergulga dekodlanadi. Ushbu texnika yordamida yana ko'plab belgilarni hosil qila oldim:

Input:
foo@xn--0117.example.com

Output:
foo@@.example.com

Bir xil belgini hosil qilishning ko'plab usullari bor edi. Email-splitting hujumlari haqida o'yladim, lekin Punycode manzili email yuborilganda dekodlanmasligiga xulosaga keldim, chunki u noto'g'ri (invalid) bo'lardi. Uning email ko'rsatilganda (display) dekodlanishi ehtimoli ancha yuqori. Tabiiyki, o'zimga bergan savol shu edi: XSS vektorini yaratish mumkinmi?

Bu fuzzer uchun ish edi. Men birini qura boshladim va u darhol qiziqarli natijalar bera boshladi:

x@xn--42 → x@,
x@xn--024 → x@@
x@xn--694 → x@;

x@xn--svg/-9x6 → x@<svg/
x@xn--svg/-f18 → x@<svg/
x@xn--svg/-fq1 → x@<svg/

IDN PHP kutubxonasidan foydalanadigan ilovalarni topish uchun yaxshi payt keldi deb o'yladim. Github'da qidiruv qilib, ushbu kutubxonadan foydalanadigan qiziqarli maqsadni topdim: Joomla! Bu ajoyib edi, chunki agar XSS olsam, RCE ham olaman. Manba kodini tahlil qilganimda, ular foydalanuvchi emailini Punycode dekodlanishidan oldin escape qilishlarini payqadim. Demak, agar men dekodlanganda HTML hosil qiladigan buzilgan Punycode yarata olsam, XSS olishim mumkin edi, lekin bu unchalik oson bo'lmasdi.

Joomla'ni ekspluatatsiya qilishga urinish

Hayajon bilan fuzzerimga qaytib, millionlab belgi kombinatsiyalarini hosil qila boshladim. Qisman XSS vektorlarini qurishga muvaffaq bo'ldim, lekin bir necha muammoga duch keldim. Faqat bitta emas, bir nechta Punycode subdomenidan foydalanib, atigi ikkita ASCII belgisini hosil qila olardim. Bu cheklov Punycode algoritmi, PHP va nuqsonli PHP IDN kutubxonasining o'ziga xos ishlash tarzidan kelib chiqardi. Misollarda ko'rganingizdek, men yaqin edim, lekin bu muammolar Joomla'ni ekspluatatsiya qilishni juda qiyinlashtirdi.

xn--x-0314.xn--0026.xn--0193.xn--0218 → <x.. .=
xn--x-0314.xn--0026.xn--0193.xn--54_52932 → <x.. .='

XSS amalga oshmasligiga xulosaga keldim, chunki garchi bitta tirnoqli HTML atributini hosil qila olsam-da, bu pastki chiziq (underscore) belgisini talab qilardi. Biroq, Joomla email manzilining domen qismida pastki chiziqqa ruxsat bermaydi.

Joomla'ni ekspluatatsiya qilib RCE olish

Xo'sh, hikoya shu bilan tugadimi? Unchalik emas. Bu haqda bir muddat o'yladim va agar bitta Punycode subdomenidan foydalansangiz, istalgan ochuvchi tegni (opening tag) hosil qilish mumkinligini aniqladim! Oxir-oqibat ko'p testlashdan so'ng, yagona ekspluatatsiya qilinadigan vektor ochuvchi style tegi ekanligiga xulosaga keldim:

Joomla'ning mavjud HTML kodining qolgan qismi bo'sh joy va yopuvchi burchakli qavsni qo'shar edi. Email foydalanuvchilar ro'yxati sahifasida chiqarilardi. Bu uning persistent (doimiy) ekanligini va hatto faollashtirilgan hisob talab qilmasligini anglatardi. Siz shunchaki foydalanuvchi ro'yxatdan o'tkazsangiz bo'ldi, va bu doimiy style injection bo'lardi! Ammo yovuz CSS'imizni u yerga qanday kiritamiz? Buning uchun CSS'ni bloklanmasdan joylashtiradigan joy kerak. Foydalanuvchining name (ism) maydoni buning uchun yaxshi tanlov edi, va yovuz uslubni import qilish uchun @import'dan foydalanish mumkin edi.

Duch kelgan muammo shu ediki, style injection'dan keyin keladigan barcha HTML kodi CSS sifatida qabul qilinardi! Buni chetlab o'tish uchun shunchaki CSS parserini bularning bari noto'g'ri (invalid) CSS selektori deb o'ylashga aldash kerak, buning uchun {} dan foydalanish kifoya. Shunday qilib, agar name maydonining boshida shuni joylasangiz, keyin bir uslubni import qilishingiz mumkin. Hujum quyidagicha ishlaydi:

E'tibor bering, birinchi hisob nomida "a" bor, ikkinchisida esa "x" bor — bu style injection avval sodir bo'lishini va ikkinchi hisob @import ishlatishini ta'minlash uchun. Jingalak qavslar import'dan oldin keladigan barcha HTML'ni noto'g'ri CSS selektori sifatida qabul qilish uchun ishlatiladi. Chrome'ning qat'iy CSS mime type tekshiruvi bu yerda ham qo'llanilmaydi, chunki inline style ishlatilgan.

Endi bizga kerak bo'lgan narsa CSRF (saytlararo so'rovni soxtalashtirish) tokenini CSS orqali exfiltratsiya qilish edi, va yaxshiyamki bu haqda ko'plab yaxshi maqolalar bor. Eng yaxshi usul — import chaining (import zanjirlash)dan foydalanish va d0nut hamda Pepe Vila tomonidan ishlab chiqilgan vositalardan birini ishlatish. Men o'zimning blind CSS exfiltration tadqiqoti doirasida allaqachon ishlab chiqqan vositani moslashtirishga (customise) qaror qildim, bu esa uni aynan Joomla tokenini olib chiqadigan qilish edi. Moslashtirilgan kodni maqolaning keyingi qismida Github repo'sida bo'lishaman.

CSS exfiltratorim ishlab turgan holda, ikkita hisobni ro'yxatdan o'tkazdim va super admin hisobi bilan foydalanuvchilar sahifasiga tashrif buyurdim. Exfiltrator admin'ning CSRF tokenini ko'rsatdi, shuning uchun keyingi qadam — olingan tokendan foydalanadigan CSRF ekspluatini admin'ga yetkazish edi. Mening exfiltratorim shuningdek CSRF eksploitini ham quradi. Eksploit keyin RCE olish uchun admin shablonini (template) o'zgartiradi!

Hujum namoyishini video ko'rinishida bu yerda tomosha qilishingiz mumkin: hujum namoyish videosi

Videoda chapda och ranglar bilan admin brauzeri, o'ngda esa to'q ranglar bilan hujumchining brauzeri ko'rsatilgan. Hujumchi ikkita hisob ro'yxatdan o'tkazadi: birinchisi buzilgan Punycode manzilidan style tegini kiritish uchun, ikkinchisi esa CSS exfiltratsiya uslub jadvalini (stylesheet) kiritish uchun. Keyin admin backend va foydalanuvchilar ro'yxati sahifasiga tashrif buyuradi, zararli CSS bir zumda yuklanadi va bir necha soniya ichida tokenni exfiltratsiya qiladi.

Bu sodir bo'lishi bilanoq, hujumchi admin'ning CSRF tokeni haqida xabardor qilinadi va admin bilan tezkor xabar (instant message) suhbatini boshlaydi. Admin hujumchidan kelgan havolani bosadi va backend shablonini tahrirlashga CSRF qilinadi, bu esa system buyrug'ini chaqirib cat /etc/passed ni bajaradigan PHP kodini kiritadi.

Metodologiya/Vositalar

Ushbu tadqiqotni olib borar ekanman, testlashda foydali deb topgan metodologiyani ishlab chiqdim: Probe, Observe, Encode va Exploit (tekshirish, kuzatish, kodlash va ekspluatatsiya qilish). Avval ushbu maqolada aytib o'tilgan probe'lardan foydalaning, keyin natijalarni Collaborator kabi vositada kuzating. Hujumingiz uchun kerakli belgilarga ega bo'lguningizcha jarayonni takrorlang. Shu jarayon tugagach, ekspluatatsiyani amalga oshiring. Ushbu metodologiyani ham encoded-word, ham Punycode hujumlariga qo'llashingiz mumkin.

Avval "encoded-word" uchun probe qiling, uning qo'llab-quvvatlanishini tasdiqlash uchun dekodlangan emailni kuzating. Keyin turli belgilarni kodlang va ularning qanday dekodlanishini kuzating. Shundan so'ng ushbu belgilarni suiiste'mol qiladigan ekspluat bilan davom eting.

Natijalarni kuzatish uchun SMTP interactionlarini ko'rish imkonini bergan Burp Collaboratordan foydalandim.

Hackvertor teglari bilan email-splitting hujumlarini hosil qilish

Email-splitting hujumlarini topishga yordam berish uchun bir nechta Hackvertor teglarini yaratdim. Hackvertor — men yozgan bepul Burp Suite kengaytmasi bo'lib, so'rovda teglardan foydalanish va ma'lumot ustida ichma-ich (nested) o'zgartirishlar qilish imkonini beradi. Siz shunchaki tegni unicode overflow sodir bo'lishini xohlagan joyga qo'yasiz, so'ngra o'zgartirmoqchi bo'lgan belgilarni teg ichiga joylashtirasiz:

<@_unicode_overflow(0x100,'...')>@</@_unicode_overflow>
<@_unicode_overflow_variations(0xfff,'...')>@</@_unicode_overflow_variations>
foo<@_encoded_word_encode('...')>@<@/_encoded_word_encode>example.com
<@_encoded_word_decode('...')>=41=42=43<@/_encoded_word_decode>
<@_email_utf7('...')></@_email_utf7>
<@_email_utf7_decode('...')></@_email_utf7_decode>
<@_encode_word_meta('iso-8859-1','...')></@_encode_word_meta>

Birinchi teg bitta unicode overflow hosil qiladi va overflow yaratish uchun o'nlik sanoqda 256 ga teng bo'lgan 0x100 teg argumentidan foydalanadi. Ikkinchisi teg argumentini maksimal unicode kod nuqtasi sifatida ishlatib, teg ichida ko'rsatilgan belgiga overflow bo'ladigan imkon qadar ko'p belgini hosil qiladi. Uchinchi teg sizga encoded-word konvertatsiyasini amalga oshirish imkonini beradi, misolda men @ belgisini kodlayman. To'rtinchi teg encoded-word ketma-ketligini dekodlaydi. UTF-7 emaillarni va encoded-word meta belgilarini yaratish va dekodlashga yordam beradigan yana boshqa teglar ham bor.

Ushbu teglardan foydalanish uchun Hackvertor menyusida "Allow code execution tags" (kod bajarish teglariga ruxsat berish)ni yoqishingiz kerak. Keyin xuddi shu menyudagi "View Tag Store"ni bosing. Shundan so'ng ikkala tegni ham ularning nomini bosib, keyin o'rnatish tugmasidan foydalanib o'rnatishingiz mumkin.

Turbo Intruder yordamida encoded-word ekspluatatsiyasini avtomatlashtirish

Birinchi bir nechta xatoliklarni topganimda, boshqa xatoliklarni topish uchun avtomatlashtirish juda foydali ekanligini bildim, va ko'pincha Turbo Intruder bu jarayonni avtomatlashtirishda juda foydali bo'ldi. Turbo Intruder — James Kettle tomonidan yozilgan yana bir bepul Burp kengaytmasi. Mailer'ni ekspluatatsiya qilishga yordam berish uchun Turbo Intruder skriptini yaratdim. Ushbu skript server encoded-word'ni qo'llab-quvvatlashini aniqlagan, lekin mailer null yoki boshqa belgilardan foydalanib emailni bo'lishga ruxsat berishini bilmoqchi bo'lgan holatlarda ishlatiladi.

U Github, Zendesk, Gitlab, Bugcrowd va boshqa ko'plab tizimlarni sinab ko'rish paytida kashf etgan, emailni bo'ladigan ma'lum texnikalar ro'yxatidan foydalanadi. Skriptni ushbu taqdimotda aytib o'tilgan boshqa hujumlarni amalga oshirish uchun osongina moslashtirish mumkin. Undan foydalanish uchun shunchaki validServer o'zgaruvchisini soxtalashtirmoqchi bo'lgan maqsadli domeningizga o'zgartirishingiz kerak. Keyin so'rovda email qo'shilishini xohlagan joyga %s ni joylashtirasiz, so'ngra so'rovni o'ng tugma bilan bosib, Turbo Intruder'ga yuborasiz va o'zgartirilgan skriptdan foydalanasiz. Keyin hujumni ishga tushiring. Agar hujum ishlasa, Turbo Intruder ichida collaborator interaction olishingiz kerak. Bu email domeni soxtalashtirilishi mumkinligini anglatadi. Agar (men duch kelganimdek) reyting cheklovlariga (rate limit) ega ilovalarga duch kelsangiz, o'sha serverlar bilan yaxshi muomala qilish uchun REQUEST_SLEEP o'zgaruvchisini o'zgartirishingiz mumkin.

Buzilgan Punycode uchun fuzzing

Buzilgan Punycode topishga yordam berish uchun Punycode fuzzer yaratdim. Uni PortSwigger hamkasblarim bilan bo'lishdim va mening cheklovlarim doirasida kimdir XSS vektorini hosil qila oladimi yo'qmi, buni ko'rish uchun bir sinov (challenge) yaratdim. Hech kim bunga erisha olmadi, lekin men baribir CSS exfiltratsiyasi orqali RCE oldim. Fuzzer Punycode manzili bilan qandaydir kirish ma'lumotini berish orqali ishlaydi, va joy egallovchilar (placeholder) tasodifiy raqamlar, belgilar yoki bo'sh joylar bilan almashtiriladi. Matches va contains esa fuzz qilingan chiqishga mos keladigan oddiy regex'lar. Bu qanday belgilar hosil qilinishi mumkinligini topishda juda samarali bo'ldi.

Bonus material

DEF CON'da qo'shimcha 5 daqiqa vaqtim bo'lgani uchun bir nechta bonus vektorlarni taqdim etdim.

RFC SMTP optional parameters (ixtiyoriy parametrlar) deb ataladigan narsalarga ruxsat beradi. Parametrlardan biri bo'lgan "ORCPT" email manzilining domen qismini yashirincha o'tkazish (smuggle) va uning manzilini o'zgartirish uchun ishlatilishi mumkin. Ko'plab ilovalar ko'pincha qo'shtirnoqli local-part'ni qabul qiladi, lekin escape belgilarni noto'g'ri ishlaydi, shuning uchun bundan foydalanib email manzilini o'zgartirish uchun suiiste'mol qilish mumkin:

"foo\\"@psres.net> ORCPT=test;admin"@example.com

Bu texnika Postfix'da ishlaydi, ehtimol boshqa mailer'larda ham ishlar.

Yana bir bonus sifatida, mana Postfix'da ishlaydigan va men aniqlagan yana bir necha kutilmagan email parslash xatti-harakati. Bulardan access control (kirishni boshqarish)ni chetlab o'tish uchun foydalana olmadim, lekin shunga qaramay ular qiziqarli va email manzillari qanday parslanishi haqidagi taxminlaringizga qarshi chiqadi. Birinchisi UUCP'dan foydalanadi va tirnoqlardan qat'i nazar yuboriladi.

Input: "psres.net!collab"(\"@example.com
Results in email to: collab@psres.net

Ikkinchisi esa kvadrat qavs sintaksisi bilan ham source route'dan foydalanadi.

Input: collab%psres.net@[127.0.0.1]
Results in email to: collab@psres.net

Himoya

Email parsing kutubxonasidan foydalanganda "encoded-word"ni o'chirib qo'yishni tavsiya qilaman. Oxirgi chora sifatida, quyidagi regex yordamida email manzilida "encoded-word"ning ochuvchi va yopuvchi belgilarini qidirib, uning ishlatilishining oldini olishingiz mumkin:

=[?].+[?]=

Email manzilini, hatto u Github kabi SSO (yagona kirish) provayderidan kelgan bo'lsa ham, har doim validatsiya qilishingiz kerak. Email domenidan hech qachon yagona ruxsat berish (authorization) vositasi sifatida foydalanmang, chunki ko'rganimizdek, uni osongina soxtalashtirish mumkin.

Manbalar

Ushbu tadqiqotni olib borishda bir nechta blog postlari/slaydlar meni juda ilhomlantirdi. Har birini o'qishni tavsiya qilaman, chunki ularda juda foydali ma'lumotlar bor. CSRF tokenini exfiltratsiya qilish uchun ishlatgan import chaining texnikasi Pepe Vila va d0nut dan olingan.

Email parsing:

• https://www.jochentopf.com/email/address.html
• https://nathandavison.com/blog/exploiting-email-address-parsing-with-aws-ses
• https://medium.com/@fs0c131y/tchap-the-super-not-secure-app-of-the-french-government-84b31517d144

CSS Exfiltration:

• https://vwzq.net/slides/2019-s3_css_injection_attacks.pdf
• https://d0nut.medium.com/better-exfiltration-via-html-injection-31c72a2dae8b

Unicode:

• https://www.sonarsource.com/blog/10-unknown-security-pitfalls-for-python/#:~:text=8.%20Unicode%20Case%20Collision

Materiallar

Ushbu tadqiqot uchun barcha materiallar Github repozitoriyasida mavjud.

CTF

Yangi ko'nikmalaringizni sinab ko'rishingiz uchun Web Security Academy'da CTF yaratdik. Qulayligingiz uchun, Git repozitoriyasining Joomla papkasida Joomla'ning zaif nusxasi bilan docker faylini ham yaratdim.

Vaqt jadvali

• Joomla'ga 2024-yil 30-yanvar, soat 15:40 da xabar berildi - 2024-yil 20-fevralda tuzatildi (CVE-2024-21725)
• IdnaConvert PHP kutubxonasiga 2024-yil 8-fevral, soat 11:49 da xabar berildi - 2024-yil 14-fevralda tuzatildi
• Gitlab'ga 2024-yil 5-fevral, soat 11:55 da xabar berildi - 2024-yil 25-aprelda tuzatildi
• Github'ga 2024-yil 5-fevral, soat 11:55 da xabar berildi - 2024-yil 9-mayda tuzatildi
• Zendesk'ga 2024-yil 5-fevral, soat 14:54 da xabar berildi - 2024-yil 9-mayda tuzatildi

Asosiy xulosalar

To'g'ri (valid) email manzillari katta parser nomuvofiqliklarini keltirib chiqarishi mumkin.

"@example.com" bilan tugaydigan manzillar ham boshqa joyga borishi mumkin.

Natijada, kirishni boshqarishni ta'minlash uchun email domenlaridan foydalanish hech qachon xavfsiz emas.