книги хакеры / журнал хакер / 185_Optimized

Root винчестера

Взлом

4

Для доступа к информации из сервисных разделов не подойдут стандартные ATA-команды, вместо этого для записи и чтения используются специальные команды VSC (Vendor Specific Commands). Как правило, производители держат

всекрете эти команды, но порой выпускают утилиты для работы с сервисными разделами — например, программа wdidle3.exe от компании Western Digital и ее опенсорсный аналог idle3-tools. Еще один пример для WD — программа HDDHackr, меняющая записи в системных разделах HD.

Объем сервисного раздела зависит от модели винчестера. Например, в диске WD2500KS-00MJB0 семейства Hawk объемом 250 Гб (прошивка 02AEC) в сервисный раздел записывается две копии файлов, около 6 Мб каждая. Размер зоны на каждой поверхности составляет около 23 Mб (64 трека по 720 секторов на каждом). Поскольку этот диск имеет шесть поверхностей (головки от 0 до 5), модули сервисных разделов располагаются на месте, сопоставленном с головками 0 и 1, а место, закрепленное за головками со 2 по 5, зарезервировано, но не используется. Таким образом, зарезервированный раздел занимает около 141 Мб, из которых 12 Мб находится в использовании.

Для сравнения: модель WD10EACS-00ZJB0, емкостью

втерабайт и с восемью поверхностями, имеет зарезервированное пространство 450 Мб, из которых занято 52 Мб. Ариэль Беркман (Ariel Berkman) из компании Recover Information Technologies LTD написал статью о работе с сер-

висными отделами HDD, а также выложил PoC-код (bit.ly/ UXpBcC) для записи 94 Мб информации в сервисный отдел диска Western Digital 250GB Hawk. Делается это следующим образом:

• Узнаем свой SATA IO адрес, используя lspci -v.

• Для компиляции используем команду gcc -Wall -O -g -o

SA-cover-poc SA-cover-poc.c.

•Создаем рандомный файл (94 Мб в размере) и вычисляем его MD5-хеш.

•Записываем файл в сервисный раздел.

•Очищаем винчестер с помощью команды dd-ing /dev/ zero, которую следует распространить на весь жесткий диск (или на его отдельную часть, предварительно заблокировав доступ к остальному). Достаточно всего один раз прогнать этот код, чтобы уничтожить данные безвозвратно.

•Читаем содержимое сервисного раздела, вычисляем его хеш и убеждаемся в целостности данных.

root@Shafan1:~/SA# dd if=/dev/urandom count=184320 > random-file ; md5sum random-file root@Shafan1:~/SA# ./SA-cover-poc -p 0x0170

-w ./random-file

root@Shafan1:~# dd if=/dev/zero of=/dev/sdb bs=1M

root@Shafan1:~/SA# ./SA-cover-poc -p 0x0170 -r after-dding-dev-zero

root@Shafan1:~/SA# md5sum after-dding-dev-zero

Рис. 2. Разъем для подключения через последовательный порт. Одной тайной меньше

Рис. 3. Arduino Nano

в качестве адаптера

Рис. 4. Окно настроек

PuTTY

Рис. 5. Обнуление

S.M.A.R.T.

5

ЗАКЛЮЧЕНИЕ

Однако настало время закругляться. В этой статье я попытался показать неизведанные уголки и возможности жесткого диска. Не углубляясь в код, мы рассмотрели способы расширения возможностей винчестера.

Если даже слегка приподнять этот занавес, открывается огромное поле для полета фантазии. Можно, например, перепрошить контроллер, чтобы скрыть от посторонних глаз особо важный раздел. Или портить данные при попытке клонировать жесткий диск, обезопасив себя таким образом от криминалистических утилит.

Одним словом, вариантов для экспериментов действительно много, так что каким образом использовать жесткий диск — выбор за тобой.

ťŦŤřŦŖŢŢű Śšŵ ŘŤŧŧŨŖţŤŘšśţŞŵ HDD

При низкоуровневых экспериментах возможно столкнуться с такой неприятностью, как поломка винчестера. Не стоит сразу прибегать к драконовским мерам и форматировать диск, можно попробовать восстановить его работоспособность с помощью некоторых программ.

1.TestDisk — самая простая и эффективная программа для восстановления HDD. Предназначена для поиска и реконструкции потерянных разделов, загрузочного сектора, удаленных файлов; исправляет таблицу разделов. Работает с большим количеством файловых систем. Работает в консольном режиме, чем достигается высокая скорость.

