Проверка ведер. Как искать уязвимости в бакетах AWS S3 - «Новости»

Ес­ли тол­ком ничего не находит­ся, то идем на сайт ком­пании. Здесь нам поможет Burp Suite. Прос­то прос­матри­вай веб‑сайт, а затем ана­лизи­руй получен­ную кар­ту.

При этом бакеты всег­да находят­ся на сле­дующих URL:

Нуж­но ли нам под­бирать пра­виль­ный реги­он? Нет! Amazon любез­но под­ска­жет, что мы ищем где‑то не там. Поэто­му нам дос­таточ­но лишь наз­вания бакета.

Но как получить это наз­вание? Чаще все­го оно скры­вает­ся в записях CNAME (в них сопос­тавле­ны псев­донимы с исходны­ми DNS-име­нами) домена ата­куемой ком­пании. Обна­ружить их мож­но вот так:

При­мер:

Да, может быть, CNAME и пуст, но пос­мотрим, что еще есть на этом IP:

При­мер:

И получим, что к IP при­вязан еще и адрес s3-website-us-west-2.amazonaws.com. Это так называ­емый Website Endpoint. Эндпой­нты исполь­зуют­ся, ког­да с бакетом интегри­рован прос­тень­кий ста­тичес­кий веб‑сайт.

Все бакеты S3, нас­тро­енные для веб‑хос­тинга, получа­ют домен AWS, который мож­но исполь­зовать без собс­твен­ного DNS. То есть имя бакета в дан­ном слу­чае сов­пада­ет с име­нем домена, а имен­но flaws.cloud.

Ко­неч­но же, каж­дый домен переби­рать вруч­ную проб­лематич­но. Уско­рит дело прос­тень­кий скрипт на Bash:

Об­рати вни­мание, что не все домены зарегис­три­рова­ны как записи CNAME. Некото­рые могут не отоб­ражать­ся явно в про­цес­се раз­решения имен. В таком слу­чае удоб­но исполь­зовать сайт dnscharts.hacklikeapornstar.com. Сюда мож­но заг­рузить спи­сок доменов, а сер­вис уже самос­тоятель­но най­дет записи и по воз­можнос­ти сопос­тавит их с облачны­ми сер­висами.

Ес­ли ты не зна­ешь, как находить под­домены, то рекомен­дую ути­литу Amass в связ­ке с но­вой тех­никой перечис­ления доменов.