Как хакеры получают доступ к компьютеру

Обновлено: 04.07.2024

Этичный хакинг и тестирование на проникновение, информационная безопасность

Если получен доступ к роутеру, можно ли получить доступ к устройствам в локальной сети? Чтобы ответить на этот вопрос, давайте разберёмся, как работает домашняя локальная сеть.

Как работает домашняя локальная сеть

В домашней локальной сети основой является роутер — довольно сложное сетевое устройство. Это устройство обеспечивает работу локальной сети. При подключении нового устройства к локальной сети роутера, он с помощью протокола DHCP присваивает новому устройству IP адрес. В качестве диапазона IP адресов в домашних сетях обычно используются 192.168.1.0/24, 192.168.0.0/24 или 192.168.100.0/24.

То есть у вашего компьютера или телефона, подключённого к Интернету через роутер, имеется локальный IP адрес.

Возможно вы уже слышали про NAT и даже знаете, что эта технология позволяет Интернет-провайдеру использовать один единственный внешний (белый) IP адрес для всех или для множества его клиентов. Но NAT используется не только на уровне провайдера Интернет услуг, но и уже в вашем роутере. Рассмотрим NAT чуть подробнее.

NAT — это технология, которая позволяет множеству устройств выходить в Интернет используя один и тот же IP адрес. Кстати, в вашей локальной сети, в которой имеется роутер, уже применяется NAT — именно благодаря этому все ваши устройства могут выходить в Глобальную сеть и не нужно каждому из них иметь внешний IP.

Можно ли получить доступ к компьютеру в локальной сети, если есть доступ к роутеру?

Вроде бы, ответ очевиден — технология NAT не даёт такой возможности в принципе: подключение к локальным устройствам, у которых нет белого IP, а есть только локальный IP вида 192.168.0.*, невозможен.

Но я начал с того, что роутер это весьма сложное сетевое устройство. И это устройство поддерживает множество функций по настройке сети, в частности оно поддерживает:

настройку статичных IP адресов для устройств в локальной сети минуя протокол DHCP
Forwarding портов

Forwarding портов

Forwarding, который ещё называют «переадресацией» портов, «проброской портов», «перенаправлением портов» или «Port mapping» (сопоставление портов) позволяет делать очень замечательную вещь — с его помощью устройства за NAT, то есть устройство в локальной сети, имеющее локальный IP адрес, могут стать доступными глобально. Правила могут быть настроены весьма гибкой, можно сделать пересылку нескольких портов на один, или с одного на несколько, или несколько на несколько и так далее. Но для наших целей больше всего интересно следующее правило, которое словами можно выразить так:

Номера портов необязательно должны быть одинаковыми, поэтому правило может быть таким:

В результате мы получим доступ к порту 80 (его обычно прослушивает веб-сервер) устройства в локальной сети 192.168.0.5.

Это означает, что мы можем получить доступ к любому открытому порту и запущенному на нём службе в локальной сети! Это может быть веб-сервер, SSH, FTP, сетевые протоколы Windows и т.д.

Просмотр устройств локальной сети. Настройка статических адресов в локальной сети

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

Рассмотрим пример. В локальной сети провайдера есть роутер с IP адресом 100.69.64.23 к которому получен административный доступ.

Все (или практически все) роутеры могут показать информацию о подключённых в данный момент клиентах. Эта информация может быть:

на странице статуса роутера
на странице настройки DHCP
на странице статуса LAN (локальной сети)

Например, на этом роутере информация собрана на странице DHCP Clients List:

Например, для MAC 00:80:92:c4:6a:f9 найдена следующая информация:

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

Из всех устройств самыми интересными мне показались следующие

Причина в следующем:

их MAC-адреса, вроде бы, не принадлежат производителям мобильных телефонов
их IP адреса являются самыми первыми — то есть к роутеру весьма вероятно вначале подключаются проводные устройства, а затем устройства по Wi-Fi
эти устройства отсутствуют в списке беспроводных клиентов:

Если атака планируется длительной, то определённым устройствам можно присвоить статичные IP адреса. Дело в том, что проброска портов настраивается относительно IP адреса. А целевое устройство через некоторое время может сменить IP адрес на произвольный. Если это случиться, то правила переадресации портов будут работать — просто теперь они будут отправлять пакеты другому устройству, которое заняло этот IP адрес.