2.Acronis Disk Director — целый программный пакет, в который включено немалое количество инструментов для работы с HDD. Содержит в себе утилиту Acronis Recovery Expert, которая служит для реконструкции файлов и разделов. В отличие от предыдущей программы имеет графический интерфейс, но работает с меньшим количеством файловых систем.

3.Paragon Partition Manager — бесплатная программа от отечественных разработчиков, умеет почти все то же самое, что и Acronis, но ужасно медленная.

Взлом

ЗАЧЕМНАМKPI?

На определенном этапе развития ИБ-компании может встать

ПРИМЕНИМНАДЕЛЕ

Итак, предположим, что у нас все уже налажено в «бумажной», организационной части ИБ: есть IDS, DLP, контакты с местным CERT, абуз-мыло, секурити-мыло и сканеры уязвимостей. Теперь нужно заранее определиться с регистрируемыми и контролируемыми параметрами инцидента. Для IT-дел есть всем известные метрики ITIL и COBIT, но в отношении инцидентов ИБ далеко не все метрики можно применить с пользой.

Возьмем пример: если мы будем замерять каждый месяц количество инцидентов, то что это нам будет говорить? Допустим, инцидентов было мало — это значит, что их нет или что мы их не засекли? То есть количество инцидентов в месяц, даже с их градацией по критичности и/или импакту, — не самый полезный показатель. То же самое с критичностью инцидентов — получается непонятная кривая, которая может прыгать в разные стороны, но не давать полезной информации.

Итак, что же можно считать важным параметром, по которому можно оценивать любой инцидент и за который должна отвечать наша команда? Одно из очевидных решений — время реакции. Как только случилось событие, важно зарегистрировать момент, когда наша команда приняла информацию об инциденте и начала действовать. Неплохо бы еще иметь и прописанные стандарты, позволяющие оценить качество реакции. В частности, по этим стандартам мы можем ранжировать инциденты по важности и назначать разное допустимое время реагирования. Скажем, будем считать, что все SQLi-алерты, приходящие из IDS, имеют высокий приоритет, а алерты, приходящие в результате сканирования Acunetix, — средний. Для каждого приоритета будут свои требования на время реагирования — так называемый SLA.

Теперь у нас уже есть как минимум две метрики, которыми можно оценивать работу команды реагирования: время реакции на инцидент и процент инцидентов с нарушенным SLA (то есть тянули с действиями очень долго).

Кроме того, имеет смысл также оценивать среднее время реакции, тогда по данной метрике можно видеть общий прогресс или регресс.

Кроме времени реагирования, есть еще время разрешения проблемы, то есть срок, который потребовался команде

KPI для мужиков

ŨŶƀƂƄżŻƈŸƑŹƁƕźŻƈƒźžŶŹƆŶƂƂŶƇKPI ƅƄƇƁžŸƉSLA

ŨŶƀƂƄżŻƈŸƑŹƁƕźŻƈƒźžŶŹƆŶƂƂŶƇŸƑŸƄźƄƂƅƄIDS

IDS FP ~ 13%

1

13

Detected Attacks

(System Not Affected)

Succesful Attacks

(True Positives)

False Positives

118

на разрешение инцидента и его закрытие. Например, как много времени понадобилось для установки патча Heartbleed, нахождения инсайдера и остановки его деятельности и/или выявления всех связанных с этим инцидентом важных деталей (завершенное расследование инцидента). И это время для разных типов инцидентов тоже может быть в рамках некоторых допустимых пределов, то есть опять SLA. И соответственно, такие же метрики — сколько раскрытых не вовремя инцидентов, среднее время закрытия уязвимостей и так далее.

Итого у нас уже минимум шесть метрик, которые еще сами по себе можно ранжировать по типам инцидентов, — например, при работе с DLP-источником у нас уходит больше времени на заключение по инциденту, чем с IDS, так как требуется больше человеко-часов для того, чтобы разобраться, что произошло. Это обобщение, которое базируется на сухих фактах. Например, используя среднее время реагирования, можно обосновать требования к SOC по работе 24/7, если такой роскоши еще нет.

Конечно, требования к метрикам зависят опять же от задач и целей, которые мы решаем и определяем, но главное, что такие цифры показывают именно эффективность нашей работы, а не абстрактную статистику уязвимости и инцидентов, которая не очень четко говорит об эффективности. Взять, например, другой показатель — число выявленных критичных уязвимостей, ранжированных по источнику события: сканер безопасности, внешние пентесты, внутренний источник

(собственная SecTeam, например), Bug Bounty, Abuse report

и так далее. Такая метрика может реально показывать процент эффективности того или иного источника. Например, были у нас одни цифры до введения Bug Bounty, а после стали другие — количество инцидентов с IDS и Bug Bounty выросло, а, допустим, количество инцидентов с Abuse report и внешних пентестов упало. Или в итоге вообще количество инцидентов, которые привели к «взлому плохими парнями», упало. Но возможно, ничего и не изменится :). У разных компаний, с разным ИТ-ландшафтом и бизнесом, будут разные результаты.

Дополнительно уже не совсем про инциденты, но все же — можно строить KPI для самих «источников», например как от-

ношение False Positive к True Positive, в случае Bug Bounty —

как Low Critical и High Critical репортов к общему количеству репортов и так далее.

В итоге будет статистически видно, какие источники более «булшитны» и менее полезны, а главное — по этой же метрике можно смотреть, как в течение года мы влияли на результат. К примеру, наш IDS дает N% False Positive алертов, что создает инцидент (в момент алерта это обычный высокоприоритетный инцидент, мы еще не знаем, что там и почему, но в процессе разбора сделали заключение — False Positive). Такие FP тратят ресурсы компании, поэтому очевидно, что процент FP надо снижать, например оптимизировать правила IDS, делая их более точными, или отключать, если они вообще неприменимы в данной среде. В итоге эта метрика в динамике будет показывать, как мы работаем c IDS: игнорируем, улучшаем FP-показатель, уменьшая его, или он вообще растет, потому что мы бездумно увеличиваем сигнатурную базу всякой дрянью.

ЧТОЖЕХОТЕЛСКАЗАТЬАВТОР?

Как видно, в инфобезопасности можно придумать очень много возможных метрик, но главное — использовать их с умом. Любой инцидент как объект имеет множество свойств и параметров, которые можно отслеживать, ранжировать, группировать и делать выводы.

Главное — понять, чего мы хотим, и ориентироваться на реальную применимость и адекватность в рамках своей среды. То есть это не должна быть просто «менеджерская» инициатива с целью изобразить бумажную деятельность. Метрики могут быть очень полезны, особенно когда они основаны на реальных данных, которые зависят от реальных событий и реальной работы, иначе это будет невозможно интерпретировать. Поэтому нужно понимать, кто будет работать с KPI, для каких целей, какие процессы затрагиваются и нужно ли это вообще — насколько это адекватно. Если все сделать по уму, то даже «бумажная» ИБ будет практична.

Так что придумать можно все что угодно, главное — чтобы все это имело смысл как для тех, кто оценивает, так и для тех, кого оценивают. Всем добра.

Взлом

РАССМАТРИВАЕМ ПРОХОЖДЕНИЕ САМЫХ ИНТЕРЕСНЫХ ЗАДАНИЙ ИЗ ОДНОЙ НЕБЕЗЫЗВЕСТНОЙ ЛАБОРАТОРИИ «СА»-ПРОФИТ

В данной публикации описано прохождение большинства предложенных заданий лаборатории с конкурса «СА»-ПрофИТ, который проводился в начале сентября 2013 года онлайн на портале PentestIT, а сейчас активно используется в проекте Zero Security.

ВСТУПЛЕНИЕ

Приветствую тебя, уважаемый читатель. Начну свое повествование, пожалуй, с того, как сам столкнулся с этой лабораторией. О ней я узнал после того, как попал на бесплатную стажировку от Zero Security (bit.ly/1i0lHGO), в которой данная лаборатория использовалась для практического взлома. Прежде всего необходимо было зарегистрироваться на сайте лаборатории. Первым делом после регистрации нашему взору предстает карта с довольно подробной схемой сети, захватом которой мы и будем заниматься. Что же конкретно нужно делать? Все в добрых традициях CTF-состязаний — получить десять флагов. Ну что ж, довольно пустых разговоров, приступим к захвату.

ФЛАГ1

Первым меня заинтересовал флаг SMTP. Надо сказать, что с ним все было достаточно очевидно, — на 25-м порту явно висел SMTP-сервер. Найдя на сайте некую почту info@ test.lab, я решил попробовать просто сбрутить пароль для нее. Для этого я воспользовался стандартной утилитой, входящей в состав Kali Linux, под названием Hydra. Почитав немного мануалов, соорудил следующую конструкцию:

hydra -l info@test.lab -P passwords.lst smtp://192.168.56.252:25

ФЛАГ2

Посмотрев названия всех тасков на карте, я, не знаю почему,

WARNING

Вся информация, содержащаяся в статье, предоставлена только в ознакомительных целях.

