SeerLight тарабынан
Ар кандай кызматты куруу сөзсүз түрдө коопсуздук боюнча тынымсыз ишти камтыйт. Коопсуздук бул үзгүлтүксүз процесс, ал продукттун коопсуздугун туруктуу талдоо жана жакшыртуу, алсыздыктар жөнүндө жаңылыктарга мониторинг жүргүзүү жана башка көптөгөн нерселерди камтыйт. Анын ичинде аудиттер. Аудиттер ички жана тышкы эксперттер тарабынан ишке ашырылат, алар коопсуздукту камсыздоодо түп-тамырынан бери жардам бере алышат, анткени алар долбоорго аралашпаган жана ачык пикирге ээ.
Макала Mail.ru Cloud Solutions (MCS) командасына булут кызматын сынап көрүүгө жардам берген тышкы эксперттердин эң жөнөкөй көз карашы жана алар тапкан нерселер жөнүндө. "Тышкы күч" катары MCS маалыматтык коопсуздук чөйрөсүндө өзүнүн жогорку тажрыйбасы менен белгилүү болгон Digital Security компаниясын тандады. Жана бул макалада биз тышкы аудиттин бир бөлүгү катары табылган кээ бир кызыктуу кемчиликтерди талдап чыгабыз - өзүңүздүн булут сервисиңизди түзүүдө бир эле тырмоодон качышыңыз үчүн.
продукт Description
булутта виртуалдык инфраструктураны куруу үчүн платформа болуп саналат. Ал IaaS, PaaS жана иштеп чыгуучулар үчүн даяр тиркеме сүрөттөрүнүн базарын камтыйт. MCS архитектурасын эске алуу менен, төмөнкү багыттар боюнча продуктунун коопсуздугун текшерүү зарыл болгон:
- виртуалдаштыруу чөйрөсүнүн инфраструктурасын коргоо: гипервизорлор, маршрутизация, брандмауэрлер;
- кардарлардын виртуалдык инфраструктурасын коргоо: бири-биринен обочолонуу, анын ичинде SDN тармагындагы жеке тармактар;
- OpenStack жана анын ачык компоненттери;
- S3 өзүбүздүн дизайн;
- IAM: үлгүлүү көп ижарачы долбоорлор;
- Көрүнүш (компьютердик көрүнүш): API'лер жана сүрөттөр менен иштөөдө алсыздыктар;
- веб-интерфейс жана классикалык веб чабуулдар;
- PaaS компоненттеринин алсыздыгы;
- бардык компоненттеринин API.
Балким, бул кийинки тарых үчүн зарыл болгон нерселердин баары.
Кандай иштер аткарылды жана эмне үчүн керек болду?
Коопсуздук аудити жеке маалыматтардын агып кетишине, купуя маалыматтын өзгөрүшүнө же кызматтын жеткиликтүүлүгүнүн үзгүлтүккө учурашына алып келиши мүмкүн болгон аялуу жерлерди жана конфигурация каталарын аныктоого багытталган.
Орточо эсеп менен 1-2 айга созулган иштин жүрүшүндө аудиторлор потенциалдуу чабуулчулардын аракеттерин кайталап, тандалган кызматтын кардар жана сервер бөлүктөрүндө алсыздыктарды издешет. MCS булут платформасынын аудитинин контекстинде төмөнкү максаттар аныкталган:
- Кызматта аутентификацияны талдоо. Бул компоненттин кемчиликтери дароо башка адамдардын эсебине кирүүгө жардам берет.
- Үлгү үлгүсүн жана ар кандай эсептердин ортосундагы мүмкүндүктү көзөмөлдөөнү изилдөө. Чабуулчу үчүн башка бирөөнүн виртуалдык машинасына кирүү мүмкүнчүлүгү эң керектүү максат болуп саналат.
- Кардар тараптын алсыздыктары. XSS/CSRF/CRLF/ж.б. Зыяндуу шилтемелер аркылуу башка колдонуучуларга кол салуу мүмкүнбү?
- Сервер тараптын алсыздыктары: RCE жана инъекциялардын бардык түрлөрү (SQL/XXE/SSRF жана башкалар). Сервердин алсыздыктарын табуу көбүнчө кыйыныраак, бирок алар бир эле учурда көптөгөн колдонуучулардын компромиссине алып келет.
- Тармак деңгээлинде колдонуучу сегментинин изоляциясын талдоо. Чабуулчу үчүн изоляциянын жоктугу башка колдонуучуларга каршы чабуулдун бетин бир топ жогорулатат.
- Бизнес логикалык талдоо. Бизнести алдап, виртуалдык машиналарды бекер жасоого болобу?
Бул долбоордо иш "Gray-box" модели боюнча жүргүзүлдү: аудиторлор кызмат менен катардагы колдонуучулардын артыкчылыктары менен иштешти, бирок жарым-жартылай API баштапкы кодун ээлеп, иштеп чыгуучулар менен чоо-жайын тактоо мүмкүнчүлүгүнө ээ болушту. Бул, адатта, эң ыңгайлуу жана ошол эле учурда реалдуу иш модели: ички маалыматты дагы эле чабуулчу чогулта алат, бул убакыт маселеси.
Кемчиликтер табылды
Аудитор ар кандай пайдалуу жүктөрдү (чабуул жасоо үчүн колдонулган пайдалуу жүктү) туш келди жерлерге жөнөтө баштоодон мурун, нерселердин кандайча иштээрин жана кандай функциялар менен камсыздалганын түшүнүү керек. Бул пайдасыз көнүгүү сыяктуу сезилиши мүмкүн, анткени изилденген жерлердин көпчүлүгүндө алсыздыктар болбойт. Бирок тиркеменин түзүмүн жана анын иштөө логикасын түшүнүү гана эң татаал чабуул векторлорун табууга мүмкүндүк берет.
Шектүү көрүнгөн же кандайдыр бир жол менен башкалардан абдан айырмаланган жерлерди табуу маанилүү. Ал эми биринчи коркунучтуу аялуу ушул жол менен табылган.
IDOR
IDOR (Коопсуз Түз Объект Шилтемеси) алсыздыктары бизнес логикасындагы эң кеңири таралган кемчиликтердин бири болуп саналат, ал тигил же бул объектилерге кирүүгө чындап уруксат берилбеген объекттерге кирүү мүмкүнчүлүгүн берет. IDOR алсыздыгы ар кандай деңгээлдеги критикалык колдонуучу жөнүндө маалымат алуу мүмкүнчүлүгүн түзөт.
IDOR варианттарынын бири бул объекттерге кирүү идентификаторлорун манипуляциялоо жолу менен система объектилери (колдонуучулар, банк эсептери, соода корзинасы) менен аракеттерди аткаруу болуп саналат. Бул эң күтүүсүз кесепеттерге алып келет. Мисалы, акча каражаттарын жөнөтүүчүнүн эсебин алмаштыруу мүмкүнчүлүгү, ал аркылуу сиз аларды башка колдонуучулардан уурдасаңыз болот.
MCS учурда, аудиторлор жаңы эле коопсуз эмес идентификаторлор менен байланышкан IDOR аялуулугун табышкан. Колдонуучунун жеке аккаунтунда UUID идентификаторлору ар кандай объекттерге кирүү үчүн колдонулган, алар коопсуздук боюнча эксперттер айткандай, өтө кооптуу көрүнгөн (башкача айтканда, орой күч чабуулдарынан корголгон). Бирок кээ бир субъекттер үчүн, бул тиркеменин колдонуучулары жөнүндө маалымат алуу үчүн үзгүлтүксүз алдын ала сандар колдонулат экени аныкталган. Менимче, сиз колдонуучунун идентификаторун бир жолу өзгөртүп, суроо-талапты кайра жөнөтүп, ошону менен ACLди (жетүү башкаруу тизмеси, процесстер жана колдонуучулар үчүн берилиштерге жетүү эрежелери) айланып өтүү менен маалымат алууга болот деп ойлой аласыз.
Сервер тараптын өтүнүчүн жасалмалоо (SSRF)
OpenSource өнүмдөрү жакшы, анткени аларда пайда болгон көйгөйлөрдүн деталдуу техникалык сыпаттамалары жана, эгер бактылуу болсоңуз, аны чечүүнүн сүрөттөлүшү бар көптөгөн форумдар бар. Бирок бул монетанын экинчи жагы бар: белгилүү алсыздыктар да майда-чүйдөсүнө чейин сүрөттөлөт. Мисалы, OpenStack форумунда аялуу жерлердин сонун сүрөттөмөлөрү бар и , эмнегедир оңдоого эч ким шашылбайт.
Тиркемелердин жалпы функционалдуулугу – бул колдонуучунун серверге шилтемени жөнөтүү мүмкүнчүлүгү, аны сервер басканда (мисалы, көрсөтүлгөн булактан сүрөттү жүктөп алуу). Эгерде коопсуздук куралдары шилтемелердин өздөрүн же серверден колдонуучуларга кайтарылган жоопторду чыпкалабаса, мындай функцияны чабуулчулар оңой колдоно алышат.
SSRF алсыздыктары чабуулдун өнүгүшүн бир топ илгерилетиши мүмкүн. Чабуулчу төмөнкүлөрдү ала алат:
- чабуулга дуушар болгон локалдык тармакка чектелген жетүү, мисалы, белгилүү бир тармак сегменттери аркылуу жана белгилүү бир протоколду колдонуу;
- локалдык тармакка толук кирүү, эгерде тиркеме деңгээлинен транспорттук деңгээлге чейин төмөндөтүү мүмкүн болсо жана натыйжада колдонмо деңгээлинде жүктү толук башкаруу;
- сервердеги локалдык файлдарды окуу мүмкүнчүлүгү (эгерде file:/// схемасы колдоого алынса);
- жана дагы көп нерселер.
OpenStack'те SSRF аялуулугу көптөн бери белгилүү, ал табияты боюнча "сокур": серверге кайрылганыңызда, сиз андан жооп албайсыз, бирок сурамдын жыйынтыгына жараша ар кандай каталарды/кечиктирүүлөрдү аласыз. . Ушунун негизинде, сиз ички тармактагы хосттордо порт сканерин жүргүзө аласыз, анын кесепеттерин баалабай коюуга болбойт. Мисалы, өнүмдө корпоративдик тармактан гана жеткиликтүү болгон бэк-офис API болушу мүмкүн. Документтер менен (инсайдерлер жөнүндө унутпаңыз), чабуулчу ички ыкмаларга кирүү үчүн SSRF колдоно алат. Мисалы, эгер сиз кандайдыр бир жол менен пайдалуу URL даректеринин болжолдуу тизмесин ала алсаңыз, анда SSRF аркылуу сиз алар аркылуу өтүп, суроо-талапты аткара аласыз - салыштырмалуу айтканда, эсептен эсепке акча которуу же чектөөлөрдү өзгөртүү.
Бул OpenStackте SSRF аялуу биринчи жолу табылган жок. Мурда VM ISO сүрөттөрүн түз шилтемеден жүктөп алууга мүмкүн болгон, бул да ушундай кесепеттерге алып келген. Бул функция азыр OpenStackтен алынып салынды. Кыязы, коомчулук муну маселенин эң жөнөкөй жана ишенимдүү чечими деп эсептесе керек.
жана HackerOne кызматынын (h1) жалпыга жеткиликтүү отчету, инстанциялардын метаберилиштерин окуу мүмкүнчүлүгү менен сокур эмес SSRF эксплуатациялоо бүт Shopify инфраструктурасына Root мүмкүнчүлүгүн берет.
MCSде SSRF кемчиликтери окшош функционалдуу эки жерде табылган, бирок брандмауэрлердин жана башка коргоонун аркасында аларды пайдалануу дээрлик мүмкүн эмес болчу. Кандай болбосун, MCS командасы коомчулукту күтпөстөн, баары бир бул көйгөйдү чечти.
XSS кабыктарды жүктөөнүн ордуна
Жазылган жүздөгөн изилдөөлөргө карабастан, жылдан жылга XSS (сайттар аралык сценарий) чабуулу дагы эле эң көп желе аялуулугу (же ?).
Файлдарды жүктөө ар бир коопсуздук изилдөөчүсү үчүн сүйүктүү жер. Көбүнчө сиз ыктыярдуу скрипт (asp/jsp/php) жүктөй аласыз жана OS буйруктарын аткара аласыз, пентестер терминологиясында - "жүк кабыгы". Бирок, мындай алсыздыктын популярдуулугу эки тарапта тең иштейт: алар эске алынып, аларга каршы каражаттар иштелип чыккан, ошондуктан жакында "снарядды жүктөө" ыктымалдыгы нөлгө барабар.
Чабуулчу команда (Digital Security тарабынан сунушталган) бактылуу болду. Макул, сервер тарабындагы MCSде жүктөлүп алынган файлдардын мазмуну текшерилген, сүрөттөргө гана уруксат берилген. Бирок SVG да сүрөт. SVG сүрөттөрү кандайча кооптуу болушу мүмкүн? Анткени аларга JavaScript үзүндүлөрүн кыстара аласыз!
Жүктөлүп алынган файлдар MCS сервисинин бардык колдонуучуларына жеткиликтүү экен, бул булуттун башка колдонуучуларына, тактап айтканда, администраторлорго чабуул жасоого болоорун билдирет.
Фишинг кирүү формасына XSS чабуулунун мисалы
XSS чабуулунун мисалдары:
- Эгер жүктөлгөн скрипт API ресурсуна дароо кире алса, эмне үчүн сеансты уурдоого аракет кылуу керек (айрыкча азыр HTTP гана кукилери бардык жерде, JS скрипттерин колдонуу менен уурдоодон корголгон)? Бул учурда, пайдалуу жүк XHR сурамдарын сервердин конфигурациясын өзгөртүү үчүн колдоно алат, мисалы, чабуулчунун жалпы SSH ачкычын кошуп, серверге SSH мүмкүнчүлүгүн алат.
- Эгерде CSP саясаты (мазмунду коргоо саясаты) JavaScript инъекциясына тыюу салса, чабуулчу ансыз деле жеңе алат. Таза HTMLди колдонуп, сайтка жасалма кирүү формасын түзүп, ушул өркүндөтүлгөн фишинг аркылуу администратордун сырсөзүн уурдаңыз: колдонуучунун фишинг барагы ошол эле URL дарегинде аяктайт жана колдонуучуга аны аныктоо кыйыныраак.
- Акыр-аягы, чабуулчу уюштура алат — 4 КБдан чоңураак cookie файлдарын коюу. Колдонуучуга шилтемени бир гана жолу ачуу керек жана колдонуучу атайын браузерди тазалоону ойлогонго чейин бүт сайтка кирүү мүмкүн эмес болуп калат: көпчүлүк учурларда веб-сервер мындай кардарды кабыл алуудан баш тартат.
Келгиле, башка табылган XSSтин мисалын карап көрөлү, бул жолу акылдуураак эксплуатация менен. MCS кызматы брандмауэр орнотууларын топторго бириктирүүгө мүмкүндүк берет. Топтун аты XSS табылган жерде болгон. Анын өзгөчөлүгү, вектор эрежелердин тизмесин карап жатканда эмес, топту жок кылууда дароо ишке кирбей турганында болгон:
Башкача айтканда, сценарий төмөнкүдөй болуп чыкты: чабуулчу атында "жүктөө" менен брандмауэр эрежесин түзөт, администратор аны бир аздан кийин байкап, жок кылуу процессин баштайт. Жана бул жерде зыяндуу JS иштейт.
MCS иштеп чыгуучулары үчүн, жүктөлүп алынган SVG сүрөттөрүндөгү XSSден коргоо үчүн (эгерде алардан баш тартуу мүмкүн болбосо), Digital Security командасы төмөнкүлөрдү сунуштады:
- Колдонуучулар жүктөгөн файлдарды "кукилерге" эч кандай тиешеси жок өзүнчө доменге жайгаштырыңыз. Скрипт башка домендин контекстинде аткарылат жана MCS үчүн коркунуч туудурбайт.
- Сервердин HTTP жообуна "Content-disposition: тиркеме" аталышын жөнөтүңүз. Андан кийин файлдар браузер тарабынан жүктөлүп алынат жана аткарылбайт.
Мындан тышкары, азыр XSS эксплуатациясынын тобокелдиктерин азайтуу үчүн иштеп чыгуучулар үчүн көптөгөн жолдор бар:
- "HTTP гана" желегин колдонуп, сиз сеанстын "Cookies" аталыштарын зыяндуу JavaScript үчүн жеткиликсиз кыла аласыз;
- чабуулчуга XSSти эксплуатациялоону бир топ кыйындатат;
- Angular же React сыяктуу заманбап үлгү кыймылдаткычтары колдонуучунун маалыматын колдонуучунун браузерине чыгарардан мурун автоматтык түрдө дезинфекциялайт.
Эки фактордук аутентификациянын кемчиликтери
Каттоо эсебинин коопсуздугун жакшыртуу үчүн колдонуучуларга ар дайым 2FA (эки фактордук аутентификация) иштетүү сунушталат. Чынында эле, бул колдонуучунун эсептик дайындары бузулган болсо, чабуулчунун кызматка кирүүсүнө жол бербөөнүн натыйжалуу жолу.
Бирок экинчи аутентификация факторун колдонуу ар дайым эсептин коопсуздугуна кепилдик береби? 2FAны ишке ашырууда төмөнкү коопсуздук маселелери бар:
- OTP кодун одоно күч менен издөө (бир жолку коддор). Иштин жөнөкөйлүгүнө карабастан, OTP катаал күчтөн коргоонун жоктугу сыяктуу каталар ири компанияларда да кездешет: , .
- Алсыз муундун алгоритми, мисалы, кийинки кодду болжолдоо мүмкүнчүлүгү.
- Логикалык каталар, мисалы, телефонуңузда башка бирөөнүн OTP талабын коюу мүмкүнчүлүгү ушул сыяктуу Shopifyден.
MCS учурда, 2FA Google Authenticator жана негизинде ишке ашырылат . Протоколдун өзү буга чейин убакыт сынагынан өткөн, бирок колдонмо тарабында кодду текшерүүнү ишке ашыруу текшерүүгө арзыйт.
MCS 2FA бир нече жерлерде колдонулат:
- Колдонуучунун аныктыгын текшерүүдө. Оор күчкө каршы коргоо бар: колдонуучу бир жолку сырсөздү киргизүүгө бир нече жолу гана аракет кылат, андан кийин киргизүү бир азга бөгөттөлөт. Бул OTPди одоно күч менен тандоо мүмкүнчүлүгүн бөгөттөйт.
- 2FA аткаруу үчүн оффлайн резервдик коддорду түзүүдө, ошондой эле аны өчүрүүдө. Бул жерде эч кандай катаал күч менен коргоо ишке ашырылган жок, бул эгер сизде каттоо эсебинин сырсөзү жана активдүү сессия болсо, резервдик коддорду калыбына келтирүүгө же 2FAны толугу менен өчүрүүгө мүмкүндүк берди.
Камдык коддор OTP тиркемеси тарабынан түзүлгөн сап маанилеринин бирдей диапазонунда жайгашканын эске алсак, кодду кыска убакыттын ичинде табуу мүмкүнчүлүгү бир топ жогору болгон.
"Burp: Intruder" куралы аркылуу 2FA өчүрүү үчүн OTP тандоо процесси
жыйынтык
Жалпысынан алганда, MCS продукт катары коопсуз көрүнөт. Аудит учурунда пентестинг тобу кардар VMлерине жана алардын маалыматтарына кире алган жок жана табылган кемчиликтер MCS командасы тарабынан тез эле оңдолду.
Бирок бул жерде коопсуздук үзгүлтүксүз иш экенин белгилей кетүү маанилүү. Кызматтар статикалык эмес, алар дайыма өнүгүп турат. Ал эми кемчиликсиз бир продуктуну толук иштеп чыгуу мүмкүн эмес. Бирок сиз аларды өз убагында таап, алардын кайталануу мүмкүнчүлүгүн азайта аласыз.
Эми MCSтин бардык айтылган кемчиликтери оңдолду. Жана жаңылардын санын минимумга түшүрүү жана алардын иштөө мөөнөтүн кыскартуу үчүн, платформа командасы муну улантууда:
- дайыма тышкы компаниялар тарабынан аудит жүргүзүү;
- катышууну колдоо жана өнүктүрүү;
- коопсуздук менен алектенүү. 🙂
Source: www.habr.com