|
Преди да разгледаме някои специфични атаки, ще бъде от полза да разгледаме как по принцип се изпраща атакуваща (malicious) поща. Това не е толкова просто, както някои може би са си го представяли, защото повечето съвременни e-mail клиенти с графичен интерфейс не позволяват директно манипулиране на заглавната част (header) на SMTP-блока (SMTP= Simple Mail Transfer Protocol, което е основен Интернет-протокол за електронна поща). Microsoft може да е тотално оплюван за безразличето, с което се отнася към сигурността на получателя, но трябва да му се признае, че с програми като Outlook (по-нататък само "O") и Outlook Express ("ОЕ") е доста трудно да се изпрати злоумишлено кодиран HTML-текст. От друга страна, потребителите на UNIX не би следвало да имат никакъв проблем с използването на мейл-клиенти, работещи в чисто текстов режим от команден ред.
Под Windows предпочитаният механизъм е ръчното изпращане на съобщение директно до SMTP-сървъра от команден ред (промпт). Най-добрият начин да се постигне това е да се предаде текстов файл със съответните SMTP-команди и данните към тях чрез netcat. Това е една многофункционална програма, разпространявана още и само като nc), която е трудно да бъде описана (и затова няма да го правя). Неин автор е Hobbit (). Един от многото й възможни режими на работа е пренасочване на текст към мейл-сървър. Ето как става това.
Първо, създаваме текстов файл с желаните SMTP-команди и данни към тях (нека наречем този файл evilmail.txt). При създаването на този файл е най-важно да се декларира съответния MIME-синтаксис (MIME = Multi-part Internet Mail Extension), за да бъде съобщението правилно форматирано. Типичното приложение предполага този текст да бъде изпратен в HTML-формат, така че "тялото" на съобщението се превръща в атакуващия компонент. Критичната част в текста по-долу са трите реда, започващи с "MIME-Version: 1.0". Ето така:
helo
mail from: <haralampi@nyakakyvserver.com>
rcpt to: <neshtastna@zhertva.com>
data
subject: Pechelish computer!
Importance: high
MIME-Version: 1.0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<h2>Zdrasti, kopele!</h2>
</HTML>
.
quit
Както споменах, използваме netcat (или nc), за да пренасочим текста на файла към желания мейл-сървър, който слуша SMTP-команди с данни на порт 25. Това става със следния команден ред:
type evilmail.txt | nc -vv mail.openrelay.net 25
Според мен е излишно да уточнявам, но за съвсем новаците нека поясня, че е КРАЙНО желателно не да пратите пощата директно на сървъра на получателя, а да използвате препращащ (relay) мейл-сървър (да обяснявам ли защо?), който предлага нецензурирано препращане на SMTP-съобщения и предприема всички необходими мерки, за да скрие собствения си IP-адрес, така че да остане непроследим дори след анализ на log-файла на мейл-сървъра, до който се изпраща пощата. Подобни "open SMTP relays" са любим ресурс на спамерите, могат лесно да се изровят от дискусиите в Usenet и понякога могат дори да се намерят на .
Нещата се усложняват, ако искате да изпратите attachment към HTML-форматираната поща. За целта се прибавя нов MIME-раздел към съобщението и се кодира attachment-а в т.н. Base 64 (както е описано в MIME-спесификацията RFC-та с номера 2045 - 2049). Това става най-лесно с приложната програма mpack на John G Myers (достъпна на ). Mpack услужливо добавя и съответните MIME-заглавни части (header-и) така, че изгодът от работата й става за директно изпращане до SMTP-сървър. Ето пример за команден ред, преобразуващ (кодиращ) файла xxx.txt в yyy.mim. Командният параметър '-s Predupreden-si' задава съдържанието на полето 'subject', т.е. е опционален (незадължителен):
mpack -s Predupreden-si -o yyy.mim xxx.txt
Сега идва ред на по-сложната част. Така създадения нов MIME-раздел трябва да бъде вмъкнат в съществуващото форматирано HTML-съобщение. За по-ясно, нека използваме горния пример (с файла evilmail.txt) и разбием съобщението на потребителски дефинирани MIME-раздели, които се дефинират на редове 'Content-Type:'. MIME-границите се предхождат от две тирета ('--'), а затварящата граница има наставка от също две тирета. В примера по-долу отбележете вложеното използване (nesting) на "multipart/alternative" MIME-раздела (boundary2), така че получателите, използващи "О" да могат да декодират коректно тялото на HTML-съобщението. Обърнете специално внимание на празните редове, защото MIME-синтаксиса се интерпретира различно в зависимост от празните редове. Последна забележка: задаваме Importance (важност) на съобщението 'high', за да хипнотизираме допълнително жертвата. Ето крайния резултат:
helo
mail from: <haralampi@nyakakyvserver.com>
rcpt to: <neshtastna@zhertva.com>
data
subject: Pechelish computer!
Importance: high
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="_boundary1_"
--_boundary1_
Content-Type: multipart/alternative
boundary="_boundary2_"
--_boundary2_
Content-Type: text/html; charset=us-ascii
<HTML>
<h2>Zdrasti, kopele!</h2>
</HTML>
--_boundary2_--
--boundary1_
Content-Type: application/octet-stream; name="xxx.txt"
Content-ID: <5551212>
Content-Transfer-Encoding: inline; filename="xxx.txt"
Content-MD5: Psn+mcJEv0fPwoEc4OXYTA==
SSBjb3VsZGEgaGFja2VkIHlhIGJhZCANCg==
--_boundary1_--
.
quit
Пренасочването на този текст с помощта на netcat към отворен SMTP-сървър ще завърши с изпращането на HTML-форматирана поща с прикрепен (attachment) файл xxx.txt до получател с адрес neshtastna@zhertva.com. За по-пълно разбиране на използването на MIME-граници в многоразделни (multipart) съобщения можете да прочетете RFC 2046 (Section 5.1.1) на адрес . Доста информативно е също да разгледате някаква тест-поща, изпратена до "ОЕ". За целта, изберете Properties | Details | Message Source, за да видите "суровите" данни (за разлика от "ОЕ", "О" няма да ви позволи да видите всички "сурови" SMTP-данни).
Описаният по-горе метод (с или без attachment-a) ще бъде често споменаван по-нататък като MHC (mail-hacking capsule - ядро на атака с електронна поща).
Общи препоръки за защита срещу атака с електронна поща
От описанието по-горе е ясно, че е желателно да се забрани обработката (rendering) на HTML-форматираната поща. За нещастие, това е или доста трудно или направо невъзможно при повечето съвременни e-mail клиенти.
Също така е "здравословно", ако забраните допълнителените web-възможности под формата на т.н. "технологии за мобилен код": за "О"/"ОЕ" изберете Tools | Options | Security и в прозореца за настройка, който ще се покаже, идете в раздела "Secure content" и изберете от списъка на възможните опции за параметъра "Zone" стойност "Restricted sites". И помнете, че тази настройка не е валидна при работа с IE, който има отделна настройка. Тази проста предпазна мярка решава голяма част от проблемите, за които ще стане дума по-нататък. Силно се препоръчва!
Разбира се, препоръчва се още предпазливост при разбота с пркрепените файлове (attachments). Полезно е да се знае, че повечето проблеми, породени от получена електронна поща, са свързани с известно "съучастие" от страна на получателя. Microsoft предлага patch за "O" на адрес , който прави малко по-трудно автоматичното стартиране на attachment-и, като принуждава потребителя да мине през поне два диалогови прозореца за потвърждение, преди да се стигне до активиране на ежентуално приложената зловредна програма (същият patch задава по подразбиране и правилната стойност на параметъра Zone на Restricted sites, както е описана по-горе). По-наттаък ще видите, че това не е панацея, но все пак повдига значително летвата пред потенциалните хакери. Вие можете да я повдигнете още малко като възприемете принципа: "НЕ ОТВАРЯМ ПИСМА И НЕ СВАЛЯМ ПРИКРЕПЕНИ ФАЙЛОВЕ, ИЗПРАТЕНИ МИ ОТ НЕПОЗНАТИ!".
Следващият постинг (ако има такъв) ще бъде с тема "EMH #2: Стартиране на произволен код през електронна поща"
In a Tokyo bar:
Special cocktails for the ladies with nuts.
|
EMH #1: Основни положения [re: Delwin-]