Карта сайта

Взлом

Наш флаг GAME где-то здесь

function get_new_level(start_height,hash){

flag_cur_count = 0

elements = new Array();

flags = new Array();

.........

$.ajax({

url:"/home/newlevel",

dataType: "json",

type: "POST",

async: false,

data: {height: start_height, hash: hash},

success: function(data){

..........

flag_fisrt = data.pop()

if (flag_fisrt.id == "key"){

alert(flag_fisrt.type)

flag_fisrt = data.pop()

}

flag_count = flag_fisrt.type

ctx_score.fillText(flag_count, 15 , 30)

$.each(data, function(i,j){

if (width <= cur_width){

cur_height+=48

cur_width = 0

}

switch(j.type){

.........

}

cur_width+=48

})

},

complete: function(){

ball = {x:24,y:start_height}

setInterval(play,10)

}

})

что в этом задании необходимо найти и расковырять какую-то инъекцию. Однако у меня почему-то очень долго не срасталось с ее выбором. Пока в один прекрасный момент, тихонько пыхтя над задачей, я не обнаружил такую уязвимость, как Post Command Injection. Суть данной атаки заключается в том, что через определенный символ-разделитель указывается обычная линукс-команда, результат выполнения которой мы и видим на экране. Поняв, что это то, что нужно, я указал в строке пинг команду ;ls;, в результате чего в ответ мне вернулся список директорий. «Ура!» — подумал я и начал аналогичным способом исследовать каждую директорию. Так и был найден этот флаг.

ФЛАГ4

Следующим делом я решил идти на поиски уже упоминавшегося флага TERMINAL. После некоторой мороки с SSHподключением я наконец увидел заветную строку приветствия терминала. Дальше все шло не совсем как обычно, а если точнее — был найден файл с неизвестным мне до сих пор расширением terminal.tr. Скажу сразу: на то, чтобы разобраться, что же это за файл, времени ушло гораздо больше, чем на решение самого таска :) Ну собственно, после N часов гугления я выяснил, что это какой-то криптоконтейнер. Почитав немного об этом виде файлов, я установил, что, вероятнее всего, этот контейнер создан утилитой TrueCrypt. В стандартном инструментарии все того же Kali нашлась утилитка, под названием TrueCrack, с помощью которой можно было вскрыть этот криптоконтейнер. Я запустил вот такую команду для подбора пароля:

truecrack -t /root/terminal.tr -s 4 -m

6 -v -c 0123456789

и пошло долгое время ожидания. Через несколько часов наша утилитка сказала, что пароль подобран. С огромнейшим удовольствием я взглянул внутрь контейнера и там нашел наш долгожданный флаг.

ФЛАГ5

Тем временем сложность флагов все росла, и мы стали подбираться к гораздо более интересным таскам. Одним из таких оказалось задание под названием FILE. Первым делом я взялся сканировать Nmap’ом машину данного флага. В результате сканирования обнаружилось несколько открытых портов, а также два порта, назначение которых я не знал. Именно поэтому они сразу привлекли мое внимание, и я решил, что именно их должен проверить в первую очередь. Надо сказать, чутье на этот раз меня не подвело. На этих портах висел файловый сервер Samba (что это такое, я опять же узнавал из гугла :)). Ну что ж, немного поколупавшись, я выяснил, что для подключения нам необходима пара логин/пароль. Логин, кстати говоря, был успешно найден на почте (помнишь самый первый флаг?), хотя в тот момент я еще и не подозревал, от чего он. Пробросив для дальнейшей работы один из портов следующим образом:

ssh info@192.168.56.252 -L

0.0.0.0:1139:172.16.0.4:139

с помощью уже известной нам Hydra начинаем брутить пароль к самбе:

hydra -l m.ivanova -P john.password.lst

smb://localhost:1139

После получения пароля, пробросив второй порт, необходимо подключить удаленную директорию. Сделать это можно прямо из родного для Kali «проводника» — прописав в адресную строку smb://localhost, мы увидим две замечательные директории. В одной из них лежит наш заветный флаг. А вот во второй оказались файлы, на которые я на радостях даже не обратил внимания. Забегая вперед, скажу тебе по секрету, что в эту директорию мы еще чуть позже вернемся.

ФЛАГ6

Итак, наша следующая цель — флаг IDS. Его я искал весьма долго: файл был надежно спрятан. Однако, затратив максимум усилий и уйму времени, обнаружил наконец файл ids.cap. Файлы такого расширения я встречал и раньше (когда пытался поломать