by SeerLight
Пабудова любога сэрвісу абавязкова ўключае ў сябе пастаянную працу над бяспекай. Бяспека - гэта бесперапынны працэс, які ўключае ў сябе пастаянны аналіз і паляпшэнне абароненасці прадукту, маніторынг навін пра ўразлівасці і многае іншае. У тым ліку - аўдыты. Аўдыты праводзяць як уласнымі сіламі, так і сіламі знешніх экспертаў, якія могуць кардынальна дапамагчы з бяспекай, паколькі не пагружаныя ў праект і маюць незамылены погляд.
Артыкул - пра гэты самы незамылены погляд знешніх экспертаў, якія дапамаглі камандзе Mail.ru Cloud Solutions (MCS) пратэставаць хмарны сэрвіс, і пра тое, што яны знайшлі. У якасці "вонкавых сіл" MCS абралі кампанію Digital Security, вядомую сваёй высокай экспертызай у колах ИБ. І ў дадзеным артыкуле мы разбяром некаторыя цікавыя ўразлівасці, знойдзеныя ў рамках вонкавага аўдыту - каб вас мінулі такія ж граблі, калі вы будзеце рабіць свой хмарны сэрвіс.
апісанне прадукту
- Гэта платформа для пабудовы віртуальнай інфраструктуры ў воблаку. Яна ўключае IaaS-ы, PaaS-ы, маркетплейс гатовых вобразаў прыкладанняў для распрацоўшчыкаў. З улікам архітэктуры MCS трэба было праверыць бяспеку прадукта па наступных кірунках:
- абарона інфраструктуры асяроддзя віртуалізацыі: гіпервізары, маршрутызацыя, фаерволы;
- абарона віртуальнай інфраструктуры замоўцаў: ізаляцыя сябар ад сябра, уключаючы сеткавую, прыватныя сеткі ў SDN;
- OpenStack і яго адчыненыя кампаненты;
- S3 ўласнай распрацоўкі;
- IAM: мультытэнантныя праекты з ролевай мадэллю;
- Vision (машынны зрок): API і ўразлівасці пры працы з выявамі;
- вэб-інтэрфейс і класічныя вэб-напады;
- уразлівасці PaaS-кампанентаў;
- API усіх кампанентаў.
Мабыць, з істотнага для далейшай гісторыі - усё.
Што за працы праводзіліся і навошта яны патрэбны?
Аўдыт бяспекі накіраваны на выяўленне ўразлівасцяў і памылак канфігурацыі, якія могуць прывесці да ўцечкі персанальных дадзеных, мадыфікацыі адчувальнай інфармацыі ці ж да парушэння даступнасці сэрвісаў.
Падчас прац, якія доўжацца ў сярэднім 1-2 месяцы, аўдытары паўтараюць дзеянні патэнцыйных зламыснікаў і шукаюць уразлівасці ў кліенцкай і сервернай частцы абранага сэрвісу. У кантэксце аўдыту хмарнай платформы MCS былі пазначаны наступныя мэты:
- Аналіз аўтэнтыфікацыі ў сервісе. Уразлівасці ў дадзеным кампаненце дапамаглі б адразу патрапіць у чужыя акаўнты.
- Вывучэнне ролевай мадэлі і размежаванні доступу паміж рознымі акаўнтамі. Для зламысніка магчымасць атрымаць доступ да чужой віртуальнай машыны - жаданая мэта.
- Уразлівасці кліенцкай часткі. XSS/CSRF/CRLF/etc. Можа, існуе магчымасць атакаваць іншых карыстачоў праз шкоднасныя спасылкі?
- Уразлівасці сервернай часткі: RCE і разнастайныя ін'екцыі (SQL/XXE/SSRF і гэтак далей). Серверныя ўразлівасці, як правіла, складаней знайсці, але яны прыводзяць да кампраметацыі адразу мноства карыстачоў.
- Аналіз ізаляцыі карыстацкіх сегментаў на ўзроўні сеткі. Для зламысніка адсутнасць ізаляцыі значна павялічвае паверхню нападу на іншых карыстачоў.
- Аналіз бізнес-логікі. Ці можна падмануць бізнэс і ствараць віртуальныя машыны бясплатна?
У дадзеным праекце працы праводзіліся па мадэлі "Gray-box": аўдытары ўзаемадзейнічалі з сэрвісам з прывілеямі звычайных карыстальнікаў, але часткова валодалі зыходнымі тэкстамі API і мелі магчымасць удакладняць дэталі ў распрацоўшчыкаў. Звычайна гэта самая зручная, і пры гэтым дастаткова рэалістычная мадэль працы: унутраная інфармацыя ўсё роўна можа быць сабрана зламыснікам, гэта толькі пытанне часу.
Знойдзеныя ўразлівасці
Перш чым аўдытар пачынае адпраўляць розныя payload'ы (карысную нагрузку, з дапамогай якой праводзіцца напад) у выпадковыя месцы, неабходна разабрацца, як што працуе, які функцыянал прадстаўлены. Можа здацца, што гэты бескарысны занятак, бо ў большасці вывучаных месцаў ніякіх уразлівасцяў не акажацца. Але толькі разуменне структуры дадатку і логікі яго працы дасць магчымасць адшукаць самыя складаныя вектары нападаў.
Важна знайсці месцы, якія здаюцца падазронымі ці нечым моцна адрозніваюцца ад іншых. І першая небяспечная ўразлівасць была знойдзена менавіта такім чынам.
IDOR
IDOR-уразлівасці (Insecure Direct Object Reference, небяспечныя прамыя спасылкі на аб'екты) - адзін з самых частых варыянтаў уразлівасцяў у бізнэс-логіцы, які дазваляе тым ці іншым спосабам атрымаць доступ да аб'ектаў, да якіх у рэчаіснасці доступ не дазволены. IDOR-уразлівасці ствараюць магчымасць атрымання звестак пра карыстача рознай ступені крытычнасці.
Адзін з варыянтаў IDOR - выкананне дзеянняў з аб'ектамі сістэмы (карыстальнікамі, банкаўскімі рахункамі, таварамі ў кошыку) за кошт маніпуляцый з ідэнтыфікатарамі доступу да гэтых аб'ектаў. Гэта прыводзіць да самых непрадказальных наступстваў. Напрыклад, да магчымасці падмены акаўнта адпраўніка грашовых сродкаў, за кошт якой можна красці іх у іншых карыстальнікаў.
У выпадку MCS аўдытары як раз выявілі IDOR-уразлівасць, звязаную з нясек'юрнымі ідэнтыфікатарамі. У асабістым кабінеце карыстальніка для доступу да любых аб'ектаў выкарыстоўваліся ідэнтыфікатары UUID, якія здаваліся, як кажуць бяспечнікі, унушальна небрутабельнымі (гэта значыць абароненымі ад нападу перабору). Але для вызначаных сутнасцяў было выяўлена, што для атрымання інфармацыі аб карыстачах прыкладання выкарыстоўваюцца звычайныя прадказальныя нумары. Думаю, вы здагадваецеся, што можна было змяніць ID карыстальніка на адзінку, адправіць запыт нанова і атрымаць такім чынам інфармацыю ў абыход ACL (access control list, правіл доступу да дадзеных для працэсаў і карыстальнікаў).
Server Side Request Forgery (SSRF)
OpenSource-прадукты добрыя тым, што па іх ёсць велізарная колькасць форумаў з падрабязным тэхнічным апісаннем якія ўзнікаюць праблем і, калі вам павезла, з апісаннем рашэння. Але ў гэтага медаля ёсць адваротны бок: гэтак жа падрабязна распісаны і вядомыя ўразлівасці. Напрыклад, на форуме OpenStack ёсць выдатныя апісанні ўразлівасцяў и , якія чамусьці ніхто не спяшаецца выпраўляць.
Частая функцыянальнасць прыкладанняў - магчымасць для карыстальніка адправіць на сервер спасылку, па якой сервер пераходзіць (напрыклад, каб загрузіць малюнак з названай крыніцы). Пры недастатковай фільтрацыі сродкамі бяспекі саміх спасылак або адказаў, якія вяртаюцца ад сервера карыстачам такі функцыянал лёгка выкарыстоўваюць зламыснікі.
SSRF-уразлівасці могуць моцна прасунуць развіццё нападу наперад. Зламыснік можа атрымаць:
- абмежаваны доступ да атакаванай лакальнай сеткі, напрыклад толькі па вызначаных сегментах сеткі і па вызначаным пратаколе;
- поўны доступ лакальнай сеткі, калі магчымы даунгрейд з узроўня прыкладанняў да транспартнага ўзроўня і, як следства, поўнае кіраванне нагрузкай на ўзроўні прыкладанняў;
- доступ да чытання лакальных файлаў на серверы (калі падтрымліваецца схема file:///);
- і многае іншае.
У OpenStack даўно вядомая SSRF-уразлівасць, якая носіць "сляпы" характар: пры звароце да сервера ты не атрымліваеш ад яго адказ, але затое атрымліваеш розныя тыпы памылак/затрымак, у залежнасці ад выніку запыту. На падставе гэтага можна выканаць сканаванне партоў на хастах ва ўнутранай сетцы, з усімі вынікаючымі наступствамі, якія не варта недаацэньваць. Да прыкладу, у прадукта можа прысутнічаць API для бэк-офіса, даступны толькі з карпаратыўнай сеткі. Валодаючы дакументацыяй (не забываем пра інсайдэраў), зламыснік можа з дапамогай SSRF звярнуцца да ўнутраных метадаў. Напрыклад, калі ўдалося нейкім чынам атрымаць прыблізны спіс карысных URL, то з дапамогай SSRF можна па іх прайсці і выканаць запыт - умоўна кажучы, перавесці грошы з рахунку на рахунак або памяняць ліміты.
Гэта не першы выпадак выяўлення SSRF-уразлівасці ў OpenStack. У мінулым існавала магчымасць загружаць ISO-выявы ВМ па прамой спасылцы, што таксама прыводзіла да падобных наступстваў. На дадзены момант гэтая функцыя выдаленая з OpenStack. Відаць, суполка палічыла гэта самым простым і надзейным вырашэннем праблемы.
А ў публічна даступнай справаздачы з сэрвісу HackerOne (h1) эксплуатацыя ўжо не сляпы SSRF з магчымасцю чытання метададзеных інстанса прыводзіць да атрымання Root-доступу да ўсёй інфраструктуры Shopify.
У MCS у двух месцах з падобнай функцыянальнасцю выявіліся SSRF-уразлівасці, але іх практычна немагчыма было эксплуатаваць з-за фаерволаў і іншых абарон. Так ці інакш, каманда MCS усё роўна пафіксіла гэтую праблему, не чакаючы супольнасці.
XSS замест загрузкі «шэлаў»
Нягледзячы на сотні напісаных даследаванняў, з года ў год XSS (напад міжсайтавага скрыптынгу) усё яшчэ самая вэб-уразлівасць (або ?).
Загрузка файлаў - любімае месца для любога даследчыка бяспекі. Часта аказваецца можна загрузіць адвольны скрыпт (asp/jsp/php) і выканаць каманды АС, у тэрміналогіі пентэстэраў - "загрузіць шелл". Але папулярнасць такіх уразлівасцяў працуе ў абодва бакі: пра іх памятаюць і распрацоўваюць сродкі супраць іх, так што ў апошні час верагоднасць "загрузіць шелл" імкнецца да нуля.
Атакуючай камандзе (у асобе Digital Security) пашанцавала. ОК, у MCS на боку сервера правяралася змесціва загружаных файлаў, дазволеныя былі толькі выявы. Але SVG - гэта таксама карцінка. А чым могуць быць небяспечныя SVG карцінкі? Тым, што ў іх можна ўбудоўваць фрагменты JavaScript!
Аказалася, што загружаныя файлы даступныя ўсім карыстальнікам сэрвісу MCS - значыць можна атакаваць іншых карыстальнікаў аблокі, а менавіта - адміністратараў.
Прыклад укаранення з дапамогай XSS-напады фішынгавай формы лагіна
Прыклады эксплуатацыі XSS-напады:
- Навошта спрабаваць скрасці сесію (тым больш, што зараз усюды HTTP-Only cookies, абароненыя ад крадзяжоў з дапамогай js-скрыптоў), калі загружаны скрыпт можа адразу звяртацца да API рэсурсу? У гэтым выпадку карысная нагрузка можа праз XHR-запыты памяняць канфігурацыю сервера, напрыклад, дадаць адчынены SSH-ключ зламысніка і атрымаць SSH-доступ да сервера.
- Калі CSP-палітыка (палітыка абароны кантэнту) забараняе ўкараняць JavaScript, зламыснік можа абысціся без яго. На чыстым HTML звярстаць фэйкавую форму ўваходу на сайт і сагнаць пароль адміністратара праз такі прасунуты фішынг: фішынгавая старонка для карыстача апыняецца на тым жа URL, і карыстачу яе складаней выявіць.
- Нарэшце зламыснік можа задаволіць - выставіць Cookies памерам больш за 4 Кбайт. Карыстальніку дастаткова адзін раз адкрыць спасылку - і ўвесь сайт становіцца недаступны, пакуль не здагадаешся спецыяльна пачысціць браўзэр: у пераважнай большасці выпадкаў вэб-сервер адмовіцца прымаць такога кліента.
Разгледзім прыклад яшчэ адной выяўленай XSS, у гэты раз з хітрэйшай эксплуатацыяй. Сэрвіс MCS дазваляе аб'ядноўваць налады фаервола ў групы. У імені гурта і была выяўленая XSS. Яе асаблівасць заключалася ў тым, што спрацоўваў вектар не адразу, не пры праглядзе спісу правілаў, а пры выдаленні групы:
Гэта значыць, сцэнар атрымліваўся наступны: зламыснік стварае правіла фаервола з "нагрузкай" у імені, адміністратар праз некаторы час яго заўважае, ініцыюе працэс выдалення. І тут-то шкоднасны JS і адпрацоўвае.
Распрацоўнікам MCS для абароны ад XSS у загружаных SVG-малюнках (калі ад іх нельга адмовіцца) каманда Digital Security рэкамендавала:
- Размяшчаць файлы, загружаныя карыстальнікамі, на асобным дамене, які не мае нічога агульнага з «кукавым». Скрыпт будзе выконвацца ў кантэксце іншага дамена і не будзе несці пагрозы для MCS.
- У HTTP-адказе сервера аддаваць загаловак "Сontent-disposition: attachment". Тады файлы будуць спампоўвацца браўзэрам, а не выконвацца.
Акрамя таго, цяпер для распрацоўшчыкаў даступна шмат спосабаў змякчэння рызык эксплуатацыі XSS:
- з дапамогай сцяга "HTTP Only" можна зрабіць сесійныя загалоўкі "Cookies" недаступнымі для шкоднаснага JavaScript;
- значна ўскладніць эксплуатацыю XSS для зламысніка;
- сучасныя шаблонізатары, такія як Angular або React, аўтаматычна чысцяць карыстацкія дадзеныя перад высновай у браўзэр карыстача.
Уразлівасці двухфактарнай аўтэнтыфікацыі
Для падвышэння бяспекі акаўнтаў карыстачам заўсёды рэкамендуецца ўлучыць 2FA (двухфактарную аўтэнтыфікацыю). Сапраўды, гэта эфектыўны спосаб перашкодзіць зламысніку атрымаць доступ да сэрвісу, калі ўліковыя дадзеныя карыстальніка былі скампраметаваныя.
Але ці заўсёды выкарыстанне другога фактару аўтэнтыфікацыі дае гарантыю захаванасці акаўнта? У рэалізацыі 2FA бываюць такія праблемы бяспекі:
- Грубы перабор OTP-кода (аднаразовых кодаў). Нягледзячы на прастату эксплуатацыі, такія памылкі, як адсутнасць абароны ад брутта OTP, сустракаюцца і ў вялікіх кампаній: , .
- Слабы алгарытм генерацыі, напрыклад магчымасць прадбачыць наступны код.
- Лагічныя памылкі, напрыклад магчымасць запытаць чужы OTP на свой тэлефон, як гэта у Shopify.
У выпадку MCS 2FA рэалізавана на аснове Google Authenticator і . Сам пратакол ужо правераны часам, а вось рэалізацыю праверкі кода на баку дадатку варта праверыць.
У MCS 2FA выкарыстоўваецца ў некалькіх месцах:
- Пры аўтэнтыфікацыі карыстальніка. Тут абарона ад перабору ёсць: у карыстача - усяго некалькі спроб уводу аднаразовага пароля, потым увод на некаторы час блакуецца. Гэта блакуе магчымасць правесці падбор OTP пераборам.
- Пры генерацыі афлайнавых backup-кодаў для выканання 2FA, а таксама яе адключэнні. Тут абароны ад перабору рэалізавана не было, што дазваляла пры наяўнасці пароля ад уліковага запісу і дзейснай сесіі перагенераваць backup-коды або адключыць 2FA зусім.
Улічваючы, што backup-коды размяшчаліся ў тым жа дыяпазоне значэнняў радкоў, што і згенераваныя дадаткам OTP, шанец падабраць код за кароткі час быў моцна вышэй.
Працэс падбору OTP для адключэння 2FA з дапамогай прылады "Burp: Intruder"
Вынік
У цэлым, MCS як прадукт аказаўся бяспечным. За час аўдыту камандзе пентэстэраў не атрымалася атрымаць доступ да кліенцкіх ВМ і іх дадзеным, а знойдзеныя ўразлівасці хутка выпраўленыя камандай MCS.
Але тут важна адзначыць, што бяспека - гэта бесперапынная праца. Сэрвісы не з'яўляюцца статычнымі, яны ўвесь час развіваюцца. А распрацаваць прадукт цалкам без уразлівасцяў немагчыма. Але можна своечасова іх знаходзіць і мінімізаваць шанц іх паўтору.
Цяпер усе згаданыя ўразлівасці ў MCS ужо выпраўленыя. А каб зрабіць колькасць новых мінімальнай і скараціць час іх існавання, каманда платформы працягвае рабіць гэта:
- рэгулярна праводзіць аўдыты вонкавымі кампаніямі;
- падтрымліваць і развіваць удзел;
- займацца бяспекай. 🙂
Крыніца: habr.com