Топ новини

Все по-често в сферата на информационната сигурност започва да се среща израза “DoH” : DNS-over-HTTPS.

Създаден за сигурност

Какво представлява DoH ? Накратко – по дизайн, DNS протоколът изпраща заявките в чист вид (plaintext). Така, ако злонамерено лице прихване DNS заявката, ще може да прочете нейното съдържание и оттам да предприеме други зловредни действия. Това, разбира се, представлява сериозен риск.

Вместо да изпрати DNS заявката на порт 53, DoH криптира заявките като ги „маскира“ като WEB трафик на порт 443 (HTTPS). По-този начин DNS трафика не се различава от стандартния HTTPS трафик и съответно съдържанието му остава нечетимо за трета страна (ISP доставчик, зловредно лице по средата на комуникацията – MiTM и т.н.).

През Февруари Firefox разреши DoH да бъде включен по подразбиране за потребителите си в САЩ. За повече информация тук.

Не само позитиви

Както всяко нещо, така и DoH има своите предимства и недостатъци. Предимствата са, че предотвратява някои опасни DNS атаки и може да се каже че повишава поверителността (единствено DoH доставчика ще има видимост върху DNS заявките).

Дотук добре, на пръв поглед всичко е наред и не би трябвало да има някакъв проблем. От гледна точка на специалистите по киберсигурност обаче, това представлява сериозна пречка за засичане на зловредна дейност в мрежата. Причината: голяма част от зловредните кодове в наши дни използва именно DNS, за да извършват своите зловредни дейности (обръщане към  CnC сървър, свързване и сваляне на зловредни файлове и т.н.).

Системи за сигурност като IDS на практика стават неизползваеми за следене на DNS трафик, защото за тях това ще бъде стандартен криптиран трафик изпратен на порт 443.

Хакерската групировка от Иран Oilrig е една от първите, които се възползваха от това „предимство“ на DoH, имплементирайки го в своите атаки.

Иноватори

По време на уеб семинар Висенте Диас, анализатор на зловреден софтуер за производителят на антивирусни програми Kaspersky спомена, че използването на DoH за зловредни дейности е започнало през май тази година. Тогава групата OilRig е добавила нов инструмент към своя хакерски арсенал и е започнала да използва нова програма, наречена DNSExfiltrator като част от инструментариума си за проникване в хакнатите мрежи.

Както подсказва името му, инструментът може да прехвърля информация между две точки, използвайки класически DNS заявки, но може да използва и по-новия DoH протокол.

Според Диас, Oilrig, известни също като APT34, използват DNSExfiltrator за събиране на откраднатата информация от вътрешната мрежа и след това я изпращат към управляван от тях сървър.

Причината за използването на DoH като канал за ексфилтрация е именно възможността да изпълняват зловредни действия без да бъдат забелязани от наличните инструменти за сигурност.

OILRIG и DNS като метод на ексфилтрация

Фактът, че Oilrig бяха една от първите APT групи, които внедриха DoH, също не е изненада.

В исторически план групата и преди се е занимавала с DNS-базирани техники за ексфилтрация. Преди да премине към използването на инструмента с отворен код DNSExfiltrator, групата използваше специално написан инструмент поне от 2018 г., наречен DNSpionage. Това се твърди в няколко доклада на Talos, NSFOCUS и Palo Alto Networks.

Отново през май от Kaspersky споменаха, че Oilrig ексфилтрира данни, използвайки DoH, към домейни свързани с COVID-19.

През същия месец Reuters съобщиха за таргетирана фишинг кампания, организирана от неидентифицирани ирански хакери. Тя е била насочена към персонала на фармацевтичния гигант Gilead. Случайно или не, по това време организацията обяви, че започва работа върху варианти за лечение на COVID-19. Не е ясно обаче дали става въпрос за едни и същи инциденти.

Различни доклади свързват повечето ирански APT групи с Ислямският революционен гвардейски корпус или накратко „Пасдаран“, което е най-високото военно образувание на Иран.

Вместо заключение

Ако сте краен потребител, определено използването на DoH би повишило вашата сигурност и поверителност, особено ако го имплементирате не само на ниво приложение (напр. браузър, операционна система и т.н.), а за цялата мрежа. От Cloudflare са изготвили наръчник на тази тема, който може да прочетете тук.

Не по същия начин стоят нещата, ако вие сте човекът, който отговаря за сигурността на цялата инфраструктура, било то в ролята на IT администратор, специалист по мрежова и информационна сигурност и т.н. Помислете добре дали искате да имплементирате DoH във вашата мрежа.

Да, от една страна ще получите „благинките“ описани по-горе, но заслужава ли си цената? А тя не е изобщо малка за преглъщане – видимостта върху DNS заявките на цялата мрежа. Все още наличните инструменти за сигурност не могат да предоставят 100% видимост на DoH заявките, което, като се вземе предвид нарастващата популярност на този протокол, определено ще се промени в бъдеще.

