Windows

  • Google разкрива усъвършенствана хакерска операция, насочена към Windows и Android устройства

    Изследователите по киберсигурност от екипа 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) и защитни механизми, които биха идентифицирали подозрително и нехарактерно поведение на устройствата.

  • Не отлагайте да актуализирате вашия Windows

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

    За ваше удобство, програмите имат достъп до файловите пътища. Поставете например път на файл в Google Chrome и той ще задейства Windows Explorer или ще отвори PDF във вашата система. Но ако пътят до файла не е оформен с правилно определени атрибути, той би сринал Windows, като доведе до BSOD (син екран на смъртта).

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

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

  • Microsoft: Хакерите на SolarWinds са имали достъп до нашия сорс код

    Хакерската група, стояща зад атаката на SolarWinds, е успяла да направи пробив и да осъществи достъп до част от изходния код (source code) на Microsoft, това потвърди самата компания.

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

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

    Модифицирането на изходния код – което Microsoft заяви, че хакерите не са направили – може да има потенциално пагубни последици, предвид широкото разпространение на продуктите на Microsoft (MS Office и Windows OS. Дори само фактът, че хакерите са имали възможност да прегледат кода, им дава предимство при последващо атакуване на продукти или услуги на Microsoft.

  • Криптовирусът RansomEXX прескача от Windows на Linux

    Ransomware тормози потребителите на Windows от години. В последно време той се променя и адаптира, за да може да компрометира и Linux сървъри. А вече е регистриран криптовирус, който прескача от Windows на Linux.

    Засечен е нов троянец, наречен RansomEXX, който първоначално заразява Windows система и след това я използва за вход към набелязана Linux машина. Става дума за изключително таргетирани атаки: Всяка проба от кода, която изследователи от Касперски са проучили, е съдържала името на атакуваната организация. Сред жертвите е и Konica Minolta.

    RansomEXX не е непознат – той атакува Windows от лятото на 2020 г. Еволюцията на зловредния код обаче е новост: Това е може би първият случай, при който криптовирус прескача между различни операционни системи.

    Ransomware е изключително печеливш бизнес. Твърди се, че операторите на Ryuk заплахи са спечелили 34 млн. USD само от една успешна атака. Kиберпрестъпната група REvil казва, че прави над 100 млн. USD годишно от платени откупи. При това положение е най-логично да очакваме, че „пазарното развитие“ на криптовирусите ще продължи.

    Препоръки:

    • Провеждайте редовни обучения на целия персонал, с фокус върху киберсигурността
    • Въведете в организацията си най-подходящата комбинация от решения за киберзащита, по възможност, основана на препоръка от професионалист
    • Прилагайте редовно ъпдейти на системите, за да елиминирате налични уязвимости, които могат да се окажат входна точка за кибератака
    • Прилагайте принципа най-необходимия достъп (least privilege)
    • Управлявайте паролите си, като, по възможност, използвате мениджъри на пароли и двуфакторна автентикация
  • Ботнетът Emotet атакува с нов злонамерен шаблон за Windows Update

    Ботнетът Emotet използва нов злонамерен прикачен файл, който се представя за съобщение от Windows Update и ви приканва да актуализирате Microsoft Word.

    Emotet е зловреден софтуер, която се разпространява чрез фишинг имейли, съдържащи злонамерени документи на Word или Excel. Тези документи използват макроси за изтегляне и инсталиране на троянския кон Emotet на компютъра на жертвата. Веднъж заразен, този компютър започва да разпраща спам и-мейли и в крайна сметка може да доведе до рансъмуер-атака в мрежата на жертвата.

    В предишни свои прояви Emotet маскираше спам кампаниите си като фактури, информация за доставка, информация за COVID-19, информация за здравето на президента Тръмп, автобиографии или поръчки за покупка.

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

  • Лошият съсед – CVE-2020-16898

    Microsoft публикува информация относно критична уязвимост в IPv6 стака на всички модерни Windows операционни системи, оценена с впечатляващите 9.8 CVSSv3 базови точки. Тази уязвимост позволява отдалечено изпълнение на код (RCE) чрез специално изработени IPv6 пакети, без нападателят да има нужда да се автентикира.

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

    • Текущият proof-of-concept (PoC) експлойт, споделен с членовете на MAPP (Microsoft Active Protection Program), е изключително прост и 100% ефективен, но той не води до RCE, а само до незабавен BSOD (Blue Screen of Death). Т.е. тази уязвимост към момента може да бъде експлоатирана за осъществяване на DoS атаки. 

    • Уязвимостта се корени в проблеми с обработката на ICMPv6 Router Advertisement, които са част от ICMPv6 Neighbor Discovery “протокола”. За щастие такива пакети не се изпращат свободно в интернет и най-често биват филтрирани на ниво firewall/border router. При това положение, атакуващият най-вероятно ще се намира в локалния мрежов сегмент на жертвата.
    • “Лошият съсед” (Bad Neighbor) е прякорът на CVE-2020-16898, която има потенциал да се имплементира в саморазпространяващ се  зловреден код (червей). Засега постигането на BSOD е само върхът на айсберга: това е първата стъпка към осъществяването на успешен RCE, чрез навързване (chaining) на няколко уязвимости, което рано или късно ще се случи със сигурност.
    • Всъщност, според ветерани като Malware Jake,  едва ли ще се постигне RCE.

    Засегнатите операционни системи и версии са:

    • Windows 10 Version 1709 for 32-bit Systems
    • Windows 10 Version 1709 for ARM64-based Systems
    • Windows 10 Version 1709 for x64-based Systems
    • Windows 10 Version 1803 for 32-bit Systems
    • Windows 10 Version 1803 for ARM64-based Systems
    • Windows 10 Version 1803 for x64-based Systems
    • Windows 10 Version 1809 for 32-bit Systems
    • Windows 10 Version 1809 for ARM64-based Systems
    • Windows 10 Version 1809 for x64-based Systems
    • Windows 10 Version 1903 for 32-bit System
    • Windows 10 Version 1903 for ARM64-based Systems
    • Windows 10 Version 1903 for x64-based Systems
    • Windows 10 Version 1909 for 32-bit Systems
    • Windows 10 Version 1909 for ARM64-based Systems
    • Windows 10 Version 1909 for x64-based Systems
    • Windows 10 Version 2004 for 32-bit Systems
    • Windows 10 Version 2004 for ARM64-based Systems
    • Windows 10 Version 2004 for x64-based Systems
    • Windows Server 2019
    • Windows Server 2019 (Server Core installation)
    • Windows Server, version 1903 (Server Core installation)
    • Windows Server, version 1909 (Server Core installation)
    • Windows Server, version 2004 (Server Core installation)

    Как да се защитим

    Накратко: Calm down and patch!

    Приложете съответните пачове и си отворете по една студена бира за добре свършената работа.
    За тези от вас, които, по една или друга причина, не могат да приложат обновленията, съществува workaround: Изключете  ICMPv6 RDNSS чрез powershell команда и рестартирайте операционната система.

    netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable

    За пълна видимост и регистриране на опити за експлоатация, вече има публикувани Suricata IDS/IPS правила.

    За най-актуална информация, препоръчваме да следите официалната статия със съвети от Microsoft.

    За да научите повече за тази уязвимост, препоръчваме да прочетете чудесните статии на McAffee и Rapid7:

    https://www.mcafee.com/blogs/other-blogs/mcafee-labs/cve-2020-16898-bad-neighbor/

    https://blog.rapid7.com/2020/10/14/there-goes-the-neighborhood-dealing-with-cve-2020-16898-a-k-a-bad-neighbor/

    А, ако ви се струва, че имате Deja Vu, не сте се объркали – Ping of Death.

     

  • Windows Power Toys: Направете Windows 10 по ваш вкус с безплатно open source приложение

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

    Ако искате да направите Windows наистина изцяло по ваш вкус, отговорът не е само в системните настройки. Решението е пакет с приложения, създаден от Microsoft, и наличен за сваляне, безплатно от GitHub. Ето част от екстрите, с които ще разполагате, след като се запознаете с този текст:

    • Как да подреждате автоматизирано различни отворени прозорци според типа им
    • Как да преглеждате текстови файлове, без да се налага да ги отваряте
    • Как да промените клавишните комбинации по подразбиране в операционната система
    • Как да преименувате повече от един файл едновременно

    Fancy Zones

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

    По принцип, в Windows можете да преместите един прозорец на няколко места на екрана: отгоре, отдолу, вляво или вдясно използвайки клавишната комбинация Windows Key + Arrow Keys.

    С Fancy Zones можем да зададем различна зона на екрана използвайки вече готовите темплейти.

    Или да начертаем конкретни зони с Custom Layout Creator

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

    Може да преместим прозорец във вече обозначена зона, като използваме комбинацията Left Shift + Left Mouse Button. При използването ѝ, зоните се показват на екрана и тази, върху която искаме да се сложи прозореца, се обозначава с червен цвят по подразбиране.

    Shortcut Guide

    Shortcut Guide ни позволява да видим различните клавишни комбинации които използват Windows бутона. За целта, единствено задържаме Windows Key за една секунда, след което се появява менюто, показващо ни всички клавишни комбинации.

    Power Rename

    Power Rename ни позволява да редактираме имената на голям брой файлове наведнъж. Имаме възможност да задаваме много различни аргументи при използване на самият инструмент, като например ^example, който ще маркира всеки файл който започва с example и ще ни позволи да го редактираме.

    Като цяло инструментът е изключително сложен, но Microsoft са ни предоставили много подробни инструкции в Github хранилището на Power Rename, както и малко демо под формата на видео, което показва какво представлява инструмента.

    Preview Pane 

    Preview Pane е технология, която ни показва предварителен преглед на маркирани от нас файлове. Ако, например, не желаем да отваряме 20 различни текстови документа или снимки един по един, с Preview Pane можем директно да ги разгледаме още във File Explorer.

    Може да намерите source кода на проекта в Github хранилището, ако се интересувате как точно е направено.

    Image Resizer

    Image Resizer работи подобно на Power Rename с идеята, че позволява да редактираме много файлове наведнъж. Конкретно, в Image Resizer имаме възможността да редактираме измеренията на избрани от нас снимки. Това, което прави инструмента изключително полезен, са и допълнителните опции, с които идва. Например, да създаваме вече предефинирани размери, които можем да запазим за по-късно или дори да увеличим, или намалим размера на снимките с даден процент.

    Keyboard Manager

    Keyboard Manager или KBM ни позволява да променяме функцията на клавишните ни комбинации или дори да предефинираме отделни клавиши. Например, можем да променим командата за копиране на файлове Ctrl + C на Ctrl + D. Или, когато напишем латинско Z да излиза З на кирилица. За жалост, поне засега, инструментът няма възможността да презаписва комбинация от клавиши върху един бутон, например ако искаме да преместим Ctrl + C -> C или Ctrl + V -> V

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

    Освен това поддържа и допълнителни макро бутони като тези при Razer клавиатурите. Може да намерите официалния FaQ за инструмента в Github.

    Power Toy Run

    Последното приложение в този пакет е Power Toys Run. Може да го отворим чрез клавишна комбинация Alt + Space. Той представлява търсачка, с която може да търсим различни документи, приложения, или дори да го използваме като калкулатор за много по-бързи калкулации като събиране, умножение и т.н.

    Други възможности на инструмента са например:

    • С клавишната комбнация Ctrl + Shift + Enter можем да отворим приложение като администратор.
    • С Ctrl + Shift + E можем да отворим директорията, в която се намира приложението
    • Ctrl + C ни позволява да копираме директорията директно от Power Toy Run.

    Инструментът е най-новият в пакета и има малки проблеми, за които може да прочетете отново в Github.

    В заключение

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

    Лично за мен Shortcut Guide, File Explorer Preview и Power Toys Run са модулите които могат най-много могат да ни улесняат работата с Windows. Може да намерите всички инструменти, заедно с тяхната документация, в официалната страница на Microsoft в Github.

  • SIGRed: уязвимост в Windows Server се спотайва 17 години?

    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 бита) е 216 -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 с промяна на регистър.

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

  • Възкресен Windows “зомби” бъг в Win32k

    Последен ъпдейт на 4 май 2020 в 11:57 ч.

    Преди една година, Гил Даба обещава, че ще открие над 15 бъга, свързани с компонента на Windows win32k. Миналата седмица обаче той публикува цели 25.

    Механизъм на действие

    Бъговете се възползват от дългогодишен проблем с win32k, свързан с компонента за потребителски интерфейс в Windows. Обикновено този софтуер работи в User Mode (потребителски акаунт), използван от стандартни приложения за Windows. Тъй като е част от система с по-малко привилегии, в User Mode не може да се получи директен достъп до хардуера. Вместо това софтуерът изпраща заявка към ядрото (kernel) – част от операционната система, грижеща се за функциите на по-ниско ниво.

    С течение на времето Microsoft изместват функциите на win32k към ядрото, но тъй като хиляди различни потребителски програми разчитат на него, много често се налага то да премине в User Mode, за да извърши дейността си. Този своеобразен мост между ядрото и User Mode обаче е потенциално опасен. 

    В случай че приложение, работещо в User Mode, намери начин да компрометира Kernel Mode (), то ще получи достъп до най-ниските и привилегировани нива на операционната система.

    UAF грешка

    Често срещана грешка, която допускат разработчиците в миналото е, че забравят да заключат обект в паметта, намиращ се в Kernel Mode, преди той да използва win32k, което би го върнало обратно в User Mode. Ако това се случи, атакуващият ще може да изтрие обекта, използвайки стандартния акаунт, т.е User Mode. Тогава програмата би се опитала да върне контрола над обекта и да му предостави административни права, което ще бъде неуспешно, тъй като той вече ще бъде изчезнал. Това създава така наречената use-after-free (UAF) грешка, при която атакуващият може да използва освободеното място в паметта.

     „Зомби“ бъг

    Microsoft коригират множество бъгове, свързани със съответния клас – win32k, за да предотврати евентуалното му експлоатиране експлойт. Даба открива нов бъг, подобен на тях: възможно е човек да осъществи връзка между обект от ядрото (например прозорец в Windows) и друг обект, който създава (друг прозорец). Впоследствие, лицето, работещо в User Mode, изпраща заявка към Windows да унищожи създателя на обекта, работещ в Kernel Mode, но не може да го направи, докато действията, извършвани в Kernel Mode не бъдат приключени. Така Windows маркира създателя за изтриване, след като бъде готов с всички задачи. Това всъщност превръща обекта в нещо, което програмистите наричат „зомби“ обект.

    Даба открива множество бъгове от този клас, които обяснява в своя доклад. В него той показва как е обработил 13 от тях, добавяйки и PoC в GitHub хранилището си. Той споменава, че Microsoft работят върху бъговете от този клас в  Windows Insider Preview версията, коригирайки ги един по един.

    Признание

    Заради своите заслуги, Даба получава заслужена похвала – Microsoft добавя името му в своята секция за признание през февруари 2020. В тази своеобразна зала на славата, място намират имената на хора, открили бъгове и спомогнали за тяхното разрешаване.

  • Microsoft купи домейна corp.com заради кражба на акаунти

    Microsoft ще плати над 1.7 млн. USD, за да придобие домейна corp.com. Компанията не иска той да попада в ръцете на киберпрестъпници, които да злоупотребяват с него и да крадат Windows акаунти.

    Причината домейнът да позволява подобни кражби е свързана с факта, че до скоро Microsoft насърчаваше бизнес потребителите си да използват името CORP за домейн на Active Directory при конфигуриране на windows мрежи.

    С все по-тясното интегриране на DNS с Windows домейните, може да се получат проблеми с колизия на истинския домейн corp.com. Това може да доведе до факта, че windows ще се опита да се свърже с домейна corp.com, а не с локалния си домейн CORP, което да доведе до неоторизирано споделяне на потребителски имена, пароли, принтери и др.

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

     

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

Back to top button