zero-day

Zero-day или 0-day (oh day) – “нулев ден” на български – е клас уязвимости (vulnerability) или методи за атака (exploit). Използването на този термин стартира през 90-те години на миналият век в warez BBS средите.

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

Определението Х-day, където Х е брой дни – 30, 60 и т.н., се е използвало за да се отбележи колко време е необходимо, за да се изготви пиратска версия (крак) за даден софтуер, след първоначалното му публикуване. Най-търсен и елитен е бил пиратският софтуер, маркиран със 0-day етикет, понеже официално не е бил публикуван никъде и най-вероятно за набавянето му е била хакната компанията, която го разработва.

0-day днес – какво се е променило

В наши дни терминът има съвсем друго значение – характеризира клас уязвимости (слабост/недостатък/пропуск), открити от независими субекти (изследователи в областта на информационната сигурност) преди собственика/разработчика на съответния софтуер/хардуер.

Интерпретацията на “0” може да бъде доста разновидна, но двете най-точни определения са:

• 0 дни за подготовка от страна на защитаващата страна, за да се предпази от атаките на недоброжелатели
• 0 дни, за да се изготви fix/patch от страна на производителя/разработчика на засегнатият софтуер/хардуер

И в двата случая можем да преведем 0-day като „никакво време”.

0-day уязвимости и 0-day атаки

0-day може да бъде както уязвимост, така и експлойт/вектор за атака. Когато става дума за 0-day уязвимост, то тя може да бъде теоретична или много трудна за експлоатиране, да има определени условия/изисквания, за да бъде успешна атака и т.н.

0-day атаки/експлойти, от друга страна, са много „по-страшни“ и изискват спешни действия за справяне с тях. Не забравяйте, че някой вече е намерил съответната уязвимост, разучил я е и успешно осъществява атаки „in the wild“ (в реални условия срещу реални жертви).

Още малко теория

Може да срещнете, макар и доста рядко, терминът Forever-day vulnerability. Това означава, че откритият 0-day няма да бъде поправен от разработчика/вендора. Причините може да са, че продуктът вече не се поддържа (End-of-Life) или разработчикът няма интерес да поправи пропуските.

В такава ситуация имате две възможности:

• Да потърсите алтернативен продукт (софтуер/хардуер), който не ви излага на риск
• Да приложите заобиколен начин (workaround) за смекчаване/отстраняване на уязвимостта

Времевата линия при откриването на 0-day

Дефинирането и точното описание на 0-day уязвимост или експлойт е доста трудно. Повече детайли можете да откриете в блог поста Like Nailing Jelly to the Wall: Difficulties in Defining “Zero-Day Exploit”.

Кой, как и защо търси 0-day уязвимости

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

В зависимост от целта обаче, можем да разделим субектите, занимаващи се със 0-day уязвимости и/или експлойти, в следните категории:

• Добронамерени изследователи (security researchers)

Независими или работещи за дадена компания, тези професионалисти търсят 0-day уязвимости за да ги докладват на производителите/вендорите.

Процесът по докладване се нарича “responsible disclosure” или “coordinated disclosure”. Случва се изследователите да не могат да осъществят контакт, да не срещнат съдействие или дори да бъдат заплашени със съд от страна на производителя.

При такива обстоятелства, изследователите извършват Full Disclosre, т.е. правят своето откритие публично достояние и то без да спестяват детайли. Неписано правило е, че ако 90 дни след Responsible Disclosure, вендорът не е взел мерки и не е публикувал patch, адресиращ уязвимостта, то изследователят има право да сподели своето откритие, без това да се счита за неморално.

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

• Самите производители

Една част от 0-day уязвимостите биват откривани от разработчика на съответния продукт/услуга и биват отстранявани без да е необходимо да бъдат публично оповестявани.

Когато съществуват съмнения, че тези уязвимости са били експлоатирани „in the wild“, вендорите би трябвало да следват добрите практики и да направят Full Disclosure. Такъв пример е 0-day атаките срещу Sophos XG NGFW през пролетта на 2020 г.

• Криминални организации и злонамерени хакери

Те имат същите професионални умения като добронамерените изследователи, но често, финансово мотивирани, се “крият в сенките” и опитват да се възползват максимално от своите открития.

• Шпионски, военни и спонсорирани от държавата организации (Advanced Persistent Threats – APT)

Някои от вас ще си помислят, че се шегувам и ще кажат: “Този е гледал твърде много филми за агент 007 и прекарва твърде много време в разнищването на конспирации!”.

