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

Після появи такої техніки атаки як Clickjacking, розробленої Джеремією Гроссманом та Робертом Хенсеном в 2008 році, виробники браузерів почали замислюватися над методом протидії даній атаці. Щоб не чекати доки кожен окремий веб розробник почне додавати захист від Clickjacking (а також від MouseOverJacking, розробленої мною), а зробити захист на рівні браузера. Як це зробив розробник NoScript плагіна для Firefox, додавши подібний захист ще в 2008 році.

І на початку 2009 року, з виходом Internet Explorer 8, було розроблене рішення для протидії Clickjacking та MouseOverJacking атакам. Це http-заголовок X-Frame-Options. Це було одне з найкращих покращень безпеки в 2009 році (але в своєму записі я вже описав можливості обходу цього захисного методу). Детально про цей заголовок, його формат та значення заголовка, що підтримуються браузерами, ви можете прочитати на сайті Mozilla в статті The X-Frame-Options response header.

На даний час підтримуються наступні значення заголовка X-Frame-Options:

• DENY - сторінка (з будь-якого сайта) не може бути показа у фреймі.
• SAMEORIGIN - сторінка може бути показана у фреймі, якщо вона знаходиться на тому самому сайті (домені).

Спочатку Microsoft реалізувала його в своєму браузері IE8, а потім інші виробники браузерів додали його підтримку. На даний момент, за даними Мозіли, наступні браузери підтримують заголовок X-Frame-Options (починаючи з вказаних версій):

• Internet Explorer 8.0.
• Firefox 3.6.9 (Gecko 1.9.2.9).
• Opera 10.50.
• Safari 4.0.
• Chrome 4.1.249.1042.

Метод захисту від Clickjacking та MouseOverJacking атак за допомогою заголовка X-Frame-Options має свої переваги та недоліки.

Переваги методу:

1. Захист від атак через приховані frame та iframe.
2. Легкість реалізації на сайті - потрібно лише додати на необхідну сторінку (або на весь сайт) даний заголовок.
3. Два режима блокування: DENY і SAMEORIGIN.
4. Всі основні п’ять браузерів (їх останні версії) підтримують даний заголовок.

Недоліки методу:

1. Веб розробникам і адмінам потрібно додавати його підтримку на сайті, щоб захист спрацював у браузері. Тобто по замовчуванню всі сайти є уразливими до даних атак (навіть у версіях браузерів, що підтримують цей заголовок), доки на них не буде налаштоване виведення цього заголовка.
2. Методика атак через CSS, що я описав в статті про MouseOverJacking, дозволяє обходити даний захист та може застосовуватися для проведення Clickjacking та MouseOverJacking атак.
3. Не всі браузери підтримують цей заголовок, в тому числі старі версії основних п’яти браузерів. Тому мільйони користувачів цих браузерів будут незахищені перед атаками, навіть на сайтах, що використовують цей заголовок.

Продовжуючи розпочату традицію, після попереднього відео про зміну адмінського пароля в Joomla, пропоную нове відео на веб секюріті тематику. Цього разу відео про обхід аутентифікації через SQL Injection. Рекомендую подивитися всім хто цікавиться цією темою.

sql injection

В даному відео ролику демонструється одна з найбільш простих і відомих SQL ін’єкцій. Але в даному випадку має місце не просто SQL Injection атака, а обхід аутентифікації через SQL Injection. Тому що SQL ін’єкція має місце в формі аутентифікації. Причому автор відео знайшов дану уразливість на сайті університету (web.arizona.edu) в старій версії phpMyAdmin (версія 2.5.6).

Подібні SQL ін’єкції в формах аутентифікації достатньо поширені. Я сам багато разів знаходив такі уразливості на різних сайтах та в різних веб додатках, про що я вже писав, зокрема в CMS WebManager-Pro. Рекомендую подивитися дане відео для розуміння векторів атак через SQL Injection.

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

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

• Ransomware (malware)
• Fraudulent dialer
• Pass the hash
• Tapjacking - це Clickjacking для мобільних пристроїв.
• Likejacking - це Clickjacking для “лайків” Facebook.

