Новий масовий взлом сайтів на сервері HostPro

20:39 15.07.2011

Нещодавно, 09-11.07.2011, відбувся новий масовий взлом сайтів на сервері HostPro (а один сайт ще 04.03.2011). Перший масовий взлом сайтів на сервері HostPro відбувся в січні.

Був взломаний сервер української компанії HostPro. Взлом відбувся після згаданого масового взлому сайтів на сервері Virtes.

Всього був взломаний 21 сайт на сервері хостера HostPro (IP 80.91.191.125). Це наступні сайти: www.get-viza.com.ua, www.3atoka.com, amberlife.com.ua, www.spani.biz, www.nicolekids.com.ua, www.ozdorovis.com, rpb.org.ua, allodessa.com, progon.od.ua, ukrsepro.in.ua, krcc.com.ua, kosmetik-express.biz, 00008.info, fitopiramida.com, touchgadget.ru, allodessa.com.ua, www.salsa.mk.ua, psovajaohota.com, www.romashka.net.ua, www.apple2.ru, finpravda.com.ua.

З зазначених сайтів 20 було взломано на протязі 9-11 липня 2011 року хакерами з RKH, а 1 сайт був взломаний 04.03.2011 хакером iskorpitx.

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


4 відповідей на “Новий масовий взлом сайтів на сервері HostPro”

  1. HostPro каже:

    Дозвольте додати трохи сумнівів до Вашої безапеляційної заяви про злам нашого серверу.
    Ми перевірили вказані Вами сайти. Деякі з них (mberlife.com.ua,
    llodessa.com, rogon.od.ua) взагалі ніколи не були у нас розміщені.

    Щодо решти, то причиною “зламу” був занадто простий пароль доступу адміністратора у адмін.частину CMS, підібрати який було набагато простіше, ніж ламати сервер. Звісно, ніхто root-доступ до серверу не отримував.

    Ми надіслали цим користувачам повідомлення про незахищеність паролів та рекомендації про посилення безпеки сайтів.

  2. MustLive каже:

    Світлана

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

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

    Стосовно вказаних мною сайтів. Вся інформація про сайти, що зазнали масового дефейсу береться мною з zone-h.org. Про що я писав в лютому, але так як в ранніх записах про масові дефейси про це не зазначалось, то я побачив, що в деяких людей виникають питання з приводу вказаних в тесті сайтів, а про zone-h не всі знають і не всі будуть вичитувати в мене на сайті про це, тому вже давно я вказую в записах лінку на zone-h.org, де можна побачити перелік взломаних сайтів і побачити їх дефейси. І в даному записі також наводиться лінка на цей сайт.

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

  3. MustLive каже:

    mberlife.com.ua, llodessa.com, rogon.od.ua

    Домени насправді amberlife.com.ua, allodessa.com, progon.od.ua - то я якогось біса витер перші літери в цих трьох доменах, коли переносив інформацію з zone-h (трохи неуважно це зробив). Не лінуйтесь заходити по лінці на zone-h.org, що я давно вже вказую в своїх записах про масові дефейси, якщо у вас виникають питання по переліку сайтів ;-) .

    Щодо решти, то причиною “зламу” був занадто простий пароль доступу адміністратора у адмін.частину CMS

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

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

    Звісно, ніхто root-доступ до серверу не отримував.

    У вас в січні за 2 дні взломано було 25 сайтів, а в липні за три дні було взломано 55 сайтів на двух серверах. Тому заяви, що ви ні в чому не винні є некоректними. Ламати велику кількість сайтів - а в цих трьох випадках мова йде саме про масові дефейси - за короткий час і при цьому окремо один за одним ніхто не буде. В 99% випадків при масових дефейсах використовуються дірки сервера, щоб спростити собі життя при атаці (а в 1% - це тривалий час і менша кількість сайтів, порівняно з іншими випадками).

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

  4. HostPro каже:

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

    “Ви перевіряли ці паролі у всіх зазначених сайтів? Що у всіх них такі веб додатки, які тримають паролі (в файлах чи СУБД) в чистому вигляді, а не в хешах? Сумніваюся, що у всіх них. Ви що брутфорсили (чи використовували інші методи підбору) хеші паролів? Сумніваюся. Так тоді звідки вам знати, що паролі прості :)

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

    Ще раз повторюсь, що в такому випадку “хакеру” не треба нічого ламати - достатньо спробувати підібрати пароль, потім пройтися по сайтам, розміщеним на тому ж IP і написаним на тих же чи подібних CMS, і спробувати використати пароль там. Паролі справді були дуже простими. І це не обов*язково робити вручну, вистачить елеметарного скрипта.

    Так, ми перевіряємо паролі на СMS лише у випадку подібних інцидентів, щоб виключити можливість зламу серверу. Ми фізично не можемо перевіряти паролі на адміністративну частину популярних чи самописних СMS, встановлених клієнтами. Якби клієнти встановлювали, наприклад, CMS Joomla через Fantastico, їм би автоматично згенерувався складний пароль, що б запобігло подібним проблемам.

    Щодо “статистики” зламів на серверах. На серверах, де розміщуються ці сайти, сайтів значно більше, ніж по 25 (це віртуальний хостинг). При зламі серверу дефейснутих сайтів було б значно більше і це були б не лише сайти на популярних CMS, в яких при перевірці виявлено елементарні паролі, Вам так не здається?

    “Ламати велику кількість сайтів - а в цих трьох випадках мова йде саме про масові дефейси - за короткий час і при цьому окремо один за одним ніхто не буде. ”
    Якщо користувачі абсолютно не будуть думати про безпеку своїх сайтів, а потім перекладати власну необачність на вину хостера, то, на жаль, одним скриптом зможуть поламати швидко, один за одним, стільки сайтів, скільки буде необачних користувачів.

Leave a Reply

You must be logged in to post a comment.