Тези, които имат задълбочен опит в сферата на киберсигурността ще потвърдят, че именно тези организации са най-големият “производител” на 0-day експлойти!

Няма как да сте забравили за NotPetya и WannaCry! А помните ли, че EternalBlue експлойтите, използвани в тези червеи (worms), са всъщност 0-days изтекли от NSA (No Such Agency?!).

Ще освежа паметта ви с The “Shadow Brokers” Story и със скорошните атаки, експлоатиращи 0-days в Exchange сървъри.

На най-недоверчивите препоръчвам The Perfect Weapon, Zero Days, Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon, DARKNET DIARIES EP 29: STUXNET

Zero-day по света

Наскоро FireEye публикува изследване, включващо географското разпределение на 0-day уязвимости/атаки през последните няколко години:

Game Theory: Why System Security Is Like Poker, Not Chess предлага една по-различна перспектива по темата.

Бизнесът със 0-days

Като оставим настрана шпионските игри, 0-days са чист бизнес, който цели генериране на финансова печалба или имидж. Ето кои са едни от най-големите играчи:

• Zerodium: Компания, която търгува със 0-day уязвимости и създава експлойти. Цената на някои 0-days е внушителна (2,5 млн. USD). Компанията често е обект на критика, поради липсата на прозрачност относно клиентите ѝ.
• ZeroDayInitiative (ZDI): Платформа, финансирана от Trend Micro. Напълно прозрачна относно процеса и възнагражденията (макар и доста по-малки от тези на Zerodium), предлагани в замяна на 0-day уязвимости и експлойти. ZDI са организатор на Pwn2Own състезанието, за което сме писали няколко пъти. Горещо препоръчвам DARKNET DIARIES EP 82: MASTER OF PWN
• NSO Group и Cellbrite: Kомпании, фокусирани върху предлагането на продукти и услуги, използващи 0-day експлойти. Често са обект на критика, защото търгуват с държави, управлявани чрез диктатура. NSO Group стана най-известна след разкритията на канадската CitizenLab: HIDE AND SEEK Tracking NSO Group’s Pegasus Spyware to Operations in 45 Countries
• Google Project Zero: Мисията им е да направят откриването и експлоатацията на 0-day уязвимости от недоброжелатели по-трудни, съответно да подобрят значително безопасността и сигурността на Интернет за всички. Публикуват и поддържат таблицата 0-day “In the Wild”. Наскоро откриха 11 0-day уязвимости, използвани в изключително сложна атака срещу Windows, Android и iOS потребители (за сравнение – Stuxnet използва 4).
• MSRC – Microsoft Security Response Center и TALOS са подорганизации съответно на Microsoft и Cisco. Те също се занимават с откриването и отстраняването на уязвимости, независимо от производителя.

Как да се предпазите

Макар да няма “универсална” защита и стратегия срещу 0-day експлойти, спазването на добра работна хигиена е задължителна:

• Следете новините, за да сте информирани за новооткритите 0-day уязвимост или експлойти
• Поддържайте системите актуални (up-to-date)
• Минимизирайте повърхността за атака (attack surface)
• Следвайте всички добри практики в сферата на киберсигурността

След като стана известно, че хакери са използвали zero-day уязвимости, за да компрометират Microsoft Exchange сървъри, ежедневно научаваме за нови експлоатации.

Предупрежденията на изследователите по киберсигурност, че хакът ще отвори вратата за атаки с криптовируси, се сбъдна: Засечен е нов рансъмуер, наречен „DearCry“, който атакува Microsoft Exchange с експлойти на ProxyLogon.

Атаката се разпространява

Microsoft observed a new family of human operated ransomware attack customers – detected as Ransom:Win32/DoejoCrypt.A. Human operated ransomware attacks are utilizing the Microsoft Exchange vulnerabilities to exploit customers. #DearCry @MsftSecIntel

— Phillip Misner (@phillip_misner) March 12, 2021

До момента киберспециалистите са открили жертви на криптовируса в САЩ, Люксембург, Индонезия, Ирландия, Индия и Германия.

Детекторите на доставчиците на антивирусен софтуер са засекли множество разновидности на DearCry:

