Re[2]: Kernel Sockets Module (TDI, WSK) - Низкоуровневое программирование

Всем привет!

На rootkit.com выложены исходники модуля, предоставляющий, по описанию автора, простое API для работы с сокетами в ядре. Для Windows XP, 2003 используется TDI, для Vista, 2008, Seven — WSK. Почитать можно здесь. Скачать исходники тут.

Беглый просмотр исходников показал, что например, отправка почты выглядит так:

static const unsigned __int32 SMTPServer = 0x5E64B101;//smtp.mail.ru -> 94.100.177.1 == 0x5E64B101
static const unsigned __int16 SMTPPort = 2525;
static const char * SMTPUserName = "ABB2DD72C746";
static const char * SMTPUserPassword = "qwerty";
static const char * MailFromAddress = "ABB2DD72C746@mail.ru";
static const char * MailToAddress = "ABB2DD72C746@mail.ru";
static const char * AttachedFileName = "{CB9AC2C1-9FD2-4AD5-9167-E5D4A2EEBB4C}";
static const char * MailSubject = "Subject";
static const char * MailTextCharSet = "WINDOWS-1251";
static const char * MailText = "Mail Text";

static const char * AttachedFileBody = "This is attached file body";

NTSTATUS DriverEntry(__in struct _DRIVER_OBJECT * DriverObject, __in PUNICODE_STRING RegistryPath)
{
...
...
    EnableKernelSocketsModule();

    //Sending e-mail by KernelSocketsModule
    SMTPClientSendEMail(SMTPServer, SMTPPort, SMTPUserName, SMTPUserPassword, MailFromAddress, MailToAddress, MailSubject, MailText, MailTextCharSet, true, AttachedFileName, AttachedFileBody, local_strlen(AttachedFileBody));
...
...
    return STATUS_SUCCESS;
}

Думаю, будет интересно...

"Работа в ядре для script-kiddies"?

Это ж 100% малварный код, зачем его публиковать на ресурсе, где стыдливо не ругаются матом и пишут новые, годные ЯП? Предлагаю добровольный бан

.

Здравствуйте, TarasCo, Вы писали:

TC>"Работа в ядре для script-kiddies"?
TC>Это ж 100% малварный код, зачем его публиковать на ресурсе, где стыдливо не ругаются матом и пишут новые, годные ЯП? Предлагаю добровольный бан

.

С другой стороны, этот код может помочь разобраться в основах работы с TDI и WSK.
Или я не прав?

Здравствуйте, TarasCo, Вы писали:

TC>"Работа в ядре для script-kiddies"?

TC>Это ж 100% малварный код, зачем его публиковать на ресурсе, где стыдливо не ругаются матом и пишут новые, годные ЯП? Предлагаю добровольный бан

.

Малварное в нём только то, что он обращается напрямую к устройствам \Device\Tcp, \Device\Udp и пр.,
минуя возможные фильтрующие устройства в стеке устройств. Это позволяет обходить только некоторые
файрволлы, работающие на уровне TDI. В остальном этот код предназначен для упрощения программирования
сети в режиме ядра. Чистоты кода ради несложно заменить обращение к устройствам традиционным способом —
к верхним устройствам в стеке — с помощью IoGetDeviceObjectPointer(). Модуль в разработке.

Здравствуйте, -prus-, Вы писали:

P>Всем привет!

P>На rootkit.com выложены исходники модуля, предоставляющий, по описанию автора, простое API для работы с сокетами в ядре. Для Windows XP, 2003 используется TDI, для Vista, 2008, Seven — WSK. Почитать можно здесь. Скачать исходники тут.

P>Думаю, будет интересно...

К сожалению только на Windows х86 системах, из-за неподписанных драйверов...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Bardano, Вы писали:

B>Малварное в нём только то, что он обращается напрямую к устройствам \Device\Tcp, \Device\Udp и пр.,
B>минуя возможные фильтрующие устройства в стеке устройств.
Это и есть типичное малварное поведение.

B>Это позволяет обходить только некоторые файрволлы, работающие на уровне TDI.
т.е. некоторые студенческие поделки. Нормальные фаерволлы дополнительно перехватывают пакетный уровень и проверяют, проходил ли пакет через верхний перехват. Трафик с обходом TDI будет либо молча заблокирован, либо будут вопли (обоснованные) о странной сетевой активности.

B>В остальном этот код предназначен для упрощения программирования
Что уж проще, вынести сетевую часть в UM или пользоваться KM интерфейсами без прямого обращения к устройствам ? ИМХО метод больше предназначен для набивание шишек на лбу

B>сети в режиме ядра. Чистоты кода ради несложно заменить обращение к устройствам традиционным способом -
B>к верхним устройствам в стеке — с помощью IoGetDeviceObjectPointer(). Модуль в разработке.
Уже лучше.