Продовжуючи розпочату традицію, після попереднього відео про взлом комп’ютера через розшарений принтер, пропоную нове відео на веб секюріті тематику. Цього разу відео про зміну адмінського пароля в Joomla. Рекомендую подивитися всім хто цікавиться цією темою.

Reset Admin Password for Joomla

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

При наявності доступа до БД сайта (при наявності доступа до менеджерів СУБД на сайті, таких як phpMyAdmin та MySQL Perl/CGI Client, або розміщені на сайті шела з таким функціоналом, або навіть менеджера СУБД), можна змінити пароль адміна. Рекомендую подивитися дане відео для розуміння векторів атак через доступ до БД.

This is English version of my Strictly social XSS article.

Earlier I’ve told about different classes of Cross-Site Scripting vulnerabilities, including about many classes created by me. Last time I’ve told about Cross-Application Scripting, and concerning classes created by me - about Cross-Language Scripting. And now I’ll tell you about another one type of XSS vulnerabilities. I’ve created this class already in September 2007 (though I’ve found such holes earlier) and at last came to writing of detailed article about it.

This is Strictly social XSS. Which I’ve announced already in 2007 and now would tell about it in detail. At 23.09.2007 I’ve found Cross-Site Scripting vulnerability in Mozilla and Firefox, which I’ve disclosed at beginning of October. Which I’ve referred to Strictly social XSS type. And since then I’ve many times used the term Strictly social XSS for such vulnerabilities, actively popularizing it.

If in September 2007 I’ve found possibility of this attack via gopher protocol, then at 9th of February 2008 I’ve found possibility of using of http, https and ftp protocols. Which I’ve wrote about in post Cross-Site Scripting with UTF-7 in Mozilla and Firefox. In all these cases the attack was conducted at visiting of special page with UTF-7 text (it could be as reflected, as persistent attack), where it was needed to force victim to set UTF-7 encoding in a browser (by choosing appropriate item in menu). Which could be done by using method of social engineering, as I showed on examples of XSS attacks for different protocols.

gopher:///1+ADw-SCRIPT+AD4-alert('XSS')+ADw-/SCRIPT+AD4-
gopher:///1Turn%20on%20UTF-7%20to%20view%20this%20message%20+ADw-SCRIPT+AD4-alert('XSS')+ADw-/SCRIPT+AD4-

Taking into account, that the attack could be conducted on any gopher, http, https and ftp resource (which showed UTF-7 text, set in URL, in the answer on the request), so it was universal Strictly social XSS vulnerability. Also I’ll note, that if in 2007 Mozilla ignored this vulnerability, then in autumn 2008 Mozilla silently fixed this vulnerability in Firefox 3.0.2.

Nuances of Strictly social XSS.

Main feature of Strictly social XSS vulnerabilities is that a user needs to make some actions (specific to individual browser or individual site). For example, click, mouse over, selecting of element on a page (input field, combobox or other element), or selecting of some item in menu of the browser (e.g. changing of codepage). I.e. this type of XSS vulnerabilities, comparing with others, more requires usage of the methods of social engineering.

Among browsers which had such holes there are Mozilla and Firefox, which I mentioned about earlier, and Internet Explorer via attack via protocol guessing in IE6. Among such holes at web sites there are specific for separate sites and such ones, which are widespread at many sites, and also such ones, which require usage of browser functionality (but at that the hole is specific for the site, not for the browser). E.g. vulnerability on craigslist.org, which I’ve found at 01.11.2007.

The hole on craigslist.org required for attack to force a user to select required item in menu in the browser (if Site Navigation Bar turned on, as it often happens). And if it was turned on at a user (Show Always or Show Only As Needed), then it was only needed to force a user to make a click in menu Site Navigation Bar in the browser. For executing of JavaScript code it was needed to select site’s RSS feed in Site Navigation Bar in menu More. Attack could work in the browsers, which supported Site Navigation Bar, such as Mozilla, Firefox and Opera.