• Ransomware/Win.DoejoCrypt [AhnLab]
• Win32/Filecoder.DearCry.A [ESET]
• Trojan-Ransom.DearCry.B [GDATA]
• Ransom-DearCry [McAfee]
• Ransom:Win32/DoejoCrypt.A [Microsoft]
• DearCry [Rising]
• Ransom/W32.DearCry [TACHYON]
• Win32.DEARCRY [TrendMicro]
• Ransomware.Dearcry [Webroot]

Как DearCry криптира компютрите

Проба от рансъмуера, анализирана от BleepingComputer, включва следния PDB път: C:\Users\john\Documents\Visual Studio 2008\Projects\EncryptFile -svcV2\Release\EncryptFile.exe.pdb

Когато бъде стартиран, DearCry създава Windows услуга с име „msupdate“, която започва да криптира файлове със следните разширения:

Криптираните файлове получават допълнително разширение .CRYPT:

Рансъмуерът използва AES-256 за криптиране на файловете и публичен ключ RSA-2048 за криптиране на AES. Също така добавя „DEARCRY!“ низ в началото на всеки заключен файл:

След като приключи с криптирането на компютъра, рансъмуерът създава бележка за откуп с име „readme.txt“ на работния плот на Windows:

Пачнахте ли Microsoft Exchange сървърите си

Фирмата за киберсигурност Palo Alto Networks съобщава, че десетки хиляди Microsoft Exchange сървъри са ъпдейтнати в рамките на няколко дни. Съществуват обаче около 80 хил. по-стари сървъра, които не могат директно да приложат последните актуализации на защитата.

Прочетете още: Над 61% от всички Microsoft Exchange Server не са пачнати срещу активно експлоатирана уязвимост

Организациите, които използват Exchange, трябва да имат едно на ум, че може да са били компрометирани, преди да закърпят системите си. Все пак знаем, че хакерите са експлоатирали zero-day уязвимостите „in the wild“ в продължение на поне два месеца преди Microsoft да пусне корекциите на 2 март 2021 г.

Препоръки

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

Не неглижирайте и възможността в инфраструктурата ви вече да „живее“ недоброжелател – разгледайте и приложете стъпките, които Microsoft препоръчва за смекчаване на последиците:

Microsoft has released a new, one-click mitigation tool, the Microsoft Exchange On-Premises Mitigation Tool, to help customers who do not have dedicated security or IT teams to apply security updates for Microsoft Exchange Server. Learn more: https://t.co/IfChAqpcEH pic.twitter.com/xD94M8Czg5

— Microsoft Security Intelligence (@MsftSecIntel) March 15, 2021

Изследователите по киберсигурност от екипа Project Zero на Google, специализирани в откриването на 0-day уязвимости, публикуваха доклад от шест части, в който подробно описват сложна хакерска операция, засечена в началото на 2020 г.

Тя е насочена към собствениците на Android и Windows устройства. Атаките са извършени чрез два експлойт сървъра (единият, предназначен за Windows потребители, а другият – за Android), изпълняващи различни последователни експлойт събития (exploit chains) чрез т.нар. “Watering hole” метод за атака.

И двата експлойт сървъра са използвали уязвимости в Google Chrome, за да осигурят нерегламентиран достъп до устройствата на жертвите. Веднъж получили входна точка посредством браузъра, хакерите инсталират експлойт на ниво ОС, за да получат по-голям контрол върху устройството на жертвата.

Последователните експлойт събития включват комбинация от уязвимости, както от тип 0-day, така и n-day. 0-day се отнася за уязвимости, неизвестни за вендора към момента на експлоатиране, а n-day – за такива, които са били закърпени, но все още се наблюдава активното им експлоатиране.

Какво съдържат експлойт сървърите

• Четири „renderer“ грешки в Google Chrome, една от които все още не е била позната (0-day) на Google, когато е била открита от екипа на Project Zero
• Два експлойта, които са специализирани в това, да избягват засичането им в облачно базирани среди (sandboxing) и които ескплоатират три 0-day уязвимости в Windows
• Пакет за ескалиране на привилегиите (privilege escalation kit), съставен от публично известни n-day експлойти за по-стари версии на Android OS.

0-day уязвимостите са закърпени през пролетта на 2020г

• CVE-2020-6418 – Chrome Vulnerability in TurboFan (закърпен през Февруари 2020)
• CVE-2020-0938 – Font Vulnerability on Windows (закърпен през Април 2020)
• CVE-2020-1020 – Font Vulnerability on Windows (закърпен през Април 2020)
• CVE-2020-1027 – Windows CSRSS Vulnerability (закърпен през Април 2020)

