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

Проверка осведомленности персонала об ИБ-угрозах является одним из самых востребованных кейсов. Проводится она, как правило, методами социальной инженерии.

Данный пост написан мной в соавторстве с коллегами Перспективного мониторинга на основании реальных кейсов, отработанных нашей рабочей группой на практике.

Цель: проверка соблюдения сотрудниками политик ИБ.
Методы: социальная инженерия.
Локальная цель: получение информации, которая позволит реализовать атаку «повышение привилегий».

Приветствую всех, кто решил прочитать мою новую статью с разбором уязвимостей. В прошлый раз небольшим циклом из трех статей я рассказал об уязвимостях в Steam (1, 2 и 3). В данной статье я расскажу об уязвимостях похожего продукта — Origin, который тоже является лаунчером для игр. Обнаруженные уязвимости получили номера CVE-2019-19247 и CVE-2019-19248.



В этот раз не будет никакой дичи с банами-анбанами. История общения с security подразделением компании Electronic Arts Inc изначально шла на профессиональном уровне. При обращении мне выдали регистрационный номер, отчеты тщательно изучили и подтвердили. Ни один мой имейл не был проигнорирован, а для небольшого обсуждения был организован конфколл. Сопровождение этих отчетов было для меня очень простым, за что большое спасибо Adrian Stone, Elise Murphy и другим сотрудникам EA, работавшим с моими отчетами. Запись в security-блоге и advisory.

Теперь к уязвимостям. Я нашел две уязвимости типа «повышение привилегий» (lpe — local privilege escalation или eop — escalation of privileges) в Windows клиенте Origin. Такой тип уязвимостей позволяет любому пользователю ОС Windows получить больше прав, чем изначально выдано администратором. В данном случае речь идет о двух «типовых» повышениях — от любого пользователя до NT AUTHORITY\SYSTEM (учетная запись, обладающая максимальными правами в ОС). Первая уязвимость довольно скучная, поэтому в следующем разделе я вкратце опишу ее. А вот вторая была довольно интересной, в ее разделе я расскажу именно о том, как я ее искал.

В предыдущих сериях

Не так давно я рассказал о двух уязвимостях Стима: CVE-2019-14743 и CVE-2019-15316. Там была целая история о том, как я пытался зарепортить их, у меня не получалось, меня забанили, и только после публичного раскрытия и помощи сообщества удалось достичь результатов. Valve сделали вид, что извинились, и разбанили меня на HackerOne, так что очередную уязвимость я решил передать через этот сервис. На третий раз (здесь должна быть очевидная шутка о Half-Life 3) все прошло более или менее успешно.

В предыдущей серии

Не так давно я опубликовал описание уязвимости для Steam. Я получил много отзывов от читателей. Valve не проронили ни слова, а HackerOne прислал огромное слезливое письмо и, в основном, молчал. В итоге меня забанили Valve на H1 — я не могу участвовать в их программе по отклонению уязвимостей (остальной H1 мне доступен).



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

А оно простое и грустное — Valve все так же терпят фиаско. Последнее обновление, которое было призвано устранить проблему, легко обходится и уязвимость все еще актуальна. Да, я это проверил — прекрасно работает.

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

Я не первый год занимаюсь поиском уязвимостей, и, казалось бы, многое видел, но есть такая часть работы, к которой не удается привыкнуть и которую не могу понять. Это абсолютное нежелание вендоров принимать информацию об уязвимостях и проблемах. Я понимаю, что очень неприятно, когда тебе прямо показывают, что ты допустил ошибку и, скорее всего, не одну. Неприятно подтверждать в открытых источниках публично, что проблемы были, что сотрудники что-то недоработали. Но я не понимаю почему информацию об уязвимости нужно отвергать.


Итак, герой нашей истории — ПО Steam от компании Valve. И уязвимость повышения привилегий в нем, которая позволяет любому пользователю выполнить команды от имени NT AUTHORITY\SYSTEM.

Рассмотрим классический сюжет, многие из нас уже сами успели побывать на этой сцене…

Директор
Менеджер
Тимлид
Разработчик
HR

Директор: Коллеги, я собрал вас, чтобы обсудить ситуацию с набором на позицию «разработчик front-end».

Когда я исследую безопасность ПО, то одним из пунктов проверки является работа с динамическими библиотеками. Атаки типа DLL hijack («подмена dll» или «перехват dll») встречаются очень редко. Скорее всего, это связано с тем, что и разработчики Windows добавляют механизмы безопасности для предотвращения атак, и разработчики софта аккуратнее относятся к безопасности. Но тем интереснее ситуации, когда целевое ПО уязвимо.

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

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



Под катом будет несколько вариантов создания таких библиотек — как в виде кода, так и утилитами.

