Subnets.ru blog

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

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

Специалисты по информационной безопасности из корпорации Google обнаружили несколько критических уязвимостей в протоколе Network Time Protocol (NTP). Именно с его помощью в начале 2014 г.была проведенасамая мощная DDoS-атака в истории интернета.

«Новые уязвимости позволяют атакующему сформировать специальный пакет и, отправив его на целевую систему, вызвать переполнение буфера и далее выполнить в системе произвольный вредоносный код с привилегиями NTPD (фонового процесса, осуществляющего обмен данными по протоколу NTP)», — говорится в сообщении.

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

Сложность ситуации в том, что протокол NTP используется на бесчисленном количестве серверов, роутеров и других сетевых устройств, подчеркивает Ars Technica. Кроме того, природа уязвимостей такова, что воспользоваться ими легко может даже неподготовленный, начинающий взломщик.

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

Источник: http://www.cnews.ru/top/2014/12/22/beschislennoe_kolichestvo_serverov_mozhet_byt_atakovano_hakeramidiletantami_591140

Overview

The NTP Project ntpd version 4.2.7 and pervious versions allow attackers to overflow several buffers in a way that may allow malicious code to be executed. ntp-keygen prior to version 4.2.7p230 also uses a non-cryptographic random number generator when generating symmetric keys. These vulnerabilities affect ntpd acting as a server or client.

Description

The Network Time Protocol (NTP) provides networked systems with a way to synchronize time for various services and applications. The reference implementation produced by the NTP Project (ntp.org) contains several vulnerabilities.CWE-332: Insufficient Entropy in PRNG — CVE-2014-9293 If no authentication key is defined in the ntp.conf file, a cryptographically-weak default key is generated. CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) — CVE-2014-9294 ntp-keygen before 4.2.7p230 uses a non-cryptographic random number generator with a weak seed to generate symmetric keys. CWE-121: Stack Buffer Overflow — CVE-2014-9295 A remote unauthenticated attacker may craft special packets that trigger buffer overflows in the ntpd functionscrypto_recv() (when using autokey authentication), ctl_putdata(), and configure(). The resulting buffer overflows may be exploited to allow arbitrary malicious code to be executed with the privilege of the ntpd process. CWE-389: Error Conditions, Return Values, Status Codes — CVE-2014-9296 A section of code in ntpd handling a rare error is missing a return statement, therefore processing did not stop when the error was encountered. This situation may be exploitable by an attacker. The NTP Project provides more information about these issues in their security advisory. The NTP Project implementation is widely used in operating system distributions and network products. These vulnerabilities affect ntpd acting as a server or client. CERT/CC is not aware of any public exploit of these vulnerabilities at this time. The CVSS score below is based on the buffer overflow vulnerabilities (CVE-2014-9295).

Impact

The buffer overflow vulnerabilities in ntpd may allow a remote unauthenticated attacker to execute arbitrary malicious code with the privilege level of the ntpd process. The weak default key and non-cryptographic random number generator in ntp-keygen may allow an attacker to gain information regarding the integrity checking and authentication encryption schemes.

Solution

Apply an updateThese issues have been addressed in ntp-4.2.8. The update may be downloaded from ntp.org.

Restrict status queriesAs noted in the announcement for ntp-4.2.8: The vulnerabilities listed below can be significantly mitigated by following the BCP of putting restrict default … noquery in the ntp.conf file.  With the exception of: receive(): missing return on error References: Sec 2670 / CVE-2014-9296 / VU#852879 below (which is a limited-risk vulnerability), none of the recent vulnerabilities listed below can be exploited if the source IP is restricted from sending a ‘query’-class packet by your ntp.conf file.

Источник: http://www.kb.cert.org/vuls/id/852879

4 декабря прошел очередной (уже 10-ый) пиринговый форум MSK-IX.

Я был одним из участников данного форума, уже не впервый раз. Как и на других форумах MSK-IX были и интересные доклады и не очень.

Но и в этот раз не обошлось без тем о безопасности сетей и о DDoS. Что меня побудило на написание данной статьи ? Сейчас расскажу.

На данном форуме уже 3 доклада было посвящено данной проблеме, т.е. рост этой проблемы очевиден и чем дальше тем хуже. Я хочу обратить внимание на данную проблему не только тех кто присутствовал на данном мероприятии, но и остальных наших подписчиков.

