Всё так страшно

[vg]

http://www.microsoft.com/technet/treevi ... 03-046.asp

И самое главное, как в этом поучаствовал сам мелкософт ))) Предлагаю обсудить эти страсти – мордасти.

Речь идёт о двух простых и безобидных вещах.
1) Если руки-крюки, то существует вероятность (мелкософт говорит, что это, ну очень страшно), что хацкер-удалёнец заполучит один из экаунтов (имя пользователя + его парольчик). Конечно, если это случится, то вы рискуете стать спамером. Никакое запрещение релэя вас не спасёт, т.к. вполне легально с вашего smtp и под вашем экаунтом удалёнец будет рассылать эротические картинки, перемежающиеся с рекламой корма для собак (разумеется, при этом предполагается, что вы не подозреваете, что вас уже ну…. того…. этого…. ).

2) Мелкософт говорит, что возможно и удаленное произвольного кода и DoS (это не самое смешное, почитайте методы лечения в ссылке), но об этом позже.

Началось всё в сентябре-октябре. Дыру нашли Китайцы, как указано
http://www.winnetmag.com/MicrosoftExcha ... 40507.html
http://www.winnetmag.com/Windows/Articl ... 40543.html
Возможно и раньше, но то, что Китайцы безобразничают - точно.
Этой мелкой пакости даже дали гордое название «Новый вид SMTP AUTH атаки», см. статьи выше.

В 20-х числах мелкософт поместил вышеупомянутую статью на течнет. Дальше понеслось. Люди стали пробовать. Думаете защищаться? Нет - других хацкать, поскольку мелкософт уже протрубил на весь мир о своей дырке. И рассказал, по существу, как это можно реализовать. Любопытные стали пробовать - а действительно эта «дырка работает»?

Лично моё мнение – в общем случае не работает. Ниже собственно, что вы можете увидеть в своих логах (если вас уже…. того …. этого) и мои аргументы в том, что ничего архи-ужасного не происходит.

23-го октября в Eventview – вере я обнаружил совершенно наглую попытку залогониться «административно» (вернее там удалённая попытка подобрать пароль):

Event Type: Failure Audit
Event Source: Security
Event Category: (2)
Event ID: 539
User: NT AUTHORITY\SYSTEM
Computer: MYSERVER
Logon Failure:
Reason: Account locked out
User Name: administrator
Domain:
Logon Type: 3
Logon Process: Advapi
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Workstation Name: MYSERVER
…
…

Event Type: Failure Audit
Event Source: Security
Event Category: (2)
Event ID: 529
User: NT AUTHORITY\SYSTEM
Computer: MYSERVER
Logon Failure:
Reason: Unknown user name or bad password
User Name: administrator
Domain:
Logon Type: 3
Logon Process: Advapi
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Workstation Name: MYSERVER

Это был явный подбор пароля, поскольку таких записей в логе было около 40. Смотрим дальше.
В логе фаервола (для тех секунд) было почти всё хорошо и допустимо с точки зрения IDS – все пакеты «легальные»:

218.7.157.238 x.y.w.z 1906 25 SYN
x.y.w.z 218.7.157.238 25 1906 SYN ACK
218.7.157.238 x.y.w.z 1917 25 SYN
x.y.w.z 218.7.157.238 25 1917 SYN ACK
218.7.157.238 x.y.w.z 1929 25 SYN
x.y.w.z 218.7.157.238 25 1929 SYN ACK
218.7.157.238 x.y.w.z 1943 25 SYN
x.y.w.z 218.7.157.238 25 1943 SYN ACK
218.7.157.238 x.y.w.z 1906 25 ACK
x.y.w.z 218.7.157.238 25 1906 PSH ACK
218.7.157.238 x.y.w.z 1958 25 SYN
x.y.w.z 218.7.157.238 25 1958 SYN ACK
218.7.157.238 x.y.w.z 1917 25 ACK
218.7.157.238 x.y.w.z 1971 25 SYN
x.y.w.z 218.7.157.238 25 1971 SYN ACK
218.7.157.238 x.y.w.z 1929 25 ACK
218.7.157.238 x.y.w.z 1987 25 SYN
x.y.w.z 218.7.157.238 25 1987 SYN ACK
218.7.157.238 x.y.w.z 1943 25 ACK
218.7.157.238 x.y.w.z 2002 25 SYN
x.y.w.z 218.7.157.238 25 2002 SYN ACK
218.7.157.238 x.y.w.z 1906 25 PSH ACK
x.y.w.z 218.7.157.238 25 1906 ACK
218.7.157.238 x.y.w.z 1958 25 ACK
x.y.w.z 218.7.157.238 25 1958 PSH ACK
x.y.w.z 218.7.157.238 25 1917 PSH ACK
x.y.w.z 218.7.157.238 25 1929 PSH ACK
x.y.w.z 218.7.157.238 25 1943 PSH ACK
218.7.157.238 x.y.w.z 2019 25 SYN
x.y.w.z 218.7.157.238 25 2019 SYN ACK
218.7.157.238 x.y.w.z 1971 25 ACK
218.7.157.238 x.y.w.z 1987 25 ACK
218.7.157.238 x.y.w.z 2035 25 SYN
….
…

Всего хендшейков - 23 и все почти сразу ))). Анормальность с точки зрения обычного трафика SMTP – огромное число активных соединений. Это не обычный флуд. Все соединения завершены вполне корректно, т.е.
…
…
218.7.157.238 x.y.w.z 1958 25 FIN ACK
x.y.w.z 218.7.157.238 25 1958 ACK
x.y.w.z 218.7.157.238 25 1958 FIN ACK
218.7.157.238 x.y.w.z 1958 25 ACK

В логе Exchange сервера обнаружились соответствующие по времени следующие записи (46 записей).

218.7.157.238 softht SMTPSVC1 MYSERVER EHLO +softht
218.7.157.238 softht SMTPSVC1 MYSERVER EHLO +softht
218.7.157.238 softht SMTPSVC1 MYSERVER EHLO +softht
218.7.157.238 softht SMTPSVC1 MYSERVER EHLO +softht
….
…..
218.7.157.238 softht SMTPSVC1 MYSERVER QUIT softht
218.7.157.238 softht SMTPSVC1 MYSERVER QUIT softht
218.7.157.238 softht SMTPSVC1 MYSERVER QUIT softht
218.7.157.238 softht SMTPSVC1 MYSERVER QUIT softht

Анормальность в этом логе такая же, как и в логе фаервола.

Соображения о том, что это не может представлять серьёзную угрозу:

1) попытки видны во всех логах. Даже, если админ не знает, что происходит – можно просто прикрыть трафик на фаерволе от злодеев.

2) попытки вряд ли увенчаются успехом, поскольку при минимальном качестве администрирования любой экаунт будет заблокирован уже после 3-5 неудачных попыток логон. Времени посмотреть любые из перечисленных логов будет навалом для админа.

3) соображения о возможности удалённого выполнения кода мне кажутся абсурдом (в данной ситуации). Переполнения буфера, как и знание административного экаунта – не позволят передать управление на другому деструктивному процессу в данном случае. Если знаете как, напишите. Этот процесс уже должен в таком случае существовать.

4) про DoS я вообще молчу. Исследователь паролей должен действовать скрытно, надеясь более на социальный инжинеринг. Иначе его заметит в логах даже самый ленивый админ.

5) Теоретически подобрать имя пользователя и соответствующий пароль, конечно, можно. Но вот вопрос – а что потом с этим административным экаунтом делать-то? Как удалённо будем запускать деструкцию, если зачастую наружу торчит только 25, и 110 порт?

Как думаете, отцы сисадмины?

[vg]

Не понимаю, почему никто не хочет зубы поскалить? Я просто негодую, я весь вышел из себя, читая юмористические рассказы мелкософта на течнете. Вот слегка отрихтованный перепост с одного форума.

ВНАЧАЛЕ ОБ ЭТОМ
*************************************

>What does this patch do?
>For Exchange 2000 Server the patch removes the vulnerability by requiring that the authentication used >etween Exchange servers within an Exchange organization is used before an Exchange server accepts >the SMTP extended verb requests. Additionally, this patch implements correct input validation in the >affected buffer.

Если это ответ технарям, то здесь три раза смешно:

1) Здесь сказано про обмен МЕЖДУ «…Exchange servers within an Exchange organization…». Т.е. про то, что Билл Гейтс мечтает, дескать, весь мир только и использует его продукты. Комментировать - не возможно. То, что выше написано про обмен МЕЖУ MS EXHANGE ( И ТОЛЬКО МЕЖДУ НИМИ ) имеет очень отдалённое отношение (если имеет вообще) к Сети, где и sendmail-ы иногда встречаются.

2) “…before an Exchange server accepts >the SMTP extended verb requests…» Это каки-таки рексвесты? Ну, надо же написать народу-то. Какую ещё дырку мелкософт оставил, для каких команд smtp? Об этом см. ниже.

3) «…Additionally, this patch implements correct input validation in the >affected buffer ..». Если посмотреть те дополнительные ссылки, которые есть на этой же странице, то там написано

см. http://www.cve.mitre.org/cgi-bin/cvenam ... -2003-0714

The Internet Mail Service in Exchange Server 5.5 and Exchange 2000 allows remote attackers to cause a denial of service (memory exhaustion) by directly connecting to the SMTP service and sending a certain extended verb request, possibly triggering a buffer overflow in Exchange 2000.

Ну, каких буферов? Да их для разных служб может быть тысячи. Далее там написано про специально подготовленные хакерские пакеты, которые укладывают в SMTP. То же написано на странице течнета выше:

Technical Description:
In Exchange 2000 Server, a security vulnerability exists that could allow an unauthenticated attacker to connect to the SMTP port on an Exchange server and issue a specially-crafted extended verb request. That request could cause a denial of service that is similar to the one that could occur on Exchange 5.5. Additionally, if an attacker issues the request with carefully chosen data, the attacker could cause a buffer overrun that could allow the attacker to run malicious programs of their choice in the security context of the SMTP service.

Нифига себе. Значит нужно у мелкософта спросить, что они такого оставили в реализации SMTP для специальных реквестов, что может напрочь убить этот сервайс. Только вот какое это отношение это имеет к обсуждаемой тематике – к нехорошему использованию команды AUTH плохими мальчиками? Так бы и сказали – косяково написан SMTP, и вне зависимости к обсуждаемой проблематике.

Вообще-то здесь я не понял, и вот чего «… could allow the attacker to run malicious programs ….». Ну как можно сорвать стек, или переполнить буфер, чтобы затем передать управление на деструктивный код атакера, при условии, что это «делается это по SMTP»? Этож самое интересное.

ТЕПЕРЬ ОБ ЭТОМ
*************************************
на той же странице течнета

Workarounds
• Use SMTP protocol inspection to filter out SMTP protocol extensions.
There are default ISA publishing rules for Exchange for filtering out any SMTP protocol extensions from traffic that passes the firewall. Other third-party products may offer similar functionality. More information on how to publish an Exchange server computer with ISA Server can be found at:
http://support.microsoft.com/default.as ... -us;311237.

Ссылка выше ничего общего с обсуждаемой проблематикой не имеет. Там написано, как прикрутить Ексченжди с прокси или исой. Там речь идёт о том, как заставить Ексчендж слушать требуемые порты и соответствующим образом отвечать удалённым хостам. Фильтрация, которая обсуждается в той статье – это обычные фильтры для smtp. Там и слова нет про «smtp auth – атаку». Более того. Эти фильтры по определению «пропускают» любой почтовый трафик, с любым MIME.

Продолжаем смеяться дальше:

• Only accept authenticated SMTP sessions.
If practicle, accept only connections from SMTP servers that authenticate themselves by using the SMTP AUTH command.
To require SMTP authentication on an Exchange 2000 server:
1. Start Exchange System Manager.
2. Locate the server in the organization tree.
3. Expand the Protocols container for the server.
4. Expand the SMTP container.
5. For each SMTP virtual server:
• Open the properties and of the virtual server object.
• Click the Access properties page.
• Click the Authentication button.
• Clear the "Anonymous Access" checkbox.
• Click OK to accept the change.

Здесь товарищи от мелкософта просто сошли с ума, думая, что других серверов, кроме Ексчандж не существует. А я, например, хочу почту с mail.ru получать. Этот совет мелкософта – полный дэбилизм. Если сделать так, то вы будете «общаться» только с ограниченным кол-вом почтовых серверов. Похоже, что тот, кто написал ЭТО - даже не прочитал соответствующий раздел хелпа Ексчанджа.

А вот теперь уже умираем со смеху:

• Use a firewall to block the port that SMTP uses.
Use a firewall to block the port that SMTP uses. Typically, that is port 25.

Ну, а этот совет заблокировать 25 порт я комментировать просто не могу. Что здесь сказать, мелко-гуру-йцы и есть мелко.


ПС. Всё это было б так смешно, если б не было так грустно.