Безбедносна ревизија на облак платформата MCS

SkyShip Dusk од SeerLight

Изградбата на која било услуга нужно вклучува постојана работа на безбедноста. Безбедноста е континуиран процес кој вклучува постојана анализа и подобрување на безбедноста на производите, следење вести за ранливости и многу повеќе. Вклучувајќи ги и ревизиите. Ревизиите се вршат и внатре и од надворешни експерти, кои можат радикално да помогнат во безбедноста бидејќи не се нурнати во проектот и имаат отворен ум.

Написот е за овој најдиректен поглед на надворешни експерти кои му помогнаа на тимот на Mail.ru Cloud Solutions (MCS) да ја тестира услугата облак и за она што го пронашле. Како „надворешна сила“, MCS ја избра компанијата за дигитална безбедност, позната по својата висока експертиза во круговите за безбедност на информациите. И во оваа статија ќе анализираме некои интересни пропусти пронајдени како дел од надворешната ревизија - за да го избегнете истото гребло кога креирате сопствена услуга за облак.

Описание продукта

Mail.ru Cloud Solutions (MCS) е платформа за градење виртуелна инфраструктура во облакот. Вклучува IaaS, PaaS и пазар на готови слики од апликации за програмери. Имајќи ја предвид архитектурата MCS, неопходно беше да се провери безбедноста на производот во следниве области:

• заштита на инфраструктурата на околината за виртуелизација: хипервизори, рутирање, заштитни ѕидови;
• заштита на виртуелната инфраструктура на клиентите: изолација едни од други, вклучувајќи мрежа, приватни мрежи во SDN;
• OpenStack и неговите отворени компоненти;
• S3 од нашиот сопствен дизајн;
• ИАМ: проекти со повеќе станари со модел за улоги;
• Визија (компјутерска визија): API и пропусти при работа со слики;
• веб-интерфејс и класични веб-напади;
• ранливости на компонентите на PaaS;
• API на сите компоненти.

Можеби тоа е сè што е суштинско за понатамошната историја.

Каква работа беше извршена и зошто беше потребна?

Безбедносната ревизија има за цел да ги идентификува пропустите и конфигурациските грешки кои би можеле да доведат до истекување на лични податоци, модификација на чувствителни информации или нарушување на достапноста на услугата.

За време на работата, која во просек трае 1-2 месеци, ревизорите ги повторуваат дејствата на потенцијалните напаѓачи и бараат пропусти во деловите на клиентот и серверот на избраната услуга. Во контекст на ревизијата на облак платформата MCS, беа идентификувани следните цели:

1. Анализа на автентикација во услугата. Ранливостите во оваа компонента би помогнале веднаш да се влезе во туѓи сметки.
2. Проучување на моделот на улоги и контрола на пристап помеѓу различни сметки. За напаѓачот, способноста да се добие пристап до туѓа виртуелна машина е посакувана цел.
3. Ранливости на страната на клиентот. XSS/CSRF/CRLF/итн. Дали е можно да се нападнат други корисници преку малициозни врски?
4. Ранливост на серверот: RCE и сите видови инјекции (SQL/XXE/SSRF и така натаму). Ранливостите на серверот генерално е потешко да се најдат, но тие доведуваат до компромис на многу корисници одеднаш.
5. Анализа на изолација на корисничкиот сегмент на ниво на мрежа. За напаѓачот, недостатокот на изолација во голема мера ја зголемува површината на нападот против другите корисници.
6. Бизнис логичка анализа. Дали е можно да се измамат бизниси и да се создадат виртуелни машини бесплатно?

Во овој проект, работата беше спроведена според моделот „Греј-кутија“: ревизорите комуницираа со услугата со привилегии на обичните корисници, но делумно го поседуваа изворниот код на API и имаа можност да разјаснат детали со програмерите. Ова е обично најзгодниот, а во исто време и сосема реален модел на работа: внатрешните информации сè уште може да ги собира напаѓачот, тоа е само прашање на време.

Пронајдени ранливости

Пред да започне ревизорот да испраќа различни носивост (корисниот товар што се користи за извршување на нападот) на случајни места, неопходно е да се разбере како функционираат работите и каква функционалност е обезбедена. Можеби изгледа дека ова е бескорисна вежба, бидејќи на повеќето студирани места нема да има ранливости. Но, само разбирањето на структурата на апликацијата и логиката на нејзината работа ќе овозможи да се најдат најсложените вектори за напад.

Важно е да најдете места што изгледаат сомнително или се многу различни од другите на некој начин. И првата опасна ранливост беше пронајдена на овој начин.

ИДОР

Ранливостите на IDOR (Insecure Direct Object Reference) се една од најчестите пропусти во деловната логика, која им овозможува на еден или на друг да добијат пристап до објекти до кои пристапот всушност не е дозволен. Ранливостите на IDOR создаваат можност за добивање информации за корисник со различен степен на критичност.

Една од опциите на IDOR е да се вршат дејства со системски објекти (корисници, банкарски сметки, ставки во количката) со манипулирање со идентификатори за пристап до овие објекти. Ова води до најнепредвидливите последици. На пример, можноста за замена на сметката на испраќачот на средства, преку која можете да ги украдете од други корисници.

Во случајот со MCS, ревизорите штотуку открија ранливост на IDOR поврзана со небезбедни идентификатори. Во личната сметка на корисникот, UUID идентификаторите се користеа за пристап до какви било објекти, кои изгледаа, како што велат експертите за безбедност, импресивно небезбедни (т.е. заштитени од напади со брутална сила). Но, за одредени субјекти беше откриено дека се користат редовни предвидливи бројки за да се добијат информации за корисниците на апликацијата. Мислам дека можете да погодите дека беше можно да се смени корисничкиот ID за еден, да се испрати барањето повторно и со тоа да се добијат информации заобиколувајќи го ACL (листа за контрола на пристап, правила за пристап до податоци за процеси и корисници).

Фалсификување на серверско барање (SSRF)

Доброто кај производите на OpenSource е што имаат огромен број форуми со детални технички описи на проблемите што се појавуваат и, ако имате среќа, опис на решението. Но, оваа монета има друга страна: познатите ранливости се исто така детално опишани. На пример, има прекрасни описи на ранливости на форумот OpenStack [XSS] и [SSRF], што поради некоја причина никој не брза да го поправи.

Вообичаена функционалност на апликациите е можноста корисникот да испрати врска до серверот, на кој серверот кликнува (на пример, да преземе слика од одреден извор). Ако безбедносните алатки не ги филтрираат самите врски или одговорите вратени од серверот до корисниците, таквата функционалност лесно може да се користи од напаѓачите.

Ранливостите на SSRF можат многу да го унапредат развојот на нападот. Напаѓачот може да добие:

• ограничен пристап до нападнатата локална мрежа, на пример, само преку одредени мрежни сегменти и користење на одреден протокол;
• целосен пристап до локалната мрежа, доколку е можно спуштање од ниво на апликација на ниво на транспорт и, како резултат на тоа, целосно управување со оптоварувањето на ниво на апликација;
• пристап до читање локални датотеки на серверот (ако е поддржана шемата file:///);
• и многу повеќе.

Во OpenStack одамна е позната ранливоста на SSRF, која е „слепа“ по природа: кога контактирате со серверот, не добивате одговор од него, но добивате различни типови на грешки/одложувања, во зависност од резултатот на барањето. . Врз основа на ова, можете да извршите скенирање на портите на хостовите на внатрешната мрежа, со сите последователни последици кои не треба да се потценат. На пример, производот може да има back-office API до кој е достапен само од корпоративната мрежа. Со документација (не заборавајте за инсајдерите), напаѓачот може да користи SSRF за пристап до внатрешните методи. На пример, ако некако сте успеале да добиете приближна листа на корисни URL-адреси, тогаш со помош на SSRF можете да поминете низ нив и да извршите барање - релативно кажано, да префрлите пари од сметка на сметка или да ги промените лимитите.

Ова не е прв пат да се открие ранливост на SSRF во OpenStack. Во минатото, беше можно да се преземаат VM 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 се насекаде, заштитени од кражба со помош на скрипти js), ако вчитаната скрипта може веднаш да пристапи до API-то на ресурсите? Во овој случај, товарот може да користи XHR барања за да ја промени конфигурацијата на серверот, на пример, да го додаде јавниот SSH клуч на напаѓачот и да добие SSH пристап до серверот.
• Ако политиката CSP (политика за заштита на содржината) забранува инјектирање на JavaScript, напаѓачот може да помине без него. Користејќи чист HTML, креирајте лажен формулар за најавување на страницата и украдете ја лозинката на администраторот преку овој напреден фишинг: страницата за кражба на идентитет за корисникот завршува на истата URL-адреса и на корисникот му е потешко да ја открие.
• Конечно, напаѓачот може да организира клиент DoS — поставете колачиња поголеми од 4 KB. Корисникот треба да ја отвори врската само еднаш, а целата страница станува недостапна додека корисникот не помисли конкретно да го исчисти прелистувачот: во огромното мнозинство на случаи, веб-серверот ќе одбие да прифати таков клиент.

Ајде да погледнеме пример на друг откриен XSS, овој пат со полукав експлоат. Услугата MCS ви овозможува да ги комбинирате поставките за заштитен ѕид во групи. Името на групата беше местото каде што беше откриен XSS. Неговата особеност беше што векторот не беше активиран веднаш, не при прегледување на списокот со правила, туку при бришење група:

Односно, сценариото се покажа како следново: напаѓачот создава правило за заштитен ѕид со „оптоварување“ во името, администраторот го забележува по некое време и го започнува процесот на бришење. И тука работи злонамерниот JS.

За програмерите на MCS да се заштитат од XSS на поставените SVG слики (ако не можат да се испуштат), тимот за дигитална безбедност препорача:

• Поставете датотеки поставени од корисниците на посебен домен кој нема никаква врска со „колачиња“. Скриптата ќе биде извршена во контекст на друг домен и нема да претставува закана за MCS.
• Во одговорот на HTTP на серверот, испратете го насловот „Content-disposition: attachment“. Потоа, датотеките ќе бидат преземени од прелистувачот и нема да бидат извршени.

Покрај тоа, сега има многу начини на располагање на програмерите за ублажување на ризиците од експлоатација на XSS:

• користејќи го знамето „Само HTTP“, можете да ги направите заглавјата „Колачиња“ на сесиите недостапни за злонамерниот JavaScript;
• правилно спроведена политика на CSP ќе му отежне на напаѓачот да го искористи XSS;
• модерните мотори на шаблони како што се Angular или React автоматски ги дезинфицираат корисничките податоци пред да ги испратат во прелистувачот на корисникот.

Пропусти за автентикација со два фактори

За да се подобри безбедноста на сметката, на корисниците секогаш им се советува да овозможат 2FA (двофакторна автентикација). Навистина, ова е ефикасен начин да се спречи напаѓачот да добие пристап до услугата доколку се загрозени ингеренциите на корисникот.

Но, дали користењето на втор фактор за автентикација секогаш гарантира безбедност на сметката? Постојат следниве безбедносни проблеми при имплементацијата на 2FA:

• Брутално-силно пребарување на OTP кодот (еднократни кодови). И покрај едноставноста на работењето, големите компании исто така се среќаваат со грешки како што е недостаток на заштита од брутална сила ОТП: Лабава футрола, Случај на Фејсбук.
• Алгоритам за слаб генерирање, на пример способност за предвидување на следниот код.
• Логички грешки, како што е можноста да побарате туѓ OTP на вашиот телефон, вака беше од Shopify.

Во случајот на MCS, 2FA се имплементира врз основа на Google Authenticator и Дуото. Самиот протокол е веќе временски тестиран, но вреди да се провери имплементацијата на проверка на кодот на страната на апликацијата.

MCS 2FA се користи на неколку места:

• При автентичност на корисникот. Постои заштита од брутална сила: корисникот има само неколку обиди да внесе еднократна лозинка, а потоа внесувањето е блокирано некое време. Ова ја блокира можноста за избор на ОТП со брутална сила.
• Кога генерирате офлајн резервни кодови за извршување на 2FA, како и оневозможување. Овде, не беше спроведена заштита од брутална сила, што овозможи, доколку имате лозинка за сметката и активна сесија, да ги регенерирате резервните кодови или целосно да го оневозможите 2FA.

Имајќи предвид дека резервните кодови се наоѓаа во истиот опсег на вредности на низа како оние генерирани од апликацијата OTP, шансата да се најде кодот за кратко време беше многу поголема.

Процесот на избор на OTP за оневозможување на 2FA со помош на алатката „Burp: Intruder“.

Резултира

Генерално, MCS се чини дека е безбеден како производ. За време на ревизијата, тимот што тестираше не беше во можност да добие пристап до VM на клиентите и нивните податоци, а пронајдените пропусти беа брзо коригирани од тимот на MCS.

Но, тука е важно да се напомене дека безбедноста е континуирана работа. Услугите не се статични, тие постојано се развиваат. И невозможно е целосно да се развие производ без ранливости. Но, можете да ги најдете на време и да ја минимизирате можноста за нивно повторување.

Сега сите споменати пропусти во MCS се веќе поправени. И со цел да се сведе бројот на нови на минимум и да се намали нивниот животен век, тимот на платформата продолжува да го прави ова:

• редовно спроведува ревизии од надворешни компании;
• поддршка и развој на учество во програмата Mail.ru Group Bug Bounty;
• се вклучи во безбедноста. 🙂

Извор: www.habr.com