Все мы сталкивались с проблемой DDoS`а, но далеко не все понимают, что она существует благодаря нам самим. Почему ?

Потому что не все, далеко не все, админы следуют, казалось бы простым, правилам и тем самым они, сами того не понимая, являются соучастниками DDoS атак, т.к. не делают ничего чтобы препятствовать им. Число Amplification атак растет как на дрожжах. Почему ? Да потому что реализация такой атаки проста. Они и далее будет расти, если ВЫ, уважаемый читатель, по прежнему будете бездействовать и рано или поздно это бездействие вернется к вам, как бумеранг.

Доклады (PDF версии докладов, а так же видео доступны тут):

Хорошие манеры или манифест устойчивой маршрутизации

(Докладчик: Андрей Робачевский Internet Society)

DDoS атаки: динамика за 2014 год

(Докладчик: Алексей Семеняка Qrator Labs)

Отражение DDoS-атак: защита CDN-трафика с CloudFlare

(Докладчик: Мартин Леви Cloudflare)

Давайте пройдемся по этим докладам и посмотрим какова ситуация по данной проблеме на текущий день.

Проект MANRS (Mutually Agreed Norms for Routing Security)

• https://www.routingmanifesto.org/
• https://www.manrs.org/

Простые правила:

• Фильтрация BGP: Предотвращение распространения неправильной маршрутизационной информации
• Анти-спуфинг: Предотвращение трафика с подложными IP-адресами
• Содержание контактой и иной иформации в up-to-date: Улучшение информационного обмена и координации между сетевыми операторами в глобальном масштабе

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

Хуже чем что ? Читаем далее.

Посмотрите на рост кол-ва атак:

А вот как вам такая картинка:

Россия даже Китай обогнала по кол-ву ботов…. а теперь задумайтесь насколько велика разница по кол-ву народа в Китае и в России.

Вам не обидно за державу ? Мне обидно.

Теперь посмотрим на такой график:

Кол-во атак, из-за криво настроенной службы NTP, впереди планеты всей…. Хотя настройка службы NTP занимает не более 5 минут.

Смотрим во что все это выливается:

А теперь спросите себя: А вы хотите оказаться жертвой атаки в 400 Гбит/с ? Думаю что ответ будет «НЕТ!».

Ну и следующий вопрос, который стоит задать себе: А что лично Я сделал для того чтобы это остановить ?

Если ответ будет «ничего», то СРОЧНО приступите к тому, чтобы остановить ЭТО в подконтрольных вам сетях.

Для этого много не надо, как минимум:

1. вы не должны выпускать НЕ свои IP-адреса из своей сети
2. ваши DNS сервера не должны позволять рекурсию
3. ваши NTP сервера должны быть настроены и не пропускать MONLIST
4. ваша SNMP служба не имеет дефолтовых community public и private, а так же отвечат на запросы от НЕ ваших хостов
5. если у вас есть BGP клиенты, то убедитесь что у вас есть BGP фильтры на анонсы от ваших клиентов и что они пропускают только префиксы вашего клиента

Что надо делать:

1. На вашем Border`е (пограничный маршрутизатор вашей сети) зафильтровать все пакеты, где SRC IP не является IP-адресом из ваших подсетей.
2. Настроить ваш DNS сервер, чтобы он выполнял рекурсивняе запросы только для IP-адресов из ваших подсетей.
3. Настроить NTP службу.
4. Настроить SNMP службу.
5. Установить фильтры на анонсы подсетей ваших BGP клиентов.

Запрет рекурсии DNS  для bind и разрешение только вашим клиентам

acl "allow-recursion" {
        127.0.0.1;
        10.0.0.0/8;
        172.16.0.0/12;
        192.168.0.0/16;
        XXX.XXX.XXX.XXX/YY;
        ...
};
options {
        ...
        allow-recursion{ allow-recursion; };
        allow-query-cache{ allow-recursion; };
        ...
};

Либо полностью отключить возможность рекурсии, если этот DNS сервер используется только для резолва ваших доменов:

options {
        ... 
       recursion no;
       allow-query-cache{ none; };
       ...
}; 

Настройки для NTP службы

# by default act only as a basic NTP client
restrict -4 default nomodify nopeer noquery notrap
restrict -6 default nomodify nopeer noquery notrap
# allow NTP messages from the loopback address, useful for debugging
restrict 127.0.0.1
restrict -6 ::1
# server(s) we time sync to
server 192.0.2.1
server 2001:db8::1
server time.example.net 

Вот ещё вариант конфига для NTP:

disable monitor
enable auth
# server(s) we time sync to
server 192.36.143.151
restrict 192.36.143.151 noquery notrap
server 195.66.241.10
restrict 195.66.241.10 noquery notrap
server 192.87.106.2
restrict 192.87.106.2 noquery notrap
server 145.238.203.14
restrict 145.238.203.14 noquery notrap

driftfile /var/db/ntp.drift

restrict 127.0.0.1
restrict XXX.XXX.XXX.XXX mask 255.255.YYY.ZZZ nomodify notrap
restrict default ignore

Где XXX.XXX.XXX.XXX это ваша IP-подсеть, а 255.255.YYY.ZZZ её маска.

Настройка SNMP службы

rocommunity MYCOMPANY-RO 127.0.0.1
rocommunity MYCOMPANY-RO XXX.XXX.XXX.XXX
rwcommunity MYCOMPANY-RW 127.0.0.1
rocommunity MYCOMPANY-RO XXX.XXX.XXX.XXX

Где XXX.XXX.XXX.XXX это доверенный хост в вашей сети. Так же вы можете просто запретить фаирволом обращение на порт UDP 161 для всех кроме ваших доверенных хостов.

Так же не стоит забывать о ваших пользователях,если они у вас есть, которые так же имеют реальные IP-адреса и которые в большинстве случаев вообще не понимают «как это работает», а значит они так же могут являться источниками для осуществления DDoS`а.

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

DNS Amplifiers

# dig @ВАШ-IP-АДРЕС +edns=0 +ignore +noadflag com ANY

NTP Amplifiers

# ntpdc -nc monlist ВАШ-IP-АДРЕС

SNMP Amplifiers

# snmpbulkget -v2c -c public ВАШ-IP-АДРЕС 1.3

«Инструменты«, помимо ваших рук, которые вы можете использовать для поиска IP-адресов из вашей AS которые могут быть использованы в кач-ве усилителей атаки:

• QRATOR RADAR MONITOR
• openntpproject.org
• openresolverproject.org

Посетите данные ресурсы, посмотрите что они покажут вам по вашим IP подсетям. Если результат не будет нулевым, то обязательно устраните все проблемы. Если вы этого не сделаете, то кто-то обязательно пострадает от DDoS`а, а вы можете стать следующим.

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

В противном случае данное ЗЛО будет только расти и приумножаться.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)