Чтобы этого избежать можно привязать IP к MAC-адресу — мне ещё не встречались роутеры, которые не умеют этого делать. Настройка выполняется достаточно просто.

Настройка переадресации портов

В зависимости от модели роутера эта вкладка может называться

Forwarding
Port Forwarding
Port mapping
Переадресация портов
другие варианты

Например, на рассматриваемом роутере эту вкладку я нашёл по пути Application → Port Forwarding:

Всего портов 1-65535 и роутеры позволяют делать переадресацию диапазонов, то есть 65 тысяч портов не придётся настраивать по одному.

Но есть очень важное замечание — мы не можем настроить переадресацию того порта, на котором работает веб-сервер роутера. То есть если роутер открывается на 80 порту, то этот порт должен стать исключением. Иначе произойдёт следующее: ни мы, ни даже владелец роутера больше не сможем попасть в панель администрирования роутера пока не будут сброшены настройки на заводские.

Обратите внимание, что некоторые роутеры работают не на 80, а на 8080 или 443 порте.

Итак, если веб-интерфейс роутера работает на 80 порту и мы хотим получить доступ к локальным ресурсам устройства с IP 192.168.1.2, то нам нужно установить следующие три правила:

Переадресацию портов 1-79 на 1-79 порты адреса 192.168.1.2
Переадресацию портов 81-65534 на 81-65534 порты адреса 192.168.1.2
Переадресацию порта 65535 на 80 порт адреса 192.168.1.2

Первые два правила с диапазонами (надеюсь) очевидны. Третьим правилом мы перенаправляем запросы, пришедшие на порт 65535, на 80 порт локального компьютера, поскольку там может быть веб-сервер или что-то другое интересное.

Начнём с того, что сделаем контрольный замер, какие именно порты открыты:

Эта команда покажет открытые порты на роутере:

Добавляем первое правило:

Заново сканируем порты:

Констатируем — нас постигла неудача. 80-й порт — это порт самого роутера, а на устройстве с IP 192.168.1.2 просканированные порты закрыты.

Не отчаиваемся — переделываю все правила на переадресацию портов на IP 192.168.1.3:

И опять сканируем порты:

Поясню, хотя команда Nmap одна и та же, но на самом деле в предыдущий раз мы сканировали порты устройства в локальной сети с IP 192.168.1.2. А последняя команда уже сканирует порты на 192.168.1.3.

А вот здесь нам повезло:

Напомню, что все эти порты, кроме 80, открыты на устройстве, у которого даже нет белого IP адреса, у него IP адрес 192.168.1.3.

А как проверить 80 порт на 192.168.1.3? Делаем это так:

Порт оказался закрыт.

Чтобы собрать информацию об отрытых портах, изучим их баннеры:

Не очень интересно — видимо, это всё функции связанные с принтером.

А там мы видим интерфейс многофункционального устройства (принтер-копер-сканер) MFC-J5910DW:

Ещё раз для тех, кто потерялся, это устройство с IP адресом 192.168.1.3!

Также я сумел подключиться к FTP:

Заключение

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

Я занимаюсь поиском уязвимостей в различных системах безопасности. В определённый момент мне стало понятно, что мои клиенты недостаточно хорошо знакомы (если вообще знакомы) с базовыми приёмами «хакинга». Ключи к API, пароли, SSH-ключи, сертификаты — всё это отличные механизмы защиты. Но это так до тех пор, пока их держат в секрете. После того, как подобные данные оказываются доступными тем, у кого доступа к ним быть не должно, оказывается, что сложность паролей и продвинутость алгоритмов хеширования уже значения не имеют. В этом материале я хочу рассказать о концепциях, методах и инструментах, применяемых исследователями систем безопасности для нахождения секретных данных. Такие данные используются для взлома систем. Я, кроме того, расскажу тут о простых последовательностях действий, которые помогут снизить риск успешной хакерской атаки.

Важно отметить то, что «игра» в нападение и защиту, в которую играют хакеры и владельцы компьютерных систем, это — нечестная игра. Атакующему достаточно, чтобы проникнуть в систему, выиграть лишь раз. А тому, кто защищается, выиграть можно лишь всегда побеждая. Главная сложность тут — знать о том, на что надо обращать внимание. Но после того, как защитник будет знать о том, через какие именно виртуальные «двери» в его систему может проникнуть хакер, эти «двери» можно защитить с помощью достаточно простых механизмов. Я полагаю, что простота этих механизмов иногда принижает их важность и является причиной того, что многие защитники компьютерных систем упускают эти механизмы из виду.

