В минулому і цьому році я знайшов Cross-Site Scripting уразливості в різних браузерах (IE, Chrome і Opera), що відносяться до типу Saved XSS. Про дані XSS я писав раніше, зокрема в проекті День багів в браузерах 2. І нещодавно, 14.11.2008, я розробив методику проведення Code Execution атаки через дані XSS уразливості.
Зараз розповім про Code Execution атаку через Cross-Site Scripting уразливість в Internet Explorer.
Атака працює при збереженні в IE веб сторінки на комп’ютер користувача і наступному її відкритті в IE. Дана методика може використовуватися для обходу різних проксі й фаєрволів, що аналізують зміст веб сторінок на предмет шкідливого коду (тому що атакуючий код з’являється в сторінці вже після збереження). А також може використовуватися для обходу антивірусів.
Code Execution:
http://site/?--><script>c=new/**/ActiveXObject('WScript.Shell');c.Run('calc.exe');</script>
Символи коментарю “/**/” потрібні, щоб обійти обмеження IE на пробіли, який замінює їх в URL на %20 і не конвертує назад при збереженні сторінки. Зате він робить це при використанні iframe в коді сторінки, тому в цьому випадку коментарі не потрібні.
Для проведення прихованої атаки можна використати iframe:
<iframe src="http://site/?--><script>c=new ActiveXObject('WScript.Shell');c.Run('calc.exe');</script>" height="0" width="0"></iframe>
Дана атака працює в Internet Explorer коли ввімкнена (Enabled чи Prompt) опція “Initialize and script ActiveX control not marked as safe” (для Local intranet). Це такий баг в дірці Microsoft і це метод обходу багу. Дане налаштування потрібне лише при атаці через цю XSS, коли JS код знаходиться на тому ж рядку, де і коментар. Бо коли на іншому рядку (тобто без передуючого коментарю), то код спрацьовує і без цієї опції (Disable). Що може бути досягнуто у випадку, якщо атака проводиться не через XSS, а безпесередньо в тілі сторінки розміщений (відповідним чином) атакуючий код.
Уразлива версія Internet Explorer 6 (6.0.2900.2180) і попередні версії. Та Internet Explorer 7 (7.0.6000.16711) і попередні версії.