Здравствуйте, Bardano, Вы писали:

B>Малварное в нём только то, что он обращается напрямую к устройствам \Device\Tcp, \Device\Udp и пр.,
B>минуя возможные фильтрующие устройства в стеке устройств.

Когда MS реализует поддержку серверной части HTTP протокола в ядре — понятно, ускоряют IIS.

Есть ли хоть одно (не связанное с массовой раассылкой) применение SMTP клиента, когда будет оправдан перенос в ядро?

B>В остальном этот код предназначен для упрощения программирования
B>сети в режиме ядра.

Ну, то есть код — в первую очередь предназначен для людей, а как его можно использовать? Судя по примеру, можно взять его и написать спамбота. Примеры других применений отсутствуют. Отсюда и утверждение о 100%

С другой стороны, де-юре код чист и не нарушает правила ресурса.
И если NY Times публикует ~~fraud~~ откровения вроде:

"It's extremely difficult to write code for your kernel that doesn't crash your computer," said Alfred Huger, vice president of Symantec's Security Response team.
...
"On the whole malware spectrum, it's a very small piece and it's of limited risk today," Huger said.

то рано или поздно кому-то придётся дать этим авторитетным шарлотанам ниже пояса, а не в лоб, как пытался Frank Boldewin

GN>С другой стороны, де-юре код чист и не нарушает правила ресурса.
GN>И если NY Times публикует ~~fraud~~ откровения вроде:
GN>

"It's extremely difficult to write code for your kernel that doesn't crash your computer," said Alfred Huger, vice president of Symantec's Security Response team.
GN>...
GN>"On the whole malware spectrum, it's a very small piece and it's of limited risk today," Huger said.

то рано или поздно кому-то придётся дать этим авторитетным шарлотанам ниже пояса, а не в лоб, как пытался Frank Boldewin

мда, а что дальше? нафиг тогда юзермод? Он ведь для слабаков с коротким членом да? Потом еще кто нить выложит враппер для win32k.sys и начнем гуишные апликухи писать в виде .sys файлов? Настоящие мужчины пишут исключительно под кернелмод, правда?
Дело не в том наскока сложно написать безглючный кернелмоде код. Дело в том что это сделать не проще, чем безглючный юзермоде код, с той лишь разницей что любой баг--> bsod в лучшем случае, local elevation vulnerability в обычном случае и remote privileged code exeution vulnerability в худшем . Именно для того и был юзермод задуман чтобы этого избежать. А пихание всего чего можно в кернелмод вернет вин системы в эпоху win'9x, где кернелмод был по сути формальностью. И кроме того нарушает основополагающий принцип любой системы безопасности — принцип минимальных привилегий, причем совершенно независимо от длины вашего чле... то есть от вашей способности писать безглючный код.

Здравствуйте, ononim,

Я хотел сказать совсем не о том (более того, функция в 400 строк вызывала сомнение, стоит ли копировать "that doesn't crash")

O>И кроме того нарушает основополагающий принцип любой системы безопасности — принцип минимальных привилегий,

Это в safety.

В security исходят из того, что атакующий обладает всеми необходимыми техническими средствами для проведения атаки. Система строящаяся на других принципах (It's extremely difficult to write code) — не может даже претендовать, не то что быть секьюрной.

Пока обладающие авторитетом люди заявляют: "ничего страшного не происходит", не читавший Шнайера обыватель будут доверять свою безопасность в их руки, фактически становясь жертвами "афёры".

Публикация подобного кода наглядно показывает ошибочность подобных утверждений даже без знакомства с основами security. Потом еще и код накопипастят все кому не лень, и Symantec будет вынужден как-то исправляться.

Другими словами, если публикуются "обычные" эксплуатации уязвимостей (и это несёт пользу в виде исправления ошибок) то почему не могут вот такие?

GN>Здравствуйте, ononim,
GN>Я хотел сказать совсем не о том (более того, функция в 400 строк вызывала сомнение, стоит ли копировать "that doesn't crash")
O>>И кроме того нарушает основополагающий принцип любой системы безопасности — принцип минимальных привилегий,
GN>Это в safety.
это в секурити

GN>В security исходят из того, что атакующий обладает всеми необходимыми техническими средствами для проведения атаки. Система строящаяся на других принципах (It's extremely difficult to write code) — не может даже претендовать, не то что быть секьюрной.
Верно. Но кроме того исходят из того что не существует никаких "технических средств" для того, чтобы код работающиий с меньшими привилегиями повлиял на код работающий с более высокими привилегиями или на изолированнй код работающий на таких же привилегиях.
А вы предлагаете исходить из концепции что любой ваш код идеален.

GN>Пока обладающие авторитетом люди заявляют: "ничего страшного не происходит", не читавший Шнайера обыватель будут доверять свою безопасность в их руки, фактически становясь жертвами "афёры".
То есть разработчики Unix, NT Шнайера не читали. Высосали из пальца концепции многопользовательских систем, да еще сертифицировали их всякими сертификатами... Вот неграмотные, сходите их поучите уму-разуму.

GN>Публикация подобного кода наглядно показывает ошибочность подобных утверждений даже без знакомства с основами security. Потом еще и код накопипастят все кому не лень, и Symantec будет вынужден как-то исправляться.
GN>Другими словами, если публикуются "обычные" эксплуатации уязвимостей (и это несёт пользу в виде исправления ошибок) то почему не могут вот такие?
А я чета не понял к чему тут эти два абзаца.
Указанный код не является уязвимостью сам по себе. Уязвимым может быть код который его будет использовать и работать при этом с наивысшими привилегиями, вместо того что тихонько крутиться себе под ограниченным вистовским юзером. Система безопасности винды _гарантирует_ что код работающй не под админом не может скомпрометировать данные админа, или другого пользователя при настройках по умолчанию. В противном случае идет речь о новой локальной уязвимости и поститься соответствующий KB.

Здравствуйте, ononim, Вы писали:

O>>>И кроме того нарушает основополагающий принцип любой системы безопасности — принцип минимальных привилегий,
GN>>Это в safety.
O>это в секурити

В таком случае он никак не основополагающий.

O>А вы предлагаете исходить из концепции что любой ваш код идеален.

я вообще нигде в этой теме не упоминал свой код, похоже, осталось влияние других обсуждений?

GN>>Пока обладающие авторитетом люди заявляют: "ничего страшного не происходит", не читавший Шнайера обыватель будут доверять свою безопасность в их руки, фактически становясь жертвами "афёры".
O>То есть разработчики Unix, NT Шнайера не читали. Высосали из пальца концепции многопользовательских систем, да еще сертифицировали их всякими сертификатами... Вот неграмотные, сходите их поучите уму-разуму.

Я не про это писал.

Ещё раз: Alfred Huger, vice president of Symantec's Security Response team, утверждал через NY Times что проблемы кернелмодной малвары не существует, поскольку якобы сложно писать. Пипл хавает и платит деньги за иллюзию защиты. Обсуждаемый здесь код раскрывает подлог.

Видимо мне следовало про писать в ответе навопрос, а не на ответ.

O>А я чета не понял к чему тут эти два абзаца.

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

Та лёгкость, с котороя я применяю слова "афёра" и т.п.? ну а как ещё это можно назвать, что бы не соврать?

O>Указанный код не является уязвимостью сам по себе.

Конечно не является. Это эксплуатация уязвимости. В данном случае под уязвимостью подразумевается не пресловутое переполнение буфера, а дефекты архитектуры ряда фаерволов, которые эксплутатирует SMTPClientSendEMail().

GN>Ещё раз: Alfred Huger, vice president of Symantec's Security Response team, утверждал через NY Times что проблемы кернелмодной малвары не существует, поскольку якобы сложно писать. Пипл хавает и платит деньги за иллюзию защиты. Обсуждаемый здесь код раскрывает подлог.
ааа... приношу свои извинения, неправильно вас с Альфредом понял

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, Bardano, Вы писали:

B>>Малварное в нём только то, что он обращается напрямую к устройствам \Device\Tcp, \Device\Udp и пр.,
B>>минуя возможные фильтрующие устройства в стеке устройств.

GN>Когда MS реализует поддержку серверной части HTTP протокола в ядре — понятно, ускоряют IIS.

GN>Есть ли хоть одно (не связанное с массовой раассылкой) применение SMTP клиента, когда будет оправдан перенос в ядро?

B>>В остальном этот код предназначен для упрощения программирования
B>>сети в режиме ядра.

GN>Ну, то есть код — в первую очередь предназначен для людей, а как его можно использовать? Судя по примеру, можно взять его и написать спамбота. Примеры других применений отсутствуют. Отсюда и утверждение о 100%

GN>С другой стороны, де-юре код чист и не нарушает правила ресурса.

Да. Всё так. Формально код ничего злонамеренного не содержит (за исключением вышеупомянутого \Device\Tcp, \Device\Udp и пр., что легко устранить). Использоваться может, конечно же, в malware, откуда он и взят. Сам по себе служит для упрощения программирования сети. SMTP-клиент в проекте — только для демонстрации интерфейсных функций модуля. Полагаю, что могут существовать НЕзлонамеренные задачи, для решения которых может потребоваться программирование сети в режиме ядра. Два месяца назад, когда передо мной возникла эта задача — программирования сети в режиме ядра, сложность и непонятность интерфейса TDI повергла меня в удручённость. Такого простого интерфейса как этот мне не хватало. В публикации этого кода, упрощающего программирование сети в режиме ядра, ничего опасного не вижу (имелось в виду, что сложность использования TDI будет преградой в деятельности авторов спамботов?). Интерфейс WSK, появившийся в Windows Vista, почти так же прост как интерфейс этого модуля. И, поскольку Windows XP и Windows Server 2003 на данный момент весьма распространены и в них нет WSK, а в Windows 7 УЖЕ нет TDI, я решил реализовать такой WinSock-подобный интерфейс для программирования сети в режиме ядра, который бы не имел зависимости от целевой платформы, для которой строится драйвер. Опубликовал его с целью получить отзывы, советы и сообщения об обнаруженных ошибках.

B>Два месяца назад, когда передо мной возникла эта задача — программирования сети в режиме ядра

Какая же эта была задача? Поведай нам.

B>в Windows 7 УЖЕ нет TDI...

Есть.

Здравствуйте, ononim, Вы писали:

O>мда, а что дальше? нафиг тогда юзермод? Он ведь для слабаков с коротким членом да? Потом еще кто нить выложит враппер для win32k.sys и начнем гуишные апликухи писать в виде .sys файлов? Настоящие мужчины пишут исключительно под кернелмод, правда?

Какое... я бы сказал, этологичное восприятие ситуации!

O>Дело не в том наскока сложно написать безглючный кернелмоде код. Дело в том что это сделать не проще, чем безглючный юзермоде код, с той лишь разницей что любой баг--> bsod в лучшем случае, local elevation vulnerability в обычном случае и remote privileged code exeution vulnerability в худшем . Именно для того и был юзермод задуман чтобы этого избежать. А пихание всего чего можно в кернелмод вернет вин системы в эпоху win'9x, где кернелмод был по сути формальностью. И кроме того нарушает основополагающий принцип любой системы безопасности — принцип минимальных привилегий, причем совершенно независимо от длины вашего чле... то есть от вашей способности писать безглючный код.

Конечно же, для большинства прикладных задач наиболее удачное решение — это User-Mode приложение или служба. Нет опасности BSOD, разделение привилегий и прочее упомянутое. Но, думаю, МОГУТ быть задачи, требующие программирования сети в Kernel-Mode... Впрочем, ничего кроме моей malware задачи мне в голову не приходит.

P.S. На тему этологии

:
"ТРАКТАТ О ЛЮБВИ, как её понимает жуткий зануда" — Анатолий Протопопов
"Фаллос как зеркало иерархии" — Анатолий Протопопов

Здравствуйте, x64, Вы писали:

B>>Два месяца назад, когда передо мной возникла эта задача — программирования сети в режиме ядра
x64>Какая же эта была задача? Поведай нам.
К примеру, сетевая файловая система. Дополнительный двойной переход user-kernel на каждый вызов уж очень убивает производительность и так небыстрого файлового стека.

C>К примеру, сетевая файловая система.

Да я знаю примеры, remote storage опять же (сейчас, кстати, занимаюсь темой). Мне интересно, что у автора конкретно было.

Здравствуйте, x64, Вы писали:

B>>Два месяца назад, когда передо мной возникла эта задача — программирования сети в режиме ядра

x64>Какая же эта была задача? Поведай нам.

Малварная. На этом ресурсе о ней нельзя, да?

B>>в Windows 7 УЖЕ нет TDI...

x64>Есть.

Правда?

Повсюду в MSDN — предупреждения, что поддержки TDI после Windows Vista не будет.

Здравствуйте, x64, Вы писали:

C>>К примеру, сетевая файловая система.

x64>Да я знаю примеры, remote storage опять же (сейчас, кстати, занимаюсь темой). Мне интересно, что у автора конкретно было.

Не могли бы Вы обратить внимание на пост TDI Listen/Accept Code Problem?
Я не могу найти причину того, почему TDI Listen/Accept код не работает.

Здравствуйте, mansur, Вы писали:

P>>Думаю, будет интересно...

M>К сожалению только на Windows х86 системах, из-за неподписанных драйверов...

Это замечание относится не к обсуждаемому Kernel Sockets Module, а ко всем драйверам для x64.

	От:	-prus-
	Дата:	15.03.10 10:33
	Оценка:	6 (2)

	От:	TarasCo
	Дата:	15.03.10 13:45
	Оценка:	+1

	От:	-prus-
	Дата:	15.03.10 15:12
	Оценка:

	От:	Bardano
	Дата:	15.03.10 15:56
	Оценка:	6 (1) +1

От:	mansur	https://netmontools.com
Дата:	16.03.10 05:00
Оценка: