К теме уязвимости в сетевых роутерах мы обращаемся далеко не первый раз, но исследования группы Bad Packets и компании Ixia (новость, отчет Bad Packets, отчет Ixia) интересны тем, что представляют почти полную картину: как ломают роутеры, какие настройки меняют, и что потом происходит.

Подобные атаки не имеют каких-то технически сложных элементов, да и цель у злоумышленников простая — заработать денег на рекламе и, если получится, украсть пароли доступа к банковским системам и платным интернет-сервисам. Если коротко: атакующие сканировали сеть для поиска уязвимых роутеров (в основном — неновых моделей производства D-Link). Обнаружив такой роутер, они меняли в нем записи DNS, перенаправляя трафик на собственные серверы. Уязвимости при этом использовались тривиальные, доступ к настройкам у непропатченных устройств происходил без авторизации. Самым старым устройствам в списке целей больше 10 лет, но несмотря на это, теоретически киберпреступники могли атаковать больше 15 тысяч жертв.

Не секрет, что интернет — очень враждебная среда. Как только вы поднимаете сервер, он мгновенно подвергается массированным атакам и множественным сканированиям. На примере ханипота от безопасников можно оценить масштаб этого мусорного трафика. Фактически, на среднем сервере 99% трафика может быть вредоносным.

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

Чаще всего тарпиты применяют для защиты. Технику впервые разработали для защиты от компьютерных червей. А сейчас её можно использовать, чтобы испортить жизнь спамерам и исследователям, которые занимаются широким сканированием всех IP-адресов подряд (примеры на Хабре: Австрия, Украина).

Знаете, когда я почти нечаянно обнаружил, читая прекрасную книгу Дмитрия Кетова «Внутреннее устройство Linux» (и это не реклама), что каждый скачанный нами файл из Интернета с легкой руки браузера оставляет в расширенных атрибутах файла (в inode файла, не в самом файле) как минимум полную ссылку на то откуда он был скачан, я пришел в легкое возбуждение и хотел тут же броситься спасать мир. Позже, немного изучив этот вопрос, почитав «коммиты» и «комменты», говорившие, что этой возможности, встроенной в ядро GNU/Linux, как минимум уже около 10 лет, что ею пользуется не только браузеры, но и, к примеру, популярная утилита wget (curl нет), и что эта вещь считается чуть ли не нормой в Linux (и, как выяснилось позже, в MacOS), то я немного подуспокоился. Одно не давало мне покоя: поиск ключевого слова getfattr в google по сайту «Хабра»: site:https://habr.com getfattr, равно как и по ЛОРУ: site:https://linux.org.ru getfattr ничего толком не дал. «Значит» — подумал я — «эта тема еще особенно не обсуждалась». — Что же, тогда пришло время ее обсудить, но для начала пришлось немного по-исследовать. И вот что я обнаружил:

Хранение паролей всегда было головной болью. В классическом варианте у вас есть пользователь, который очень старается не забыть жутко секретный «qwerty123» и информационная система, которая хранит хеш от этого пароля. Хорошая система еще и заботливо солит хеши, чтобы отравить жизнь нехорошим людям, которые могут украсть базу с хешированными паролями. Тут все понятно. Какие-то пароли храним в голове, а какие-то засовываем в зашифрованном виде в keepass.

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

С наступлением 2019 года хорошо вспомнить прошлое и подумать о будущем. Оглянемся на 30 лет назад и поразмышляем над первыми научными статьями по фаззингу: «Эмпирическое исследование надёжности утилит UNIX» и последующей работой 1995 года «Пересмотр фаззинга» того же автора Бартона Миллера.

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

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

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

Ссылки на все части:
Часть 1. Получение первоначального доступа (Initial Access)
Часть 2. Выполнение (Execution)
Часть 3. Закрепление (Persistence)
Часть 4. Повышение привилегий (Privilege Escalation)
Часть 5. Обход защиты (Defense Evasion)
Часть 6. Получение учетных данных (Credential Access)
Часть 7. Обнаружение (Discovery)
Часть 8. Боковое перемещение (Lateral Movement)
Часть 9. Сбор данных (Collection)
Часть 10 Эксфильтрация или утечка данных (Exfiltration)
Часть 11. Командование и управление (Command and Control)

Получение первоначального доступа

Данной публикацией начинаю цикл постов, посвященных описанию основных техник, применяемых злоумышленниками на различных этапах осуществления хакерских атак.
Излагаемый материал будет свободным пересказом содержания матриц Adversarial Tactics, Techniques & Common Knowledge (ATT@CK) от компании The Mitre:

• PRE-ATT&CK (техники подготовительных стадий атаки);
  
• ATT&CK Matrix for Enterprise (техники атаки на корпоративные системы);
  
• ATT&CK Mobile Profile (техники атак на мобильные устройства).

Совсем недавно мы рассказали о том, как команда нашего IaaS-провайдера автоматизировала работу с DNS-записями в хостинг-панели.