Включайте многофакторную аутентификацию (multi-factor authentication, MFA) везде, где это возможно. Защищайте с её помощью учётные записи Google и GitHub, аккаунты облачных провайдеров, личные кабинеты VPN-сервисов. Если используемая вами система не предусматривает использование MFA — подумайте о переходе на другую систему.
Выполняйте ротацию паролей и ключей, применяйте политики ротации паролей.
Регулярно проверяйте код на наличие в нём того, чего в нём быть не должно. Лучше всего сделать такие проверки частью процесса проверки кода перед публикацией.
Делегируйте одной центральной системе задачи по работе с профилями регистрации и по управлению доступом к другим системам. Эта система должна находится под вашим контролем, вы должны постоянно за ней наблюдать.

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

Хакеры находят секретные данные в JavaScript-файлах

Ключи к API разбросаны по всему интернету. Воспользоваться ими может кто угодно. Это — факт. Часто у того, что ключи оказываются в общем доступе, нет каких-то особых причин. Разработчики просто повсюду их забывают. Например, ключи попадают в код по следующим причинам:

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

Хотя многие хакеры самостоятельно читают код JavaScript-файлов, такие файлы, в основном, ищут с помощью инструментов вроде meg, а потом проверяют то, что нашли, на наличие там соответствующих паттернов.

Как они это делают? После использования сканера вроде meg они ищут в найденных файлах строки, соответствующие различным шаблонам. Тот же, кто создал meg , написал ещё одну отличную программу, именно для этого и предназначенную. Она называется gf и представляет собой улучшенный вариант grep . В данном случае использование при запуске gf опции truffleHog или, в другом варианте её написания, trufflehog , позволяет инструменту находить высокоэнтропийные строки, представляющие собой ключи к API. То же самое касается и поиска строки API_KEY . Результаты поиска по такой строке часто (слишком часто) оказываются успешными.

Нередко у того, что ключи появляются в коде, есть совершенно нормальные причины, но такие ключи не защищены от посторонних. Приведу пример. Один клиент, с которым я работал, пользовался внешним сервисом картографической информации. Так делается во многих проектах. Для того чтобы загружать картографическую информацию и работать с ней, нужно было выполнять обращения к соответствующему API с использованием ключа. Но мой клиент забыл настроить применяемый им сервис так, чтобы ограничить источники, с которых в этот сервис могут поступать запросы, использующие этот конкретный ключ. Несложно представить себе простую атаку, которая заключается в том, чтобы истощить квоту на использование ресурсов картографического сервиса путём отправки к нему множества запросов. Это может стоить пользователю такого сервиса больших денег. Или, что ещё «лучше» (с точки зрения атакующего), такая атака может привести к тому, что те части проекта клиента, которые завязаны на картах, попросту «упадут».

JS-файлы используются хакерами не только для поиска секретных данных. Ведь такие файлы — это код вашего приложения, который может увидеть любой, кому этот код интересен. Хороший хакер может, внимательно прочтя код, разобраться в используемом в нём подходе к именованию сущностей, выяснить пути к API, может обнаружить ценные комментарии. Подобные находки оформляются в виде списка слов, передаваемого автоматическим сканерам. Это — то, что называется «интеллектуальным автоматизированным сканированием» («intelligent automated scan»), когда хакер комбинирует автоматические инструменты и собранную им информацию о конкретном проекте.

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

▍Что делать?

