DDoS

На 13 месеца във федерален затвор в САЩ е осъден 22-годишен хакер, за ролята му в създаването на зловреден код на ботнет, използван в големи Distributed Denial of Service (DDoS) атаки. 

Ботнет мрежата Satori е наследник на скандалния зловреден софтуер Mirai, който придобива контрол върху уязвими “IoT” устройства. Самите създатели на Mirai бяха арестувани и осъдени през 2018 г. 

„Киберпрестъпниците зависят от анонимността, но остават видими в очите на правосъдието“, е заявил американският прокурор Шродер. 

[button color=“green“ size=“big“ link=“https://thehackernews.com/2020/06/ddos-botnet-hacker-jailed.html“ target=“true“ nofollow=“false“]Прочетете повече по темата тук[/button]

 

В рубриката Бързи новини подбираме водещи заглавия за вас и споделяме линкове към външни публикации. 

Amazon Web Services (AWS) заяви, че е била засегната от рекордна DDoS атака с обем 2.3 Tbps (терабита в секунда). (Неуспешният) опит за сваляне на облачните услуги е продължил в рамките на три дни през февруари 2020 г.

Използван е методът на отразяване (reflection) на CLDAP, а ударът е бил с 44% по-силен от всичко, което облачният доставчик е виждал преди.

Атаката е най-мащабната до момента в историята на интернет и почти два пъти по-голяма от предишния лидер –  DDoS атаката с 1.3 Tbps, която свали GitHub през 2018 г.

[button color=“green“ size=“big“ link=“https://www.cbronline.com/news/record-ddos-attack-aws“ target=“true“ nofollow=“false“]Прочетете повече по темата тук[/button]

 

В рубриката Бързи новини подбираме водещи заглавия за вас и споделяме линкове към външни публикации. 

Група от израелски студенти доказа нова уязвимост, която може да доведе до пълен интернет апокалипсис. Тя засяга DNS – един от протоколите, считани за гръбнака на съвременните мрежи.

Подходът за атака е наречен NXNSAttack: Recursive DNS Inefficiencies and Vulnerabilities и е насочен към рекурсивни и авторитетни DNS сървъри. Резултатът е DDoS с коефициенти на увеличение над 1600 пъти.

Засегнати са както ISC BIND (CVE-2020-8616), така и някои от най-големите публични DNS услуги:

Public DNS recursive resolver (IP)	Max # of delegations = F/2	Victim cost Cpkt/v	PAF
CloudFlare (1.1.1.1)	24	96	48x
Comodo Secure (8.26.56.26)	140	870	435x
DNS.Watch (84.200.69.80)	135	972	486x
Dyn (216.146.35.35)	50	408	204x
FreeDNS (37.235.1.174)	50	100	50x
Google (8.8.8.8)	15	60	30x
Hurricane (74.82.42.42)	50	98	49x
Level3 (209.244.0.3)	135	546	273x
Norton ConnectSafe (199.85.126.10)	140	1138	569x
OpenDNS (208.67.222.222)	50	64	32x
Quad9 (9.9.9.9)	100	830	415x
SafeDNS (195.46.39.39)	135	548	274x
Ultra (156.154.71.1)	100	810	405x
Verisign (64.6.64.6)	50	404	202x

В зависимост от фактора на увеличение (PAF), жертвата, подложена на NXNSAttack, би получила многократно повече пакети от изпратените от нападателите. Цифрите са наистина впечатляващи, като се има предвид, че досега известни методи за такъв тип DNS увеличителни и отразителни атаки са с доста по-ниски стойности.

Основните съставки на новата атака са:

• лекотата, с която може да се притежава или контролира авторитетен DNS сървър;
• използването на несъществуващи имена на домейни;
• допълнителна резервираност в DNS структурата, за да се постигне отказоустойчивост и бързо време за реакция.

Важно е да отбележим, че някои от възможните средства за защита, като например различни ограничители (rate limits), са нож с две остриета, което позволява на атакуващия да доведе до отказ от услугата за легитимни потребители.

Зловещи ефекти

От февруари насам откривателите на NXNSAttack са започнали работа със съответните разработчици на DNS софтуер, CDN и DNS доставчици, за да им помогнат да отстранят тази заплаха и да смекчат ефекта от евентуални атаки след публикуване на своето проучване.

Дори и след месеци усилена колаборация и пачване, най-вероятно са останали кътчета от интернет, които са все още уязвими и могат да бъдат експлоатирани. Това би довело до инциденти, подобни на тези причинени от Mirai botnet, макар и с далеч по-малък на брой зомбирани устройства.

Уязвимостта се корени в това, как DNS рекурсивни сървъри обслужват Name Server насочващи отговори (NS referral response), без да имат IP лепнат (glue) запис.

Как работи атаката

Графично представяне на самата атака:

И разменените съобщения:

За да разберем как работи NXNSAttack, трябва да вземем под внимание йерархичната структура на DNS в интернет. Когато браузър се обърне към домейн като google.com, той пита DNS сървър, за да открие IP адреса на този домейн, число като 64.233.191.255.

Обикновено на тези заявки се отговаря от DNS рекурсивни (резолюционни) сървъри, контролирани от доставчици на интернет и DNS услуги. Но ако тези рекурсивни DNS сървъри не разполагат с точния IP адрес под ръка, те пренасочват заявката към „авторитетен“ сървър, свързан с конкретни домейни, за отговор.

NXNSAttack злоупотребява с доверената комуникации между тези различни слоеве на DNS йерархията. Атаката има за „реквизит“ не само достъп до колекция от персонални компютри и/или други IoT устройства (ботнет), но и създаване на DNS сървъри за домейн, който бихме нарекли „attacker.com“. (Изследователите твърдят, че всеки може да си купи домейн и да си настрои DNS сървър само за няколко долара).

След това нападателят изпраща поредица заявки от ботовете за домейна, който контролира. Или по-точно – вълна от заявки за фалшиви поддомейни като 123.attacker.com, 456.attacker.com и т.н., използвайки низове от произволни числа, за да променя постоянно заявките за поддомейни.

Опитите за посещения на тези недействителни домейни ще задействат обръщения към рекурсивният DNS сървър (примерно този на интернет доставчика), който от своя страна ще изпрати заявката към авторитетен сървър – в случая, DNS сървърът под контрола на атакуващия. Вместо само да предостави IP адрес, този авторитетен сървър ще съобщи на рекурсивният (resolver) DNS сървър, че не знае местоположението на исканите поддомейни, като ще го насочи да поиска друг авторитетен DNS сървър, прехвърляйки заявката към домейна на жертва по избор на нападателя.

Откривателите на тази уязвимост са установили, че насочването на заявки за един несъществуващ поддомейн (123.attacker.com) към стотици несъществуващи поддомейни, принадлежащи на жертвата (asd.victim.com, 4321.victim.com и тн…), би могло да позволи на хакер да претовари не само DNS сървърите на интернет доставчиците, като ги подмами да изпратят повече заявки, отколкото сървърите биха могли да обработят (потенциално да спрат и всичките им услуги, както се случи при атаката на Mirai срещу Dyn), но също да „свалят“ авторитетните DNS сървъри на жертвата, следователно целия домейн victim.com ще остане offline за света.

Жертвата вероятно ще открие, че един злонамерен DNS сървър стои зад атаката и ще спре да отговаря на искания от attacker.com. Но Шафир от университета в Тел Авив изтъква, че нападателите могат да използват няколко домейна, за да променят атаката и да затруднят защитата. „Можете да имате десетки подобни домейни и да ги сменяте на всеки няколко минути“, казва Шафир – „Много е лесно.“

Повече от един вариант

В друг вариант на NXNSAttack, хакер може дори да насочи своите действия към несъществуващи домейни от най-високо ниво (TLD) като „.fake“, за да атакува така наречените root сървъри, които отговарят за домейни от най-високо ниво – .com и .gov.

Въпреки че тези сървъри обикновено са проектирани да разполагат с много голяма честотна лента, изследователите казват, че биха могли да използват много фалшиви домейни, използвайки фалшиви поддомейни от първата версия на тяхната атака, потенциално увеличавайки всяка заявка повече от хиляда пъти. Резултатът е можело да бъде катастрофален за целият интернет:

„Когато се опитате да атакувате един от root сървърите, атаката става много по-разрушителна“, казва Шафир. „Не успяхме да покажем (докажем), че root сървъри могат да бъдат изцяло претоварени, защото са много мощни, но атаката има огромен фактор на усилване (PAF), а това са най-важните активи на световната мрежа. Части от интернет изобщо няма да работят в този най-лош случай.“

Ако всичко до тук ви се струва познато (deja vu), не сте сгрешили – подобна уязвимост, която би могла да доведе до сравними атаки и резултати, е била тайно отстранена през 2008 година. Препоръчвам да изгледате видеото от статията HACKER HISTORY: HOW DAN KAMINSKY ALMOST BROKE THE INTERNET

„От моя гледна точка съм просто в екстаз, че подобно сътрудничество, което получих през 2008 г., все още се случва през 2020 г.“, казва Камински. „Интернет не е нещо, което би оцеляло, ако не се правеха цялостни подобрения, всеки път когато някой подпали нещо.“

В заключение – интернет е много „крехка“ екосистема, като градивните и компоненти (DNS, BGP и други) са били проектирани колкото да работят. За великите умове, създали интернет, не е било възможно да предвидят мащабите и значението на своите творения, следователно не са обърнали достатъчно внимание на въпроса – „Какво ще стане, ако …. ?“

Последен ъпдейт на 28 юни 2018 в 11:49 ч.

Похватите за амплификация и отразяване (amplification and reflection) са едни от най-често използваните при изпълнение на DDoS атаки. Благодарение на настройките си по подразбиране и/или „лоши“ конфигурации, протоколите и услугите като DNS, NTP, SSDP и Memcache се превръщат в опустошителни вектори за атака. В сравнение с традиционните методи за изпълнение на DDoS атаки, а именно създаване на многобройна botnet мрежа от IoT и мобилни устройства, каквито са Mirai, Hajime и WireX, вече споменатите услуги предоставят възможност за достигане на далеч по-обемни (~2Tbps) атаки с много по-малък брой уязвими сървъри. Как? Използваният транспортен протокол (UDP) е идеален за целта, като фактора на амплификация достига до 50 000, в зависимост от приложението:

UDP-based Amplification Attacks

Protocol	Bandwidth Amplification Factor
Memcache	50000
NTP	556.9
CharGen	358.8
DNS	up to 179 [48]
QOTD	140.3
Quake Network Protocol	63.9
BitTorrent	4.0 – 54.3 [49]
SSDP	30.8
Kad	16.3
SNMPv2	6.3
Steam Protocol	5.5
NetBIOS	3.8

Източник: Wikipedia

За scrubbing услуги, предоставяни от големите доставчици като Google, CloudFlare, Akamai и Imperva, не представлява проблем да се справят с атаки от такъв тип. Обема на зловредния трафик не е важен, защото изходния порт (source порта) в хедърите на амплифицираните пакети следва предсказуем модел, примерно филтрацията на пакети с изходен порт 53 при DNS атака е стандартна мярка.

Вече не може да разчитаме на това 

Именно от Imperva оповестиха откритията си относно иновативния метод за маскиране на традиционни DDoS атаки. Наскоро те са противодействали на SSDP амплифицирана атака, при която са забелязали пакети с нестандартен начален порт – нещо, за което досега се смяташе, че едва ли е възможно, камо ли някой да е готов да се защитава от такава атака.

На база първоначална хипотеза, Imperva успяват да създадат Proof-of-Concept за изпълнение на замаскирана DDoS атака, като използват UPnP (Universal Plug and Play) експлойт.

UPnP е протокол с дълго минало и множество проблеми касаещи сигурността

За незапознатите, UPnP е мрежов протокол опериращ върху UDP на порт 1900 за откриване на други устройства и случайно избран TCP порт за управление. Протокола има широко приложение в IoT устройствата (компютри, принтери, рутери и други), като служи за взаимното им откриване в LAN мрежата.

Какви са евентуалните проблеми с UPnP:

1. В някои имплементации настройките по подразбиране предоставят отдалечен достъп през WAN;
2. Липсва оторизиращ механизъм, което в комбинация с първата точка влошава положението сериозно;
3. Съществуват уязвимости предоставящи възможност за отдалечено изпълнение на код.

Исторически погледнато, първото разглеждане на слабости в UPnP е през 2001 с откриването на buffer overflow exploit. След това през 2006 е публикувана статия с интересното име  – „Universal Plug and Play: Dead Simple or Simply Deadly“. В нея са описани методи за отдалечена пренастройка на устройства поддържащи UPnP чрез XML SOAP API съобщения.

От Rapid7 и Akamai също отделят време да изследват възможностите за експлоатиране на тази технология. През 2015 година по време на DEF CON 23, Ricky Lawshae изнася интересна презентация на тема UPnP и SOAP съобщения. В нея се отделя специално внимание на факта, че е възможно отдалечено изпълнение на AddPortMapping команди, които от своя страна управляват логиката за пренасочване на портове.

Маскиране на DDoS атака чрез UPnP пренасочване на портове

В описаната от Imperva SSDP атака, анализаторите са открили, че около 12% от пакетите идват от неочакван изходен порт, а не от UDP/1900. След оценка на няколко възможни опции, те успяват да пресъздадат атака, при която независимо типа на амплифицираният протокол, изходните портовете биват замаскирани.

Как би изглеждала евентуална подготовката за стартиране на DNS маскирана DDoS атака?

 

1. Откриване на общодостъпни UPnP устройства
   С помощта на IoT търсачката shodan.io, резултатът за българското пространството

За сравнение, в световен мащаб и към момента на публикуване на тази статия, точният брой е 1,365,553. Това по никакъв начин не означава, че всички тези устройства са уязвими, но намирането им измежду множеството не представлява проблем за мотивираните престъпници.

2. Ето така изглежда XML който UPnP сервира

3. Промяна на правилата за пренасочване на портове
   В rootDesc.xml са описани всички предоставяни услуги и свързани устройства, където по секцията <SCPDURL> могат да се видят действията, които устройството ще приеме отдалечено. В началото на списъка виждаме вече споменатото действие – AddPortMapping, което позволява конфигурирането на пренасочващи правила.
   
   Използвайки схемата на XML файла, може да бъде създаден SOAP запис, който да пренасочи всички UDP пакети от порт 1337 към публичен DNS сървър (3.3.3.3) на порт UDP/53. За повечето от нас, това пренасочване няма смисъл и дори очакваме да не сработи! При port forwarding правилата се прави връзка от публични (външни) към частни (вътрешни) IP адреси Source и обратното, а не се прави proxy заявка от външно към друго външно IP. Всъщност, много малко рутери имплементират такъв тип проверка, при който удостоверяват, че предоставеното вътрешно IP наистина е вътрешно.

 

4. Стартиране на замаскираната атака
   С направеното до тук, атаката следва следният сценарий:
   1. Уязвимият рутер получава DNS заявка на UDP/1337;
   2. Заявката е пренасочена към DNS сървър с краен (destination) порт UDP/53, благодарение на правилото за пренасочване;
   3. DNS сървъра отговаря на заявката като със sourse port UDP/53;
   4. Рутера предава отговора на DNS сървъра към първоначалният заявител, но не и преди да смени source порта обратно към UDP/1337.

В случая престъпникът (1.1.1.1) се представя (spoof) от името на жертвата – така усилените и замаскирани пакети достигат до крайната точка (4.4.4.4)

Описаната техника важи за всички протоколи и услуги, които така или иначе се използват за DDoS атаки, но с нея вече не може да се разчита на филтрация на база source IP и port. Така стандартните защитни механизми стават ненадеждни, като най-вероятна технология за защита от такива атаки е Deep Packet Inspection (DPI), която от своя страна изисква много повече ресурси и е предизвикателство да обработва in-line трафик без значителна инвестиция.

Истинското решение на проблема е такива устройства да не бъдат публично достъпни и да филтрираме достъпа до тях. Mерки, които често биват пренебрегвани, понеже реално не предоставят реални ползи за техните ползватели.

Бъдете винаги в крак с новините от света на информационната сигурност – станете наши фенове във Facebook. 

Последен ъпдейт на 28 юни 2018 в 13:15 ч.

На 28 февруари станахме свидетели на най-мащабната DDoS атака в историята на интернет. Добре познатия на всички сайт за хостване на проекти на разработчици GitHub попадна от лошата ѝ страна и принудително бе спрян, макар и за кратко.

Обемът на атаката е измерен на 1.35 Tbps (терабита в секунда), постигнати чрез средно 126.9 милиона пакети в секунда.

За атаката не е използвана ботмрежа, а много по-прост и лесен за експлоатация метод – използването на отговори от Memcached сървъри.

Нова механика за блокиране

Най-интересното в случая е самата механика зад атаката. Тя няма нужда от дистрибуцията на зловреден код до стотици хиляди устройства. Вместо това, авторите ѝ се възползват от лошо подсигурени и публично достъпни Memcached сървъри – машини, които оптимизират работата на бази данни като запомнят най-често достъпваната информация в RAM паметта си. Освен това, те имат и друга особеност – заявка от едва няколко байта може да получи отговор в размер на стотици килобайти.

По този начин, всеки атакуващ може да изпрати малък брой заявки към различни Memcached сървъри и да замени IP-то на изпращача с това на фирмените ви сървъри. Така вие ще получите огромен обем данни, усилен от неправилно внедрената UDP функционалност на Memcached услугата. Това дава и името на този тип атака – amplification attack (атака чрез усилване).

Защо е разумно да очакваме още такива инциденти

Въпреки че amplification атаките не са нищо ново, тази използва хиляди неправилно конфигурирани сървъри, за да изпълни целите си.

„Предимството“ на този вектор е, че е достъпен – няма мрежи за поддръжка и няма нужда от заразата на стотици хиляди машини, за да се достигне достатъчно голям обем от трафик. Като много други, той разчита на грешките в човешкия фактор.

Не е ясно на колко по-мащабни атаки ще станем свидетели докато се изчисти проблемът с публично достъпни memcached сървъри. Заради това е нужно да се действа сега – като скролирате до края на статията.

Съвети за потребители, системни администратори и разработчици

IP spoofing-a все още е разрешен от голяма част от интернет доставчиците, а филтрирането на фалшифициран трафик на потребителско ниво е почти непосилно за повечето. Ако използвате Memcached е нужно да станете част от решението преди да станете част от проблема:

Препоръките са дадени от CloudFlare в публикацията им относно инцидента. 

Потребители:

• Обновете софтуера си – последната версия на решението забранява UDP комуникация поначало.
• Ако използвате стара версия, можете да използвате –listen 127.0.0.1 при старт, за да накарате сървъра да „слуша“ изцяло локално или –U 0, за да забраните UDP изцяло.
• Използвайте следните команди, за да тествате дали сървърът ви е уязвим – ако получите празен отговор, значи всичко е наред:

$ echo -en „\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n“ | nc -q1 -u 127.0.0.1 11211

STAT pid 21357

STAT uptime 41557034

STAT time 1519734962

Системни администратори:

• Поставете сървъра зад защитна стена и не позволявайте UDP или TCP достъп до него.
• Използвайте описаните горе инструкции, за да забраните приемането на UDP пакети и да тествате за уязвимост. За да тествате TCP, можете да използвате nmap.

Разработчици:

• Ограничете използването на UDP комуникация в софтуера си, особено незащитена чрез оторизация такава. Има редица примери за това защо не трябва да го правите – DNS, NTP, Chargen, SSDP, а сега и Memcached. Ако използвате UDP, то е задължително да връщате по-малки като размер отговори на потребителските заявки.

Бъдете винаги в крак с новините от света на информационната сигурност – станете наши фенове във Facebook. 

Последен ъпдейт на 28 юни 2018 в 13:49 ч.