О печальной защите информации в 2017 году

В данном посте я хочу поговорить не про гигантов типа Google, Яндекс или ВК, а про обычные компании с которыми мы работаем или которые не так известны.


Несмотря на кучу законов типа ФЗ-152 уровень защищенности персональных (и не только) данных к сожалению переживает по моим наблюдениям не лучшие свои времена.


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


1.

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


Вооружившись VirtualBox с установленным внутри WireShark и другими средствами мониторинга начал следить за программой, исследовал формочки приложения. В WireShark промелькнул HTTP-запрос, отправляющий сообщение на сервер. Так же обнаружил и HTTP-запрос, получающий сообщения с сервера. Немного поразбежавшись, обнаруживаем, что никакой авторизации на стороне сервера нет. Получаем сразу 2 уязвимости. Мы можем читать сообщения любого пользователя, включая, что пишут админу, а так же от имени пользователя отправлять сообщения другому пользователю.


2.

На следующую уязвимость в конце зимы или весной в 2017 году я наткнулся совершенно случайно с помощью рекламы в Яндекс-Директе.

Попалась на глаза мне контекстная реклама одной фирмы, которая говорила, что есть филиалы во многих городах РФ. Что-то тогда меня заинтересовало и я открыл их сайт.

Там открыл форму обратной связи.

С удивлением замечаю попадаю на сайт без домена, а только IP-адрес сервера.

Стало любопытно, а что работает на этой машинке? Проверяю порт FTP и… захожу под гостем. Куча всяких файлов, рабочая WEB-папка со страницами сайта. Есть немножко бэкапов. С виду сервер использовался как или помойка или как тестовый сервер.

Открываем файл конфигурации из Web-папки … Видим логин и пароль от FTP-другого сервера.

Проверяем… И попадаем уже во второй сервер…

Там тоже поднят WEB-сервер и вообще файлов намного больше… на 200 гигабайт с лишним. В основном это конечно бэкапы баз, но и очень много рабочих и свежих документов.

Внутри конфига WEB-сервера уже засвечивается и SQL-сервер с логином и паролем, который крутится на этом сервере. И да. На него тоже можно попасть.

Итог: получаем утечку в из крупной фирмы с возможностью исказить/уничтожить информацию и бэкапы баз данных.


3.

Также в этом году для работы потребовалось создать парсер сайта довольно большой бюджетной организации для формирования БД (около миллиона строк в 3 таблицах), что бы уменьшить ручной труд и постоянные запросы к сайту. Сам сайт тоже тот еще тормоз, поэтому создание парсера было логичным решением, что бы получить сразу готовые таблицы и всегда иметь их под рукой.

В голове вместе с алгоритмом парсера и количество срок кода росла также лень всё это делать. Тогда я решил проверить теорию с предыдущим сервером. И.. Вы не поверите! Ситуация практически повторилась! Мы опять попали на FTP сервер, но на этот раз там лежал файл VPNRouter_64.vmdk. Виртуальная машинка.

Немного колдуем над файлом и получаем доступ к разделу виртуального диска внутри машинки.

Самое интересное, это папка OpenVPN с настроенной конфигурацией и сертификатами.

Копируем на свой комп, подключаемся, и… Бинго! Мы внутри защищенной сети.

Смотрим какой нам присвоил сервер виртуальный IP.

Открываем терминал, запускаем nmap сканируем всю подсеть на 80,21,1433 порты.

Есть несколько компьютеров с такими открытыми портами!

И опять нас радостно встречает FTP без пароля на одном из серверов!

А дальше классика. Открываем Web.config, получаем строку подключения к серверу и с помощью dBeaver мы получаем доступ к базе данных внутри сети. Что еще интереснее, данная комбинация подошла и на другие SQL-сервера внутри этой сети. Один пароль на все сервера (всего их было 3-5 серверов, уже не помню). И это довольно крупная бюджетная организация для нашего региона!

Опять же возможность положить сайты, совершить утечку персональных данных (я там себя нашёл), исказить/удалить.


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


4.

Еще один случай опять же на работе, опять же в этом году.

Другая бюджетная организация дала VPN (L2TP) доступ и программку которая работает с их сервером, обмен с базой данных.

