mkDOSfs-атака
Заветной целью компьютерного негодяя является получение root-шелла, т.е. возможности выполнять команды с максимально высокими полномочиями. Но вот эта цель достигнута, что дальше? Кто-то тихарится до поры-до времени, чтобы в нужный момент включить взломанный компьютер в атакующий ботнет. Кто-то сразу начинает эксплуатировать его для рассылки спама. Вариантов множество. Задача полностью вывести систему из строя ставится редко. Но, оказывается, есть способ обрушить зараженную машину максимально надежно и изощренно…
Внимание! Материал публикуется в целях информирования компьютерного сообщества об обнаруженной уязвимости. Автор не несет ответственности за применение изложенного материала в противозаконных целях.
Речь не идет о традиционных вариантах:
(т.н. патч Бармина)
и т.п.
У этих методов есть недостатки:
1) На их выполнение требуется некоторое время (операция rm отнюдь не мгновенная).
2) Результаты вреда становятся заметны сразу и легко отследить момент вторжения (хотя можно, конечно, и по расписанию навредить).
3) Большинство современных систем не так-то легко позволит выполнить такое.
Метод, с которым столкнулся я, гораздо более коварен. Экспериментируя с загружаемыми флэшками, перепутал буквы и вместо
ввел
где /dev/sda — жесткий SATA диск, на котором находились система, пользовательские файлы, исходники, всё это очень хорошо отлажено за долгие месяцы, стабильно работало… Короче говоря, пинсец, насяльника. Но самое страшное заключалось не в том что я разрушил файловые таблицы, а система без сопротивления позволила это сделать, а в том, что после введения смертоносной команды ничего страшного не произошло: компьютер как ни в чем не бывало весело выполнял задачи, ибо файловые таблицы разделов, конечно же, были в момент загрузки считаны в ОЗУ и эксплуатировались оттуда. Мысль о том, что случилось страшное, некоторое время напоминала о себе, однако нужно было доделать срочную работу, связанную с теми самыми злополучными загружаемыми флэшками, и бэкап решено было сделать «потом». Я благополучно проработал несколько часов, а в 3 ночи выключил машину, т.к. мысль добраться до кровати вытеснила все остальные.
Пробуждение было страшным. Всё, всё что нажито непосильным трудом… Эх, да что там говорить.
Сейчас, по прошествии недели, систему восстановил почти в прежнем виде (заодно обновив до свежайшей версии), а большую часть данных собрал из внешних бэкапов (такие, к счастью, случаются). И все-таки кое-что погибло безвозвратно.
Как видите, данный метод разрушения очень эффективен. Во-первых, вредоносный удар наносится мгновенно и инструментом, который входит в состав почти любого дистрибутива. Во-вторых, последствия проявляются только после перезагрузки, что сбивает с толку жертву: невозможно выяснить ни момент атаки, ни логику атаки. В-третьих, ни один из инструментов для восстановления файловых таблиц (типа testdisk и иже с ним) не помог: погибшая разметка была достаточно сложной и часть разделов так и не определилась, причем среди не определившихся были самые ценные.
Выводы:
1) Регулярно делать резервные копии .
2) Сообщить об этой уязвимости mkdosfs разработчикам (другие подобные инструменты, такие как mkfs.extX, не согласятся выполнять столь опасные операции на примонтированных дисках).
3) Рассмотреть альтернативные способы загрузки системы с носителей, доступных только для чтения. По такому принципу работает, например, мой шлюз — грузится с LiveCD и любая авария на нем исправляется простой перезагрузкой.
Внимание! Материал публикуется в целях информирования компьютерного сообщества об обнаруженной уязвимости. Автор не несет ответственности за применение изложенного материала в противозаконных целях.
Речь не идет о традиционных вариантах:
rm -rf /*
(т.н. патч Бармина)
dd if=/dev/random of=/dev/sda
и т.п.
У этих методов есть недостатки:
1) На их выполнение требуется некоторое время (операция rm отнюдь не мгновенная).
2) Результаты вреда становятся заметны сразу и легко отследить момент вторжения (хотя можно, конечно, и по расписанию навредить).
3) Большинство современных систем не так-то легко позволит выполнить такое.
Метод, с которым столкнулся я, гораздо более коварен. Экспериментируя с загружаемыми флэшками, перепутал буквы и вместо
mkdosfs -I /dev/sdf
ввел
mkdosfs -I /dev/sda
где /dev/sda — жесткий SATA диск, на котором находились система, пользовательские файлы, исходники, всё это очень хорошо отлажено за долгие месяцы, стабильно работало… Короче говоря, пинсец, насяльника. Но самое страшное заключалось не в том что я разрушил файловые таблицы, а система без сопротивления позволила это сделать, а в том, что после введения смертоносной команды ничего страшного не произошло: компьютер как ни в чем не бывало весело выполнял задачи, ибо файловые таблицы разделов, конечно же, были в момент загрузки считаны в ОЗУ и эксплуатировались оттуда. Мысль о том, что случилось страшное, некоторое время напоминала о себе, однако нужно было доделать срочную работу, связанную с теми самыми злополучными загружаемыми флэшками, и бэкап решено было сделать «потом». Я благополучно проработал несколько часов, а в 3 ночи выключил машину, т.к. мысль добраться до кровати вытеснила все остальные.
Пробуждение было страшным. Всё, всё что нажито непосильным трудом… Эх, да что там говорить.
Сейчас, по прошествии недели, систему восстановил почти в прежнем виде (заодно обновив до свежайшей версии), а большую часть данных собрал из внешних бэкапов (такие, к счастью, случаются). И все-таки кое-что погибло безвозвратно.
Как видите, данный метод разрушения очень эффективен. Во-первых, вредоносный удар наносится мгновенно и инструментом, который входит в состав почти любого дистрибутива. Во-вторых, последствия проявляются только после перезагрузки, что сбивает с толку жертву: невозможно выяснить ни момент атаки, ни логику атаки. В-третьих, ни один из инструментов для восстановления файловых таблиц (типа testdisk и иже с ним) не помог: погибшая разметка была достаточно сложной и часть разделов так и не определилась, причем среди не определившихся были самые ценные.
Выводы:
1) Регулярно делать резервные копии .
2) Сообщить об этой уязвимости mkdosfs разработчикам (другие подобные инструменты, такие как mkfs.extX, не согласятся выполнять столь опасные операции на примонтированных дисках).
3) Рассмотреть альтернативные способы загрузки системы с носителей, доступных только для чтения. По такому принципу работает, например, мой шлюз — грузится с LiveCD и любая авария на нем исправляется простой перезагрузкой.
Комментарии (7)
RSS свернуть / развернутьУж если рушить так чтобы наверняка — чтобы testdisk и photorec не помогли
Я думаю что если постараться — можно было восстановить раздел
Sergei_T
yababay
Sergei_T
FREExLOADER
ahmetzyanov_d
У меня было хуже — заводскую систему управления линией уронили
два электрика игрушкой.
Но я правило 1 и правило 3 — соблюдаю свято !!!
Markony
ksandras
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.