От SANS са написали подробен доклад на тема „Методи за увеличаване на видимостта при използването на DoH” , който много добре описва ситуацията към текущия момент.

Невнимателен системен администратор, хванал се на LinkedIn фишинг, е станал причина за успешна атака срещу фирма, свързана с криптовалути (точното име и дейност не се споменава в анализа на F-Secure). Автори на тактиката за пробива са Lazarus Group (на тази организация се приписва глобалната атака, при която през 2017 г. криптовируса WannaCry за броени дни порази стотици хиляди компютри в над 150 държави по света).

Механика на атаката

Хакерите са получили достъпа до системите на компанията-жертва чрез обява за работа в LinkedIn. Тя е изпратена до личния профил на системен администратор в професионалната социална мрежа. Обявата е била от името на блокчейн компания, търсеща нов сисадмин с набор от умения, точно като на получателя за съобщението.

Обявата е включвала Microsoft Word документ, уж „защитен“ съгласно действащите в ЕС правила на GDPR. Отварянето на документа е активирало макрос, който е свалил зловреден код на устройството на потребителя и оттам се е разпространил върху цялата компания.

За обирането на портфейлите с криптовалута на жертвата е използвана модифицирана версия на Mimikatz

Една организация е толкова уязвима, колкото уязвимо е най-слабото й звено. В информационната сигурност най-уязвими са хората и хакерите много добре разбират това.

А сега, накъде, Lazarus Group?

Според анализаторите от F-Secure, групата ще продължи атаките си към организации, работещи с криптовалута, докато има изгода от това. Не се изключва възможността хаковете да разширят обхвата си и към самите доставчици – „копачите“ на криптовалута.

За мистериозната Lazarus Group се предполага, че стои зад атаки срещу банки от Югоизточна Азия и Европа през последните няколко години (сред най-значителните е тази срещу Централната банка на Бангладеш, при която бяха източени 81 млн. USD през 2016 г.). Явно, че свързваната със Северна Корея групировка диверсифицира дейността и портфейла си.

Позицията на LinkedIn

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

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

За да подкрепят този неуморен стремеж към иновации, те често разчитат на трети страни да осигурят необходимия хардуер и софтуер за продуктите си. Едно от най-разпространените такива решения са DSP чиповете (Digital Signal Processor).

Какво представлява DSP технологията на човешки език?

DSP (Digital Signal Processor) е система на чип, състояща се от хардуер и софтуер, проектирана да оптимизира функционирането и употребата на смартфоните, като част от отговорностите ѝ са:

• Зареждане – управлява функцията „бързо зареждане“
• Мултимедия и визуализация – например Augmented Reality (технология, която добавя виртуални елементи към реалния свят, използвайки камерата на смартфона – използва се при филтрите на Snapchat, в играта Pockemon Go и други).
• Обработка на изображения и видео с високо качество
• Изчисления, свързани с невронни мрежи (лицево разпознаване)
• Различни аудио функции – например стрийм на аудио, видео и гласови данни.

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

Прекалено хубаво, за да е истина?

До тук DSP чиповете създават представата, че са отговорни за супер силите на съвременните смартфони, но на каква цена идва това? От икономическа гледна точка, позволяват на производителите да предоставят на потребителя най-иновативните и мощни решения. Погледнато от технически аспект обаче, те представляват допълнително звено, подлежащо на атака.

Тук идва “тънкият момент” – тъй като дизайнът, кодът и като цяло технологията зад DSP чиповете може да бъде изключително сложна, производителите на крайния продукт могат да унаследят уязвимости, за които никой не подозира. Може да си ги представим като черните кутии в самолетите – никой не знае какво точно има вътре, включително и какви уязвимости.

От Сheck Point провеждат проучване по темата, наречено неслучайно “Ахил”, в което извършват обширен преглед на сигурността на DSP чиповете на един от водещите производители – Qualcomm Technologies. Чиповете (Snapdragon) на Qualcomm са разпространени в устройства, съставляващи над 40% от пазара на мобилни телефони, включително Google, Samsung, LG, Xiaomi, OnePlus и други.

Над 400 сегмента уязвим код

В тествания DSP чип са открити повече от 400 сегмента уязвим код и тези уязвимости биха могли да окажат следното въздействие върху потребителите:

• Нападателите могат да превърнат телефона в перфектния шпиониращ инструмент, без да се изисква никакво взаимодействие с потребителя – информацията, която може да бъде извлечена от телефона, включва снимки, видеоклипове, запис на разговори, данни от микрофона в реално време, данни за местоположението и т.н.
• Атакуващите имат възможността да спрат цялостното функциониране на смартфона – отказвайки достъп на потребителя до данните на телефона (включително снимки, видеоклипове, контакти и т.н.) се извършва целенасочена атака тип отказ-от-услуга (denial-of-service).
• Зловреден софтуер или друг злонамерен код могат напълно да прикрият дейностите си и да не могат да бъдат отстранени.

