Ботмрежи

Последен ъпдейт на 4 октомври 2018 в 17:13 ч.

Новооткрит малуер използва различни техники, за да остане незабелязан и да изгради ботмрежа от свързани към интернет устройства. Ботнетът е засечен първо от Веселин Бончев от Националната лаборатория по компютърна вирусология (НЛКВ) към БАН.  Наречен е Torii, тъй като използва Tor мрежата, за да атакува устройства.

Бончев съобщава за ботнета на 20 септември, след като го засича със своя honeypot. Бончев публикува туит за откритието си, а Avast прави последващ анализ на новооткрития ботнет.

My honeypot just caught something substantially new. Spreads via Telnet but not your run-of-the-mill Mirai variant or Monero miner…

First stage is just a few commands that download a rather sophisticated shell script, disguised as a CSS file. (URL is still live.) pic.twitter.com/r5L0I8PC0h

— Vess (@VessOnSecurity) September 19, 2018

Според Avast Torii засега не е използван за DDoS атаки, спам или копаене на криптовалути, показва проучване на компанията за киберсигурност Avast. Това, което го прави значим, е че за разлика от така популярния ботнет Mirai, използва по-сложни техники за заразяване на устройства. Mirai беше открит през август 2016 г. и засягаше различни устройства като домашни рутери и свързани към интернет камери. Заплахата от него стана значително по-голяма, след като кодът на малуера беше публикуван в интернет за свободно сваляне. Това даде възможност лесно да бъде копиран, модифициран и разпространяван.

Ботмрежа от ново ниво

„За разлика от Mirai, QBot  и техните производни, този ботнет се опитва да действа по-скрито и да остане на устройството, след като се инсталира на него. Засега той не прави нещата, които един ботнет обичайно прави – например да осъществява DDoS атаки и да копае криптовалути. Вместо това той притежава богат арсенал от функции за извличане на чувствителна информация и архитектура, способна да изпълнява различни команди и кодове. И всичко това се случва чрез криптирана комуникация“, посочват от Avast.

Според проучването Torii може да засегне голям брой устройства и работи на устройства с различни архитектури на процесора, включително MIPS, ARM, x86, x64, PowerPC, SuperH и други. Предполага се, че малуерът функционира поне от декември 2017 г.

Как протича атаката

Заразяването протича на няколко етапа. В първия етап малуерът открива свързани към интернет устройства и ги тества за слаби потребителски имена и пароли. Когато получи достъп до устройството, Torii се опитва да открие архитектурата на неговия процесор и инсталира пейлоуд. Тъй като има възможност да инсталира пейлоуд за различни и широко използвани процесори, това увеличава значително способността му да засяга голям брой устройства. Инсталирането на пейлоуд става на два етапа и според Avast се използват поне 6 метода, за да се гарантира, че зловредният код ще остане на заразеното устройство.

Другото, което отличава Torii, е, че атаката на устройствата започва от изходни Tor нодове (сървъри, които са част от Tor мрежата). когато се инсталира на едно устройство, малуерът комуникира с командни сървъри чрез криптирана връзка. Анонимизирането помага на ботнета да остане под радара и да не привлича внимание.

„Очевидно е, че Torii е пример за еволюцията на малуера, насочен към интернет на нещата. Неговата сложност е на ниво, каквото не сме виждали досега. След като зарази устройство, Torii изпраща много информация към командния сървър. Освен това. докато има връзка с командния сървър, авторите на атаката могат да стартират зловреден код в заразеното устройство. Това предполага, че Torii може да се превърне в модулна платформа в бъдеще“, коментират от Avast.

Последен ъпдейт на 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:49 ч.