Блог

Сейчас я перевожу свои проекты на .NET и именно в данный момент полным ходом идет работа над сетевыми утилитами CyD Сетевые утилиты и безопасность. Основная часть модулей перенесена, и сейчас работа кипит над самым сложным и самым интересным модулем - автоматизированной системой поиска уязвимостей на WEB сайтах. Самым интересным тут будут автоматический поиск на SQL инъекцию, XSS уязвимости и инклуд. Работа уже движется к своему завершению, и к концу года я планирую выложить программу в открытый доступ. Те, кто уже купил CyD Network Utilities получат новую версию бесплатно, и окажутся в двойной выгоде, потому что смогут использовать программу на старом движке и на новом. В принципе, тех, кто зарегестрируется до выхода .NET варианта я не смогу лишить такого же удовольствие, так что у всех еще есть время получить этот приятный бонус.

Но я бы не стал писать заметку, только из-за этой новости, потому что она будет висеть на сайте CyD Software Labs, где ей и место. Я завел этот разговор потому, что вчера я завершил написание нового модуля автоматического тестирования на SQL инъекцию и результат мне понравился. Но обо всем по порядку, потому что сам процесс разработки уже был интересным. Автоматизация поиска уязвимостей достаточно интересный процесс и в ближайшее время я перепишу модули поиска файловой инъекции (PHP Include) и поиска XSS уязвимостей.

В интернете появилась информация о том, что найден эксплоит (exploit) для .NET Framework. Я использую этот фреймворк почти каждый день и возлагаю на него большие надежды, поэтому сразу же заинтересовался вопросом. Поски эксплоита меня привели к эксплоиту и его описанию. Достаточно прочитать только это: "The 'exploit' starts with the modification of a framework dll (assembly) from outside the runtime using administrative privileges".

Ну и кто дадумался поднимать панику? Какой же это нафиг эксплоит, который требует административных прав? Тогда и format C: это тоже супер гениальный эксплоит для файловой системы! С правами администратора я могу горы свернуть, они бы еще написали эксплоит, который требует системных прав или уровня ядра!!! Товарищи пытаются создать что-то, при этом абсолютно не понимая, что это такое и как должно выглядеть.

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

Недавно на books.ru оставлял комментарий на какую-то книгу и случайно обратил внимание на каптчу (Captcha). В глаза бросилось то, что она нарисована в виде банального текста. Я сначала протер глаза и очки, в надежде, что мне это кажется. Кликаю дважды по каптче, а она выделяется как банальный текст. Я снова не верю глазам и лезу в исходник страницы. Не может быть!!! Captcha действительно лежит в открытом виде и передается от формы к сценарию банальным параметром.

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

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

Шли, шли к свободе и пришли к великой русской стене ради нашей безопасности. В Интернете пошли разговоры о том, чтобы построить шлюз между рунетом и остальной сетью. И это предложил президент отечественной ассоциации разработчиков ПО. Для этого за 10 лет может быть написан сетевой экран, а разработка обойдется в несколько сотен миллионов долларов.

Первое, что меня смущает – срок возведения стены. Сколько человек будет заниматься этим? Если бы Agnitum писала свой сетевой экран с такой же скоростью, то она никогда бы не стала одним из заметных игроков на рынке безопасности. Это что же можно разрабатывать и внедрять столько времени? Это не просто уже шлюз, защита или безопасность, это великая Китайская стена в интернете получается.

Расходы тоже как всегда с размахом. Допустим, что потратят всего 200 миллионов на разработку и внедрение. Если один сотрудник (программист, администратор, внедренец и другие) будет получать 5 000 долларов в месяц, то один человек скушает за 10 лет 600 тысяч долларов. А что вы хотели, программирование очень дорогое удовольствие даже в нашей стране, поэтому компании любят использовать сообщества OpenSource программистов в своих целях для удешевления разработки.

Сегодня я расскажу о еще одной своей уязвимости в PHP сценарии. Если тебе интересно учится на чужих ошибках, то это тебе поможет. Вчера я зашел в админку сайта HackishCode и увидел там комментарий от пользователя, который был сохранен со статусом 1, при этом имя пользователя отсутствовало. Меня это очень сильно испугало, потому что со статусом 1 можно сохранить комментарий только если его подтвердил я лично или если его оставил зарегестрированный пользователь. Неужели кто-то зарегистрировался с пустым именем, и будет мусорить? Лезу в базу и выясняю, что нет такого человека. Явно где-то уязвимость, которой воспользовались нарочно или случайно и нужно пускаться в поиски!

Пробую оставить комментарий к первой попавшейся новости от не зарегистрированного пользователя, но он, как и положено, попадает в базу со статусом 0 и не отображается. Смотрю еще раз на базу и выясняю, что испорченный комментарий оказался в разделе исходников. Смотрю в код исходников а там защита идентична, как и в новостях. Логика сохранения проста и ошибиться сложно:

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

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

Security команда из Microsoft будет помогать сторонним разработчикам искать баги в их продуктах и исправлять их. Это станет возможным благодаря программе Microsoft Vulnerability Research.

На самом деле, компания уже давно занимается подобными вещами и уже давно помогает сторонним разработчикам, в том числе и прямым конкурентам. В мае и июне компания работала вплотную с Apple исправляя ошибки, которые были найдены в Internet Explorer и помогая компании Apple исправить подобные ошибки в конкурирующем браузере Safari.

Microsoft поможет найти баги

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

В книге они рекомендуют по умолчанию запрещать все, что может нанести вред или содержит потенциальную угрозу. Если пользователь явно разрешит опасную возможность, значит, он отдает себе отчет в возможных проблемах. Это первая ошибка. Большинство пользователей сколько не предупреждай, они не осознают опасность, пока не грянет гром. А даже если и грянет, виноваты будут в люблю случае разработчики.

С того момента, как я ввел слева меню для выбора месяца, за который вы хотите просмотреть сообщения на блоге, сайт был уязвимым к SQL Injection. Дабы избежать проблем с безопасностью, все входные параметры проходят фильтрацию в централизованной функции, но именно дату и год я брал не из фильруемого массива $_GET, а из автоматом создаваемых переменных $y и $m. Без какой-либо фильтрации значения этих переменных вливалось в запрос со всеми вытекающими последствиями.

И вот тут возникает резонный вопрос - почему меня до сих пор не взломали? Если посмотреть по другим сайтам, то мой сайт с программамми сканируют и пытаются взломать по 10 человек в день минимум. Там у меня стоит система журналирования, по которой я всегда могу узнать, какие запросы отправлялись серверу и реистрируются все необычные попытки обращений. Один раз я так вычислил свою ошибку, которую почему-то не нашли хакеры, хотя были рядом. Там я тоже по случайности один параметр использовал в обход централизованного фильтра