Check Point не дава технически подробности за уязвимостите и как те могат да бъдат експлоатирани, докато не станат достъпни за крайните потребители пачове, с които да могат да се защитят. Уязвимостите на DSP чиповете са номерирани – CVE-2020-11201, CVE-2020-11202, CVE-2020-11206, CVE-2020-11207, CVE-2020-11208 и CVE-2020-11209.

Вектори на атака и опасностите за крайният потребител

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

Оттам нападателите могат да следят местоположението, да подслушват аудио в реално време, да достъпват и свалят снимки и видеоклипове от устройството.

Как да се предпазим?

В изявление служителите на Qualcomm заявяват, че работят усърдно по разрешаването на проблема и предоставянето на подходящи смекчаващи мерки, като засега няма доказателства уязвимостта да е реално експлоатирана от хакери. Също така насърчават крайните потребители да актуализират своите устройства веднага щом пачовете станат налични и да инсталират приложения само от надеждни места като например Google Play Store. Междувременно, от Check Point препоръчват организациите да защитят корпоративните данни на мобилните си устройства, като използват решения за мобилна сигурност.

Glupteba е зловреден код от тип зомби или бот. Дотук нищо необичайно – той се управлява чрез команди от престъпниците (оператори на command & control инфраструктура).

Интересното при него е, че освен да бъде инструмент за отдалечен контрол , Gluptebа включва в себе си следните “екстри”:

• Rootkit. Glupteba разполага с разновидни драйвери за ядрото (kernel) на Windows. Rootkits на ниво kernel са по-рядко срещани, защото са по-сложни за писане и често привличат внимание към себе си. Въпреки това, ако се имплантират успешно, rootkits могат да помогнат на заплахите да „летят под радара“ и по този начин да прикрият злонамерени файлове и процеси от наличните инструменти за информационна сигурност.
• Изключване на наличната антивирусна защита. Glupteba има модул, който прави всичко възможно да изключи Windows Defender и след това редовно проверява, за да се увери, че не се е включил отново. Той също така по списък търси и терминира други инструменти за сигурност, включително 3rd party антивирусен софтуер и програми за мониторинг на системата. Целта – пълно неведение от страна на потребителя и администратора за случващото се върху заразените системи.
• Червей. Glupteba използва два различни варианта на ETERNALBLUE, за да се саморазпространи в мрежата и до всяка машина, която е достъпна и уязвима.
• Инструмент за атакуване на рутери. Glupteba включва в себе си различни експлойти за компрометиране на домашни и малки корпоративни рутери , така машината на жертвата става отправна точка за атакуване на хостове в други мрежови сегменти и интернет. Той използва една от тези добре известни атаки за хакване на уязвими рутери, преобразувайки ги в мрежови прокси сървъри, които след това да използват като нови отправни точки за бъдещи атаки. Този подход представя злощастната жертва да изглежда като нападател и да се показва като привиден източник на киберпрестъпна дейност.
• Крадене на информация от браузъра. Glupteba краде информация от Chrome, Firefox, Yandex и Opera – и я изпраща към престъпниците. Файловете на браузъра често съдържат чувствителна информация като история за достъпваните URL адреси, бисквитки за удостоверяване, логин информация и дори пароли, които не могат да бъдат достъпни чрез код изпълняван в браузъра, като например JavaScript. По този начин хакерите заобикалят всички защити на браузъра, като го атакуват отвън, там където няма контрол.
• Копачка за криптовалути – Наред с всички останали зловредни дейности, Glupteba може да действа като секретно средство за управление на два различни инструмента за копаене на криптовалути. Т.нар. криптомайнъри са законни, ако ги използвате с изричното разрешение на лицето, което плаща сметките за ток (защото криптомайнърите консумират значително количество електроенергия – за справка, наскоро в България бяха разкрити ферми за криптовалути, откраднали ток за 2.5 млн. лв. за 6 месеца). По този начин вие плащате сметките за ток, а печалбите отиват единствено и само при хакерите.

Но това не е всичко

Най-интересната част, описана в репорта, е именно начина на комуникация на Glupteba с управляващите го хакери: блокчейн технологията Bitcoin. Както вероятно сте запознати, зомбитата или ботовете не са много полезни, ако не могат да направят т.нар. „call home” (обратна връзка към контролирания от хакерите сървър), за да получат следващата си вълна от инструкции.

Подробно описание и списък от вградени злонамерени команди, които хакерите могат да задействат, например update-data и upload-file, може да откриете в доклада на Sophos. Но също така, както при повечето ботове са включени и общи команди за изтегляне и стартиране на нов зловреден софтуер.