Besides above-mentioned cases, also such vulnerabilities happen in plugins for the browsers, such as Flash (particularly in content for this plugin - flash-files). Which allows to conduct these attacks in all browsers, i.e. these vulnerabilities are cross-browser and can take place at any sites with vulnerable flash-files. About examples of such mass XSS I wrote in articles XSS vulnerabilities in 8 millions flash files and XSS vulnerabilities in 34 millions flash files. In all these cases there was needed to click on flash-content to execute JavaScript-code.

Events handlers.

There are such XSS vulnerabilities, which work via events handlers, particularly those ones, which work not automatically, but at some user actions. Such as on click, on hovering cursor or at other events (as events, which exist in HTML standard, as own events of browsers developers, which are supported only by browsers of these companies). Such vulnerabilities are known for a long time, long before creation by me of the class Strictly social XSS, and usually they were referred to reflected XSS vulnerabilities (and some developers even didn’t count them as XSS and didn’t fix them).

At creation of this class of XSS vulnerabilities I’ve added all such XSS via vents handlers to it. Because these vulnerabilities require additional actions of a user, which conform to the definition of Strictly social XSS. I.e. not only new holes, which I’ve found and mentioned in this article, I referred to this class, but also old XSS holes, which work at onClick, onMouseOver and other events. So such holes via events handlers should be referred to this class.

At that cases happen, when there is filtration at web site (built in the site or WAF) and it’s possible to use common reflected XSS, but it’s possible to use events handlers. It’s that case, when reflected XSS is changing to Strictly social XSS for filtration bypass. During many years I’ve many times used Strictly social XSS for bypassing WAF, including ModSecurity.

Types of Strictly social XSS.

There are the next types of Strictly social XSS:

• Strictly social XSS reflected.
• Strictly social XSS persistent.
• Strictly social XSS DOM based.
• Strictly social XSS local.
• Strictly social XSS reflected self-contained.
• Strictly social XSS persistent self-contained.

Strictly social XSS reflected.

Strictly social XSS reflected represent by itself a link with JavaScript/VBScript code.

Examples of such XSS are vulnerability on tinyurl.com, vulnerabilities in 8 millions flash banners and vulnerabilities in WP-Cumulus for WordPress and tens of ports of WP-Cumulus for different engines, which together are using at around 34000000 web sites.

Strictly social XSS persistent.

Strictly social XSS persistent represent by itself a link with JavaScript/VBScript code.

Example of such XSS is vulnerability on tinyurl.com and vulnerability in WordPress.

Strictly social XSS DOM based.

Strictly social XSS DOM based represent by itself an inclusion of JavaScript/VBScript code in event handler, such as click (onClick) or other event.

Examples of such XSS are vulnerabilities in Joomla and Joostina, on yandex.ru, images.yandex.ru and market.yandex.ru, afisha.yandex.ru and video.i.ua.

Strictly social XSS local.

Strictly social XSS local represent by itself such XSS in local application, particularly in browser. About such type I’ve wrote already in details in article Local XSS.

Examples of such XSS are vulnerabilities in Mozilla and Firefox, in Mozilla and Firefox via redirectors, in Internet Explorer 6, on search.yahoo.com and craigslist.org.

Strictly social XSS reflected self-contained.

Strictly social XSS reflected self-contained represent by itself a link with data with JavaScript code.

Example of such XSS is vulnerability on www.s-cars.org.

Strictly social XSS persistent self-contained.

Strictly social XSS persistent self-contained represent by itself a link with data with JavaScript code.

Examples of such XSS are vulnerabilities on tinyurl.com and vulnerability in WordPress.

Using of Strictly social XSS together with additional attack techniques.

Taking into account, that for execution of JS/VBS code at Strictly social XSS vulnerabilities the additional actions of a user are needed, it’s complicating the attack. For simplification of the attack, up to full automation (similar to reflected XSS), it’s possible to use additional attack techniques. Particularly such techniques as ClickJacking, MouseOverJacking and attack via clipboard.

If for the attack a victim needs to do a click, then it’s possible to use ClickJacking (made by Jeremiah and Robert).

If for the attack a victim needs to do mouse over, then it’s possible to use MouseOverJacking (made by me).

If for the attack a victim needs to paste a text from clipboard, then for this it’s needed at first to put attacking code into her clipboard, for that it’s possible to conduct attack via clipboard (made by me), for remote putting of a code into clipboard.