Минифицируйте код. Благодаря этому код обфусцируется. Подобная обработка кода обратима, но благодаря ей можно обойти многие автоматические сканеры, что уменьшает потенциальные возможности атаки.
Оставляйте в коде только абсолютный минимум ключей и путей к API. В то время как без некоторых из них обойтись не получится, о большинстве из них сказать того же самого нельзя. Оставляйте в коде только те ключи, которым совершенно необходимо в нём присутствовать.
Понизьте разрешения, связанные с ключами, до абсолютного минимума. Если вспомнить пример с сервисом картографической информации, то можно сказать, что ключи должны быть такими, чтобы с их помощью можно было бы делать только то, для чего они предназначены, и чтобы пользоваться ими можно было бы только там, где они должны использоваться. Удостоверьтесь в том, что эти ключи нельзя использовать для атаки на систему.
Используйте те же инструменты для автоматического сканирования кода, которые используют хакеры. Включайте их в системы непрерывной интеграции. Особенно это касается средств для поиска строковых паттернов, которые работают очень быстро. Используйте простые инструменты вроде grep или gf для поиска строк. Такая проверка кода сродни тестам. Она позволяет убедиться в том, что разработчики не оставляют в коде дыр, которыми может воспользоваться злоумышленник для взлома системы.
Внедрите у себя практику код-ревью. Всегда полезно, когда кто-то проверяет ваш код. Все автоматические сканеры мира не способны выявить 100% возможных проблем. Код-ревью — это отличный способ повышения качества и защищённости кода.

Хакеры анализируют информацию из прошлого, пользуясь интернет-архивами

Архив Интернета (известный ещё как «Wayback Machine») хранит периодически создаваемые снимки веб-сайтов. Этот проект позволяет увидеть то, каким был интернет многие годы тому назад. Данные архива представляют немалый интерес для хакеров, которым нужно собрать сведения о некоем проекте. Сканировать файлы старых вариантов веб-сайтов можно с помощью инструментов наподобие waybackurls (он основан на waybackurls.py). Это значит, что даже если вы нашли в коде сайта ключ и убрали его оттуда, но не произвели ротацию ключей, хакеры могут найти этот ключ в старой версии сайта и воспользоваться этим ключом для взлома системы.

Вот что нужно сделать в том случае, если вы нашли ключ там, где его быть не должно:

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

▍Архив Интернета — это не единственное место, где можно найти ключи

Старый код даёт злоумышленникам самую разную интересующую их информацию.

Хакеры пользуются GitHub

GitHub — это настоящая золотая жила для хакеров. Если знать о том, где искать, то, воспользовавшись простыми инструментами поиска, можно найти много всего интересного. Если учётная запись вашей организации на GitHub не защищена механизмом многофакторной аутентификации, то все без исключения сотрудники организации представляют собой ходячие дыры системы безопасности. Вполне реально то, что некоторые из сотрудников используют везде один и тот же пароль, и то, что этот пароль уже был украден у них через какую-то другую систему. Хакер, которого интересует некая организация, может легко автоматизировать поиск скомпрометированных паролей, да что там говорить, он может найти такие пароли и вручную.

Список сотрудников организации можно создать, воспользовавшись методами разведки, основанной на открытых источниках (Open source intelligence, OSINT). Помочь в этом злоумышленнику может LinkedIn или общедоступный список сотрудников компании с GitHub.

Если, например, кто-то решил взломать компанию Tesla, то он вполне может начать изучение компании с этой страницы:

А даже если компания не использует GitHub в качестве git-платформы, на GitHub, всё равно, можно найти что-то ценное. Достаточно, чтобы этой платформой пользовался хотя бы один из сотрудников компании, например, для домашнего проекта. Если в коде этого проекта (или в истории git) появится что-то секретное, относящееся к компании, этого будет достаточно для того чтобы проникнуть в системы этой компании.

Отслеживание полной истории изменений, вносимых в каждый проект, это — природа git. В свете вопросов безопасности этот факт играет огромную роль. Другими словами, каждое изменение, внесённое в код любым, кто имеет доступ к каким-либо системам некоей организации, подвергает эту организацию опасности.

▍Почему это происходит?

Компании не проверяют свои системы на предмет наличия в них уязвимостей.
Те компании, которые выполняют подобные проверки, обычно не обращают внимания на общедоступные учётные записи своих сотрудников.
Те компании, которые проверяют и свои системы, и учётные записи сотрудников (а таких, по грубым оценкам, менее 1%), часто слишком сильно полагаются на автоматические сканеры и не проверяют историю коммитов (то есть — анализируют не всё дерево git, а лишь то, что лежит на поверхности, представленное самой свежей версией кода).
И наконец, достаточно часто компании не выполняют ротацию ключей и не применяют двухфакторную аутентификацию. Два этих приёма способны закрыть большинство вышеупомянутых брешей систем безопасности.

▍Основы использования особых поисковых запросов в GitHub

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

