от Vesselin Markov(18-04-2005)

рейтинг (53)   [ добре ]  [ зле ]

Printer Friendly Вариант за отпечатване



Предупреждение: Потребителите на Internet Explorer няма да могат да видят графиките към този документ поради несъвместимост на браузъра с RFC 2397 (инлайн обектни данни). Използваната потребителска информация е фиктивна и се стреми да демонстрира проблема.


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

Дискутираните уязвимости включват, но не са лимитирани до разгледаните случаи -- те имат много по-широко приложение.

Както е добре известно, целият трафик между клиент и сървър може да бъде записан и в последствие анализиран. Той може да бъде както криптиран, така и обикновен текст.

В случай при който злонамерено лице е добило достъп до такова устройство (напр. рутер, кеширащ сървър) през което минава браузинг трафика на клиентите, всичкият входящ и изходящ трафик може лесно да бъде прихванат с обикновен пакетен снифър като tcpdump, който освен да вижда хедърите на пакетите, може и да записва цялата информация съдържаща се в тях.

[снапшот 1]



Прави впечатление че тук липсва възможност за ползване на SSL, т.е. данните се подават в чист текст. Дори потребителят да не е наясно че предотставящите услугата не разполагат със SSL сертификат, браузърът му (ако е по-нов) ще го уведоми че изпраща данни в некодиран вид.

Въпреки това, най-често такива съобщения биват игнорирани.

Така например, ако целта е да се наблюдава трафика между сървърите на Нет Инфо БГ АД и по-конкретно тези които служат за безплатно хостване на поща (abv.bg/gyuvetch.bg/gbg.bg), и браузърите на клиентите, може да се подходи по следния начин:

tcpdump
linux# resolveip abv.bg
 IP address of abv.bg is 194.153.145.67
 IP address of abv.bg is 194.153.145.68
 IP address of abv.bg is 194.153.145.77
 IP address of abv.bg is 194.153.145.80
 IP address of abv.bg is 194.153.145.86
 
 linux# tcpdump -i any src or dst net 194.153.145.0/24 and port 80 -w abv.log -s 0
 tcpdump: WARNING: Promiscuous mode not supported on the "any" device
 tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
 366 packets captured
 375 packets received by filter
 0 packets dropped by kernel
 
 linux# file abv.log
 abv.log: tcpdump capture file (little-endian) - version 2. (Linux "cooked", capture length 65535)

Командният ред съдържащ tcpdump указва да се записва трафика от всички интерфейси, отговарящ на желаният критерй (по-горе). Чрез последният параметър (-s 0) се прихваща пълната големина на пакета.

Следващата стъпка е получената информация да се анализира. Това отново може да се извърши от tcpdump (с опция -r file), както и с помощта на strings (отпечатва всички символи които подлежат на прочит). В случая е използвана алтернативна програма за анализ на мрежи в графичен режим - ethereal.

[снапшот 2]



Изображение 2 онагледява записаните данни. От тук може да се проследи комуникацията / TCP поток.

[снапшот 3]



От изображение 3 е става ясно че информацията е била подадена в прочитаем вид като обикновена HTTP/1.1 POST заявка към скрипт /app/servlet/bg.abv.mail.Login. Съответно, потребителското име и парола са вече достояние на повече от един човек.

Стринг
username=testuser&hostname=abv.bg&password=testpass&LOGIN_LOGIN=+%C2%EB...

Лично мое мнение е че такъв подход е неправилен и е грешка от страна на собствениците на сайта. Потребителите на услугата не са предупредени за възможните импликации от липсата на адекватна осигуреност на личните им данни. Абсолютно същият дисплей се среща и при ред други доставчици на такъв вид услуги, включително Mail.BG, Mail.ru, Mail.com, наред с всичките им домейни.

Малко изключение прави DirBG, където има възможност за ползване на криптирана връзка, но това не става по подразбиране, нито потребителите са известени за проблемите които могат да очакват ако всеки път не я избират.

HTTP заявка
 POST / HTTP/1.0
 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, 
 application/vnd.ms-excel, application/vnd.ms-powerpoint, 
 application/msword, application/x-shockwave-flash, */*
 Referer: http://mail.dir.bg/
 Accept-Language: en-ie
 Content-Type: multipart/form-data;
 boundary=---------------------------7d51ee4c039e
 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.1.4322)
 Host: mail.dir.bg
 Content-Length: 534
 Pragma: no-cache
 Cache-Control: max-age=259200
 Connection: keep-alive
 
 -----------------------------7d51ee4c039e
 Content-Disposition: form-data; name="Username"
 lsbg_
 -----------------------------7d51ee4c039e
 Content-Disposition: form-data; name="Password"
 parolka
 -----------------------------7d51ee4c039e
 


Какво може да се направи от съответния доставчик ако няма намерение да се сдобие със сертификат?

Като за начало, задължително трябва да предупреди потребителите за възможните рискове на които подлежат. Би могъл да се употреби подход реализиран от пионери в бранша като Yahoo! Mail. При последните, дори клиентът да не избере сигурна връзка, информацята която браузърът изпраща към сървърите е вече частично кодирана с MD5. Въпреки колизиите наскоро намерени в този хеш, MD5 продължава да бъде сравнително надеждно средство за предпазване на релативни тип данни.

Пример:

MD5 стринг
/*
 * Take a string and return the hex representation of its MD5.
 */
 
 function MD5(str)
 {
         x = str2blks_MD5(str);
         var a =  1732584193;
         var b = -271733879;
         var c = -1732584194;
         var d =  271733878;
         
         for(i = 0; i < x.length; i += 16)
         {
                 var olda = a;
                 var oldb = b;
                 var oldc = c;
                 var oldd = d;
                 
                 a = ff(a, b, c, d, x[i+ 0], 7 , -680876936);
                 d = ff(d, a, b, c, x[i+ 1], 12, -389564586);
                 c = ff(c, d, a, b, x[i+ 2], 17,  606105819);
                 b = ff(b, c, d, a, x[i+ 3], 22, -1044525330);
                 a = ff(a, b, c, d, x[i+ 4], 7 , -176418897);
                 d = ff(d, a, b, c, x[i+ 5], 12,  1200080426);
                 c = ff(c, d, a, b, x[i+ 6], 17, -1473231341);
                 b = ff(b, c, d, a, x[i+ 7], 22, -45705983);
                 a = ff(a, b, c, d, x[i+ 8], 7 ,  1770035416);
                 d = ff(d, a, b, c, x[i+ 9], 12, -1958414417);
                 c = ff(c, d, a, b, x[i+10], 17, -42063);
                 b = ff(b, c, d, a, x[i+11], 22, -1990404162);
                 a = ff(a, b, c, d, x[i+12], 7 ,  1804603682);
                 d = ff(d, a, b, c, x[i+13], 12, -40341101);
                 c = ff(c, d, a, b, x[i+14], 17, -1502002290);
                 b = ff(b, c, d, a, x[i+15], 22,  1236535329); 
                 
                 [...]

[снапшот 4]



В много от свободно разработвания софтуер (като SquirrelMail) също не са положени минимални усилия за защита на информацията съборазно посочения вече сценарий, с презумция че удостоверяването ще се извършва винаги по защитен начин.

Ресурси

[1] Tcpdump - http://www.tcpdump.org
[2] Ethereal - http://www.ethereal.com
[3] Netinfo - http://www.abv.bg
[4] Yahoo! Mail - http://mail.yahoo.com


17 Април 2005




<< Ограничаване на upload-трафик | Linux + FreeBSD мини ръководство >>