Раніше я вже розповідав про різні класи Сross-Site Scripting уразливостей, в тому числі про багато класів XSS створених мною. В останнє я розповідав про Міжпрограмний XSS (Cross-Application Scripting), а стосовно класів XSS створених мною - про Міжмовний XSS (Cross-Language Scripting). А зараз розповім вам про ще один тип XSS уразливостей. Даний клас я створив ще у вересні 2007 року (хоча знаходив такі дірки й раніше) і ось нарешті дістався до написання детальної статті про нього.

Це Виключно соціальний XSS - Strictly social XSS. Який я анонсував ще в 2007 році і зараз розповів про нього детально. 23.09.2007 я знайшов Cross-Site Scripting уразливість в Mozilla та Firefox, яку я оприлюднив на початку жовтня. Яку я відніс до типу Strictly social XSS. І відтоді я неодноразово використовував термін Strictly social XSS для подібних уразливостей, активно його пропагуючи.

Якщо у вересні 2007 я знайшов можливість даної атаки через протокол gopher, то вже 09.02.2008 я виявив можливість використання протоколів http, https і ftp. Про що я писав в записі Cross-Site Scripting з UTF-7 в Mozilla та Firefox. В усіх цих випадках, атака відбувался при відвіданні спеціальної сторінки з UTF-7 текстом (це могла бути як reflected, так і persistent атака), де потрібно було змусити жертву встановити UTF-7 кодування в браузері (вибравши відповідний пункт меню). Що можна було зробити використовуючи методи соціальної інженерії, як я показав на прикладах XSS атак для різних протоколів.

gopher:///1+ADw-SCRIPT+AD4-alert('XSS')+ADw-/SCRIPT+AD4-
gopher:///1Turn%20on%20UTF-7%20to%20view%20this%20message%20+ADw-SCRIPT+AD4-alert('XSS')+ADw-/SCRIPT+AD4-

Враховуючи, що атаку можна було провести на будь-який gopher, http, https і ftp ресурс (що виводив UTF-7 текст, вказаний в URL, у відповіді на запит), то це була універсальна Strictly social XSS уразливість. Також зазначу, що якщо в 2007 році Мозіла проігнорувала цю уразливість, то вже восени 2008 року, Мозіла втихаря виправила цю уразливість в Firefox 3.0.2.

Особливості Strictly social XSS.

Визначальною рисою Strictly social XSS уразливостей є те, що користувачу потрібно зробити якісь дії (специфічні для окремого браузера чи окремого сайта). Наприклад, клік, наведення мишкою, вибір елемента на сторінці (поля, комбобокса чи іншого елемента), або вибір якогось пункту меню браузера (наприклад, зміна кодування). Тобто даний різновид XSS уразливостей, порівнянно з іншими, найбільше вимагає використання методів соціальної інженерії.

Серед браузерів, що мали подібні дірки, є Mozilla та Firefox, про які я згадував вище, та Internet Explorer через атаку через вгадування протоколу в IE6. Серед подібних дірок на сайтах зустрічаються специфічні для окремих сайтів та такі, що поширені на багатьох сайтах, а також такі, що вимагають використання функціоналу браузера (але при цьому дірка специфічна для сайта, а не для браузера). Наприклад, уразливість на craigslist.org, що я знайшов 01.11.2007.

Дірка на craigslist.org вимагала для атаки змусити користувача вибрати необхідний пункт меню в браузері (якщо Site Navigation Bar виключений, як це часто буває). А якщо він був включений у користувача (Show Always, або Show Only As Needed), то лише залишалось змусити користувача зробити клік в меню Site Navigation Bar в браузері. Для запуску JavaSript коду потрібно було в Site Navigation Bar в меню More вибрати RSS фід сайта. Атака могла спрацювати в браузерах, що підтримують Site Navigation Bar, таких як Mozilla, Firefox та Opera.

Окрім вищезгаданих випадків, також подібні уразливості трапляються в плагінах для браузерів, такому як Flash (зокрема в контенті для цього плагіна - флешках). Що дозволяє проводити дані атаки в усіх браузерах, тобто ці уразливості є кросбраузерними і можуть мати місце на будь-яких сайтах з уразливими флешками. Про приклади таких масових XSS я писав у статтях XSS уразливості в 8 мільйонах флеш файлах та XSS уразливості в 34 мільйонах флеш файлах. В усіх цих випадках необхідно було клікнути на флешку для запуску JavaScript коду.

Обробники подій.

Існують такі XSS уразливості, які спрацьовують через обробники подій, зокрема тих, що працють не автоматично, а при деяких діях користувача. Як то при кліку, при наведенню курсору чи при інших подіях (як event-ів, що існують в стандарті HTML, так і власних подій розробників браузерів, що підтримуються лише браузерами даних компаній). Такі уразливості відомі вже давно, задовго до створення мною класу Виключно соціальних XSS, і за звичай їх відносили до reflected XSS уразливостей (а деякі розробники навіть не вважали їх за XSS і не виправляли).

При створенні даного класу XSS уразливостей я додав всі такі XSS через обробники подій до нього. Тому що дані уразливості вимагають додаткових дій користувача, що відповідає визначенню Strictly social XSS. Тобто не тільки нові дірки, знайдені мною і наведені в цій статті, я відніс до цього класу, але й старі XSS дірки, що працють при onClick, onMouseOver та інших подіях. Таким чином подібні дірки через обробники подій подібно відносити до цього класу.

При цьому трапляються випадки, коли на сайті є фільтрація (вбудована в сайт чи WAF) і не можна використати звичайну відбиту XSS, а зате можна використати обробники подій. Це той випадок, коли reflected XSS замінюється на Strictly social XSS для обходу фільтрації. На протязі багатьох років я неодноразово використовув Виключно соціальний XSS для обходу WAF, в тому числі ModSecurity.

Різновиди Strictly social XSS.

Бувають наступні види Виключно соціального XSS:

• Strictly social XSS reflected.
• Strictly social XSS persistent.
• Strictly social XSS DOM based.
• Strictly social XSS local.
• Strictly social XSS reflected self-contained.
• Strictly social XSS persistent self-contained.

Strictly social XSS reflected.

Strictly social XSS reflected представляє собою лінку з JavaScript/VBScript кодом.

Прикладами такої XSS є уразливість на tinyurl.com, уразливості в 8 мільйонах флеш банерах та уразливості в WP-Cumulus для WordPress і десятках портів WP-Cumulus для різних движків, які разом використовуються на приблизно 34000000 веб сайтах.

Strictly social XSS persistent.

Strictly social XSS persistent представляє собою лінку з JavaScript/VBScript кодом.

Прикладом такої XSS є уразливість на tinyurl.com та уразливість в WordPress.

Strictly social XSS DOM based.

Strictly social XSS DOM based представляє собою включення JavaScript/VBScript коду в обробник події, такої як натискання кнопки (onClick) чи іншої події.

Прикладами такої XSS є уразливості в Joomla та Joostina, на yandex.ru, images.yandex.ru та market.yandex.ru, afisha.yandex.ru та video.i.ua.

Strictly social XSS local.

Strictly social XSS local представляє собою подібну XSS в локальному додатку, зокрема в браузері. Про даний різновид я вже детально писав в статті Local XSS - Локальний XSS.

Прикладами такої XSS є уразливості в Mozilla та Firefox, в Mozilla та Firefox через редиректори, в Internet Explorer 6, на search.yahoo.com та craigslist.org.

Strictly social XSS reflected self-contained.

Strictly social XSS reflected self-contained представляє собою лінку з data з JavaScript кодом.

Прикладом такої XSS є уразливість на www.s-cars.org.

Strictly social XSS persistent self-contained.

Strictly social XSS persistent self-contained представляє собою лінку з data з JavaScript кодом.

Прикладами такої XSS є уразливості на tinyurl.com та уразливість в WordPress.

Використання Strictly social XSS разом з додатковими техніками атаки.

Враховуючи, що для виконання JS/VBS коду при Strictly social XSS уразливості потрібні додаткові дії користувача, це ускладнює атаку. Для спрощення атаки, аж до повної її автоматизації (подібно до reflected XSS), для цього можна використати додаткові техніки атаки. Зокрема такі техніки як ClickJacking, MouseOverJacking та атаку через буфер обміну.