Умный дом представлен широком набором устройством. Во второй части цикла публикаций о безопасности IoT будут рассмотрены умные ТВ приставки, умная кухня, голосовые помощники и освещение. Ссылка на 1 часть.

Мой путь в ИБ начался с удивительного открытия: «безопасно ≠ зашифровано». Это сейчас такое утверждение выглядит простым и очевидным, а на первом курсе осознание этого факта произвело эффект сравнимый с ментальной атомной бомбой. Информационная безопасность атаковала расширением границ предметной области: оказалось, что криптография — это только один рубеж защиты, а ещё есть юридические, организационные, да и просто физические, в конце концов. Один из теоретических аспектов гласил «Все вопросы безопасности информации описываются доступами субъектов к объектам». Заучил, нарисовал мандатную и дискреционную модели доступов, рассказал, сдал и забыл.

Я специализируюсь на анализе безопасности Windows приложений. Довольно часто изучение именно различных прав доступа занимает существенную долю исследования. Чтобы автоматизировать процесс поиска странных или неправильных прав доступа пришлось разбираться в SDDL (Security Descriptor Definition Language). Кому интересно научиться читать права в форме SDDL (например что-то такое O:SYG:SYD:(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)) и познакомиться с моей утилитой для работы с дескрипторами в таком формате, добро пожаловать под кат.

В своей прошлой статье я рассказывал, как съездил на DefCamp. Сегодняшняя статья — первая часть публикации о моих исследованиях в области безопасности интернета вещей, которые легли в основу выступления на конференции.

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

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

