Зламали. Хочете зрозуміти, як


40

Хтось уже вдруге додав шматок javascript на сайт, який я допомагаю запустити. Цей javascript викрадає Google adsense, вставляючи власний номер облікового запису та наклеюючи рекламу по всьому.

Код завжди додається, завжди в одному конкретному каталозі (той, який використовується третьою рекламною програмою), впливає на кількість файлів у ряді каталогів, що знаходяться в цьому одному dir dir (20 або більше), і вставляється приблизно однаково протягом ночі час. Обліковий запис Adsense належить китайському веб-сайту (розташований у місті не за годину, звідки я буду в Китаї в наступному місяці. Можливо, я повинен піти на голову ... жартую, начебто), btw ... ось інформація про сайт: http://serversiders.com/fhr.com.cn

Отже, як вони могли додати текст до цих файлів? Це пов’язано з дозволами, встановленими для файлів (від 755 до 644)? Для користувача веб-сервера (він знаходиться на MediaTemple, тому він повинен бути захищеним, так?)? Я маю на увазі, якщо у вас є файл, для якого встановлено дозволи 777, я все одно не можу просто додати код до нього за бажанням ... як вони це роблять?

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

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

Оскільки декілька людей згадували про це, ось що я перевірив (і, маючи на увазі, я маю на увазі, що я оглянув час, коли файли були модифіковані на будь-які дивацтва, і я перехопив файли для операторів POST та обходу каталогів:

  • access_log (нічого, окрім звичайного (тобто надмірного) MSN-трафіку)
  • error_log (нічого, крім звичайного файлу, не існує помилок для нешкідливих файлів)
  • ssl_log (нічого, крім звичайного)
  • messages_log (тут немає FTP доступу, окрім мене)

* ОНОВЛЕННЯ: ** ОК, вирішено. Хакери з Китаю фізично розмістили файл на нашому веб-сайті, який дозволяє їм робити всі адміністративні речі (доступ до бази даних, видалення та створення файлів та файлів, ви називаєте це, у них був доступ). Нам пощастило, що вони не зробили щось більш руйнівне. У звичайних файлах журналу apache нічого не було, але я знайшов інший набір файлів журналів у аналізаторі журналів веб-сервера, і докази були там. Вони отримували доступ до цього файлу за допомогою власного імені користувача та пароля адміністратора, а потім редагували все необхідне прямо там на сервері. У їхньому файлі встановлено "apache" як користувач, тоді як усі інші файли на нашому сайті мають інше ім'я користувача. Тепер мені потрібно розібратися, як вони фізично потрапили до цього файлу в нашу систему. Я підозрюю, що винна в цьому врешті-решт покладається на наш веб-хостинг (Media Temple),


6
Я не знаю, ви дали комусь свій пароль?

4
Якщо ви знаєте, коли саме це відбувається, знайдіть у своєму access_log все, що незвично за цей час. Особливо зверніть увагу на всі запити POST: куди вони йдуть, що вони робили.
sanmai

3
Thx WhirlWind ... дуже корисно.
Lothar_Grimpsenbacher

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

4
@ gaoshan88 - корисніше, ніж ти можеш подумати. Один вектор атаки - це троянець, який нюхає паролі від ftp-клієнтів розробників.
Квентін

Відповіді:


9

Перш за все, chmod 744це НЕ, що ви хочете. Суть chmod полягає у відміні доступу до інших облікових записів у системі. Chmod 700набагато безпечніший, ніж chmod 744. Однак Apache потрібен лише біт виконання для запуску програми php.

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-data зазвичай використовується як обліковий запис Apache, який використовується для виконання php. Ви також можете запустити цю команду, щоб побачити обліковий запис користувача:

`<?php
print system("whoami");
?>`

FTP жахливо небезпечний, і дуже ймовірно, що вас зламали з цього методу. За допомогою FTP ви можете зробити файли для запису, а потім заразити їх знову. Переконайтеся, що ви запускаєте антивірус на всіх машинах з доступом до FTP. Є віруси, які нюхають локальний трафік за іменами та паролями FTP, а потім входять у систему та заражають файли. Якщо ви дбаєте про безпеку, ви будете використовувати SFTP, який шифрує все. Надсилання вихідного коду та паролів за допомогою чіткого тексту - це повне безумство.

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


6
+1, уникайте FTP, як чуми. Троянський трофейний трофей може заразити ваш комп'ютер і використовувати ваші облікові дані для зміни файлів. Або це може заразити ваш маршрутизатор. Або комп'ютер вашого сусіда в мережі Netcafe з незахищеною мережею Wi-Fi. Надсилати пароль в чіткому тексті - це погана, погана ідея.
Тгр

1
FTP має SSL, знаєте.
grawity

1
@grawity більшість людей не використовують "ftps", але це не дозволить вам зламатись. sftp більш популярний.
Грак

2
Дані www не повинні мати власні файли у вашому веб-каталозі. Все, що www-дані можуть бути оновлені погано написаним сценарієм на сервері.
Зоредаче

9

Облікові записи "Моїх мережевих серверів Media Temple Grid" кілька разів "ламалися". Їх захищеність дуже погана ... розпочато з ПЛАШКУВАННЯ ТЕКСТОВОГО ТЕКСТУ минулого року і триває донині (ви можете зателефонувати в технічну підтримку, і вони говорять "який ваш пароль?"). Я знаю, тому що я отримую щомісячні електронні листи про те, як вони змінили всі паролі мого облікового запису, і вони фактично входять і змінюють паролі бази даних для вас щоразу, коли вони отримують злом. Ця компанія виглядає глянцевою, як пекло на поверхні, але сервер з сіткою - безлад. Рекомендую негайно переключитися .

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

Слідкуйте за розвагою на їхній сторінці статусу : він розповість вам про найсвіжіші подвиги (і, так, справді, зараз є "можливий подвиг").


ха-ха. мої сайти gs зараз всі вниз. немає електронної пошти weblog.mediatemple.net/weblog/category/system-incidents/…
typeoneerror

2

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

Ви перевірили crontab на щось дивне?

Ви намагалися перейменувати каталог та посилання на нього (це може порушити скрипт оболонки)?


перейменування - хороша ідея. Я спробую це, як тільки я побачу, які ефекти це матиме на сайті. У Crontab була одна дещо дивна річ, є запис про час зміни файлів, але це менеджер резервних копій Plesk ... складений додаток. Якщо це порушено, то в Media Temple є велика проблема на руках.
Lothar_Grimpsenbacher

1

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

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


1

Це звучить надзвичайно звично хакерам Wordpress, які останнім часом потрапили до ряду сайтів Network Solutions. Оскільки ви перебуваєте в Media Temple, можливо, ви залишили деякі файли видимими для інших користувачів, які спільно використовують вашу машину. Це пояснило б відсутність слідів журналу POST або eery Apache. У такому випадку ввести код у командному рядку було б смертельно просто.


У журналах відображається трафік часу, коли ці файли були змінені, але це нешкідливі речі, такі як: 207.46.13.43 - - [05 / травня 2010: 01: 42: 26 -0700] "GET /oped/bpr.php?edid= 211 & page = 4 HTTP / 1.1 "404 257" - "" msnbot / 2.0b (+ search.msn.com/msnbot.htm ) "
Lothar_Grimpsenbacher

Чи знаєте ви, як працював цей хакер Wordpress? Можна сказати мені, як виправити власну проблему.
Lothar_Grimpsenbacher

2
Так, це були погані дозволи на спільні вікна, можливо, спричинені неправильними конфігураціями за замовчуванням з боку Network Solutions. Рекомендованим виправленням було блокування дозволів як 755 для папок, так і 644 для файлів.

1

Код завжди додається, завжди в одному конкретному каталозі

Це пов’язано з дозволами, встановленими для файлів (від 755 до 644)? Для користувача веб-сервера

Ви перебуваєте на спільному сервері? Якщо так (або навіть якщо ні), хтось, можливо, жорстоко змусив пароль FTP та завантажив сценарій, який додає будь-які файли, до яких він може потрапити.

той, який використовується рекламною програмою третьої сторони

А може, ця програма має подвиг.


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

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

Код третьої сторони ... це виконавчий скрипт або просто фрагмент JavaScript? JavaScript не може змінювати файли на сервері.
Салман А

@Salman A - це сукупність скриптів PHP, які керують рекламою.
Lothar_Grimpsenbacher

Гаразд, тоді я сподіваюся, що ви дослідили цей код.
Салман А

1

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


1

Перевірка журналів FTP - це перше місце. Журнал повинен містити більшість, якщо не всю діяльність, а також часові позначки, тому, якщо ви знаєте, в який час ваші файли були змінені, ви можете визначити, чи є ваш обліковий запис FTP порушений чи ні.

Далі це може бути сценарій на вашому веб-сервері, який вводить цей код. У сценарії спільного хостингу, я думаю, що це можливо зробити cat /web/malicious.com/script.js >> /web/innocent.com/index.php. Це може працювати в певних умовах, таких як команда, виконана користувачем httpd, а файл index.php також належить / записується цим користувачем. У такому випадку у вас повинен з’явитися ваш хостинг-провайдер, щоб простежити обліковий запис, який використовується для введення скриптів.


1

Більшість файлів сайтів потрібно читати веб-сервером. На веб-сервері, доступному лише для читання, веб-сервер повинен записувати лише журнали. встановити власника на когось іншого, ніж використовуваний веб-сервер. Встановіть захист 640 на всі файли, крім скриптів. Встановлення скриптів та каталогів 750. Для файлів чи каталогів, які потрібно записати веб-сервером, ви можете змінити власника на веб-сервер або встановити chmod g + 2 на відповідні файли чи каталоги.


Сценарії, що не належать до CGI, часто можуть мати режим 600 або 640 (залежно від власника файлу та групи та від того, якого користувача працює веб-сервер), оскільки багато сценарії передаються інтерпретатору.
outis

0

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

На першому кроці перевірте дату зміни файлу та перевірте журнали доступу, помилок та ftp на наявність підозрілих дій у той час.


0

Те саме трапилося зі мною назад. Наскільки я знаю, Wordpress було єдиним програмним забезпеченням, яке спричинило б щось подібне.


Тут немає жодного Wordpress.
Lothar_Grimpsenbacher
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.