Може би сте видeли предупреждение, когато сте отворили сайта си тази сутрин. Сайтът Ви може и да пренасочва към друг сайт, който се опитва да продаде нещо на посетителите си. Може да сте забелязали почти невидимо съобщение точно над заглавното изображение на сайта си. В него, "хакер" твърди, че Вашата сигурност е "w34k". Или може би просто сте посрещнати от много внезапен и неочакван "Бял екран на смъртта".
Основната причина за всички тези неща може да е една и съща: хакерска атака. Нарастващата популярност на различни инструменти за автоматизация улеснява атакуването на сайтове посредством слабости в сигурността на WordPress и негови теми и/или плъгини. Същите инструменти могат да се използват и за brute-force атаки, целящи да добият достъп до Вашия административен акаунт. Не е изненада, че виждаме все повече компрометирани сайтове всеки ден. Докато ние правим всичко възможно да защитим активно инфраструктурата си срещу хакерски атаки, клиентите ни инсталират свои собствени приложения, което неминуемо повишава риска за сигурността.
В тази статия ще разгледаме как експертите от нашия екип от отдел "Сигурност" подхождат към подобни случаи. За този пример сме избрали инсталация на WordPress, но докато детайлите могат да бъдат различни, логическата рамка на разследването е почти идентична за повечето уеб приложения.
Инцидентът
Ние извършваме редовни антивирусни проверки на всеки хостинг акаунт. Въпреки това, поради характера на PHP обфускацията (маскиране на програмен код), злонамереният софтуер може дълго време да остане неразкрит. В този случай клиентът ни уведоми, че е получил предупреждение за злонамерено съдържание, когато посещава сайта си, така че нашите колеги се наеха да прегледат ръчно неговите файлове. Обикновено инсталацията на WordPress съдържа набор от стандартни файлове в основната си директория. Същото важи за всички основни CMS приложения. Няколко файла веднага привлякоха вниманието с необичайните си имена:
133ja3lore.php a1cw42ipim.php
Ще използваме някои от стандартните инструменти на UNIX командния ред, за да получим повече информация за тези файлове и за това как те първоначално са се появили в акаунта. Всички наши хостинг планове предоставят SSH достъп, както и такъв до Apache логовете, така че можете да възпроизведете тези стъпки и сами.
Кога са създадени/променени злонамерените файлове
Командата stat предоставя много информация за всеки файл. Ето как изглеждат нейните изходни данни:
[17:09:32] server~$ stat /home/user/www/www/133ja3lore.php File: /home/user/www/www/133ja3lore.php Size: 4909 Blocks: 16 IO Block: 4096 regular file Device: fc00h/64512d Inode: 202768472 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 4731/user) Gid: ( 4674/user) Access: 2018-02-02 15:16:02.000000000 +0800 Modify: 2018-02-02 15:16:02.000000000 +0800 Change: 2018-08-07 20:49:47.771134758 +0800 Birth:
[17:09:43] server~$ stat /home/user/www/www/a1cw42ipim.php File: /home/user/www/www/a1cw42ipim.php Size: 4909 Blocks: 16 IO Block: 4096 regular file Device: fc00h/64512d Inode: 202768462 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 4731/user) Gid: ( 4674/user) Access: 2018-02-02 15:16:02.000000000 +0800 Modify: 2018-02-02 15:16:02.000000000 +0800 Change: 2018-08-07 19:41:46.676971426 +0800 Birth:
Основната разлика между mtime (Modify) и ctime (Change) е, че mtime показва последната промяна на съдържанието на файла, докато ctime показва последната промяна на съдържанието на файла или на един от неговите атрибути (такива като разрешения или собственик). В зависимост от ситуацията, можем да търсим в логовете за ctime времето, mtime времето, или дори и двете.
В този случай ще използваме ctime за нашия анализ, тъй като и за двата файла това е по-новият атрибут. Също така, ще започнем с търсене на отметката за време, която получихме от a1cw42ipim.php, тъй като този файл е бил променен около час по-рано. Следователно, предполагаме, че е качен първи и ни приближава до момента, в който хакерите са добили достъп до акаунта.
Анализ на логовете
Можете да следите логовете в реално време през секция "Логове" в Контролния панел - това е полезно в случай, че искате да анализирате нещо, което току що се е случило. В нашия случай, атаката е осъществена преди време и затова ще имаме нужда от по-стари логове. Те се намират в директория logs във Вашия хостинг акаунт и са достъпни през секция "Файлове" в Контролния панел, посредством FTP или SSH. Логовете са архивирани в gzip формат и затова ще използваме командата zgrep, за да работим с тях. Важно е да се отбележи, че архивираните логове са разделени на отделни файлове, като имената им отразяват името на поддомейна и деня. С оглед на тази информация и на часът предоставен от командата ctime, ще използваме следната zgrep команда:
zgrep "19:41:" /home/user/logs/2018-08/www-07.log.gzКогато анализираме логовете, обръщаме специално внимание на всички POST заявки, които откриваме. За разлика от GET заявките, където всички данни са кодирани в URL адреса, POST заявките включват данни в съдържанието (BODY) на заявката. Повечето уеб приложения използват този метод за качване на файлове и промени на настройките. По този начин може да се качи и злонамерен софтуер. Ето ги и изходните данни на командата, изпълнена по-горе:
www.domain.com 192.0.2.1 - - [07/Aug/2018:19:41:44 +0800] "POST /um-api/route/um!core!Files/ajax_image_upload/a2c75736fe HTTP/1.1" 200 407 "domain.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36" 0 0 "off:-:-" 5045 299593 192.0.2.2 domain.com www.domain.com 192.0.2.2 - - [07/Aug/2018:19:41:45 +0800] "POST /wp-content/uploads/ultimatemember/temp/Ao3uKpx8B9klgpJ6Ra7A8z0jycfjvtiZZDrPtZao/stream_photo_9c8d90bc587c22ae9aef83fcdb2a02d0_5b69857918ac2.php HTTP/1.1" 200 494 "domain.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36" 0 0 "off:-:-" 686 1047741 192.0.2.2 domain.com
Части от URL адресите в тези POST заявки - um-api и ultimatemember - предполагат, че нападателят е получил достъп чрез популярния плъгин Ultimate Member. В началото на август 2018 бяха обявени публично няколко уязвимости в Ultimate Member (CVE-2018-6943, CVE-2018-6944) и по-точно в проверката и валидирането на временните файлове при качване. Хакери от цял свят използваха тази уязвимост, за да качват злонамерен софтуер. Това е така и в нашия случай.
Важно е да се отбележи, че не всяко разследване протича толкова гладко. Злонамереният файл, който проучваме, може да е качен от друг злонамерен файл и да трябва да повторим същия процес няколко пъти, докато стигнем до момента, в който хакерите са добили достъп до акаунта. Хакерите често качват много файлове и изтриват предишните такива, за да замаскират своите действия. Също така е напълно възможно акаунтът да е бил компрометиран на друг сървър, преди да бъде преместен при нас. Всеки хостинг доставчик трябва да може да Ви предостави достъп и инструменти, необходими за извършване на стъпките, описани по-горе.
След като идентифицираме как и кога хакерите са добили достъп до Вашия акаунт, можем да започнем работа по почистването му и подобряването на неговата сигурност. Ще опишем това по-подробно в следващия ни пост по темата - как да почистим хакнат WordPress сайт.
