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

В своїй статті Хакерські війни я розповів про концепцію війн хакерів, про різні види хакерської діяльності в Інтернеті, та про те, які саме дії хакерів можна віднести до хакерських війн.

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

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

В своїй діяльності я з бойовими діями особливо не стикався (в основному лише спостерігав їх під час проведення власних досліджень). Але одного разу мені довелося брати участь в бойових діях - в хакерській війні за один веб ресурс. В минулому році в проекті MOSEB я писав про одну дірку в Google, що призводила до витоку ftp логіна і пароля. Тоді я швидко знайшов робочий сайт, де логін і пароль підійшли, і вирішив дефейснути його, щоб повідомити адміну про дану проблему з безпекою його сайта. Одразу ж я виявив, що його сайт вже був похаканий (дефейснутий хакерами з близького сходу). Бо інформація про ту дірку в Гуглі швидко поширилася в Інтернеті, що призвело до масових взломів сайтів (ось так Гугл піклувався про безпеку своїх користувачів).

Сайт то я дефейснув, де повідомив адміну про проблему. Але мій дефейс простояв недовго - сайт швидко був похаканий знову (вже іншими хакерами). Я відновив свій дефейс, тим самим втрутившись в ці бойові дії (і при цьому виявив, що одні з наступних хакерів взагалі видалили усі файли з сайта, залишивши лише дефейс). Але враховучи, що адмін не реагував на цю ситуацію - його сайт весь час дефейснувся різними хакерами (по багато разів за добу). В сумі я тричі дефейснув сайт (розмістивши повідомлення адміну) і двічі написав повідомлення йому на емайл, але він не відреагував. Що перетворило його сайт на вакханалію. Утримати свою позицію на тому сайті було неможливо (враховуючи обставини), тому повністю захистити той сайт не вдалося, але я зробив усе можливе. Так що в мене є невеликий бойовий досвід .

В зв’язку з ситуацією яка склалася в Уанеті зі взломами сайтів (про що я чимало писав в своїх дослідженнях), я вирішив започаткувати новий проект. Який приурочив до Дня Незалежності України, що пройшов 24 серпня (з чим я вас вітаю). Коли як раз я остаточно визначився з задачами проекту, а за день до цього опублікував статтю “Хакерські війни”, де оприлюднив саму концепцію.

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

Хакерські війни (Hackers wars) - це війни хакерів за веб сайти. Це новий етап в розвитку Інтернет - коли сайти не тільки створюються, або закриваються (коли вони завершили свою місію), але й завойовуються. Цей варіант став можливим коли, по-перше, накопичилася критична маса сайтів, і коли, по-друге, люди зрозуміли цінність сайтів. Раніше люди захоплювали землі та інші ресурси (й зараз продовжують цим займатися), а в цифровий вік люди почали захоплювати веб сайти.

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

Самі ж Інтернет користувачі, що можуть використувавати конкретний сайт, який став жертвою війскових дій, не будуть задоволені коли сайт перестане працювати. І ще менш вони зрадіють, коли на своєму улюбленому сайті вони підхоплять віруса. Тому ця концепція є більш ніж реальною - вона існує вже деякий час і торкається кожного користувача Інтернет.

Можна розрізнити шкідливі й нешкідливі види хакерської діяльності в Інтернет. До шкідливих можна віднести: взломи для дефейсів, взломи для видалення даних, взломи для розміщення шкідливих кодів (фінансово мотивовані взломи), Black SEO взломи (також фінансово мотивовані), взломи для викрадення даних (про які можна й зовсіс не довідатися) та інші. Є також ще DDoS атаки, але вони відносяться до іншої категорії, тому що в даному випадку сайти не взламуються. До нешкідливих можна віднести: взломи з метою попередження про дірки на сайті (що я періодично практикую), а також попередження власників сайтів про взломи їх сайтів (після виявлення факту взлому), в тому числі про інфікованість сайтів шкідливими кодами (що також мені доводилося робити - в цьому році повідомляв деяким власникам сайтів про це).

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