Якщо для атаки жертві потрібно зробити клік, то можна використати ClickJacking (розроблений Джеремією та Робертом).

Якщо для атаки жертві потрібно зробити наведення мишею, то можна використати MouseOverJacking (розроблений мною).

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

В презентації Total Browser Pwnag3 V1.0 Public, Rafal M. Los та Joshua D. Abraham розповідають про тотальне захоплення браузера. Про небезпеки сучасних браузерів, як через їхні дірки можна атакувати користувачів браузерів та як можна від них захиститися, щоб убезпечити себе і свій комп’ютер.

В своїй статті Атаки на незахищені логін форми я розповідав про таку атаку на форму аутентифікації, як віддалений логін. Що може бути використанно для різноманітних атак (як і автоматизований логін), коли потрібно, щоб користувач був залогінений в акаунт для проведення атаки. Зокрема це може знадобитися для використання XSS, CSRF, URL Redirector Abuse та інших уразливостей в аккаунтах користувачів чи в адмінці (так звані post-auth дірки).

Звичайна схема атаки, яку я мав на увазі у вищезгаданій статті й яку я продемонстрував на прикладі багатьох дірок в різних веб додатках (як то MyBB чи панель керування ADSL модема Callisto 821+) - це коли відомі логін і пароль до акаунта на сайті. Наприклад, коли є вільна реєстрація на сайті, тому можна зробити акаунт і використати його для подібної атаки, або коли відомі логін і пароль, але в акаунті є прив’язка до IP, або атака відбувається з Інтернета в LAN (через браузер користувача).

Але, якщо розробники встановили захист від CSRF на форму логіна (токени чи перевірку реферера), то тоді віддаленого логіна зробити не вдасться. Але сьогодні я придумав метод, як можна обійти цей захист і все рівно проводити віддалений логін. В тому числі за допомогою цього методу можна проводити віддалений логін в акаунти, логіни і паролі яких не відомі.

Мій метод передбачає використання Clickjacking та Password Manager в браузерах. Менеджери паролів використовуються вже давно - з кінця 90-х років. І всі сучасні браузери мають такі менеджери паролів, що запам’ятовують паролі й підставляють їх в форми аутентифікації на сайтах. Залишиться лише провести Clickjacking атаку на форму логіна, в яку браузер сам підставить логін і пароль (якщо користувач запам’ятав його, а це зручний функціонал, тому більшість людей його використовує), щоб провести віддалений логін.

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

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

Один з відомих мені популярних веб додатків, що має захист від Clickjacking атак (в тому числі в формі логіна) - це phpMyAdmin. В версії phpMyAdmin 2.11.11 вже був захист від даної атаки. Зокрема розробники phpMyAdmin використали метод прибирання фреймів (frame-buster) в формі логіна. А в phpMyAdmin 3.3.0 і вище, окрім цього ще використовується заголовок X-Frame-Options всередині адмінки (що допоможе лише в деяких браузерах, що його підтримують, але frame-buster захистить від віддаленого логіна).

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

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

• Scareware
• Rogue security software
• JIT spraying
• Port scanner
• Improper input validation

Продовжуючи розпочату традицію, після попереднього відео про підбір паролей до MySQL, пропоную нове відео на веб секюріті тематику. Цього разу відео про взлом комп’ютера через розшарений принтер. Рекомендую подивитися всім хто цікавиться цією темою.

Metasploit Hacking a computer through a shared printer

В даному відео ролику демонструється використання Metasploit Framework для проведення атаки на розшарений принтер в локальній мережі. Використовуючи уразливість в Microsoft Print Spooler - сервісі друку в ОС Windows.

Після визначення сканером nmap IP адрес в локальній мережі, визначається комп’ютер в якого є розшарений прінтер і непропатчений Windows (з уразливістю в Print Spooler). І даний ПК атакується в Metasploit через розшарений принтер для отримання віддаленого адмінського доступу до системи. Рекомендую подивитися дане відео для розуміння векторів атак в LAN.