Представьте, в один прекрасный день вы просыпаетесь и узнаете, что сегодня — День конституции Украины. И сообщают об этом не новости, а ваш собственный сайт, где вы и не думали размещать ничего подобного. За 9 лет управления студией разработки Code Pilots у меня накопилось несколько историй о кибербезопасности, которыми хочу поделиться с вами.

Сохраните пароли, это же так удобно!

Впервые задуматься об ИТ безопасности меня сподвигла ситуация в далеком 2007 году. Будучи фрилансером, я насохранял пароли в Total Commander (популярный в то время файловый менеджер для обновления сайтов), передал ноутбук новому владельцу и благополучно об этом забыл. Но спустя год несколько клиентов, с которыми я работал, были взломаны. Источник утечки, удалось определить почти сразу — новый владелец позвонил и пожаловался, что его компьютер был взломан. Это был хороший урок, так как избавлять сайты клиентов от нечисти пришлось не один день, и это было не самое приятное занятие. После того случая я сделал выводы и нашел куда более надежные места для хранения паролей. 

Но даже стойкий пароль, сохраненный в надежном месте, не спасет от утечки через небезопасный протокол (например, HTTP и FTP). Многие ошибочно полагают, что такой сценарий крайне маловероятен. Но только на моей практике было несколько случаев взлома сайтов через перехват трафика в общедоступном Wi‑Fi в кафе.

Вывод первый: храните пароли в сберегательной кассе специальном менеджере паролей. Например, в бесплатном Keepass или в также облачном Bitwarden.

Вывод второй: лучше забыть про HTTP и FTP, особенно если вы работаете в публичных местах.

Я у мамы хакер

Следующее столкновение было уже интереснее. К нам в Code Pilots пришел новый клиент, форум которого регулярно взламывали. Поскольку взломщик не сильно прятался, владельцу даже были известны его контакты и имя. Взломщик преследовал непонятные цели: по мелочи, но регулярно нарушал работу сайта и доставлял серьезные неудобства заказчику. 

Поймать уязвимость, которой он пользовался, получилось не с первого раза. Ведь сайт был старый, и до этого им почти не занимались. А взломщик уже оставил себе с десяток лазеек. Поэтому удаляя их одну за другой, на следующий день мы все-равно обнаруживали, что доступ к сайту есть не только у нас. Спасло детальное протоколирование всех запросов — именно так мы нашли самый изящный, лаконичный и неприметный бекдор (лазейку) примерно следующего вида:

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

Как он изначально получил доступ к сайту? Через систему контроля версий, которую предыдущие разработчики забыли закрыть от публичного доступа, да еще по невнимательности сохранили туда некоторые пароли. 

Кстати, это может касаться и вас: проверьте, что откроется, если дописать после адреса вашего сайта “/.git/config”? (пример — site.ru/.git/config). Если вы видите текст, а не страницу ошибки, дело плохо — весь исходный код вашего сайта можно скачать, а вместе с ним, возможно, получить и полный доступ к вашему сайту. В проведенном нами в 2020 году исследовании, около 7% сайтов имели эту неприятную уязвимость.

День конституции

Однажды нам позвонил клиент и пожаловался, что его сайт выглядит совсем не так, как должен. В частности, он пестрит политическими лозунгами, и поздравлениями с Днем конституции Украины. Очевидно, произошел взлом сайта и последующий дефейс (замена содержимого).

Откатить все правки и вернуть сайт в исходное состояние можно было почти мгновенно. Ведь были резервные копии, да и система контроля версий явно показывала, какие страницы менялись. Но у нас была задача важнее: понять, как именно взломщики попали на сайт, чтобы не допустить повторения ситуации. 

После тщательного анализа было установлено, что злоумышленники воспользовались на тот момент еще не широко известной уязвимостью в коде Битрикса. Через нее попали на сайт и внесли нужные им правки. Всё было сделано меньше чем за минуту — ведь чаще всего такие взломы проводятся автоматически, без участия человека.

Определив причину, мы закрыли уязвимость, вернули сайт к прежнему виду и написали подробный отчет клиенту. А заодно закрыли подобные уязвимости у всех клиентов Code Pilots.

Некоторым нашим знакомым повезло меньше: они заметили взлом лишь на третий день. И было уже поздно — у них хранилась только одна резервная копия за предыдущий день. Такаким образом, спустя три дня, в единственной резервной копии оказалась уже взломанная версия.

Вывод первый: регулярно обновляйте ваше ПО.

Вывод второй: обязательно делайте регулярные бекапы в отдельную локацию. Хорошей практикой является сохранение последних 7 дней, 4х последних понедельников, 12 первых чисел каждого месяца. Это сведет к минимуму риск потери данных

Хакер, который всех сдал

Чаще всего мы сталкиваемся с DDoS-атаками: когда к сайту делается так много запросов, что он не справляется с нагрузкой и перестает нормально работать. 

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

Это и произошло с нашим клиентом: после того, как его сайт перестал работать, ему в Телеграм написал исполнитель атаки. С уникальным предложением: за $300 он не только прекратит атаку, но и сдаст своего заказчика, который (вот сюрприз) оказался непорядочным и не оплатил всю сумму. 

Пока клиент вел задушевную беседу с атакующим, мы оперативно прятали сервер в новой локации и возвращали сайт в работоспособное состояние. К концу диалога, сайт снова заработал и какая-либо сделка потеряла актуальность. Впрочем, в любом случае, никто не собирался платить террористам.

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

Вывод второй: если у вас нет постоянной команды поддержки сайта, имейте наготове все доступы: к сайту, к серверу, к хостингу и к DNS. Это позволит не тратить драгоценное время на их поиски. Не забываем, что они должны храниться в менеджере паролей, а не в заметке на рабочем столе.

Анонимный доброжелатель

Еще одна разновидность уже описанной атаки, но в довольно оригинальной упаковке!

Владельцу интернет-магазина пишет некий специалист по безопасности, который заявляет, что на сайте есть уязвимость. У него, конечно, есть подробное описание проблемы и путей ее устранения. За этот документ он просит заплатить круглую сумму в криптовалюте. А чтобы не быть голословным, вежливо ее демонстрирует: раз, и как по щелчку сайт перестает открываться.

И все бы ничего, но даже поверхностный анализ ситуации показывает, что сайт не работает не из-за какой-то уязвимости, а из-за большого числа запросов — всё тот же DDoS!

Клиент берет паузу для того, чтобы “пообщаться с руководством” и тянет время. Параллельно мы принимаем меры, чтобы выдержать любую нагрузку. И вот момент истины: наш “специалист по безопасности” снова на связи и настойчиво требует, чтобы мы скорее принимали решение:

— Ну что вы решили?

— Вот, у нас даже всё руководство собралось, чтобы убедиться, что проблема реальна. Можете показать, как сайт перестанет работать?

— Да, конечно, смотрите

(начинается шквал запросов к сайту, но… он выдерживает нагрузку!)

— …?! (замешательство на том конце провода)

— Кажется, это банальный DDoS… До свидания!

Так мы сэкономили несколько сотен тысяч рублей для нашего клиента и получили невероятные эмоции от наблюдения за безуспешными попытками атакующих.

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

Были ли у вас подобные истории? Буду рад увидеть их в комментариях!