Дорки, применимые на GitHub, не так сложны, как те, которыми можно пользоваться в Google. Дело тут в том, что GitHub просто не предлагает пользователю столь же продвинутых поисковых возможностей, которые предлагает Google. Но, несмотря на это, правильный поиск по GitHub-репозиториям может прямо-таки творить чудеса. Попробуйте поискать в интересующем вас репозитории по следующим строкам:

А если попробуете искать определённые файлы, используя запросы вроде filename:.npmrc _auth или filename:.htpasswd , то вы сможете фильтровать результаты поиска по типам утечек данных. Вот ещё один хороший материал на эту тему.

▍Меры по снижению рисков, связанных с GitHub

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

Вот что говорит пользователь @corymcdonald:

Там, где я работаю, всем выдают аппаратные средства многофакторной аутентификации. У каждого имеется по 2 устройства YubiKey. Кроме того, каждая команда пользуется менеджером паролей 1Password, для каждой команды создано собственное хранилище паролей. Когда некий сотрудник покидает компанию, команда техподдержки выполняет ротацию паролей в каждом хранилище, к которому был доступ у этого сотрудника. Лично я, например, совершил непростительную ошибку, выложив на GitHub ключи для доступа к AWS. Рекомендовано, перед выполнением коммитов, проверять материалы с использованием git-secrets. Это позволит не дать уйти в общий доступ тому, что напоминает секретные сведения.

Хакеры используют Google

Теперь, когда мы в общих чертах познакомились с дорками, мы можем поговорить о применении особых поисковых запросов в Google. Тут с их помощью можно найти просто невероятные вещи. Google — мощная поисковая система, которая позволяет строить запросы, описывая строки, которые должны и не должны присутствовать в искомых данных. Google, кроме прочего, позволяет искать файлы с определёнными расширениями, умеет выполнять поиск по заданным доменам, по URL. Взгляните на следующую поисковую строку:

Эта строка рассчитана на поиск файлов с расширением yml , причём, это должны быть файлы docker-compose , в которых разработчики нередко хранят пароли. Не особенно уникальные пароли. Попробуйте запустить в Google поиск по этой строке. Вас удивит то, что вы найдёте.

Другие интересные поисковые строки могут быть рассчитаны на поиск RSA-ключей или учётных данных AWS. Вот ещё один пример:

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

Хакеры тщательно изучают интересующие их системы

Когда некая система очень интересует исследователя безопасности (или мотивированного хакера), он приступает к глубокому изучению этой системы. Он близко знакомится с ней. Его интересуют конечные точки API, соглашения по именованию сущностей, особенности взаимодействия внутренних частей систем, наличие доступа к разным версиям системы в том случае, если одновременно используются её разные версии.

Не очень хороший подход к защите API заключается в том, чтобы усложнять пути доступа к ним, скрывать их с использованием чего-то вроде генератора случайных символов. Это не заменяет реальных механизмов обеспечения безопасности. Исследователи безопасности пытаются найти незащищённые пути доступа к системам, конечные точки API, например, пользуясь инструментами для «нечёткого» поиска уязвимостей. Такие инструменты используют списки слов, строят из них пути и проверяют эти пути, анализируя получаемые при попытке обращения к ним ответы. Подобный сканер не найдёт конечную точку, путь к которой представлен совершенно случайным набором символов. Но такие инструменты прекрасно показывают себя в деле идентификации паттернов и в нахождении конечных точек, о которых владельцы системы либо забыли, либо никогда и не знали.

Помните о том, что «безопасность через неясность» («security through obscurity») — это не лучший способ защиты систем (хотя полностью игнорировать его не стоит).

Но и у «случайных строк», тем не менее, есть своё место в системах. Их применение всегда лучше, чем использование в путях к API последовательностей из идентификаторов ресурсов, строк вроде users и orders .

Вот — потрясающий репозиторий SecLists, который содержит множество строк, используемых при именовании сущностей. Им пользуются практически все, имеющие отношение к индустрии защиты данных. Часто эти материалы модифицируют под конкретную систему. Ещё один инструмент, который можно использовать для поиска «зашифрованных» путей, это FFuf — чрезвычайно быстрая программа, основанная на нечёткой логике, написанная на Go.

Итоги

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

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

Если говорить о защите информации, то тут не очень хорошо работает идея, в соответствии с которой скорость — это самое главное.

