DDoS

На 16 март 2021 г. DDoS атака блокира сървърите на над 15 медицински лаборатории в България.

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

Лабораторните резултати представляват чувствителни лични данни, поставени под специален режим на закрила според правилата на Общия регламент за защита на личните данни (GDPR).

Дали нападателите са получили достъп до чувствителна информация на лабораториите – не знаем.

Това, което знаем е, че който и да е бизнес може да предотврати спирането на работния си процес и да си спести значителни главоболия, ако приложи минимални превантивни мерки.

За целта е нужно:

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

Разбира се, и двете страни могат да се допитат до външни специалисти по киберсигурност, при нужда.

Какви вреди може да причини една DDoS атака

DDoS (Distributed Danial-of-service) е насочена към един от трите основни стълбове на киберсигурността – наличността. Нападателите, които и да са те и каквато и да е целта им, изпращат голям брой заявки от различни източници (Distributed DoS) към вашия сайт или сървър, докато той „откаже“ и изпадне в невъзможност да предоставя на потребителите стандартните си услуги.

В последно време обаче все по-често се наблюдава тенденцията хакерите да изнудват жертвите на DDoS и да изискват откуп (ransome), за да спрат атаката. Някои организации се съгласяват, тъй като ефектът от самата атака е разрушителен – услугата може да остане неналична с часове и дни, което може да бъде пагубно за един бизнес.

DDoS се прилага на различни нива:

• Може да запуши цялата ви мрежова честотна лента (bandwith) и по този начин да спре достъпа на всичките ви потребители до ресурса, който им предоставяте (волюметрична DDoS атака – Volumetric bandwidth attack)
• Да атакува конкретно ваше устройство – уеб сървър, защитна стена, рутер или друг актив от инфраструктурата ви (атака за изчерпване на ресурса – Resource exhaustion attack)
• Да е насочена към протоколите от L7 на OSI модела – HTTP, DNS, FTP и т.н. (атака на ниво приложен слой – Application-layer attack)

Прочетете още: ФБР предупреждава за опустошителни DDoS атаки, използващи уязвимости в мрежови протоколи

Препоръки към администраторите

Полезно по темата: Cloudflare започва да изпраща нотификации за DDoS атаки

• Защитната стена на изхода на мрежата ви би могла да филтрира определен размер на DDoS атака. Това би ограничило т.нар. “attack surface”, а именно публично достъпните услуги и протоколи, които са видими в интернет. Един такъв протокол е ICMP (пинг), който често се използва при DDoS атаки.
• Наличието на WAF (Web Application Firewall) също би спряло определени DDoS атаки, от L7 например.
• За ограничаването на едни от най-големите DDoS атаки препоръчваме използването на CDN (content delivery network). Техният мрежови капацитет е в рамките на 59 Tbps и може да се противопостави на атакуващите, които често разполагат с пъти по-голяма честотна лента (bandwith) от вас.

Краят на август беляза няколко успешни DDoS атаки, разкрити от компанията за киберсигурност Akamai.

Сред засегнатите са някои от най-големите доставчици на финансови услуги в света – MoneyGram, YesBank India, PayPal и още доста други. Те са получили искане за откуп в Bitcoin, за да бъдат прекратени атаките.

Подобни посегателства, наричани „DDoS изнудвания“ или „DDoS-за-Bitcoin“, са наблюдавани за първи път през лятото на 2016 г., но не набраха особена популярност оттогава.

Бандата, която върлува в момента обаче, изглежда е от най-сериозните и дългогодишни играчи (още от 2016 г.). И се активизира през август, когато проведе сложни DDoS атаки, в някои случаи достигнали максимална стойност от почти 200 Gb/sec.

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

Например, в случая на Новозеландската фондова борса (NZX) групата е атакувала доставчика на хостинг услуги на борсата (Spark), което е засегнало и останалите му клиенти.

Освен с пандемията от COVID-19, 2020 може да остане в историята като годината с най-висок отчетен брой DDoS атаки. Една от причините: нова техника за амплификация (буквално: раздуване) на обема на DDoS атаките и респективно: пораженията, които могат да нанесат те. Методът е улеснен от уязвимости в мрежови протоколи.

Малко статистика

По данни на NETSCOUT (компания, която предоставя статистика за DDoS активността в реално време), DDoS атаките растат със заплашителни темпове от началото на 2020 г. През април компанията публикува пост със заглавие „Най-черният месец в цифри„. Тогава бяха отчетени около 864 хил. атаки за периода 11 март – 11 април, най-високата бройка, засичана някога. За сравнение, предходния пик беше през ноември 2019 г. – около 751 хил. атаки.

Месец по-късно, за периода 11 април – 11 май са отчетени още повече – 929 хил. атаки.  А причината не е само в COVID-19.

