Пожалуй, на написание этой статьи меня подтолкнуло увеличившееся в последнее время количество взломов и утечек данных. Печальная тенденция на "дырявость систем" прослеживается как у крупных IT гигантов, так и у совсем небольших компаний. В том числе, лично автору за этот год приходилось иметь дело как с DDOS атаками, так и с прямыми взломами.
И ведь что весьма показательно - от действий хакеров пострадали не только наши проекты, но и проекты наших конкурентов. К счастью, давнишняя любовь к вопросам безопасности (в некоторой степени даже паранойя), и привычка закладывать в проекты надёжность на случай землетрясений и иных стихийных бедствий, позволили минимизировать последствия конкретно для нас. Но, как это говорится - враг не дремлет!
Если верить ГК InfoWatch, то за 2023 год только утечек данных произошло в 2.4 раза больше, чем в прошлом году. Утечки данных - это прямые последствия уязвимостей и дырявой безопасности внутри информационных систем. И ведь это ещё не конец года! Вполне может быть, что под конец 2023 мы увидим несколько иное, более зловещее число.
Посему, считаю совсем не лишним в очередной раз, несмотря на уже достаточно больше количество материала на эту тему (доступного как новичкам, так и более матерым спецам), все же рассказать о базовых принципах информационной безопасности - а точнее, о наиболее распространенных типах атак.
Что такое уязвимость? 📛
Начнем с главного. Что же такое уязвимость? Уязвимость - это какой-либо недостаток или ошибка в системе, позволяющий злонамеренно нарушить её целостность и вызвать неправильную работу. Используя некоторую уязвимость, злоумышленник может заставить систему вести себя так, как это не было задумано разработчиком. Например, обычный пользователь может получить административные привилегии. Либо же - совершенно посторонний посетитель может получить доступ к базе данных некоторого проекта. Иначе говоря, практически любая уязвимость - это "дырка", через которую внешний пользователь может как-то плохо повлиять на работу системы.
Уязвимости могут располагаться как в программной части продуктов, так и в их аппаратной части. Во втором случае, у таких уязвимостей есть серьезная проблема - когда уязвимое устройство находится уже на руках у людей (хорошо если у десятков-сотен, а бывает что и у тысяч людей), то закрыть такую "дырку" бывает довольно затруднительно, а то и вовсе невозможно.
Показательный пример - игровая консоль Nintendo Switch. Её аппаратная уязвимость позволяет получить полный доступ к системе и установить любые неподписанные приложения (читай - пиратский или вредоносный софт).
И в данном случае, даже такая большая корпорация как Nintendo, не смогла придумать ничего лучше, чем выпустить другую аппаратную ревизию устройства в которой этой уязвимости нет. Однако, старые устройства (которые уже были на руках у конечных пользователей) никуда не делись и никаким чудом не исправились - а все ещё подвержены данной уязвимости. Исправить эту проблему удалённо не предоставляется возможным. При этом, корпорация не первый раз наступает на подобного рода грабли - ещё в далекие 90, консоль NES (известная у нас как Денди) взламывалась путём подачи короткого импульса на электронный чип защиты от копирования.
Это, к слову сказать, показывает и тот факт, что уязвимости часто встречаются в любой системе - и даже у больших корпораций. Тут, что называется "все мы люди" и "все мы периодически допускаем ошибки". Смело предположу, что даже ИИ не станет тут спасением - его ведь тоже пишем мы, живые люди!
Ещё один интересный факт из мира компьютерной безопасности. Удивительная история глюков от компании Apple. Во времена iPhone 5s, когда устройства Apple начали переходить на 64 битные ЦПУ, в операционной системе был забавный баг - если выставить дату на первое января 1970 года, то телефон выключался, и больше не включался. А точнее, после вышеуказанной манипуляции, телефон больше нельзя было включить до тех пор, пока не будет отключен аккумулятор (и тем самым, сброшены системные часы на плате).
Не многие знают, что помимо "невинной" шутки для друга типа "поставь 1970 год и увидишь чудо" можно было провести и удаленную атаку, и окирпичить все iOS подключенные например к какой-то Wi-Fi сети. Всё дело в том, что в автоматическом режиме выставления даты, телефон тянет эту самую дату с NTP серверов Apple. То есть, злоумышленник мог перенаправить запросы в своей сети на свой NTP сервер, который уже бы отдавал поддельную дату 1 января 1970. Последствия этой ошибки очевидны.
Вот вам плюс одна страшилка в копилку, и повод лишний раз не подключаться к открытым Wi-Fi сетям (об этом, кстати, ещё поговорим далее). Справедливости ради, подобный баг был и в системе Андроид, но только там было необходимо выставить на обои специальную картинку.
Ещё, можно (и нужно) упомянуть такое понятие, как уязвимость нулевого дня - в переводе с IT'шного на русский это такая уязвимость, против которой ещё не придумали защиты. В принципе, даже в названии лежит весь смысл - у разработчиков было 0 дней на исправление косяка, уязвимость доступна широкому кругу лиц и на текущий момент нет средств защиты от неё.
Кстати, как раз для защиты от уязвимостей "нулевого дня", многие компании рекомендуют как можно чаще обновлять ПО. Помимо полезных функций, исправлений ошибок и т.п. очень важно и то, что разработчики с каждым новым обновление закрывают свежеобнаруженные дыры в безопасности своего программного обеспечения.
Что такое эксплойт и кибератака? ⚔️
Зная о том, что такое уязвимость, имеет смысл упомянуть и понятие эксплойт. Эксплойт - это программа, кусок кода, последовательность действий или все это сразу, позволяющие с помощью некоторой уязвимости в системе проводить на неё атаки. Иначе говоря, эксплойт - это пошаговая "инструкция" или некоторая специальная программа, которая помогает использовать некоторую конкретную уязвимость - и в конечном итоге выполнить некое несанкционированное действие.
Ну и пожалуй, то, с чем в последнее время мы сталкиваемся всё чаще и чаще - зловещий термин "кибератака". Кибератака - обобщённый термин, который подразумевает некоторое внешнее воздействие на систему, которое совершает злоумышленник. А именно - чтобы получить / закрыть доступ к системе, конфиденциальным данным, проникнуть в базу данных, и т.п.
В общем-то говоря, целенаправленные кибератаки это дело совершенно не дешевое (как и защита от них - например пентест системы может стоить вплоть до 300 тыс. рублей и более, шутка ли). Если не деньгами, то как атакующая, так и пострадавшая компания обычно платят своим опытом и временем. А потому, конечно, проводить настоящие крупные атаки (а тем более достаточно профессиональные или нацеленные на что-то большее, чем например нашкодить сисадмину в ВУЗе -- эх, были времена), вряд ли кто-то станет. Обычно, типовая атака ограничивается проверкой SQL-инъекций или DDOS - и об этом мы поговорим далее по этой статьей, и в следующих публикациях.
Часто тут возникает ситуация как с тем самым неуловимым Джо. Неуловимый он, потому, что никому не нужен. Кстати, это однажды может сыграть злую шутку - продукт, изначально задуманный прикола ради и для узкого круга лиц, внезапно может стать очень популярным, и таких примеров достаточно много. А при этом, если система изначально на это не была рассчитана с точки зрения ИБ как раз с посылом "да кому мы нужны" то в последствии это может обернуться очень плачевными делами. Мораль - даже в "лол"-проектах думайте о том, чтобы закрывать дыры. Даже пусть самыми банальными способами.
Вообще говоря, видов уязвимостей в информационных системах и различного рода кибер-атак существует великое множество. Есть даже отдельные системы классификаций (которых кстати тоже далеко не одна), например классификация CVE. В этом всем обилии достаточно сложно разобраться. А потому, вместо это я предлагаю рассмотреть наиболее известные и часто используемые уязвимости и кибератаки их эксплуатирующие.
Что такое DOS и DDOS Атаки 👨💻
Аббревиатура DOS расшифровывается как denial of service, то есть - "отказ в обслуживании". DDOS же - Distributed Denial of Service, то есть в переводе, распределённая атака типа «отказ в обслуживании» (атака по вектору DOS со множества устройств одновременно). Суть таких атак сводиться к переполнению интернет-канала или превышению серверных мощностей на выбранном проекте, массовыми запросами с большого количества внешних устройств.
Про данный вид атак наверное слышали даже те, кто слабо знаком с безопасностью в информационных технологиях. Особенно в последнее время, упоминания о таких атаках всё чаще можно найти в новостях или официальных заявлениях крупных и не очень компаний. Почему так? Потому что подобные атаки можно быстро организовать, и потому что с их помощью можно нанести максимальный вред при сравнительно небольших вложениях.
Как известно, аппаратные ресурсы любой системы не бесконечны, и этим пользуются атакующие. Злоумышленники забивают входящий канал огромным числом "мусорных" запросов. Это попросту не дает обычным пользователям нормально работать с системой.
Отличие же DOS и DDOS четко прослеживается в названии - распределённая, то есть выполняется одновременно с большого количества разных устройств (да, да, DDOS'ить могут даже смарт чайники с Wi-Fi). Тысячи, а то и сотни тысяч зараженных устройств, которые будут нагружать ресурсы терабитным траффиком. В целом, конечно DOS атаку может вполне себе провести и один человек с одного - пары устройств, но против крупной и хорошо защищенной системы едва ли от этого будет много толку.
DDOS как наиболее популярный способ кибератак 💢
По моему мнению, DDOS атаки на сегодняшний день это чуть ли не основной вид атак. За этот год, мы могли наблюдать сбои в работе даже крупных РФ банков, как раз по вине подобных злонамеренных технологий. Причина у этого в целом проста - организация такой атаки, это относительно недорогое мероприятие по сравнению с другими видами атак, и одновременно с этим, вполне серьезный удар по цели.
Согласитесь, эффект от нескольких часов до нескольких суток простоя (да даже просто сбоев в работе) любого крупного сервиса будь то онлайн банк или интернет магазин, ощутимо бьет по репутации, доходам и т.д. А сарафанное радио заботливо может приумножить возникший эффект.
Второй неприятный момент поджидает в том случае, если хостинг провайдер тарифицирует серверный трафик. В таком случае, очевидно будут и финансовые убытки. Даже без падения прямых продаж. Ну и ещё одно важное последствие - если сайт лежит достаточно долго (обычно сутки-двое), поисковые системы начнут опускать его в органической выдаче. Простой же более 4-5 дней, прямо скажем, фатален для любого интернет-проекта.
Ещё раз стоит повториться - DDOS атаку в целом сравнительно легче провести, чем скажем получить доступ к СУБД (при условии должной защищенности системы, конечно). Если цель злоумышленника именно деструктивные действия по отношению к системе и бизнесу, то для него это прямо скажем хороший выбор. Так же, атака может быть проведена и из соображения получения "выкупа" - злоумышленники могут запросить деньги просто за то, чтобы они прекратили атаку. Причины могут быть и геополитическими, и нездоровой конкуренцией, и просто потому, что кому-то не понравились. Вариантов вообще говоря много.
Говоря о защите от такого типа атак, сначала стоит упомянуть что сами DDOS-атаки можно условно поделить на два типа - низкоуровневые и высокоуровневые. Первые берут своей целью не само приложение, а сетевую инфраструктуру - интернет канал. Вторые же, целятся именно в саму систему - нагрузить процессор, память и СУБД. Вот в случае со вторым ситуация чуть попроще - от не самых крупных атак может спасти грамотно настроенная система и хороший код. Это, собственно первый вариант защиты. Настроенный файрволл, фильтрация траффика, грамотная настройка веб сервера (если таковой есть), оптимизированный код и СУБД. Это все если и не защитит на 100%, то по меньшей мере поможет отбить большую часть нелегитимного траффика. А в случае с атакой небольших масштабов, возможно и вообще сделает её незаметной.
Так же, самым банальным и простым с точки зрения времени и человеко-часов (но не цены) будет линейное наращивание мощностей. Скажем, если сервер способен обслуживать одновременно 100 пользователей, а атака идет с 1000 устройств, очевидно ресурсов обслужить все это не хватит. Однако, если сервер способен обслужить 10000 пользователей одновременно, тот от атаки в всего одну десятую даже не шелохнётся. В целом, иметь запас по ресурсам сервера это всегда не плохо, но от DDOS атак это даже не плацебо - никакая компания не сможет наращивать ресурсы бесконечно, да это и экономически не целесообразно. А вот злоумышленник может иметь в своем распоряжении огромные ботнеты, которые отбить одному даже очень мощному серверу уже будет нереально.
Если говорить уже о низком уровне, тут все несколько сложнее. Во-первых, зачастую хостинг провайдеры не дают полного контроля над всем нашим интернет каналом (что в целом логично). То есть, даже если наш сервер правильно настроен а ПО написано хорошо, нам все ещё могут попросту забить наш интернет канал. Во-вторых, атаковать могут не наш сервер напрямую, а уже самого хостинг провайдера (редко, но это возможно все же). Конечно, в таком случае это будет уже его косяк и проблема, но нам то от этого легче не будет. В таком случае, может спасти распределение своих ресурсов. Это как, например, разнесение разных сервисов на разные сервера, так и просто балансировка нагрузки.
Когда физически мы имеем несколько серверов, при том желательно даже в разных дата центрах. В таком варианте, даже если один из них отвалится, остальные продолжат в штатном режиме обслуживать клиентов. Недостаток такого подхода - цена и сложность. Даже один сервер может обходиться в крупную сумму, а уже держать их несколько в целом недешевое удовольствие. Помимо того, этот весь зоопарк нужно как-то заставить дружить между собой, что тоже не самая простая задача. На моей памяти, таким распределением ресурсов пользуются в основном достаточно крупные компании, которые могут себе это позволить. У того же Яндекса есть серверы как в РФ, так и за рубежом.
Ну и пожалуй, как по мне один из достаточно оптимальных вариантов защиты (что называется дешево и сердито) это разного рода сервисы защиты от DDOS, а так же CDN. Наиболее популярные это пожалуй CloudFlare и DDOS Guard из отечественных (к слову сказать, последний мы использовали в этом году, и не раз). Многие наверняка видели капчу перед загрузкой сайта с просьбой подтвердить, что вы не робот. Так вот это оно. Суть таких сервисов сводится к тому, что мы пропускаем весь траффик уже через них, а реальный IP сервера остается злоумышленнику неизвестен. Таким образом, эти сервисы пропускают через себя весь наш траффик и берут на свои плечи его фильтрацию. Из приятных бонусов, они как правило ещё и предоставляют услуги CDN - то есть распределенной сети серверов по всему миру, которая будет отдаленному от нашего сервера клиенту отдавать контент куда быстрее чем если бы он обращался напрямую. Недостаток же, как по мне в том, что реальный IP сервера в таком случае ни в коем случае не может быть компрометирован. Иначе, злоумышленник сможет атаковать сервер напрямую в обход всех CDN и сервисов защиты.
Подводя итог, я так же упомяну что полезным конечно будет и комбинация разных методов защиты от такого рода атак. Но в целом, в каждом случае это все будет индивидуально из зависеть от многих вводных.
MITM Атаки 🤝
Аббревиатура MITM расшифровывается как Man in the middle. Дословно переводя "человек посередине". Суть данной атаки заключается в том, что между конечным сервером и клиентом как бы встраивается посередине злоумышленник, перехватывает весь траффик проходящий между ними. А возможно и модифицирует.
Во времена до HTTPS и SSL, довольно типовым вариантом было создание открытой Wi-Fi сети в каком-нибудь кафе с целью прослушать траффик всех, кто к ней подключился. Так, например, воровали пароли или какую-либо ещё конфиденциальную информацию. И хотя те время давно прошли, хотя бы потому, что большинство веб ресурсов сейчас используют HTTPS который просто так прослушать нельзя (на самом деле, не просто, но в целом можно). Я бы все же не рекомендовал подключаться к открытым Wi-Fi сетям без особой надобности.
Во-первых, помимо mitm в чужой сети можно понаделать кучу других разных плохих вещей. Например, вспоминаем историю с багом 1970 года в IOS и возможность провернуть его через свой NTP сервер. Во-вторых, в РФ все, кто предоставляет такой доступ должны как-либо идентифицировать пользователя. Скажем, по номеру телефона или через госуслуги, или ещё как либо. И если с точки зрения буквы закона в целом понятно зачем это требуется. То вот тот факт, что помимо спецслужб данные о том где, когда и какие сайты вы посещали(а так же с каких устройств и т.п) могут попасть ещё и в руки владельцу Wi-Fi сети а потом и третьим лицам уже не есть хорошо.
К слову сказать, для mitm атаки совершенно не обязательна открытая Wi-Fi точка. Достаточно просто наличие между пользователем и конечным сервером некого посредника. Это, например может быть и VPN или прокси сервер, которые в последние время тоже очень популярны. Посему, пользоваться сомнительными и бесплатными VPN сервисами тоже не очень хорошая затея. К слову, даже провайдер, предоставляющий услуги доступа в интернет может быть тем самым человеком посредине.
Интересный случай из личной практики: до того, как на сайте был введен https протокол, многие пользователи жаловались на рекламные баннеры. Хотя мы точном знаем, что ничего подобного у себя не размещали. В итоге, выяснилось что рекламные баннеры в код сайта добавляли недобросовестные операторы связи. Очень хороший пример mitm атаки, который показывает насколько она опасна. Мало того, что личные данные пользователей могут быть попросту украдены. Так ещё и злоумышленник может встроить в ответ сервера любой вредоносный код. Скажем, это может быть JS майнер или даже просто перенаправление на фишинговый сайт.
HTTPS + TSL - защита от MITM-атак 💪
Говоря о способах защиты от атак типа MITM, для веб ресурса один из самых банальных и достаточно эффективных - это использование HTTPS и TSL. В контексте данной статьи, я не буду подробно объяснять как работает HTTPS и что такое TSL, но коротко поясню суть. При http подключении все данные (логины, пароли, cookie, данные карт), которые идут от клиента к серверу никак не защищены - их спокойно может прочитать любой, кто сможет получить доступ к этому траффику. А вот при использование https все эти данные шифруются и только клиент и сервер могут их расшифровать. В таком случае, даже если злоумышленник и сможет их получить, то ни прочитать, ни как-либо модифицировать он их уже не сможет.
Однако, есть такая штука как downgrade атака и она может помочь обойти https. О таких атаках чуть попозже, а пока коротко говоря - защитится можно используя HSTS или вообще закрыв весь http и 80 порт для него на сервере. Оставив только https, только хардкор. В идеале, ещё и отключить поддержку сервером старых версий TLS и оставить только последнюю. Но, к сожаление далеко не все устройства используемые здесь и сейчас поддерживают это, поэтому выбирать какие TLS поддерживать а какие нет надо уже исходя из понимания того, кто и с каких устройств будет подключаться.
Ещё один вариант, если скажем по каким-то причинам не подходит HTTP или требуется куда более высокий уровень конфиденциальности(отчего, кстати, такой вариант часто используют банка для каких-либо внутренних рабочих сред) это общение с сервером исключительно через VPN. Да, хотя выше и было сказано о том, что VPN сервер и сам может быть человеком посередине, но это не касается например доверенных корпоративных VPN сетей. Вообще говоря, VPN то изначально для этого и были задуман - создать некий приватный и безопасный туннель поверх сети. При этом, весь траффик внутри такого туннеля как правило шифруется. Отсюда, опять таки его уже не получиться просто так прослушать.
Downgrade Атаки ⬇️
Downgrade Атака - или по другому атака с понижением версии протокола. Суть такой атаки заключается в том, что злоумышленник каким-либо образом (в зависимости от протокола и т.п.) заставляет клиент и сервер вместо более новой и защищенной версии протокола использовать более старую и уязвимую. Например, вместо TSL 1.3 перейти на TSL 1.1. Это, как раз то, о чем было сказано выше - один из вариантов обойти HTTPS это просто вынудить клиент и сервер использовать менее его защищенную версию. И работает это не только с TLS, но и многими другими протоколами.
Как именно происходит такая атака? Опишем на примере HTTPS и TSL, но в целом справедливо это будет и для других протоколов. Просто сам алгоритм действий, который необходим для перехода от более новой версии к более старой будет несколько отличаться. Но, в целом, вся суть сводиться к тому, что для совместимости с более старым ПО и оборудованием приходится оставлять и старые же версии протоколов. И часто, злоумышленники пользуются этим.
Например, уже на windows xp достаточно проблемно открыть современные веб сайты и приложения просто потому, что: windows xp не поддерживает многие современные версии TLS это раз, и windows xp может не иметь в себе обновленных корневых SSL сертификатов это два. Отсюда, если есть необходимость по какой-то причине все же поддерживать такую старую ОС, то нам придется оставить http и старые версии tls включенным. И да, хотя это и звучит странно - казалось бы, зачем поддерживать windows xp или даже windows 7 в 2023 году? Но, просто для понимания скажу вот что - мой знакомый сисадмин работает в одной далеко не малоизвестной в РФ компании. Так вот, приличная часть их парка машин как раз примерно такого возраста. Хотя и стоит сказать, что это в основном машины в локальной сети, но все же картина справедлива - горькая правда в том, что далеко не все и не везде поддерживают хоть сколь ни будь актуальное состояние железа и его ПО.
Ну а что же до самой атаки, то обычно происходит это так: во время установки безопасного соединения, клиент и сервер обмениваются информацией о том, а какие вообще они поддерживают протоколы (т.н. TSL-рукопожатие). Злоумышленник передает серверу поддельную информацию о том, что клиент якобы поддерживает только TLS 1.1. Ну и сервер, если поддержка этой версии включена начинает общаться используя её. Дальше, в ход уже идет использование уязвимостей более старой версии протокола.
Говоря о защите от данного типа атак - самый просто вариант просто не использовать старые протоколы и отключить их. Отключить в веб сервере поддержку http и устаревших TLS. Возможно, и вовсе закрыть порт 80 на сервере (это порт как раз для https соединений, https использует 443 порт) если он не нужен. Конечно, такой вариант не подойдет, если по какой-то причине старые версии все ещё нужны.
А ещё, у HTTPS ещё есть дополнительный механизм защиты, как раз направленный на downgrade атаки. Называется он HSTS. Суть его заключается в том, что сервер отправляет специальный заголовок и браузеры, которые этот заголовок понимают, впоследствии будут подключаться к серверу по HTTPS сразу же. У этого заголовка так же обычно указывает срок жизни - например один год.
И ещё, существует так называемый HSTS preload list - это список сайтов, уже заранее внесенный разработчиками браузеров в их исходные коды. В него попадают сайты с максимальные сроком жизни HSTS а так же флагом preload. Но и тут есть свои минус, который впрочем больше зависит от внимательности - включенный единожды такой заголовок больше не даст клиентам, хотя бы раз зашедшим на сайт перейти на http. А если сайт ещё и успел попасть в preload list, то коротко говоря - дороги назад уже нет. Потому, надо понимать одну вещь. Включать hsts стоит тогда, когда он настроен уже везде - каждый поддомен и сервис а так же, сам hsts настроен правильно. В ином случае, если например на каком-то из поддоменов https не включен, или вообще по какой-то причине не планируется пользователи просто получат целое ничего(а точнее, ошибку соединения).
Берегите себя! Ну а про следующий блок уязвимостей мы поговорим уже в следующей статье.
🔥 Понравилось? Подпишись! Победим восстание роботов вместе! 🔥
🚀 P.S. Для тех, кто хочет не просто читать о программировании, а начать свой путь джедая прямо сейчас, приглашаю на Boosty! Там эксклюзивный обучающий материал по программированию для любого уровня подготовки. А ещё там можно посмотреть, как автор выглядит в жизни. Жми сюда и полетели!🚀
P.S.2 Ещё у меня есть Telegram-канал. Там посты чуть проще и веселее. Ссылка
P.S.3 Предлагаю делиться в комментариях личным взглядом на самые безумные подходы к программированию. Случаи из жизни и поучительные истории из IT приветствуются!
---
Материал подготовил со-автор блога, Андрей Сорокин. Редактура - Виталий П.