Опыт создания новой услуги по предоставлению бесплатного сервиса DNS-хостинга сподвиг нас к беглому анализу публикаций на Хабре, которые затрагивали те или иные аспекты работы DNS. Мы собрали эти материалы вместе с англоязычными дополнениями в очередной «ультимативный» дайджест от 1cloud.

В прошлых выпусках мы собрали практические материалы в SSL-и VPN-дайджест.

достаточно сильный лебедь

Если вы когда-либо искали VPN, который будет работать на десктопах, мобильных устройствах и роутерах без установки дополнительного ПО и перепрошивки роутера, вы, вероятно, выбирали между PPTP и L2TP+IPsec. У протокола PPTP имеются проблемы с безопасностью и прохождением через брандмауеры и NAT, так что в 2015 году его уже использовать не стоит, а использование L2TP излишне, т.к. L2 VPN, по моему мнению, для обычного удаленного доступа не нужен практически никогда.

Удивительно, что в интернете не так-то просто можно найти информацию о настройке чего-то помимо L2TP+IPsec в транспортном режиме, учитывая, что это обширный стек протоколов, который можно конфигурировать буквально как душе угодно, поэтому я попытаюсь устранить такое несовершенство мира.

Небольшое введение в мир IPsec

Вообще говоря, не совсем правильно называть IPsec VPN. IPsec не предназначен для построения «виртуальных частных сетей», а создан для шифрования или защиты от подмены передаваемых по IP данных. Это специальный слой поверх IP, который, в зависимости от режима и настроек, работает по-разному. В отличие от привычного VPN, который создает новый интерфейс в системе, на который вы, как это чаще всего бывает, назначаете IP-подсеть из диапазона частных адресов (т.е. создаете новый сетевой сегмент), и через который маршрутизируется трафик в зашифрованном виде, IPsec просто шифрует трафик магическим образом между «внешними» интерфейсами сервера и клиента.

Чуточку ликбеза. Навеяно предшествующими копипастами разной чепухи на данную тему. Уж простите, носинг персонал.

IP-адрес (v4) состоит из 32-бит. Любой уважающий себя админ, да и вообще айтишник (про сетевых инженеров молчу) должен уметь, будучи разбуженным среди ночи или находясь в состоянии сильного алкогольного опьянения, правильно отвечать на вопрос «из скольки бит состоит IP-адрес». Желательно вообще-то и про IPv6 тоже: 128 бит.

Обстоятельство первое. Всего теоретически IPv4-адресов может быть:
2³² = 2¹⁰*2¹⁰*2¹⁰*2² = 1024*1024*1024*4 ≈ 1000*1000*1000*4 = 4 млрд.
Ниже мы увидим, что довольно много из них «съедается» под всякую фигню.

Записывают IPv4-адрес, думаю, все знают, как. Четыре октета (то же, что байта, но если вы хотите блеснуть, то говорите «октет» — сразу сойдете за своего) в десятичном представлении без начальных нулей, разделенные точками: «192.168.11.10».

В заголовке IP-пакета есть поля source IP и destination IP: адреса источника (кто посылает) и назначения (кому). Как на почтовом конверте. Внутри пакетов у IP-адресов нет никаких масок. Разделителей между октетами тоже нет. Просто 32-бита на адрес назначения и еще 32 на адрес источника.

После скучного рассказа о подключении к кошкам переходим к настройке сети. В этот раз темы будут для новичков сложные, для старичков избитые. Впрочем сетевым аксакалам едва ли удастся почерпнуть что-то новое из этого цикла. Итак, сегодня:
а) аккуратно впитываем теорию о коммутаторах, уровнях сетевой модели, понятии инкапсуляции и заголовков (не пугайтесь — еще не время),
б) собираем спланированную в нулевой части цикла сеть,
в) настраиваем VLAN'ы, разбираемся с access и trunk-портами и тегированными Ethernet-фреймами,
г) соотносим текущие знания со стеком протоколов TCP/IP и моделью OSI (да, наконец-то мы ее коснёмся).



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

Одним из этапов тестирования мобильного приложения — это статический анализ. Статический анализ приложения — это анализ приложения без выполнения каких либо функций приложения. Наиболее удобным для меня из open source фреймворков есть MobSF. Кому интересно, добро пожаловать под кат.

Развивая IT-инфраструктуру рано или поздно приходит задача интегрироваться с какими-либо сервисами крупной организации. Это может быть, например, банк или оператор связи. Как правило в крупных организациях действуют устоявшиеся политики информационной безопасности, которые в частности требуют реализации сервиса с внешней по отношению к ним инфраструктурой через шифрованные каналы — IPSec. В то же время в небольших организациях стартапах нет опыта организации таких схем, а из оборудования есть только VDS с Linuxом на борту. Более того, к моему удивлению, в рунете практически нет материалов с описанием инструментов траблшутинга под Linux. Попробуем устранить этот пробел и описать практическую часть настроек.

Александр Крижановский (NatSys Lab.)

Нас сегодня будет интересовать операционная система – ее внутренности, что там происходит… Хочется поделиться идеями, над которыми мы сейчас работаем, и отсюда небольшое вступление – я расскажу о том, из чего состоит современный Linux, как его можно потюнить?