Как се „раздува“ DDoS?

Методът е прост. Към даден уязвим сървър се изпращат заявки. Нападателите обаче подправят (spoof) източника на всяка заявка – така отговорът за грешка от страна на сървъра ще се върне не към реалния източник на заявката, а към потенциалната жертва.

Резултатът: претоварване на мрежата/устройствата на жертвата.

Причините:

• размерът на отговора е в пъти по-голям от самите заявки. За пример: да позвъните в ресторант, да поръчате от всичко и да кажете: обадете се на съседа, за да продиктувате поръчката. Съседът ви може да слуша дълго обяснението на ресторанта, което ще блокира телефона му.
• обемът на фалшивите заявки може да е огромен. Представете си ботмрежа от хиляди компютри, изпращаща заявки към даден сървър.

Колко опустошителни всъщност са тези атаки може да прочетете тук.

Кои са засегнатите протоколи

Нападателите могат да се възползват от  широк набор протоколи за такъв тип атака – например DNS, SSDP и NTP. Но в този случай атаките са по-интересни и използват протоколи като: Apple Remote Desktop’s (ARD), Apple Remote Management Service (ARMS), Web Service Dynamic Discovery (WS-DD) и Constrained Application Protocol (CoAP). Обикновено организациите пренебрегват заплахите от тези протоколи и точно затова те са толкова опасни.

Протоколът CoAP позволява свързването на IoT устройства и комуникацията помежду им. Функционира с методи, подобни на GET и PUT  при HTTP. За разлика от HTTP обаче, CoAP е UDP базиран, което го прави податлив на атаки с подмяна на IP адреси и амплификация на пакети.

Атакуващият изпраща малък UDP пакет до IoT устройството, което в зависимост от зададените параметри в заявката, изпраща като отговор пакет с по-големи размери. В контекста на DDoS атаките, таргетиращи този протокол, съотношението между големината на заявката и отговора, се нарича коефициент на увеличение. При извършване на DDoS атака чрез амплификация и отразяване (amplification and reflection) средният коефициент на увеличение за CoAP е 34.

Другият често експлоатиран протокол е WS-DD, той се използва за локализиране на IoT устройства в локалната мрежа. За разлика от CoAP, той е и UDP И TCP базиран, но атаките работят по подобен начин, възползвайки се от уязвимостите в UDP протокола, като изпращат пакет с подправен IP адрес.  Според сигнала на ФБР, нападателите експлоатиращи този протокол, достигат атаки с размери по-големи от 350 гигабита в секунда.

Конкретно срещу Apple

Зачестиха и злоупотребите с ARD. Това е приложение за отдалечен достъп при Apple компютрите, което се използва от университети и предприятия за управление на голям брой Apple продукти. Когато ARD е активиран, услугата ARMS, извършваща комуникацията, слуша на порт 3283 (UDP) за входящи команди от отдалечени устройства на Apple. Миналия октомври атакуващите, експлоатирали ARMS при извършване на DDoS усилващи атаки, са успяли да достигнат коефициент на усилване „35.5:1“.

ФБР също така споменава за уязвимост в Jenkins – платформа с отворен код, използвана за автоматизиране на задачи. Тази уязвимост също може да бъде използвана за DDoS атаки, въпреки че все още не е известна злоупотреба с нея. И все пак, рискът съществува, като в този случай трафика на атаката може да се увеличи до 100 пъти.

Какво да направите, за да се защитите

Обикновено стратегията за защита при тези видове атаки би изисквала деактивиране на  протоколите, с които се злоупотребява. Деактивирането на ARMS, WS-DD и CoAP би довело до загуба на функционалността, производителността и цялостната свързаност на бизнеса. Малко вероятно е производителите на устройства да деактивират тези функции, защото това би повлияло на качеството на предлаганите услуги за потребителя.

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

Сигналът на ФБР идва след няколко мащабни DDoS атаки от тази година. Amazon Web Services съобщи, че е ударен от DDoS атака с 2.3 терабита в секунда (293 млн. пакета в секунда) през февруари, най-голямата DDoS атака регистрирана някога. През юни Akamai блокира DDoS атака, генерираща 809 млн. пакета в секунда срещу голяма европейска банка, и друга атака с 1.44 терабита за секунда (достигаща 385 млн. пакети в секунда) срещу уеб хостинг доставчик. Cloudflare също се бори с атака през юни, която достигна максималния брой от 754 млн. пакета в секунда.

По материала работиха: Кристиян Цанков и Стелиана Козарева 

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

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

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

Прочетете повече по темата тук

 

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

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

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

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

Прочетете повече по темата тук

 

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

Група от израелски студенти доказа нова уязвимост, която може да доведе до пълен интернет апокалипсис. Тя засяга 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 в 01: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 в 01:49 ч.