Това означава, че дори да знаете всички трикове , на които е способен Glupteba, не можете да се предвиди какъв друг зловреден код може да бъде изтеглен и стартиран. Сървърите за управление и контрол (command & control) на заразените машини (ботове), по-известни като C2 сървъри или CnC, могат да бъдат открити и блокирани във всеки един момент, така че зомби-зловредният софтуер често съдържа в себе си резервен метод за свързване отново към CnC инфраструктурата, който в повечето случаи изглежда като “невинен” източник на обновления (updates).

За да се превключи от един CnC съврър към други, принципно не се изискват много усилия, необходимо е само да се изпратят новите домейни и/или IP адреси. Престъпниците са доста креативни и използват услуги като Twitter, Reddit и Pastebin, както и други публично достъпни услуги за съхранение на съобщения.

Време е за блокчейн!

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

Всъщност, една транзакция на Bitcoin може да бъде не само финансова, защото може да съдържа поле наречено “RETURN” или по-известно като “OP_RETURN”, което на практика е коментар с дължина до 80 знака.

Нека започнем със списък на всички хешове за транзакции на биткойн (леко редактирани), свързани с един от биткойн портфейлите, използвани като скрит източник на съобщения от Glupteba.

Показаният тук номер на портфейла е извлечен от зловредния софтуер от SophosLabs.

Командния ред съдържащ bx по-долу е популярен и полезен инструмент за изследване на Bitcoin блокчейн-а:

$ bx fetch-history 15y7...qNHXRtu5wzBpXdY5mT4RZNC6 | awk '$1 == "hash" { print $2 }'
dfef43552fc953ff14ca7b7bb....b79e8409b5638d4f83b1c5cec0abc3d
98987c05277c97b06edfc030c....07e74334c203075ec27b44b3cc458bf
717da8bea87d02ef62b1806cf....7e01f0267718f0351f9ae1592e02703
20b37b655133491b94a8021ab....0266d15331a14caf10570b6623a86e4
fa9cd0622535cf6c9ff449510....c5d526d5794d9d98ba5d6469a97be2c
0d83cbc74a12a9f130fcead23....d5d56cf769c6c0a4cf1cebbf9e97e4a
a7fb3bb04b82922923e8359f8....3db69bd2863ec88b98f9c69a37212ad
52ee10617c1fc3e25922b146a....7daefdc3c3d5421b0387a737e46b396
f29cbbb96de80dbc7e5236c98....3da6f8118bb356f537ce0317f7ab10c
6a3a720ab97511528309fbf64....f37bc25d95d45d3408540174daad786
8bf7acc56aab4b87d73a85b46....1486f0a764fd0a5f13e2d79e0a14625
3bd54c0832cc411f5299064e4....c11ab05c1a4aff62fa323c068e88945
1e1c0249bb22d1fcfb596e4fb....df7ab3bf627e25a2fe9530eb3dce476
51899ffeadf5d0d605d5122c3....5b82baa15a4fa6b203abf59731c158f
8a7c43d0bbf01cdf3bb28de48....6e339a063251fce30cb83ae50c2096a
55e8fe62bcc41ec465c3f1f28....f5d82443a15a30d88fefc3f55ad2f29

Ако извлечем подробностите за всяка от тези транзакции, можем да видим кои включват OP_RETURN данни.

$ bx fetch-tx 55e8fe62bcc41ec465c3f1f28....f5d82443a15a30d88fefc3f55ad2f29
{
  hash 98987c05277c97b06...1ce207e74334c203075ec27b44b3cc458bf
  inputs
  {
    input
    {
[ . . . . . . . . . ] 
    output
    {
      script "return [18fe788a52d7aa57808d801d0f8f7cd39e1a...9f986b877befce0c2f558f0c1a9844833ac702cb3eba6e]"
[ . . . . . . . . . ]     
      value 0
    }
  }
[ . . . . . . . . . ]

Байтовете данни OP_RETURN, показани по-горе, са тайното съобщение.

За да го декриптирате ви е необходим 256-битов ключ за дешифриране AES, който е кодиран в Glupteba (можете да намерите ключовете в подробния репорт, изготвен от SophosLabs) и трябва да знаете, че данните, върнати в blockchain, се състоят от:

First 12 bytes  = AES-256-GCM initialisation vector
Last 16 bytes  = AES-256-GCM authentication tag
Bytes in between = Encrypted message (bytes from 0f8f7cd3.. to ..877befce)

Декриптирайте данните от блоковия код, за да обърнете криптирането AES-256-GCM и ще разкриете скритото съобщение.

Този вид „скриване на информация точно пред очите“ често се нарича стеганография.

Примерни псевдокодове, за да придобиете представа :

> cipher = newcipher('AES-256-GCM')
> cipher.key = d8727a0e..d66503cf        // extracted by SophosLabs
> cipher.iv = 18fe788a52d7aa57808d801d     // GCM mode needs an IV
> cipher.tag = 0c2f558f0c1a9844833ac702cb3eba6e // GCM mode needs a message hash
> plain = cipher:decrypt(0f8f7cd39e1a...9f986b877befce)
> print('secret message is: ',plain)
secret message is: venoco___ol.com        // see report for full IoC list
// this is a new C&C server to move to

По този начин Glupteba прикрива имената на използваните от него CnC сървъри.

Колко е опасен в действителност ?

Лошата новина е, че благодарение на многото и разнообразни модули за самозащита, Glupteba разполага със също толкова трикове, чрез които да прикрие своята активност от системите за сигурност.

От друга страна, тази сложност прави зловредния софтуер по-малко надежден и по ирония на съдбата по-предразположен към задействане на аларми в системи за следене за зловредна дейност и аномалии. Всъщност, някои трикове за програмиране на ниско ниво, които използва, включително rootkits на ниво Windows kernel (ядро), не само не работят на последните версии на Windows, но и често привличат вниманието към себе си от начина, по който се държат, което понякога води дори и до срив на системата – BSOD.

Също така, Glupteba разчита на множество експлойти, за които има излезли патчове от преди месеци или дори години – включително за атаките, които използва срещу рутерите – така че една патчната системата е много по-малко вероятно да се зарази.

И накрая, основният механизъм за заразяване, който е известен към този момент за разпорастренение на Glupteba в една мрежа (ако приемем, че машините имат нужните патчове за предотвратяване на ETERNALBLUE) е използване на т.нар. „кракнат софтуер“.

Например:

Вместо да инсталира и активира Adobe Illustrator, този крак инсталира Glupteba.

Как да се предпазим :

• Инсталирайте наличните патчове за сигурност СЕГА, проверявайте РЕДОВНО за новоизлезли такива – Това включва патчове за вашата операционна система, приложенията, които използвате и всички устройства в мрежата като рутери, IoT, сървъри и т.н.
• Използвайте добър антивирусен софтуер с вграден модул за уеб филтриране. Голяма част от злонамерения софтуер, включително ботовете, се сваля на няколко части от Интернет. Дори и да бъдете ударени от т.нар. „първи етап“ на атаката от зловреден софтуер, все още можете да неутрализирате хакерите, ако спрете свалянето на същинската част от кода (payload).
• Стойте далеч от пиратски/нелегален софтуер. Да приемем, че човекът, който е готов да открадне софтуер като Adobe Illustrator и да раздава инструменти за неговото „безплатно“ ползване (кракване), също е готов да приема пари от злонамерени лица, за да имплантира злонамерен софтуер в същия този „безплатно кракнат“ софтуер.

Освен с пандемията от 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 млн. пакета в секунда.

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

Забравени лендинг страници (landing pages), които редица компании използват, могат да бъдат използвани като средство за атака. Как? Като се „отвлекат“ DNS записите им. Но да започнем отначало.

Какво е landing страница? Обикновено, става въпрос за сайтове, създадени с определена еднократна цел: например, за маркетингови кампании и промоции, игри и т.н. След като сайтът изпълни предназначението си – например, след като кампанията или играта приключи, обикновено бива премахнат или забравен. Именно те са най-честите жертви на този вид атака според Зак Едуардс (Zach Edwards), американски специалист по киберсигурност, който пръв повдигна въпроса в Twitter.

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

За да се улесни използването на такъв тип уеб сайтове с кратък живот, доставчиците на хостинг услуги предлагат автоматични DNS записи. Например – temp-1234.hostco.example.  Така клиентът има възможност да създаде CNAME запис за своят истински домейн и да насочи потребителите си към временният сайт:

julyoffer.example.com: alias (CNAME record) -> temp-1234.hostco.example (cache for 5 mins)

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

Произволно търсене?

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

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

В случаите, проследявани от Едуардс, изглежда, че мошениците са използвали  закрити поддомейни, съдържащи легитимни DNS записи, за да генерират надеждни URL адреси за кампании, разпространяващи измами и зловреден софтуер.

Атаките са известни като „отвличане на DNS записи“ (DNS hijacks) – хакерите всъщност не превземат самия сайт или уеб сървър, а просто променят „указателите в интернет“, които насочват към него.

Всичко тръгва от DNS протокола

Както вероятно знаете, DNS (Domain Name System) е глобалната база данни, която автоматично превръща име на домейн, към който браузърът се е обърнал, от удобното за потребителя google.com например, в съответния компютърен IP номер (в случая 64.233.191.255), необходим за изпращане и получаване на мрежови пакети в интернет.

Резултатът от преобразуването се запазва в кешa на DNS-сървъра, така че той да може да продължи да го използва за известно време, без да се налага да търси отново всяко изображение или скрипт, нужни при преглед на съответната уеб страница. Периодът, за който информацията в DNS кеша се счита за актуална, се нарича „време-на-живот“ или TTL (Time-To-Live).

Повечето доставчици на cloud услуги поддържат своите DNS кеш TTL доста кратки, колкото да помогнат на услугите им да се адаптират по-бързо към промени в натоварването на мрежата.

Изглежда обаче, че за хакерите това кратко време е достатъчно, за да „отвлекат“ сайта ви, чрез подмяна на DNS записи и пренасочване на потребителите ви, където пожелаят.

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

Какво да направите?

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

Около 72 часа по-късно и след безброй слухове, извънредната ситуация в Garmin изглежда овладяна, а услугите на компанията отново функционират нормално. А въпросите около случилото се тепърва започват.

В този текст няма да коментираме слухове или спекулации – защото такива не липсват – а по-скоро ще извлечем част от уроците от случилото се с Garmin. Съвсем накратко, какво знаем:

• 23 юли, около обед източно-американско време. Атаката срещу Garmin започва. Редица услуги на компанията, сред които Garmin Connect, garmin.com и колцентровете на компанията спират принудително работа
• Малко след началото на проблемите, Garmin публикува официално съобщение в Twitter акаунта си, но не цитира причината за спирането на услугите си
• Редица публикации в онлайн медии твърдят, че атаката срещу компанията е дело на Evil Corp, които са успели да заразят Garmin с криптовирус, заключили са ключови за компанията файлове и системи и са поискали 10 млн. USD откуп за възстановяването им. За източници се посочват служители на компанията, вътрешни мемота от ИТ екипите ѝ, включително и скрийншоти, за които се твърди, че са от засегнатите машини
• Официалната позиция на компанията е, че не са източени лични данни на клиенти
• Възстановяването на услугите на компанията отне няколко дни,

Какви са част от научените уроци:

1. Няма твърде голяма или малка компания, която да не е интересна за киберпрестъпниците
2. Криптовирусите далеч не са преминали пика си – дори обратното. Само за предпоследната седмица на юли са засечени няколко атаки срещу мащабни организации като Garmin. Още през април ИНТЕРПОЛ предупреди за ръст в ransomware атаките. А новите тактики за разпространение не спират. Например, създаването на специална виртуална машина, с цел маскиране на заразата.
3. Бекъпът е задължителен. И не само, защото според Trend Micro 33% от засегнатите организации никога не получават файловете си обратно – а защото не се знае дали това възстановяване няма да е твърде късно

 

 

Последен ъпдейт на 26 юли 2020 в 17:07 ч.

В средата на юли редица профили на известни личности в Twitter осъмнаха с фалшиви съобщения, предлагащи да удвоят парите на последователите си в биткойни. Общо 130 профила станаха жертва на хакерите, а сред тях са имена като Бил Гейтс, Джеф Безос, Илън Мъск, Джо Байдън, Apple и други.

В продължаващото разследване, обаче, излизат интересни факти – като например, че са достъпени и личните съобщения на 36 от жертвите на хака. Една от тях е холандски депутат, чието име остава неназовано. От Twitter твърдят, че няма други компрометирани бивши или настоящи представители на държавни администрации (като визира именно Обама и Байдън).

Знае се също така, че хакерите са успели да свалят копия на целите профили на 8 от жертвите чрез функцията Your Twitter Data.

Първоначално съмненията бяха за използване на корумпиран служител, който е предоставил достъп на хакерите до вътрешен инструмент на компанията. Впоследствие стана ясно, че не е имало вътрешно съдействие, а хакерите са успели да пробият защитата на административен инструмент на Twitter по неизвестни до момента начини.

Това накара част от анализаторите по киберсигурност да определят пробива като „безпрецедентен“ по мащаба си.

„Интервю“, разказващо историята на хакерите, пробили Twitter, прочетете в The New York Time тук.

SIGRed (CVE-2020-1350). Толкова ли е опасна колкото си мислим и какви са щетите, които може да нанесе?

И преди сме чували за уязвимости с подобен “wormable” характер. Благодарение на тях може да се разпространява зловреден код, без да се изискват никакви действия от потребителя. Именно това е причината рискът от тях да е огромен. Примери за подобно поведение са EternalBlue, използвана за атаката от криптовируса WannaCry и BlueKeep в протокола за отдалечен десктоп (RDP) на Windows.

Но SIGRed е малко по-различна. На 16 юли 2020 г. Агенцията за кибер- и инфраструктурна сигурност на САЩ (CISA) обяви извънредна директива, в която се определя уязвимостта CVE-2020-1350 за сериозен риск за всички Windows сървъри. А от държавната администрация на страната бе изискано в рамките на 24 часа да елиминират проблема и да пачнат своите системи.

Какво точно представлява тази уязвимост SIGRed?

SIGRed или CVE-2020-1350 е уязвимост в Windows сървъри, които имат стартирана DNS сървър услуга.

Открита е от Check Point и е оценена с перфектните 10 CVSS точки. Причината за тази оценка: разпространява се на принципа на червеите и трудно може да бъде овладяна, ако не се вземат мерки навреме. На практика, тя би могла да позволи на атакуващите да добият администраторски права и да внедрят зловреден код.

Добрата новина за повечето потребители, е че уязвимостта засяга само Windows Server, тъй като пропускът се намира в Windows DNS сървър кода, а не в клиентския. Лошата новина е, че засяга всички Windows сървърни дистрибуции, произведени от Microsoft в последните 17 години. Така, ако мрежата, към която е свързан потребителят, разчита на Windows DNS сървър, то крайният потребител е изложен на риск само защото е част от тази мрежа.

За да разберем какво прави SIGRed, трябва да имаме поне основна представа за DNS. Най-просто казано DNS е телефонния указател на Интернет – глобална база данни с информация за имената на домейни и IP адреси.  Ако потребител иска да достъпи www.freedomonline.bg, DNS се грижи да предостави съответстващия IP адрес. По-подробно обяснение как работи DNS услугата вижте тук, но засега е достатъчно да знаем, че:

• DNS използва TCP/UDP на порт 53
• Размера на едно DNS съобщение (заявка или отговор) може да бъде максимално 512 байта (по UDP) или 65,535 байта (по TCP).
• DNS е йерархичен. Това означава, че когато сървърът не знае отговора на заявка, която получава, заявката се препраща към DNS сървър над него в йерархията.

Участниците в DNS комуникацията заемат различни роли, като основните са клиент и  сървър. Клиентите изпращат заявки, а сървърите изпращат обратно отговорите. Интересното е, че уязвимостта се намира в тази част на кода, която чака за отговор.

И сега ще си помислите, че след като чака за отговор, би трябвало грешката в кода да е от клиентската страна, тъй като сървърът изпраща отговорите, а не ги чака. Но, както казахме по-рано, структурата на DNS сървърите е йерархична. Тоест, ако сървърът не знае домейна, който търсим, той пита по-висшестоящите от него, за да получи тази информация. В този случай, рекурсивният DNS сървър заема ролята на клиент и точно тогава се проявява тази уязвимост.

Как точно работи?

Ще се опитаме да обясним принципа на работа на SIGRed на достъпен език, но по-подробни технически детайли може да бъдат прочетени в проучването на Check Point.

Формата, в който тече DNS трафика (RFC 1035), датира още от 80-те години на миналия век, когато не е имало толкова ресурси, колкото днес. Затова се е целяло служебните съобщения да бъдат в максимално компресиран формат с минимален размер. Идеята при DNS се базирала на предположението, че всички заявки и отговори биха се побрали в 512 байта (без 12 байта за служебна информация).

Ако се налагало обмен на по-дълги съобщения, те били предавани по такъв начин, че първите два байта да обозначат дължината на очакваните данни, последвани от самите данни. Най-голямото число, което може да се запише в 2 байта (16 бита) е 2¹⁶ -1, което е 0xFFFF в 16-тична бройна система или 65 535 в 10-тична. Именно това е максималният размер за DNS отговор. Това е едното важно нещо, което трябва да имаме предвид за по-нататък.

Вторият съществен момент са различните видове DNS отговори, още наричани RR (Resource Records), които се записват като TYPE с помощта на 16 битови числа. Пример за RR е “A record” – този запис съхранява IPv4 адреса със съответстващия му домейн. Друг вид запис отговаря за SIG заявката. Както вече споменахме DNS е проектиран преди доста години, когато сигурността на данните в Интернет не е била с такъв приоритет, за разлика от днес.

Чак след години е създаден DNSSEC –  е разширение на стандартния протокол, специално предназначено за защита на DNS трафика. Идеята на DNSSEC е да гарантира легитимността на DNS съобщенията. Повече за принципа на DNSSEC тук.

Тази допълнителна защита става посредством SIG заявки – записът в нея доказва, че DNS отговорите не са подменени и идват от доверен източник. По-късно RFC 3755 налага използването на RRSIG вместо SIG. RRSIG записите имат сходен формат с тези на SIG, но следват различни правила за форматиране на данните в тях. И както става обикновено след замяната на нещо старо с ново – оригиналният код, който отговарял за SIG заявките продължава да съществува някъде там, неизползван и податлив на уязвимости.

Уязвимостта съществува поради начина, по който Windows DNS сървърът анализира входящите заявки, както и как се обработват препратени заявки. По-конкретно, изпращането на DNS отговор със SIG запис над 64KB може да доведе до контролиран heap-based buffer overflow. По този начин може да се “срине” сървъра или в най-лошия случай да се изпълни отдaлечено злонамерен код (RCE).

Как по точно става това?

Първо трябва да знаем, че:

• Най-голямото количество данни, което е възможно да се появи в отговор на DNS, е 65 535 байта.
• Следователно максималният обем памет, която ще е необходима за съхраняването на тези данни при прочитането им, е 65 535 байта.
• Това означава че unsigned short int (16 -битово число) е с достатъчно голяма дължина да изчисли дадената заявка

За съжаление, SIG записите включват поле NAME, което може да бъде предадено в компресирана форма, като се използва алгоритъмът на рудиментарното компресиране на DNS. Тоест NAME низ, който може да е до 255 байта на големина, след компресирането може да заеме само два байта в DNS отговора.

SIG записите включват и поле данни за цифровия подпис, което може да бъде с произволна дължина, така че е лесно да се конструира отговор, в който общото количество данни да е точно на границата от 65 535 байта. Кодът използва 16-битова целочислена стойност, когато изчислява колко памет ще му е необходима след декомпресията.

В такъв случай имаме 65 535 байта сурови данни от отговора плюс (да речем) още 40 байта, които са допълнително внедрени от хакера използвайки хитро изработено компресирано поле NAME. Програмата ще изчисли 65 535 + 40, но понеже това ще прескочи лимита на integer типа и ще изчисли и задели само 39 байта памет за SIG записа, след това ще опита да прехвърли 65,535 + 40 байта в буфера на паметта, като по този начин ще  доведе до heap-based buffer overflow.

Как да оправим този проблем?

Като се има предвид, че Microsoft нарича това „wormable vulnerability“, е препоръчително администраторите да  приложат съответните пачове в максимално кратък период.

В случай, че ъпдейт не е възможен от Microsoft са предоставили workaround с промяна на регистър.

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

Дори и без официална статистика, можем да твърдим едно: фишингът е може би най-популярният метод за кибератаки в света. А покрай епидемията с COVID-19, той доби още по-голямо разпространение, заради работата от вкъщи и по-трудното налагане на контрол на служителите извън офисите им.

Статистиката е плашеща. Но е факт.

Фишингът в числа

• 65% от хакерските групи използват spear phishing като вектор за първоначална инфекция, а 96% от фишинг атаките се извършват с цел събиране на информация за потенциалните жертви (Symantec)
• 48% от злонамерените файлове, които са прикачени към фишинг имейлите, са .pdf, .doc, .txt – най-често срещаните файлове при работа (Symantec).
• 64% от организациите по света са претърпели фишинг атака през 2018 г. (Check Point Research)
• 94% от малуера през 2018 г. е бил разпространен чрез имейли (Verizon)
• 29% от малуера се разпространява посредством използване на откраднати потребителски имена и пароли. 33% от използваните за пробив акаунти са били разпространени в социалните медии (Verizon)
• фишинг атаките са се увеличили с 600% от началото на 2020 г., след разпространението на COVID-19 (ID Agent; KnowBe4 – KnowBe4 е всъщност организацията която прави това изследване
• Google блокират над 18 млн. злонамерени имейли с тема COVID-19 всеки ден (Google Search Paper)

Причината за тази популярност

Истината е, че фишинг атаките стават все по-добри, целенасочени и трудни за разпознаване. Атакуващите не ги интересува кои сме ние и за какво се борим. За тях крайната цел почти винаги са личните ни данни или парите, които евентуално могат да изкарат чрез някой криптовирус.

Ако се оставим да бъдем уязвими, това единствено означава, че предоставяме на киберпрестъпниците уязвимост, от която да се възползват. А ние се превръщаме в т.нар. low hanging fruit или казано на български: в лесна мишена.

Как може да се предпазим от фишинг атака?

Начините са два и те се допълват взаимно:

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

Образовайте се непрекъснато, за да знаете какво целят, как изглеждат и как да разпознавате дори и най-изпипаните фишинг атаки. Защото изследване на Kroll доказва, че 90% от пробивите в киберзащитата на бизнеса се дължат на човешки грешки.

А образованието на потребителите определено куца. Един пример (валиден не само за България): Според проучване на Proofpoint, между 34% и 53% от потребителите в различните възрастови групи, не могат правилно да отговорят на въпроса какво е фишинг. А между 45% и 62% не знаят какво е ransomware. Може би най-странното в случая е, че колкото по-млада е аудиторията, толкова по-малко запозната е тя.

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

С две думи: три пъти мислете, един път кликайте. Каквото и да се твърди в имейла, който изглежда като истински.