Hacker, rider and nomad
Привет, Хабр! Меня зовут Александр Калинин, я занимаюсь разработкой средств обеспечения безопасности контейнерных сред в МТС RED, дочерней компании МТС в сфере кибербезопасности. Сегодня расскажу о том, как я обнаружил в отладчике WinDbg уязвимость, которая позволяет запускать произвольный вредоносный код на хосте разработчика и подменять библиотеки. Также поговорим о реакции Microsoft на мой репорт.
Если вдруг вам негде провести код-ревью вашего проекта, присылайте код в программу Bug Bounty – там ваши наработки как минимум кто-нибудь посмотрит 🙈
Такой мем появился у нас в команде продуктовой безопасности Ozon после второго запуска Bug Bounty программы. Как и во многих шутках, в этой есть доля правды: нашу программу по поиску уязвимостей мы стараемся развивать так, чтобы каждый багхантер гарантированно получал адекватный ответ на свою заявку в разумные сроки.
Давайте в этой статье заглянем в чёрный ящик – посмотрим, что происходит с вашим отчётом об уязвимости на нашей стороне, то есть в Ozon.
Уязвимости в своём коде хочется находить как можно быстрее, а значит нужно автоматизировать этот процесс. Как именно автоматизировать поиск уязвимостей? Существует динамическое тестирование безопасности, существует статическое — и у обоих свои преимущества и недостатки. Сегодня подробно разберёмся со статическим на опыте его применения в Одноклассниках.
По каким принципам можно выбирать инструмент для статического тестирования? С какими сложностями сталкиваешься, когда уже выбрал? Как писать собственные правила анализа, расширяющие стандартную функциональность? Я занималась всеми этими вопросами — и теперь делюсь с Хабром тем, что узнала.
Речь пойдёт о Java, веб-приложениях, SonarQube и Find Security Bugs, но рассказанное применимо также для других языков и технологий.
Данная статья отражает личный опыт и мнение её авторов и написана с целью призвать сообщество к обсуждению. Здесь не будут называться имена, ни на кого не будут показывать пальцем.
Мы попытаемся обратить внимание на то, что считаем проблемой современного российского рынка услуг в сфере информационной безопасности.
Чтобы читателям был понятен контекст, мы решили начать с бэкграунда. Статья написана аналитиком информационной безопасности (мной) и специалистом по тестированию на проникновение (моим коллегой InfiniteSuns ).
Работая с заказчиками, мы систематически сталкиваемся с непониманием сути оказываемых нами услуг. Нередко это непонимание вызвано тем, что оно перенеслось на заказчика от компании, которая оказывала эти услуги. Однажды в ходе проведения внутреннего пентеста повышение привилегий и устранение средств защиты на предоставленной заказчиком офисной машине вызвало недоумение у начальника службы ИБ.
Далее в ходе обсуждения выяснилось, что до этого под названием «пентест» заказчику продавали сканирование внутренней сети при помощи «nmap» с параметром «--script vuln». Естественно, в очередной раз заказчик ожидал от пентестеров подобного поведения и искренне удивился, когда они начали захватывать его контроллер домена.
Во вчерашней статье мы подробно разобрали методологию комплексного тестирования защищенности и соответствующий инструментарий этичного хакера. Даже если мы с вами в совершенстве овладеем методикой взлома и проведем тестирование на самом высоком уровне, но не сможем грамотно представить результаты заказчику, то проект будет «так себе». Как написать грамотный отчет по тестированию защищенности – об этом мы и поговорим сегодня.