Продовжуючи розпочату традицію, після попереднього відео про SQL Injection в JPortal CMS, пропоную новий відео секюріті мануал. Цього разу відео про Blind SQL Injection (у веб додатку на MySQL). Рекомендую подивитися всім хто цікавиться цією темою.

Demonstration of Blind MySQL Injection (bsqlbf)

В даному відео ролику наочно демонструється проведення Blind SQL Injection атаки за допомогою perl додатка bsqlbf (з отриманням логіна, паролю та інших даних з БД). Рекомендую подивитися дане відео для розуміння векторів атаки за допомогою SQL ін’єкцій та небезпеки подібних уразливостей.

This is English version of my Number of hacked sites in Internet article.

How much of hacked sites are currently in Internet - it’s urgent question. From news you know, that sites are constantly hacking, and number of this hacks is measured in hundreds and thousands (per one way of hacks), sometimes reaches hundreds of thousands of sites.

To find out the situation with hacks of sites in Uanet I lead own researches, as a result of which publish reports about hackers activity in Uanet. And as a results of new researches today I created new method of searching hacked sites, as in Uanet, as in a whole Internet. Searching occurs with help of Google - via special dorks.

This method allow to reveal hacked sites, which were hacked recently (or long ago), and still were not fixed by admins. So this method can be used for revealing of actual state of Internet’s hacked level (to reveal recently hacked sites). It can be used also in general for researching of hackers activity in Internet, and also for leading of regional researches of hackers activity (in different countries).

Queries for revealing of hacked sites:

intitle:”hacked by” - as a whole in Internet up to 1010000 sites are currently hacked.

Of course there are also news sites in results, which wrote about hacks of sites, but there are many directly hacked sites.

Search on Uanet:

intitle:”hacked by” site:ua - up to 2060 sites are currently hacked.

intitle:”hacked by” + “pages from Ukraine” - up to 2540 sites are currently hacked.

Second query more precision (because include Ukrainian sites, which not located in ua zone) and so has more results.

In Internet (and in Uanet) there are large number of hacked sites in current time. And with every minute, when robots of Google (and other search engines) walk around the Net, this information is updating.

Скільки зараз похаканих сайтів є в Інтернеті - це актуальне запитання. З новин ви знаєте, що сайти постійно хакаються, і кількість цих взломів вимірюється сотнями і тисячами (за одну хвилю взломів), іноди сягаючи сотень тисяч сайтів.

Щоб вияснити ситуацію зі взломами сайтів в Уанеті я проводжу власні дослідження, в результаті яких публікую звіти про хакерську активність в Уанеті. І в результаті нових досліджень сьогодні я розробив нову методу пошуку похаканих сайтів, причому як в Уанеті, так і в Інтернеті в цілому. Пошук відбувається за допомогою Гугла - через спеціальні дорки.

Даний метод дозволяє виявити похакані сайти, що були похакані нещодавно (або давно), і досі не були виправлені адмінами. Тому метод можна застосовувати для виявлення актуального стану похаканності Інтернета (щоб виявити свіже похакані сайти). Його також можна застосовувати взагалі для досліджень хакерської активності в Інтернеті, а також для проведення регіональних досліджень активності хакерів (в різних країнах).

Запити для виявлення похаканих сайтів:

intitle:”hacked by” - вцілому в Інтернеті до 1010000 сайтів зараз є похаканими.

Звичайно в результатах також є новинні сайти, що пишуть про взломи сайтів, але чимало й безпосередньо похаканих сайтів.

Пошук по Уанету:

intitle:”hacked by” site:ua - до 2060 сайтів зараз є похаканими.

intitle:”hacked by” + “сторінки з України” - до 2540 сайтів зараз є похаканими.

Другий запит більш точний (бо охоплює українські сайти, що не знаходяться в зоні ua) і тому має більше результатів.

В Інтернеті (і в Уанеті) в даний час знаходиться велика кількість похаканих сайтів. І з кожною хвилиною, як роботи Гугла (й інших пошуковців) обходять Мережу, дана інформація оновлюється.

Раніше я писав про різноманітні пам’ятки з SQL Injection (в тому числі для різних Баз Даних), зокрема і про пам’ятку з SQL Injection від RSnake. Зараз пропоную ознайомитися з іншою розробкою RSnake - пам’яткою з Cross-Site Scripting. Котра може стати вам у нагоді при проведенні аудиту безпеки веб сайта (чи атаки на сайт).

XSS (Cross Site Scripting) Cheat Sheet

Дана пам’ятка доволі об’ємна - це найбільш повна пам’ятка з XSS. І вона може стати в нагоді при необхідності обійти захисні фільтри, бо XSS має багато варіацій для атаки.

Існує такий клас уразливостей як Denial of Service. І серед різноманітних уразливостей даного класу є DoS уразливості в браузерах (та їх плагінах). Що призводять до відмови в обслуговуванні браузера користувача - браузер самостійно закривається (вилітає).

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

Які небезпеки можуть бути в Denial of Service атаках на браузери? Їх декілька і кожна з них варта уваги.

1. Закриття поточного вікна браузера користувача. Що створює дискомфорт.

2. Закриття вікна браузера користувача разом з усіма відкритими табами (вікнами). Що створює ще більший дискомфорт та може призвести до врати незбережених даних, що набиралися в іншому табі.

3. BSoD - повне зависання операційної системи. Це створює чималий дискомфорт та може призвести до врати незбережених даних (як тих, що набиралися в браузері, так й інших додатках).

4. Використання DoS уразливості для проведення DoS-атаки на користувачів сайта. Це дуже небезпечна атака, що являє собою зворотню DDoS атаку (reverse DDoS attack). В даному випадку атакується не сам сайт з метою вибити його з Мережі, щоб він стан недоступний для користувачів, а атакуються користувачі сайта (через взлом сайта і розміщення на ньому DoS-експлоіта), в яких при відвідуванні сайта буде вілітати браузер і вони не зможуть його нормально переглянути - тобто сайт стане недоступним для користувачів.

5. Деякі DoS уразливості можуть мати можливість виконання коду (на комп’ютері користувача). Що є дуже небезпечно і може використовуватися для поширення вірусів та іншого шкідливого коду.

Тому розробникам браузерів слід виявляти і виправляти усі DoS уразливості в своїх продуктах.

В своїй презентації Security & PHP, Nuno Loureiro розповідає про безпеку PHP. Він розповідає про поширені уразливості у PHP веб додатках та надає поради щодо їх виправлення. Текст презентації на португальскій мові.

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

JPortal CMS SQL Injection Exploit in Action by (ruiner_zer0)

В даному відео ролику наочно демонструється проведення SQL Injection атаки на движок JPortal CMS (з отриманням доступу до панелі адміністратора). Рекомендую подивитися дане відео для розуміння векторів атаки за допомогою SQL ін’єкцій та небезпеки подібних уразливостей.

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

Тому при проведені XSS атаки потрібно звертати увагу на тривалість сесії. У випадку коли сайт вразливий до Insufficient Session Expiration, то жодних ускладнень з атакою не виникне, і сесія буде працюваи тривалий час (від декількох годин до необмеженої кількості часу). Достатній час, щоб успішно провести операцію по захопленню акаунта.

Якщо ж на сайті немає Insufficient Session Expiration уразливостей (адміністратори сайта подбали про цей аспект), то потрібно буде або дуже швидко проводити процедуру захоплення акаунта (поки активна сесія), або іншим чином вирішити це питання. Зокрема цю задачу можна вирішити шляхом продовження сесії і для цього я розробив власний метод - MustLive Session Extending Method.

Мій метод, що я розробив в 2006 році, призначений для продовження зохопленної сесії і може використовуватися при проведенні XSS атак. Даний метод був неодноразово успішно апробований на практиці .

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

Тому веб розробникам та адміністраторам сайтів варто пам’ятати про можливість обходу обмеження на тривалість сесії. І навіть відсутність Insufficient Session Expiration уразливостей не врятує від атаки професіонала. Виходячи з цього, єдиним засобом протидії від Cross-Site Scripting атак є виправлення усіх XSS дір на сайті.