В таком режиме мы уже работаем давно, но программист написавший программу уже уволился, а неудобства с программой проявляются все сильнее и мысли написать свою программу типа плагина или хотя бы нужные скрипты. И тогда я решил провести один эксперимент, а именно попробовать подключиться не через их прогу, а через редактор БД. Выдергиваю, по какому адресу их программа стучится, вбиваю в редактор БД, и… сервер нас впустил! Ему хватило подключения по VPN и доверительное соединение! Мы опять получаем доступ к серверу ко всем базам, которые там находятся со всеми вытекающими, куда по идее мы не должны были попасть.


5.

Похожая ситуация и в самой корпоративной сети, опять же в этом году.

Дали программу, файл реестра, внутри которого… Логин sa, пароль 111111As…. Доступ из внешки… Ну хоть не на стандартном порту. А на нем так же крутиться персональная информация! Любой админ из корпоративной сети сути может увидеть инфу другого филиала через SQL-редактор, к которой он не должен иметь доступа, а так же изменить/удалить всю БД! А то что изначально дали доступ без защищенного канала еще хуже! Благо щас перевели программу на Vipnet, но пару месяцев назад доступ по внешнему IP еще был, может и до сих пор есть.


6.

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


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


А сколько подобных серверов с открытым доступом в интернете? А сколько еще таких дырявых приложений в Маркете? Наверно тысячи, десятки тысяч.

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


Многие этим профессионально занимаются, пишут ботов которые ползают по интернету, пробивают стандартные порты, брутят по словарю, ломают роутеры, IP-камеры, увеличивая армию ботов. С такими ботами встречался и я, точнее мой Firewall и было занятно наблюдать как пытались подобрать пароль от моей базы по примерно по 5-10 запросов в секунду.

Так же попадались боты которые пытались ломануть мой FTP и VNC сервер из разных стран.

Обнаружив эти попытки в логах, я убрал компы за NAT  и с тех пор я держу все порты закрытыми, оставив только порт для VPN-соединения, а при, необходимости временно доступа другим людям, открываю временно их на нестандартных портах. Для постоянно доступа использую OpenVPN и генерирую сертификаты на каждое устройство.


Итак. Для минимальной безопасности:

1. Не держите FTP сервер с возможностью подключаться анонимусом. Не держите на FTP какую либо инфу, позволяющая скомпрометировать другие сервера. Конечно, если это Web-сервер и через FTP обновляется его содержимое, то дайте ему минимальные права, если его вдруг вскроют.


2. Не используйте простые пароли, которые можно легко сбрутить. Поверьте, боты не спят и рано или поздно могут приняться за ваш сервер, если он виден извне.


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


4. Если возможно, старайтесь в Андроид-приложениях шифровать все HTTP-запросы. Например http://127.0.0.1/web?query=vcXGregfds4r5f3r456sdr32vdf-6t и ответ получать примерно такой же. Через снифер уже не будет видна какая-либо зависимость от запросов и большинство любителей это уже может остановить. В идеале еще прикрутить защищенное соединение, но многих останавливает, что SSL-сертификаты платные. Можно еще использовать сокеты.


5. Не оставляйте в приложениях права админа, например в веб-приложениях, десктопных. Старайтесь давать минимальные права приложениям. Фукнции авторизации желательно вешать на сервер, а дальше посылать только ID-сессии, а не UserID. При обмене данными всегда проверять авторизована ли машина или нет. Особенно это касается Web- и Android-приложении.


6. Периодически проверяйте логи приложений, а так же лог фаервола.


7. Сервера желательно прятать за NAT, а в некоторых случаях (например, если это сервер с персональными данными или где проводятся финансовые операции) за двойной NAT.


8. Ну про своевременную установку патчей и обновлений, я думаю не стоит объяснять.


9. Ну и конечно следите за новостями о вирусных угрозах, эпидемиях, новых шифровальщиках


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

Информационная безопасность IT

1.4K постов25.5K подписчиков

Добавить пост

Правила сообщества

Обязательно к прочтению для авторов:

1. Если вы добавляете пост, утверждающий об утечке данных или наличии дыр в системе, предоставьте ссылку на источники или технически подкованное расследование. Посты из разряда "Какой-то банк слил данные, потому что мне звонили мошенники" будут выноситься в общую ленту.
2. Все вопросы "Как обезопасить сервер\приложение\устройство" - в лигу "Компьютер это просто".

Обязательно к прочтению для всех:

Добавление ссылки разрешено если она не содержит описание коммерческих (платных) продуктов и/или идентификаторов для отслеживания перехода и для доступа не нужен пароль или оплата в т.ч. интернет-ресурсы, каналы (от 3-х тематических видео), блоги, группы, сообщества, СМИ и т.д.


Запрещены политические holy wars.

По решению модератора или администратора сообщества пользователь будет забанен за:

1. Флуд и оскорбление пользователя, в т.ч. провокация спора, флуда, холивара (высказывание без аргументации о конкретной применимости конкретного решения в конкретной ситуации), требование уже данного ответа, распространение сведений порочащих честь и репутацию, принижающих квалификацию оппонента, переходы на личности.

2. Публикацию поста/комментария не соответствующего тематике сообщества, в том числе обсуждение администраторов и модераторов сообщества, для этого есть специальное сообщество.

3. За обвинение в киберпреступной деятельности.

4. За нарушение прочих Правил Пикабу.

Вы смотрите срез комментариев. Показать все
DELETED
Автор поста оценил этот комментарий

Ипать, чувак, ты прозрел! Велком в реальную жизнь. Давно уже существует 2 разных понятия, реальная безопасность, это как раз то, что вы описали. и бумажная безопасность - 152 фз 17/21 приказы, 149 Фз. с помощью которых может и хотели как лучше, но сделали как всегда... С другой стороны, после этих законов, защищенность действительно выросла, ибо был то совсем адовый пиздец...

С другой стороны, если вы разрабы, то разрабам дают если не полный (а как иначе то?), то почти полный доступ, а остальное прописывают в договоре...

раскрыть ветку (7)
Автор поста оценил этот комментарий
А комплексно не подойти, сочетая и орг меры и инженерно технические?
раскрыть ветку (4)
DELETED
Автор поста оценил этот комментарий
По идее так и надо, но бумаги слигком бумажные, хотя, надо отдать должное, пока готовишь начинаешь разбираться во всех нюансах. Но вот порядка 5 видов журналов.... Нафига...
раскрыть ветку (3)
Автор поста оценил этот комментарий

Их больше чем 5:) Согласен, что где то регулятор перегибает втребованиях, ФАПСИшный приказ тот же самый 152, но без орг мер чисто технические работать не будут, когда тетя клава уборщица допуск имеет в помещение неограниченное.

раскрыть ветку (2)
DELETED
Автор поста оценил этот комментарий
Абсолютно согласен. Все это работает только в комрлексе. А еще ИБшник должен заниматься ИБ а не всем подряд....
раскрыть ветку (1)
Автор поста оценил этот комментарий
Безусловно. Неправильно, когда функции ИБ на админов вешают. Кстати такое требование есть в новых требованиях (тавтология) по КИИ, что ИБ подразделение должно только ИБ и заниматься. Но эт только для значимых объектов, если память не изменяет
Автор поста оценил этот комментарий

Я не совсем разраб. По должности я администратор БД на одной работе. ) Но приходится постоянно совмещать и сисадмина и прогера.

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

Даже в корпоративных сетях должна быть защита от самих же админов, например из дочерних филиалах. Ну нафига выдавать sa пароль? А если ему покажется что его с ЗП обидели и он перед уходем сделает Job убивающий скажем не всю базу, а только TOP 1000 строк ежедневно и это не сразу замечают? В итоге потом окажется что во всех бэкапах чего то не хватает, да и каким макаром потом восстанавливать целостность базы?

раскрыть ветку (1)
DELETED
Автор поста оценил этот комментарий

Согласен, но иногда:

а) не хватает квалификации заказчика

б) на этапе внедрения все равно будет необходим доступ, хотя можно дать дамп той же базы, и работать уже в новой системы, но внедрение может затянуться, а работать нужно уже сейчас..

в) Учитывать риски обиженных, что прописывается в договоре. Да, для коммерческой организации взыскание убытков (допустим в суде)при инциденте безопасности уже проигрыш и увольнение безопасника (потому что допустил), но для госучреждений это нормальное течение жизни, так скажем.

г) опять же возвращаемся к оценке рисков, вероятность утечки от разраба -5%, стоимость контракта Х, стоимость обеспечения защиты от утечки от разраба - Х/2а, то и 2*Х. А еще надо оценивать последствия утечки, если это БД с клиентами или бухгалтерия - это одно, а если это БД сайта, например, госуслуги.ру, то совершенно другое.... (никакое яб сказал, последствий практически нет) Вывод очевиден. Понятно, что базовую защиту, как вы указали - пароли, быкапы и прочее, т.е. то, что не очень затратно по трудочасам и финансам надо делать обязательно. И если это не делается - это банальное раздолбайство или, увы, нехватка времени и перегрузка профильных спецов, который и швец и жнец...

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку