Поскольку я по образованию "защитник информации"(075400 МИЭТ), то постоянно интересуюсь новостями в этой области, и сегодня увидел интересную статью по теме. Автор описывает способ внедрения вредоносного кода в разные части .NET Framework, например, в метод аутентификации из System.Web.dll с последующей пересылкой логинов и паролей злоумышленнику, в метод чтения строк подключения к базе данных, компрометации классов из System.Security.Cryptography, javascript кода XSS в System.Web.dll, компроментации CAS т.е. отключение CodeAccessPermission::Demand(), CodeAccessPermission::Deny(), CodeAccessPermission::Assert(), FileIOPermission, RegistryPermission, и т.п., простого backdoor в любой код Framework'а, ну и прочих гадостей, не подчиняюшихся CAS. Им так же написана утилита позволяющая частично автоматизировать этот процесс. Конечно это "post exploitation" атака, т.е. что бы все это проделать необходимы права администратора на машине, но это на самом деле не так важно.
Изменение кода управляемой библиотеки представляет собой тривиальную задачу(даже подписанной), но основная польза от исследования автора заключается в том, что он отметил следующее поведение: если сборка загружена в GAC, то загрузчик не пытается проверять подпись, а просто загружает сборку по соотвествующему(версия, культура, маркер открытого ключа) физическому пути(например для mscorlib.dll C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll). Именно этот факт, позволяет просто перекомпилировать сборки из GAC, игнорируя хаки с подписью совсем, с дальнейшим копированием сборок по соответствующему физическому пути файловой системы. Кстати, стоит отметить, что для сборок(подписанных, разговор только о них), которые не установлены в GAC, проверка осуществляется каждый раз при загрузке приложения.
спасибо, интересная статья, отправил наших читать ))
ReplyDelete