Я уже писал ранее про бинарные баги в браузерах, связанные с web assembly. И вот первый известный мне экземлпяр: CVE-2017-5116, которая была обнаружена в JavaScript движке V8, а значит и в Chrome (для версии 61.0.3163.79 для десктопа и 61.0.3163.81 для Android). Детали по уязвимости появились сегодня.

Эта out of bounds бага возникает из-за race condition'а при доступе к уже полюбившемуся нам SharedArrayBuffer, содержащему WebAssembly код, из web-worker'а, который выполняется в другом потоке вкладки. Возникновение этой ситуации позволяет модифицировать WebAssembly-код, что в свою очередь позволяет атакующему получить read/write примитив. Подробное описание и технические детали есть тут: https://android-developers.googleblog.com/2018/01/android-security-ecosystem-investments.html.

Там же есть детали по баге CVE-2017-14904.
С помощью двух этих уязвимостей удалось взломать Google Pixel, который выжил и остался невзломанным в ходе Mobile Pwn2Own 2017.

Дошли руки посмотреть на исправления безопасности в новом релизе Chrome от 24 января (https://chromereleases.googleblog.com/2018/01/stable-channel-update-for-desktop_24.html). Мое внимание в этот раз привлекла уязвимость: “Same origin bypass in Shared Worker”. Видим, что id баги: 787103, доступ в нее, конечно, закрыт, а узнать детали хочется. Что же делать? Анализировать changelog!

Если под руками есть исходники Chromium’а, можно искать нужные коммиты через git, примерно так:

git log --all --grep="787103"


Если их нет, а тратить время на скачивание не хочется, можно пойти другим путём:

1. берем утилиту https://github.com/andreyka/chromium_bug_search и запускаем ее, передав id и название релиза:


python console.py -b 787103 -r 64.0.3282.119


2. получаем сообщение:


Commit found:
https://chromium.googlesource.com/chromium/src/+/018bb6d300c11acb953d51ef3cbec4cdcaf4a652


идем по ссылке в коммит и находим в его описании поле Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/781539.

3. проваливаемся в ревью, изучаем изменения, в конце видим 2 layout теста:

workers/data-url-shared.html;
data-url-shared-window.html.

По их коду видно, что уязвимость позволяет SharedWorrker’у с каким-то удаленным origin’ом получить доступ к MessageChannel’у c origin’ом null. Т.е из-за баги worker получает доступ к каналу чужого веб-ресусра.

Упрощенный локальный PoC на основе теста лежит тут: https://github.com/andreyka/PoCs/tree/master/CVE-2018-6032.

38 часов назад открыли детали интересной use after free баги в Jit V8 (CVE-2017-15399) с PoC, который умеет вызвать калькулятор в Chromium (если конечно запустить браузер с опцией —no-sandbox). Подробности тут: https://bugs.chromium.org/p/chromium/issues/detail?id=776677.

Но PoC для use after free баги в Jit V8 (CVE-2017-15399) можно было найти и раньше.
Вспоминаем недавнюю утилиту https://github.com/andreyka/chromium_bug_search и повторяем сценарий, но уже для этой CVE.

ID тикета мы бы получили из новости об этом релизе https://chromereleases.googleblog.com/2017/11/stable-channel-update-for-desktop.html, которая была опубликована 6 Ноября.

[776677] High CVE-2017-15399: Use after free in V8

Указываем ID тикета и что мы ищем ошибку в v8:

```python console.py -b 776677 -p v8 -r master
[+] Commit found:
https://chromium.googlesource.com/v8/v8/+/5f960dfc06a7c95af69e2b09f772b2280168469b```

В итоге попадаем в коммит https://chromium.googlesource.com/v8/v8/+/5f960dfc06a7c95af69e2b09f772b2280168469b, где видим готовый JS PoC - https://chromium.googlesource.com/v8/v8/+/5f960dfc06a7c95af69e2b09f772b2280168469b/test/mjsunit/regress/wasm/regress-776677.js, который был опубликован 23 Октября
#expdev #uaf #chrome

2 дня назад вышел новый отчет об улучшениях в безопасности Chromium'а, которые были сделаны в Q4 2017 года
Что там интересного:

- начиная с версии 63, у Chromium работает блокировка Cross-Site документов (HTML, XML и JSON), если включен режим site-isolation (http://www.chromium.org/developers/design-documents/blocking-cross-site-documents);

- также с 63 версии https://accounts.google.com теперь работает в выделенном рендререре;

- в Google начали разрабатывать Mac Sandbox V2, в котором так называемая warmup phase в macOS, которая сейчас будет работать уже в sandbox'е (https://chromium.googlesource.com/chromium/src.git/+/master/sandbox/mac/seatbelt_sandbox_design.md);

- c 23 ноября на 100% пользователей выкатили новый Chrome Cleanup Tool, улучшенный антивирусными технологиями ESET.

Полный отчет можно прочитать тут: https://dev.chromium.org/Home/chromium-security/quarterly-updates#TOC-Q4-2017

В Project Zero нашли интересный способ обойти sandbox Chromium'а.

Они обнаружили, что из рендерера в sandboх'е можно было вызвать интерфейс filesystem::mojom::Directory, который предоставлялся сервисом "catalog" и был инициализирован неправильно.
В частности, в Linux возможно было получить доступ к директории с бинарником браузера.

Подробности тут: https://bugs.chromium.org/p/project-zero/issues/detail?id=1450.

Фикс, который сделали в Chromium'е тут: https://chromium-review.googlesource.com/c/chromium/src/+/804397.

Ivan Fratric удачно пофаззил WebKit и сегодня открыл детали сразу по двум use after free багам:
https://bugs.chromium.org/p/project-zero/issues/detail?id=1465;
https://bugs.chromium.org/p/project-zero/issues/detail?id=1477. В последнем Safari у меня уже не работает.

Пока я был в небольшом творческом отпуске, в Chromium'e, FF и MS Edge нашли новый вид browlock'а.
Информация о том, что атаку уже используют ITW пришла от Malwarebytes еще в начале февраля (https://blog.malwarebytes.com/malwarebytes-news/2018/02/tech-support-scammers-find-new-way-jam-google-chrome/).

Для справки. Browlock - атака на браузер, при которой отдельная вкладка (или даже весь браузерный UI) не закрывается до тех пор, пока пользователь не выполнит нужное атакующему действие: например, выполнить денежный перевод, установить в браузер расширение и т.п.

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

Детали и PoC для Chromium есть тут: https://bugs.chromium.org/p/chromium/issues/detail?id=809775, в 65 версии хрома (которая пока еще в бете) блокировка уже не воспроизводится. Причем атака срабатывает, даже если пользователь не разрешил странице загружать несколько файлов одновременно.

Для Firefox тут (та же самая техника, что и в Chromium):
https://bugzilla.mozilla.org/show_bug.cgi?id=1438214
https://bugzilla.mozilla.org/attachment.cgi?id=8950967&action=edit

Для атак на Edge и IE используется функция:

navigator.msSaveOrOpenBlob()

но мои тесты показали, что поведение данного концепта в Edge (как и в FF) сильно зависит от версии и мощности компьютера, в старых версиях у меня просто подвисал интерфейс, но через некоторое время закрыть вкладку было можно.

Для Safari данный метод не является актуальным - блокировки интерфейса не происходит.

На днях твиттер принес упоминание об очень забавном тикете в Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=588766. Суть в том, что можно задетектить использование инкогнито вкладки, подключив на страницу ресурс из расширения, которое в икогнито не работает по умолчанию. Тогда, через onerror обработчик, можно ловить факт того, что ресуср не загрузился, а значит - пользователь во вкладке инкогнито.

Вообще-то во многих браузерах (кроме Safari версии 11+, браузеров под Apple iOS и Firefox Focus) обнаружить инкогнито при первом же посещении сайта можно через JavaScript API. Хороший PoC есть тут: https://jsfiddle.net/wsk6m6rc/.

Google объявил о запуске кампании по блокировке загрузки данных с веб-ресурсов, обладающих сертификатам, выданными Symantec или ее дочерними брендами: Thawte, RapidSSL,GeoTrust, VeriSign и Equifax.

Начиная с 66 версии Chromium, браузер начнёт показывать ошибку для сайтов с сертификатами, выпущенными до 1 июля 2016. А уже на 70 версии Chromium (бета-версия которой ожидается в сентябре) после 20 июля 2018 года браузер не будет доверять всем сертификатам Symantec независимо от даты выпуска.

Подробности тут: https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html?m=1

Firefox вслед за Chromium объявил о предупреждениях и блокировке ресурсов с сертификатами от Symantec.

С мая 2018 Firefox, начиная с версии 60, будет предупреждать о переходе на незащищенные веб ресурсы с сертификатами, выпущенными до 01.06.2016. С октября на версии 63 предупреждение будет активно для всех сертификатов Symantec.
Новость есть тут: https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/

Ждём реакции Microsoft Edge =)

Есть такая интересная технология для трекинга пользователей браузера - HSTS Super Cookie.
Она была описана еще в стандарте HSHTS: https://tools.ietf.org/html/rfc6797#section-14.9, а особенно интересна тем, что подходит для трекинга пользователей в приватном / инкогнито-режиме.

Суть в том, что веб-сайт может подгружать набор https-подресурсов, которые отдают HSTS-заголовки. Браузер пользователя, который зашел на сайт первый раз, получает эти заголовки и запоминает, что в дальнейшем на эти подресурсы надо ходить только по https, даже если в URI будет ссылка со схемой http. Соответственно, веб-сайт может таким образом задать в hsts-кэше некоторый уникальный идентификатор пользователя (закодировав его последовательностью hsts-поддоменов), который потом всегда сможет восстановить. Подробнее про механику трекинга написано тут: https://security.stackexchange.com/questions/79518/what-are-hsts-super-cookies

Интересно, что с такой идентификацией пользователя стал бороться WebKit. 16 марта они объявили, что теперь HSTS-флаг будет сохраняться в кэше браузера для веб-ресурсов, на которые непосредственно был выполнен переход (URL попал в адресную строку) или сделан редирект: https://webkit.org/blog/8146/protecting-against-hsts-abuse/. А еще у WebKit есть технология ITP (Intelligent Tracking Prevention https://webkit.org/blog/8142/intelligent-tracking-prevention-1-1/). Она очищает и не позволяет обновлять third-party-cookies веб-сайтов, которые не посещают пользователи. Теперь для ресурсов, которые блокируются ITP не будет кэшироваться HSTS.

Остальные браузеры пока что просто предлагают пользователям блокировать third-party cookies: https://www.maketecheasier.com/disable-third-party-cookies-chrome-firefox/

Команда безопасности Mozilla выложила в open source библиотеку Octo, которую можно использовать для разработки фаззеров JavaScript: https://github.com/MozillaSecurity/octo/blob/es6/README.md

Поиграться с ней можно прямо тут: https://npm.runkit.com/@mozillasecurity/octo

Нашёл в интернете гайд по полезным фичам Developers Tools для разных браузеров, которые могут пригодиться пентестерам: http://www.getmantra.com/web-app-security-testing-with-browsers/. Еnjoy.

На Zer0Con 2018 (zer0con.org) @singi21a из Theori рассказал о технике sandbox bypass в WebKit через ipc с WindowServer в macOS. Материалы и примеры кода можно найти тут: https://github.com/theori-io/zer0con2018_singi.
Атаки на GPU IPC становятся классикой в области обхода браузерных песочниц. В том году на той же конференции был похожий, но закрытый доклад от lokihardt.

Brian Pak из Theori сделал зубодробительный доклад об эксплуатации out of bounds уязвимостей в V8.
В нем есть и описание структур Partition Alloc (дефолтного аллокатора в Blink), и концепция r/w примитивов через freeListHeader и fake DataView, а также разбор реального примера их использования. Ну и на сладкое там есть сниппеты использования pwn.js (https://github.com/theori-io/pwnjs), который поможет сделать ROP (я уже писал об этой библиотеке ранее), если ему дать r/w примитивы.
Материалы тут: https://github.com/theori-io/zer0con2018_bpak?files=1.
В моем рейтинге это лучший доклад на Zer0Con 2018.

Интересный out of bounds read / write примитв в V8 Genesis::InitializeGlobal https://bugs.chromium.org/p/project-zero/issues/detail?id=1501.

И да, если кому-то интересна судьба фикса бага с примитивом stack-to-heap copy (https://bugs.chromium.org/p/project-zero/issues/detail?id=1420) в Chakra JIT, о котором я писал ранее, то Lokihardt нашел 2 обхода фикса: https://bugs.chromium.org/p/project-zero/issues/detail?id=1502 и https://bugs.chromium.org/p/project-zero/issues/detail?id=1503.

Все, кто интересуется обходом Arbitary Code Guard (aka ACG) и Code Integrity Guard (CIG) в MS Edge и Windows 10, должны изучить презентацию c CanSecWest'а 2018: https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxiaW5nc3Vuc2VjfGd4Ojc0YWZlOGNlMzg0YjYzMGY. На слайдах есть также ссылки на методы обхода CFG, которые были представлены на разных конференциях в 2017 =)

Не секрет, что расширения для браузера могут быть источником uXSS уязвимостей. Travis Ormandy нашёл забавный баг в расширении Video Downloader Professional, у которого почти 4 млн. пользователей: https://bugs.chromium.org/p/project-zero/issues/detail?id=1555

Для справки, uXSS - браузерная уязвимость, которая даёт атакующему возможность выполнить на сайте произвольный JavaScript в контексте любого (ну или почти любого) чужого origin’а.

Safari не перестает удивлять! Недавно закрыли выполнение произвольного кода с помощью функции возвращения квадратного корня (sqrt).

https://www.zerodayinitiative.com/advisories/ZDI-18-278/