Плохая новость — многие из этих новых устройств являются мишенями для атак. При этом вопросы безопасности или же решались задним числом или не решались вообще из-за отсутствия поддержки старых устройств. Подобные устройства представляют серьёзный риск для инфраструктуры (домашней или предприятия), если ими не управлять должным образом. Поэтому ниже рассмотрим, ряд вопросов, связанных с безопасностью умных вещей, доступными методами и инструментами взлома, а также особенностями обработки и защиты данных. Целью исследований является не выполнение или описание методик «взлома под ключ», а обзор подходов, которые в тех или иных условиях могут привести к доступу к данным, а также обзор ситуаций, где разработчики по какой-то причине решили не защищать пользовательские данные. Материалы представлены обзорно (полную информацию можно найти на официальном сайте.

8-9 ноября 2018 в Бухаресте (Румыния) прошла восьмая международная конференция DefCamp 2018, посвящённая вопросам информационной безопасности и технологиям защиты информации. DefCamp является одной из успешных конференций по взлому и информационной безопасности в Центральной и Восточной Европе; среди прочих можно отметить Hacktivity (Венгрия) и CONFidence (Польша). Цель мероприятия —привлечь к общению о практических новейших исследованиях специалистов по безопасности, предпринимателей, научных, общественных и частных секторов.
DefCamp собрала более 1800 участников из Румынии и соседних стран, с разным знанием и опытом — от студентов до руководителей в различных отраслях, экспертов по информационной безопасности и исследователей.



Непосредственным организатором мероприятия выступает неправительственная организация — Научно-исследовательский центр кибербезопасности Румынии / Cyber Security Research Center from Romania. По их словам, в этом году количество стран участников составило 35, включая Европу, США, Индию и ОАЭ, 60 докладчиков и 400 компаний.

Данная запись — вольный пересказ видео Is it Possible to Upload an Impossible Level in Super Mario Maker?. В ролике есть отсылка на видео The Impossible Level, поэтому перескажу и его. Мой пересказ не претендует на точность, я просто хочу поделиться интересным материалом.

О чём пойдёт речь

Поиск ошибок в ПО бывает очень разным. Я занимаюсь поиском ошибок в исходных кодах, в бинарных файлах, в больших комплексах программ и даже в каких-то железках. Но есть область, в которой я практически никогда ничем не занимался — поиск ошибок в компьютерных играх.

Люди тратят уйму времени, чтобы найти ошибки в играх. Это могут быть логические, математические и даже программистские ошибки. Кто-то делает это, чтобы посмотреть на игру под новым углом, а кто-то пытается пройти игру хоть на несколько секунд быстрее, чем любой другой игрок. Мне кажется именно сообщество спидранеров (людей, проходящих игры на скорость) внесло огромный вклад в дело поиска игровых глюков и ошибок. Но экономить время при прохождении мы будем в другой раз, сегодня просто рассказ о поиске ошибки в игровой логике.

В сентябре 2015 года компания Нинтендо выпустила Super Mario Maker — платформер про известного сантехника Марио. Одной из ключевых особенностей игры стала возможность пользователям самостоятельно создавать уровни (здесь они называются курсы) и делиться ими с другими игроками. Кто-то уровни создаёт, отслеживает процент успешных прохождений, а кто-то, собственно, проходит эти уровни. Именно в этот момент у игроков-исследователей зачесались руки — а можно ли опубликовать непроходимый уровень?


Рисовать что-то такое нет смысла, уровень хоть и действительно непроходимый, но и опубликовать мы его не сможем.

Мы публикуем седьмой по счёту регулярный отчёт нашего Центра мониторинга, посвящённый аналитике зафиксированных событий и инцидентов информационной безопасности.

Главные цифры:

• Зафиксировано 112 млн. событий (в два раза меньше, чем в предыдущем периоде).
• Подтверждено 434 инцидента (мы обрабатывали в среднем по три инцидента в день).
• 28 200 узлов на мониторинге (за два года количество контролируемых узлов выросло в 19 раз).

В мае этого года прошла конференция Positive Hack Days 8, на которой мы вновь поучаствовали в роли SOC в уже традиционном Противостоянии (The Standoff).

В этом году организаторы учли прошлые ошибки и Противостояние началось в срок. Атакующие — молодцы! Нападали практически непрерывно все 30 часов, поэтому нашей ночной смене не удалось даже вздремнуть.

Для проведения исследований работы программ и ОС существует очень много различного инструментария. Виртуальные машины, IDE, умные блокноты, IDA, radare, hex-редакторы, pe-редакторы, и даже одних утилит Sysinternals больше сотни — все это сделано для облегчения многих рутинных операций. Но иногда наступает момент, когда ты понимаешь, что среди всего этого многообразия тебе не хватает небольшой утилитки, которая просто сделает банальную и нехитрую работу. Можно написать скрипты на питоне или Powershell на коленке, но нередко на такие поделки без слез не взглянешь и с коллегами не поделишься.

Недавно такая ситуация снова наступила у меня. И я решил, что пора просто взять и написать аккуратную утилиту. О самой утилите я расскажу в одной из ближайших статей, но об одной из проблем во время разработки расскажу сейчас.

Ошибка проявляется так – если в WPF приложении, в стандартный контрол TextBox воткнуть много строк текста, то вызовы функции GetLineText() начиная с некоторого индекса будут возвращать неправильные строки.


Неправильность заключается в том, что хоть строки будут из установленного текста, но расположенные дальше, фактически GetLineText() будет просто пропускать некоторые строки. Ошибка проявляется при очень большом количестве строк. Так я ее и встретил – попытался отобразить в TextBox’е 25 мегабайт текста. Работа с последними строками выявила неожиданный эффект.

Гугл подсказывает, что ошибка существует с 2011 года и Microsoft не особо торопится что-то исправлять.

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

Соблазн сделать так, чтобы машины сами заботились о нашей безопасности и защищали людей (довольно ленивых, но сообразительных), стал слишком велик. По оценке CB Insights почти 90 стартапов (2 из них с оценкой более миллиарда долларов США) пытаются автоматизировать хотя бы часть рутинных и однообразных задач. С переменным успехом.

IPv6 — новая версия интернет протокола. Члены IETF приняли её всего 22 года назад, в 1996 году. За это время успели появиться специфичные для IPv6 атаки. Цель данной статьи, написанной по мотивам нашего выступления на PHDays 8 — показать возможности атаки в корпоративных сетях внутренним нарушителем, используя IPv4 и IPv6.

Ну или хотя бы поспотыкаются.

С начала 2017 года наш Центр мониторинга информационной безопасности видит попытки майнить криптовалюты на корпоративных ИТ-ресурсах, подключённых на мониторинг. Ну видит и видит, чего вам, битка жалко, что ли?

Действительно, а какой вред наносят майнеры в корпоративной сети? Какие угрозы для бизнеса это несёт? Давайте попробуем разобраться и понять, как искать майнеров и бороться с ними (если, конечно, решим это делать).


Marco Krohn, Creative Commons Attribution-Share Alike 4.0 International

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

Сама задача — получить число 0x17 самым внезапным образом.


Внимание! Данный пост оскорбляет чувство прекрасного и практики программирования на C. Читайте, воспринимайте и комментируйте на свой страх и риск.

Известно, что метасплойт написан на Ruby и не поддерживает скрипты, написанные на Python. Несмотря на это у метасплойта есть двусторонний RPC–интерфейс, при помощи которого можно запускать задачи.

Есть две библиотеки, позволяющие взаимодействовать с remote procedure call (RPC) metasploit — это pymetasploit от allfro и python-msfrpc от SpiderLabs. В данной статье используется первая. В интернете и репозитарии github pymetasploit есть примеры запуска эксплойтов и взаимодействия с установленными сессиям, однако мне не удалось найти примеров запуска сканеров и получения вывода для дальнейшей обработки результатов. Один из вариантов будет рассмотрен далее.