Въпреки че на споменатите по-горе експлойт сървъри не са открити 0-day за Android, специалистите от Project Zero предполагат, че хакерите най-вероятно са имали достъп именно до такъв тип експлойт. Просто той не е бил хостнат на тези сървъри по времето на провеждане на изследването.

Google: Последователните експлойт събития са сложни и добре разработени

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

Не се предоставят други подробности за нападателите или профила на таргетираните жертви.

В блога на Project Zero са налични още доклади по темата

Публикувани са и други доклади, свързани с „infinity bug“ в Google Chrome, който е използван при атаките, последователните експлойт събития, съответно при Chrome, Android, Windows, както и следексплоатационни техники, използвани отново при Android устройствата.

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

Препоръки

Разгледаната атака е поредното доказателство, че хакерите продължават да усъвършенстват и подобряват своите тактики, техники и процедури (TTPs).

Екипът на FreedomOnline.bg препоръчва винаги да използвате последната налична версия както на ниво ОС/фърмуер, така и на инсталираните програми/апликации. По този начин ще се предпазите от експлоатиране на вече известни уязвимости (n-day).

Внимавайте също така какво инсталирате на вашето устройство и какъв достъп разрешавате. За разлика от n-day, където един пач (patch) би елиминирал уязвимостта, при 0-day това само по себе си не е достатъчно, а са необходими мерки от типа на многопластова защита (defence-in-depth) и защитни механизми, които биха идентифицирали подозрително и нехарактерно поведение на устройствата.

Световноизвестният доставчик на решения за интернет сигурност, защитни стени и VPN продукти, SonicWall, разкри, че е станал жертва на координирана атака срещу вътрешните му системи. Смята се, че нападателите са имали достъп до изходния код (source code) на компанията, хостван в хранилището й в GitLab.

Хакерите са се възползвали от zero-day уязвимост в собствените продукти за защитен отдалечен достъп на SonicWall – NetExtender VPN Client и Secure Mobile Access (SMA).

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

Разследването на инцидента и последиците от него продължава. Има вероятност SonicWall  да е станал жертва на криптоатака.

Междувременно, ако вашата организация използва някой от уязвимите продукти, следва да предприемете подходящи мерки:

• Разрешете многофакторно удостоверяване (MFA) за достъп до администраторските акаунти
• Деактивирайте достъпа на NetExtender до защитната стена
• Ограничете достъпа на публични IP адреси до потребители и администратори
• Конфигурирайте директно достъпа до белия списък (white list) на SMA, за да намалите негативните последици

Apple пусна актуализации на защитата за iOS, с която закърпва 3 zero-day уязвимости.

Съветваме потребителите на iOS да ъпдейтнат веднага до iOS 14.2 ако това вече не е направено автоматично.

Става дума за:

• CVE-2020-27930 – проблем с отдалечено изпълнение на код в компонента на iOS FontParser, който позволява на атакуващите да стартират дистанционно код на устройства с iOS
• CVE-2020-27932 – уязвимост за ескалация на привилегии в ядрото на iOS, която позволява на атакуващите да стартират злонамерен код с привилегии на ниво ядро
• CVE-2020-27950 – изтичане на памет в ядрото на iOS, което позволява на нападателите да извличат съдържание от паметта на ядрото на iOS устройство

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

Общо 11 експлоатирани zero-day уязвимости са били открити и анализирани от екипа за сигурност на Google – Project Zero през първата половина на 2020 г.

0-day уязвимости през първата половина на 2020 г.

1. Firefox (CVE-2019-17026) – Използва се предимно в комбинация с друга уязвимост – CVE-2020-0674 и най-вече за таргетирани атаки. Закърпена във Firefox версия 72.0.1.Твърди се, че е от арсенала на хакерската група Dark Hotel.

2. Internet Explorer (CVE-2020-0674) – Тази, както и гореописаната Firefox 0-day уязвимост, е била използвана от държавно спонсорирана хакерска група (nation-state hacking group), известна като DarkHotel, за която се смята, че работи извън Корейския полуостров (не е ясно дали от Северна или Южна Корея). Двете уязвимости са били използвани за шпиониране на цели, разположени в Китай и Япония. Поради тази причина са открити от Qihoo 360 (китайски производител на антивирусни програми) и JPCERT (японският Център за действие при инциденти в информационната сигурност). Жертвите на тази кампания са били пренасочвани към уебсайт, който хоства експлоатиращ код  (exploit kit), насочен към 0-day уязвимостта в Firefox или IE, след което инфектира машините с троянски кон Gh0st, осигурявайки отдалечен достъп и контрол на нападателите върху компютрите на жертвите. Уязвимостта  е закърпена през февруари тази година като част от редовното закърпване на уязвимости от страна на  Microsoft, което се провежда всеки втори вторник на месеца – Patch Tuesday.

3. Chrome (CVE-2020-6418) – Експлоатирането на тази 0-day уязвимост е било засечено от екипа на Google за анализ на кибератаки и заплахи (Goolge TAG), но не са публикувани подробности къде и кога. Закърпена в Chrome версия 80.0.3987.122.

4 и 5. Trend Micro OfficeScan (CVE-2020-8467 и CVE-2020-8468) – Двете 0-day уязвимости са в приложение на Trend Micro – OfficeScan XG. Твърди се, че са открити от екипа на компанията случайно, при разследването на друга узявимост, използвана за хакването на Mitsubishi Electric. Запушени са малко след откриването им.

6 и 7. Firefox (CVE-2020-6819 and CVE-2020-6820) – Подробности за атаките, при които са използвани тези две 0-day уязвимости във Firefox, все още не са публикувани. Въпреки това специалистите по информационна сигурност предполагат, че те може да са част от събития, свързани с по-голяма експлоатационна верига. Запушени са във Firefox версия 74.0.1.

8, 9 и 10. Три уязвимости в продукти на Microsoft, открити и репортнати от Google TAG. Все още не е ясно при какви атаки са използвани. Това са CVE-2020-0938, CVE-2020-1020 и CVE-2020-1027, които са закърпени в априлското издание на Microsoft Patch Tuesday.

11. Sophos XG Firewall (CVE 2020-12271) – Уязвимост в операционната система SFOS позволява изпълнение на зловреден код върху хардуерните и виртуални устройства Sophos XG. Потенциално засегнати са всички устройства с достъпен от интернет административен портал (HTTPS услуга) и/или потребителски портал (User Portal).

SophosLabs публикуваха резултатите от проведеното разследване относно тази атака (Asnarök). Статията включва пълна техническа информация, включително и Indicators of Compromise (IoC). Уязвимостта е закърпена във фърмуер версия SFOS 17.5 MR12.

За любителите на статистиката – екипът на Google Project Zero е публикувал

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

0-day уязвимости през цялата 2019 г.

• А за любителите на историята: нека да разгледаме анализа на Google за откритите през миналата година уязвимости – общо 20 на брой, 11 от които са свързани с продукти на Microsoft.
• Две компании са открили половината от засечените 0-day уязвимости през 2019г. (Google са открили 7 и Kaspersky са открили 4).
• Не е засечено активно експлоатиране на 0-day уязвимости в Linux, Safari или macOS от 2014г., когато Google започна да води подобна статистика.
• За първи път през 2019г. е открита 0-day уязвимост в Android.
• Не всички 0-day уязвимости засягат последните налични (актуални) версии на ОС/софтуер.
• От Google подозират, че някои софтуерни вендори прикриват активно експлоатирани 0-day уязвимости, като ги определят като обикновени бъгове.
• Според тях, причината за повечето открити 0-day уязвимости в продукти на Microsoft е, че има повече налични инструменти, които са специализирани именно в откриване на подобни бъгове.
• Възможността за изолиране на приложения (app sandboxing) е една от причините, която спомага за трудното намиране на 0-day уязвимости в мобилните платформи.
• 63% от 0-day уязвимостите, открити през 2019 г., се дължат на дефекти и слабости в кода, свързани с операциите в паметта (memory corruption bugs). Същият процент важи и за 2020 г. Това също е в унисон със статистическите данни, публикувани от Microsoft и Google през 2019 г., където се твърди, че 70% от всички уязвимости в продуктите на Microsoft и в Chome са т.нар. „memory safety issues”. През 2020г. Този процент е 63% от всички уязвимости.

Заключение

Поддържането на up-to-date софтуер/ОС няма да премахне вероятността да бъдете експлоатирани от 0-day уязвимост, но ще намали риска това да се случи. А в света на информационната сигурност именно „риск“ е ключовата дума или казано по друг начин – каква е вероятността това да се случи?

Тъй като няма 100% сигурност, ние трябва да се стремим да държим този риск минимално нисък (или в допустими за нас граници).