По моему мнению, современная ОС – это плохая штука.

Дело в том, что на картинке изображены графики сайта Netmap (это штуковина, которая позволяет вам очень быстро захватывать и отправлять пакеты сетевого адаптера), т.е. эта картинка показывает, что на одном ядре с разной тактовой частотой до 3 ГГц Netmap позволяет 10 Гбит – 14 млн. пакетов в сек. отрабатывать уже на 500 МГц. Синенькая линия – это pktgen – самое быстрое, что, вообще, есть в ядре Linux’а. Это такая штуковина – генератор трафика, который берет один пакет и отправляет его в адаптер много раз, т.е. никаких копирований, никакого создания новых пакетов, т.е., вообще, ничего – только отправка одного и того же пакета в адаптер. И вот оно настолько сильно проседает по сравнению с Netmap (то, что делается в user-space показано розовой линией), и оно вообще где-то там внизу находится. Соответственно, люди, которые работают с очень быстрыми сетевыми приложениями, переезжают на Netmap, Pdpdk, PF_RING – таких технологий море сейчас.

Представляем вашему вниманию очередную порцию лекций Технотрека. В рамках курса будут рассмотрены основы системного администрирования интернет-сервисов, обеспечения их отказоустойчивости, производительности и безопасности, а также особенности устройства ОС Linux, наиболее широко применяемой в подобных проектах. В качестве примера будут использоваться дистрибутивы семейства RHEL 7 (CentOS 7), веб-сервер nginx, СУБД MySQL, системы резервного копирования bacula, системы мониторинга Zabbix, системы виртуализации oVirt, балансировщика нагрузки на базе ipvs+keepalived. Курс ведёт Сергей Клочков, системный администратор в компании Variti.

По мере взросления и стабилизации экосистемы Docker связанные с безопасностью этого продукта темы привлекают все больше внимания. При проектировании инфраструктуры невозможно избежать вопроса обеспечения безопасности Docker.

В Docker уже встроено несколько замечательных средств обеспечения безопасности:

• Docker-контейнеры минимальны: один или несколько работающих процессов, только необходимое программное обеспечение. Это снижает вероятность пострадать от уязвимостей в ПО.

  
  

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

  
  

• Docker-контейнеры изолированы как от хоста, так и от других контейнеров. Этого удается добиться благодаря способности ядра Linux изолировать ресурсы с помощью cgroups и namespaces. Но есть серьезная проблема — ядро приходится делить между хостом и контейнерами (мы еще вернемся к этой теме чуть позже).

  
  
• Docker-контейнеры воспроизводимы. Благодаря их декларативной системе сборки любой администратор может легко выяснить, из чего и как был сделан контейнер. Крайне маловероятно, что у вас в итоге окажется неизвестно кем настроенная legacy-система, которую никому не хочется конфигурировать заново. Знакомо, не правда ли? ;)

Однако в основанных на Docker системах есть и слабые места. В этой статье мы как раз о них и поговорим, рассмотрев 7 проблем безопасности Docker.

Ядро Linux широко распространено во всем мире как на серверах, так и на пользовательских машинах, на мобильных платформах (ОС Android) и на различных «умных» устройствах. За время существования в ядре Linux появилось множество различных механизмов защиты от эксплуатации уязвимостей, которые могут существовать как в самом ядре, так и в приложениях пользователей. Такими механизмами является, в частности, ASLR и stack canary, противодействующие эксплуатации уязвимостей в приложениях.

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

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

В этой статье мы:

• продемонстрируем, как фаззить обработчик JSON-запросов;
• используя фаззинг, найдём уязвимость переполнения буфера;
• напишем шеллкод на Ассемблере для эксплуатации найденной уязвимости.

Разбирать будем на примере исходных данных задания прошлого NeoQUEST. Известно, что 64-хбитный Linux-сервер обрабатывает запросы в формате JSON, которые заканчиваются нуль-терминатором (символом с кодом 0). Для получения ключа требуется отправить запрос с верным паролем, при этом доступа к исходным кодам и к бинарнику серверного процесса нет, даны только IP-адрес и порт. В легенде к заданию также было указано, что MD5-хеш правильного пароля содержится где-то в памяти процесса после следующих 5 символов: «hash:». А для того, чтобы вытащить пароль из памяти процесса, необходима возможность удалённого исполнения кода.

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

Часто нужно узнать всю информацию о какой-нибудь уязвимости: насколько найденный баг критичен, есть ли готовые сплоиты, какие вендоры уже выпустили патчи, каким сканером проверить наличие бага в системе. Раньше приходилось искать вручную по десятку источников (CVEDetails, SecurityFocus, Rapid7 DB, Exploit-DB, базы уязвимостей CVE от MITRE/NIST, вендорские бюллетени) и анализировать собранные данные. Сегодня эту рутину можно (и нужно!) автоматизировать с помощью специализированных сервисов. Один из таких — Vulners, крутейший поисковик по багам, причем бесплатный и с открытым API. Посмотрим, чем он может быть нам полезен.