Приобретение знаний о том, как работают хакеры, обычно представляет собой очень хороший первый шаг на пути к пониманию того, что такое информационная безопасность. Это — первый шаг к защите систем. Защищая системы, учитывайте вышеперечисленные способы проникновения в них, и то, что хакеры используют достаточно ограниченный набор таких способов. Рекомендуется рассматривать с точки зрения безопасности абсолютно всё, что так или иначе имеет отношение к некоей системе, вне зависимости от того, идёт ли речь о внешних или внутренних механизмах.

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

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

Что могут украсть хакеры? Если коротко – всё, что находится у вас на цифровых устройствах либо проходит через них, хранится онлайн в мессенджерах, облаках, электронной почте.

Данные банковской карты

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

Основу фишинга составляет использование психологических слабостей человека либо его невнимательности для того, чтобы он собственноручно передал мошенникам данные своей карты либо аккаунта в интернет-банке.

Классический вид фишинга – рассылка писем со ссылкой на вредоносный сайт или вирус по e-mail. Письмо может быть замаскировано под рабочее и ссылаться на заражённую страницу либо иметь прикреплённый заражённый файл для скачивания. Если вирус попадёт на ваш компьютер, он сможет передать всю информацию о сохранённых логинах и паролях (лог-файлы) мошенникам. Естественно, там могут оказаться и пароли от онлайн-кошельков или итернет-банкинга.

Логины и пароли

Выше частично мы уже описали, как мошенники могут украсть данные всех ваших учётных записей через фишинговое письмо. Однако это не единственный способ. Вирус, передающий регистрационные данные, может попасть на ваш компьютер и без фишеров.

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

Использование мощностей вашего устройства

Зловредная программа может майнить на вашем компьютере или даже телефоне криптовалюту. Объём получаемой «крипты» с одного устройства невелик, но целая сеть заражённых гаджетов может с лихвой это компенсировать.

Информация со смартфона

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

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

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

Документы

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

Однако получить фото паспорта можно не только через взлом аккаунтов. Иногда мошенники создают фейковые объявления о приёме на работу на сайтах вакансий. На этапе переписки с соискателем под предлогом проверки судимостей/кредитной истории/отсутствия в чёрном списке компании у него просят фото паспорта. Если жертва присылает документ, злоумышленники перестают выходить на связь. После они могут использовать это фото для ведения своей мошеннической деятельности от вашего имени, предоставляя в доказательство фото паспорта.

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

Как защитить себя?

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

Современные проблемы требуют современных решений. А кибермошенничество – одна из самых ярких проблем нашего времени. Но равно так же, как мошенники постоянно обучаются новым технологиям, чтобы красть ваши деньги и данные, вы можете обучаться в ответ, чтобы защитить своё цифровое имущество. Чтобы обеспечить свою безопасность, нужно всегда быть начеку и не отставать от развития технологий. Желаем вам оставаться в недоступности для хакеров.

В Екатеринбурге мошенники украли сотни файлов с личными данными пациентов онкологического центра. Они требовали выкуп в размере рублей, тем самым поставив под угрозу не только финансы больницы, но и жизни людей. Но как они это сделали? Могут ли украсть данные у любого из нас и что делать, чтобы обезопасить себя? Об этом мы поговорили с Львом Богачевым, специалистом отдела кибербезопасности.

— Основной вектор атак — это «вирусы-вымогальщики», рассылка через электронную почту или приложения. Такие рассылки чаще всего бывают либо массовыми, либо целевыми (для бухгалтеров, для юристов — для любого человека можно подобрать такое письмо, которое его точно заинтересует). Такое письмо обычно содержит вредоносное вложение — документ в формате doc, pdf, xls и прочие. При открытии такого документа злоумышленник получает удаленный доступ к компьютеру, через который он может посетить и зашифровать некоторые файлы, — говорит Богачев.

Проще говоря, бухгалтеру может прийти электронное письмо с вложенным файлом «Новинки в налогах — 2020». И когда человек откроет его, он уже заразит компьютер. Вирус может запустить целую цепочку действий: он что-то скачивает, ищет, загружает новые файлы — повышает свои привилегии.

Вернуть свои данные самостоятельно вы, скорее всего, не сможете

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

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

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

Благодаря мошенникам любой кол-центр банка сразу знает ваше имя и место жительства

Читайте также: