такая операция в среде wow64 не разрешена как обойти
Security Week 45: побег из песочницы, обход EMET через WoW64, взлом 000webhost
В 45 выпуске дайджеста о кибербезопасности Константин Гончаров оставил темы теории криптографии и законодательства, и наконец заговорил о старых добрых киберугрозах.
Цитаты из книги Евгения Касперского, которые я прикладываю к каждому новостному дайджесту, хорошо показывают ландшафт угроз по состоянию на начало 90-х годов прошлого века, а точнее — расположение темы ИБ по отношению к остальному миру. Примерно до начала двухтысячных, до появления первых массовых эпидемий все еще довольно простых зловредов, информационная безопасность воспринималась как нечто еще более сложное, чем IT в целом.
Хорошие были времена, но они закончились. В середине десятых киберугрозы обсуждают все: научные работники, парламентарии и даже звезды эстрады. Это хорошо заметно по октябрьским дайджестам самых популярных новостей: сначала мы ударились в теорию криптографии, а потом внезапно перескочили в законодательство. И, таки да, приходится: все это так или иначе влияет на киберпространство, пусть и не прямо сейчас.
Но вообще-то, вообще-то, практическая безопасность как была сложной, чисто технической темой, так и осталась. Ландшафт угроз нельзя адекватно оценить, если смотреть только на реакцию общества или только на научные исследования. Те самые законопроекты — они важны, но с практикой имеют мало общего. Они и с IT в целом связаны только потому, что их текст набирался на компьютере в «Ворде».
Законодатели и безопасность, криптография и разведка — чем запомнилась прошедшая неделя: https://t.co/2J0cWUICEy pic.twitter.com/HGqSNxNfYw
Это не то чтобы великое открытие, но явный намек: неплохо было бы соблюдать баланс. Отрадно, что на этой неделе все самые популярные новости — как раз из практической сферы. Никакой политики, никаких угроз, потенциально эксплуатируемых лет через пятнадцать. Все здесь и сейчас, как мы любим. Да здравствует умеренный хардкор. Уи-и-и-и!
В Xen закрыта опасная уязвимость, позволяющая осуществить sandbox escape
Что нашли: уязвимость в гипервизоре Xen начиная с версии 3.4.0, позволяющую при ряде условий получать полный контроль над системой из виртуальной машины, совершив то, что называется «побег из песочницы». Очевидцы событий трактуют инцидент по-разному. Сдержанный бюллетень Xen гласит: «Код, используемый для валидации данных таблиц второго уровня, можно обойти, если удовлетворены определенные условия».
Разработчики QubesOS, операционной системы с упором на безопасность, выражаются проще: «Пожалуй, худшая [уязвимость] из всех, что мы наблюдали в гипервизоре Xen. К сожалению».
Реакция разработчиков Xen:
Реакция разработчиков QubesOS:
Их можно понять — QubesOS использует виртуализацию, чтобы максимально изолировать друг от друга задачи: работу от развлечений, банкинг от порносайтов с картинками и так далее. Любая уязвимость класса sandbox escape накрывает медным тазом всю их тщательно настроенную защиту, отсюда и фрустрация. И не только у них: кодовую базу Xen активно используют тот же Amazon и еще тысячи компаний по всему миру. В частности, зарепортил эту уязвимость эксперт из китайской Alibaba. Про Amazon рекомендую почитать эту статью, довольно подробно описывающую процесс митигации.
Но в целом и так понятно: нужно оценить масштаб проблемы, накатить патч, причем сделать это быстро, но при этом ничего не сломав у клиентов (в идеале даже не перезагружая их VM). Непростая задача.
Но важная, так как в теории можно купить десяток копеечных виртуалок в разных дата-центрах Amazon EC2, через них получить контроль над хостами и далее отправиться в увлекательный квест по чужим серверам. Ключевое слово здесь «в теории»: пруфов не было и не предвидится, да и не думаю, что Amazon по части безопасности полагается только на код Xen. Но для оценки масштабов проблемы это правильный пример. Часто ли находят подобные дыры?
Xen Project закрыл брешь, которая позволяла выйти за пределы виртуалки и исполнить произвольный код на хост-машине: https://t.co/Hm02q4aHkY
Чаще, чем хотелось бы. Представитель QubesOS вообще пишет, что в процессе разработки Xen не очень заметно, чтобы безопасность была в приоритете. Предыдущую уязвимость (тоже sandbox escape, но с более жесткими ограничениями по эксплуатации) нашли в конце июля.
Подсистема WoW64 может быть использована для обхода EMET в Windows
Enhanced Mitigation Experience Toolkit — это набор технологий Microsoft, направленный на повышение защищенности приложений. Иными словами, он позволяет применить методы, усложняющие жизнь взломщиков, такие как ASLR и DEP, к программам даже в том случае, если разработчики сами не позаботились о внедрении этих полезных технологий самостоятельно. Такое «удобство» приводит и к очевидному недостатку: если систему EMET обойти, то это приведет к снижению уровня защиты не какого-то конкретного приложения, а сразу целого набора.
То, что нашли исследователи компании Duo Security, — это даже не уязвимость в смысле эксплуатируемой дыры в EMET. Это скорее «утечка на стыке» — EMET оказалась менее эффективна в 64-битной ОС, если вы работаете с программой, написанной для 32-битной версии. Что происходит часто, если не сказать почти всегда: например, большинство браузеров представляют собой 32-битный процесс в 64-битном окружении. В качестве пруфа приложу картинку со своего компьютера (а как память-то кушает!).
Для корректной работы такой конструкции в Windows 64-bit есть подсистема WoW64 (не «вау», а Windows on Windows). Успех работы EMET зависит от того, насколько хорошо технологии защиты контролируют чужой код, а в случае с применением WoW64 получается, что они этот код контролируют плохо. В качестве примера исследователи приводят эксплойт типа use-after-free-уязвимости в Adobe Flash, обнаруженной в январе этого года.
EMET предназначен для борьбы именно с такими трюками с памятью (если уж разработчик не смог), но небольшая модификация эксплойта специалистами позволила полностью обойти систему защиты Windows из-за сложностей взаимодействия EMET и WoW64.
От версии к версии MS EMET растёт не столько защита, сколько длина кода для успешной атаки https://t.co/GVuVdUL0Q8
Никому нельзя доверять. К счастью, это пока только исследование, но вывод из него понятен: Microsoft большие молодцы с системой EMET, но полностью полагаться на нее нельзя. Если уязвимость все же обнаружена и эксплуатируется, то нужно иметь возможность заблокировать ее несколькими способами, и чем больше их будет, тем лучше. В идеале эксплойту нужно вообще не дать загрузиться на уязвимую ОС или запуститься в уязвимом приложении, пристрелив его на дальнем рубеже, по черному списку сомнительных URL. История с Xen, хоть и совершенно из другой оперы, говорит о том же: безопасности должно быть много и по возможности везде.
Вишенка на тортике: некоторые исследования избавляют меня от проблемы поиска смешных картинок. Duo Security предлагает такую:
Взлом хостера 000webhost привел к утечке паролей 13,5 миллиона пользователей
Новость. FAQ хостера. Оригинальный пост о взломе в Facebook (100 лайков). Пост эксперта Троя Ханта с деталями.
Теоретически история с уязвимостью с Xen может использоваться для взлома хостингового провайдера: есть виртуалки, есть уязвимость, есть эксплойт, есть выход на приватную информацию, например на базу клиентов. Взлом литовского хостера 000webhost показывает, что такая сложная тактика, в общем-то, и не нужна (даже если возможна), когда есть гораздо более простые и надежные методы. В данном случае сломали устаревшую версию PHP на сайте компании, через это получили доступ к данным клиентов, включая пароли. Трой Хант, владелец сервиса «Have I been pwned?», утверждает, что пароли пользователей хранились у хостера открытым текстом.
Кто-то устроил взлом литовского хостинг-провайдера 000webhost, в результате чего оказались раскрыты 13 млн. паролей: https://t.co/qXlnK9yGZK
Ну вот и какой смысл использовать сложные методы атаки и исследовать уязвимость шифров, когда в реальности наши данные утекают вот так? Впрочем, среагировали на инцидент в 000webhost корректно: выложили всю необходимую информацию, сбросили пароли, временно закрыли доступ к некоторым сервисам (и не забыли сообщить, когда доступ был вновь открыт). Большими буквами, болдом, курсивом и с подчеркиванием в FAQ по инциденту написано следующее:
Ну ладно, признаю, курсива не было. Но мысль правильная: не надо использовать скомпрометированные пароли где-либо еще. Я бы добавил, что пароли вообще, по-хорошему, должны быть уникальными. В светлом будущем нашего более защищенного кибермира будет именно так.
Что еще произошло:
Новости социнжиниринга: мобильный зловред прикидывается документом Word с хорошо знакомой и понятной всем иконкой. Крадет персональные данные, рассылает платные SMS, звонит на платные номера телефонов.
Android-зловред выдает себя за документ Word и при активации нагло крадет со смартфона личные данные: https://t.co/8of4X3op3l
Вышел патч уязвимости Stagefright 2.0, первыми его получат владельцы смартфонов Nexus и те, кто регулярно синхронизирует кодовую базу с Android Open Source Project. Остальным, как водится, придется подождать, от одного месяца до никогда.
Древности:
При запуске зараженного файла поражают MBR винчестера (уменьшают размер логического диска и в освободившееся пространство записывают старый MBR-сектор и свое продолжение). Файлы (COM и EXE) стандартно инфицируются при запуске. В файлах «Flip» является вирусом-«призраком»: зашифрован, а расшифровщик не имеет постоянного участка (сигнатуры) длиннее, чем 2 байта.
Второго числа в 16.00 «переворачивают» экран: меняют (верх-низ, право-лево) расположение символов на экране и переворачивают их изображение («Р» — «Ь»).
«Flip-2327» заменяет в файлах набор команд:
(такое сочетание команд встречается в файле COMMAND.COM в подпрограмме, отвечающей за вывод на экран результатов работы функций DOS FindFirst и FindNext) — на вызов INT 9Fh. Вирус содержит обработчик int 9Fh и «уменьшает» длину файлов. Файлы, измененные таким способом, следует восстановить из резервных копий программного обеспечения.
Содержат текст «OMICRON by PsychoBlast». Перехватывают int 10h, 1Ch, 21h, 9Fh.
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницы 103, 104.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
[Файловая система] Обход механизма перенаправления WOW64 в 64-битных системах
erlik
Продвинутый
Вопрос: корректно ли здесь использовано отключение редиректа.
Вопрос: нужно ли отключение редиректа здесь:
inververs
AutoIT Гуру
4. Макрос @SystemDir возвратит по умолчанию C:\Windows\system32
Но если запертить использваться 64 битный Autoit, например, выствив #AutoIt3Wrapper_UseX64=N, то макрос возвратит C:\Windows\SysWOW64
Yashied
Модератор
Что такое редирект? Механизм, который позволяет изолировать 32-битные системные файлы от 64-битных. Это актуально только, если 32-битное приложение запускается в 64-битной ОС. К 64-битным приложениям это не относится. Для чего нужен редирект? Для того, чтобы не перекомпилировать 32-битные приложения для запуска в 64-битной ОС. Например, у вас есть такой вызов:
При выполнении этой функции файл будет браться по следующему пути:
При запуске этого кода в 64-битной ОС путь будет автоматически изменен ОС на следующий:
Это и есть результат работы редиректа. Т.е. система сама исправляет пути, ссылающиеся на System32 на SysWOW64, т.к. в первой находятся 64-битные версии библиотек, а 32-битные во второй. Если бы этого не было, то любой явно указанный вызов из системных библиотек привел бы к краху 32-битного приложения запущенного в 64-битной ОС. Например, следующий вызов в 32-битном приложении будет всегда работать, независимо от того, на какой ОС будет запущен (32- или 64-битной), если включен редирект:
Но если отключить редирект, то приложение вылетит в случае его запуска в 64-битной ОС. Все это хорошо, но бывают случаи (например ваша программа), когда необходимо из 32-битного приложения добраться до файлов, находящихся в System32, а не SysWOW64. Для этого и существует возможность отключать редирект. В противном случае, это было бы невозможно. Почему рекомендуется отключать редирект с осторожностью? См. пример с DllCall() выше.
Что касается AutoIt и функций File. то, естественно, AutoIt не вмешивается в работу редиректа. Это должны делать именно вы. Вообще, запомните следующее, если 32-битное приложение запускается на 64-битной ОС, то по умолчанию при любых обращениях к System32 система будет перенаправлять такие вызовы к SysWOW64. Насчет редиректа, Microsoft рекомендует поступать так (если это нужно): отключить редирект, получить хэндл файла, включить редирект. В AutoIt я обычно делаю так: