Websecurity - Веб безпека

В даній добірці експлоіти в веб додатках:

• PHPWCMS Cross-Site Request Forgery Vulnerability exploit (деталі)
• Apple Safari 4.0.3 null pointer dereference exploit (деталі)
• Safari 4.0.3 (Win32) CSS Remote Denial of Service Exploit (деталі)
• DM Filemanager (fckeditor) Remote Arbitrary File Upload Exploit (деталі)
• TFTP Daemon Version 1.9 Remote Buffer Overflow Exploit (деталі)

Ще в березні, 22.03.2010, Андрій Терещенко повідомив розробникам системи LiqPAY та написав в Bugtraq про уразливість в LiqPAY. Дана уразливість стосується sms-повідомлень для авторизації в системі.

Про уразливості в Приват24 (версія для Facebook), оприлюднені Андрєм в жовтні, я вже писав. Зазначу, що дана уразливість в sms-ках LiqPAY ідентична одній з уразливостей в sms-ках Facebook-версії Приват24. І ПриватБанку варто було виправити дану уразливість в Приват24 для Facebook так само, як вони це зробили в LiqPAY.

Тоді ж він отримав відповідь від ПБ, що вони не вважають це уразливістю. Але вже в березні LiqPAY виправив дану уразливість (хоча від всіх фішинг атак це не захистить). Що я добре знаю, тому що активно використовую дану систему (з листопада 2009 року). Це один з тих рідких випадків, коли ПриватБанк виправив уразливості в своїх сервісах чи сайтах.

11.03.2010 LiqPAY змінили текст sms-ки (додавши пораду не давати пароль іншим особам).
27.03.2010 LiqPAY додали в текст sms-ки адресу сайта.

• Insecure SMS authorization scheme at LiqPAY micro-payments of PrivatBank (Ukraine) (деталі)

Після попереднього дослідження інфікованих сайтів, приведу нову інформацію про заражені сайти. З числа українських сайтів.

• http://hotfile.name - інфекція була виявлена 06.10.2010. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 19 разів протягом останніх 90 днів. Зараз сайт не входить до переліку підозрілих.
• http://greenshop.kiev.ua - інфекція була виявлена 17.10.2010. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 14 разів протягом останніх 90 днів. Зараз сайт входить до переліку підозрілих.
• http://spetskontract.com - інфекція була виявлена 17.10.2010. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 3 рази протягом останніх 90 днів. Зараз сайт не входить до переліку підозрілих.
• http://comprostat9.com - інфекція була виявлена 26.09.2010. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 1 раз протягом останніх 90 днів. Зараз сайт входить до переліку підозрілих.
• http://elnik.kiev.ua - інфекція була виявлена 05.10.2010. Частина цього сайта була внесена до переліку сайтів із підозрілою активністю 11 разів протягом останніх 90 днів. Зараз сайт не входить до переліку підозрілих.

03.02.2010

У червні, 28.06.2009, я знайшов SQL Injection уразливість на сайті http://www.dala.com.ua. Про що найближчим часом сповіщу адміністрацію сайта.

Детальна інформація про уразливість з’явиться пізніше. Треба дати час адмінам на реакцію з цього приводу.

18.10.2010

SQL Injection:

http://www.dala.com.ua/index.php?menu_id=-1%20or%20version()=5

Дана уразливість досі не виправлена.

Як повідомив Андрій Терещенко, в Приват24 (версія для Facebook) є уразливості, що дозволяють обійти статичний пароль для акаунтів ПриватБанку. Уразливість стосується саме версії Приват24 для Facebook і звичайна система Приват24 невразлива.

Тому всі користувачі Facebook, що користуються клієнтом Приват24 для цієї соціальної мережі, повинні бути дуже обережні. Враховуючи наявність уразливостей, що дозволяють отримати доступ до вашого рахунку після логіна через клієнт Приват24 для Facebook (у ваш чи інший Facebook-акаунт), а також враховуючи, що ПриватБанк відмовився виправляти дані уразливості.

Цікаво, що банк навіть відповів йому на дане повідомлення про уразливості (тому що на всі ті численні повідомлення про уразливості в 2008-2010 роках ПриватБанк ні разу мені не відповів). Заявивши, що виправляти уразливості не будуть, тому що “Insecurity accepted as trade-off”. В чому немає нічого нового і це є типовим явищем для ПриватБанка. Бо даний банк не виправив майже жодної уразливості про які я їм повідомив, як я вже зазначав в новинах.

• Privat24 (Facebook version) bypass of static password for accounts of PrivatBank (Ukraine, Russia and CIS) (деталі)

Продовжуючи традицію, пропоную вашій увазі цікаві секюріті статті. Щоб ви поповнювали свої знання з веб безпеки.

Добірка цікавого чтива на тему безпеки, в тому числі web security (статті з Вікіпедії):

• Predictable serial number attack
• Privilege escalation
• Race condition
• Racetrack problem
• Reflection attack

В даній добірці уразливості в веб додатках:

• VMware vCenter, ESX patch and vCenter Lab Manager releases address cross-site scripting issues (деталі)
• XSRF (CSRF) in phpwcms (деталі)
• XSS vulnerability in WebPress (деталі)
• HP OpenView Data Protector Cell Manager Heap Overflow Vulnerability (деталі)
• Hewlett-Packard OpenView Data Protector Backup Client Service Buffer Overflow Vulnerability (деталі)
• HP OpenView Storage Data Protector, Remote Arbitrary Code Execution (деталі)
• Conpresso CMS - Cross site Scripting vulnerabilities (деталі)
• RedShop 1.0.23.1 Joomla Component Blind SQL Injection Vulnerability (деталі)
• New firefox-sage packages fix insufficient input sanitizing (деталі)
• Jira Enterprise 4.0.1 - Multiple Low Risk Vulnerabilities (деталі)

В веб секюріті діяльності та при веб розробці нерідко виникає потреба в визначенні серверних заголовків. Наприклад при аудиті безпеки сайтів чи розробці веб додатків. В заголовках сервера може бути багато цікавої інформації, зокрема витоки версій веб сервера та його модулів, а також версій веб додатків.

Існують спеціальні програми для визначення заголовків серверів. Але найбільш зручним інструментом, як для мене, є плагіни до браузерів, що дозволяють переглядати заголовки (як ті, що відправляються до сервера, так і ті, що повертає сервер). Зокрема є такий плагін для Mozilla та Firefox як Live HTTP headers, яким я користуюся вже багато років.

Також існують різні онлайн сервіси, що дозволяють визначати серверні заголовки на довільних сайтах. Одними з таких сервісів є www.onlinewebcheck.com (відомий також як online.htmlvalidator.com) та about42.nl, про уразливості в яких я писав раніше. Так що всі подібні сервіси без захисту від Insufficient Anti-automation можуть бути використанні для атак на інші сайти, про що я писав в статті Використання сайтів для атак на інші сайти. Для цього можна використати DAVOSET.

На сторінці http://www.onlinewebcheck.com ви можете провести валідацію html та подивитися серверні заголовки довільного сервера.

А на сторінці http://about42.nl/www/showheaders.php ви можете подивитися серверні заголовки довільного сервера. По замовчуванню виводяться серверні хедери google.com.

Виявлені Cross-Site Scripting уразливості в SafeHTML Microsoft Sharepoint.

Уразливі продукти: Microsoft Sharepoint під Windows XP, Windows 2003 Server, Windows Vista, Windows 2008 Server, Windows 7.

Декілька можливостей міжсайтового скриптінга.

• Microsoft Security Bulletin MS10-072 - Important Vulnerabilities in SafeHTML Could Allow Information Disclosure (2412048) (деталі)

05.09.2010

У квітні, 16.04.2010, я знайшов Information Leakage уразливість в Apache. Дірку я виявив на сайті http://www.disperindag-jabar.go.id. Про що найближчим часом повідомлю розробникам Apache.

Стосовно уразливостей в Apache, раніше я вже писав про уразливість в Apache Tomcat.

Детальна інформація про уразливість з’явиться пізніше. Спочатку повідомлю розробникам веб сервера.

15.10.2010

Information Leakage:

Дану уразливість я назвав Forced Directory Indexing. Коли при спеціальному запиті до сайта виводиться зміст папки (при цьому обходяться будь-які індексні файли).

http://site/%3f/

Таким чином можна отримати зміст будь-якої папки на сайті, тобто відбувається витік інформації.

Спочатку я вирішив, що це уразливість в Apache (зокрема в Apache 1.3.37). Хоча я виявив її лише на одному сайті й більше не знайшов жодного вразливого сайта (з цією чи іншими версіями Apache). Але після розмови з розробниками Апача вияснилося, що це особливість конфігурації одного конкретного сайта і сам веб сервер не є вразливим. Тому адмінам сайтів на Apache варто бути більш уважними при використанні Options Indexes та Path Info.