Преди около седмица приятелите ни от Sucuri ни изпратиха модифицирана версия на Apache уеб сървър, който пренасочва част от заявките към различни Blackhole пакети. Заинтригувани от откритието, анализирахме този вирус, наречен Linux/Cdorked.A. И открихме, че това е доста сложен бекдор*, който е предназначен да пренасочва трафик към потенциално опасни сайтове. Затова, системни администратори, проверете дали сървърите, които поддържате, не са сред стотиците засегнати, които ESET Live Grid откри до момента. Как точно може да го направите, може да прочетете в поста по-долу. Всъщност, Linux/Cdorked.A е една от най-софистицираните Apache атаки, които сме виждали до момента. Въпреки че все още обработваме информацията, системата ни Livegrid отчита стотици зарази или компрометирани сървъри. Вирусът не остава следи на харддиска, освен модифицирания httpd файл, което допълнително усложнява анализа на кода. Цялата информация, свързана със заплахата, се съхранява в споделената памет. Конфигурацията е изпращана от атакуващия, скрита под формата на HTTP заявки, които не се записват в логовете на Apache. Това означава, че на системата не се съхранява никаква командна информация за Linux/Cdorked.A. Технически анализ на Linux/Cdorked Тук може да научите малко повече за първия технически анализ на Linux/Cdorked, който изглежда засяга стотици уебсървъри и в момента. В binary файла на Linux/Cdorked цялата важна информация е криптирана. Както се вижда на долното изображение, има функция, която декриптира стриногвете при поискване със статичен XOR ключ. 
Версията на Linux/Cdorked, която анализирахме, съдържа общо 7 стринга, кодирани по този начин. Както се вижда на следващия скрийншот, ключът, използват за кодиране на информацията е 27A4E2DADAF183B51E3DA7F6C9E6239CDFC8A2E50A60E05F. 
Както вече споменахме, Linux/Cdorked не записва никакви файлове на харддиска. Вместо това, той алокира около 6 мегабайта споделена памет, за да съхранява конфигурационната си информация. Този блок памет от POSIX паметта се използва за всички Apache процеси и може да бъде достъпен от всички тях, тъй като вирусът не ограничава достъпа до тази памет. Долните сркийншоти показват (четене, писане за всички) правата, които са зададени на този фрагмент от споделената памет. 
Има два начина, по които атакуващият може да осъществи контрол върху поведението на заразения сървър: чрез обратна shell връзка или чрез подаване на специални команди, които се задействат чрез HTTP заявки.Вирусът Linux/Cdorked.A HTTP сървърът е оборудван със вратичка за обратна връзка, която може да бъде задействана чрез специална HTTP GET заявка. Тя е стартирана, когато бъде подадена заявка по специална пътека със стринг на самата заявка, който съдържа името на хоста и порта за връзка. Клиентското IP на HTTP диалога се използва за декриптирането на стринга на заявката под формата на 4-байтов XOR ключ. Освен това, клиентското IP се презаписва като XOR ключ. Това означава, че можем да създадем X-Real-IP хедър, който в действителност ще бъде "\x00\x00\x00\x00" ключ. Стрингът на заявката трябва да бъде кодиран преди изпращане. 
Паралелно с това, разкриването на вируса изисква следенето на продължителен HTTP трафик. От друга страна, HTTP заявите не се появяват в лог файла на Apache заради начина на вплитане на кода на вируса в сървъра. Пренасочване в Linux/Cdorked.A Когато пренасочва клиент, вирусът добавя base64 кодиран стринг към заявката, съдържаща информация, подобна на оригиналния адрес, който потребителят е искал да посети. И в зависимост от това, дали заявката е била насочена или не към javascript файл, за да може сървърът да отговори с адекватно натоварване. 
Примерно пренасочване изглежда така: Location: hxxp://dcb84fc82e1f7b01. xxxxxxgsm.be/index.php?j=anM9MSZudmNiaW11Zj1jY3 Zja3FqdSZ0aW1lPTEzMDQxNjE4MjctMzYwNDUzNjUwJnNyYz0yMzImc3VybD13d3cuaW5mZWN0ZWRzZXJ2 ZXIuY29tJnNwb3J0PTgwJmtleT0xM0Q5MDk1MCZzdXJpPS9mb3J1bS93Y2YvanMvM3JkUGFydHkvcHJvdG 9hY3Vsb3VzLjEuOC4yLm1pbi5qcw==След декодиране се появяват следните параметри: js=1&nvcbimuf=ccvckqju&time=1304161827-360453650&src=232&surl=www.infectedserver.com&sport=80&key=13D90950&suri=/forum/wcf/js/3rdParty/protoaculous.1.8.2.min.js Параметърът "surl" показва заразения хост, а "suri" е за индикация на оригиналния хост. След пренасочването, на клиента (засегнатият потребител) се запазва уеб бисквитка, за да не бъде пренасочен отново. Тази бисквитка се активира и в случай, че потребителят изпрати заявка към страница за администрация. Бекдорът проверява адреса и името на сървъра и проверява за някоя от следните ключови думи: '*adm*', '*webmaster*', '*submit*', '*stat*', '*mrtg*', '*webmin*', '*cpanel*', '*memb*', '*bucks*', '*bill*', '*host*', '*secur*', '*support*'. Това най-вероятно се прави с цел избягване на препращане на на зловредно съдържание към администраторите на сайтовете, което превръща откриването на заплахата в още по-трудно начинание. 
За осъществяване на пренасочването е необходимо изпълняването на още няколко условия. Например, извършва се проверка за присъствието на Accept-Language, Accept-Encoding и хедър за Referrer. Други Linux/Cdorked.A команди Открихме общо 23 команди в Linux/Cdorked.A, които могат да бъдат изпратени към сървъра чрез POST заявка към специално създаден адрес. Заявката съдържа и част от бисквитка, започваща с "SECID=". Стойността на заявката трябва да съдържа 2 хек-кодирани байта, които са криптирани с клиентското IP. SECID данните от бисквитката ще бъдат използвани като аргументи за част от командите. Вярваме, че адресите за пренасочване на клиентите се изпращат към бекдора именно чрез този метод. Пренасочената информация се съхранява криптирана в алокираното място от споделената памет. Вярваме, че условията за пренасочване се задават именно по този начин, например - одобрен списък от потребителски агенти за пренасочване могат да бъдат одобрени предварително, докато други списъци с IP-та могат да не бъдат пренасочвани. Открихме следният списък с команди в анализирания от нас файл: 'DU', 'ST', 'T1?, 'L1?, 'D1?, 'L2?, 'D2?, 'L3?, 'D3?, 'L4?, 'D4?, 'L5?, 'D5?, 'L6?, 'D6?, 'L7?, 'D7?, 'L8?, 'D8?, 'L9?, 'D9?, 'LA', 'DA'. И накрая, малко информация за статуса, който вирусът връща в ETag HTTP хедъра, както се вижда на скрийншота по-долу. Все още анализираме целта на всяка от тези команди и ще публикуваме резултатите след края на анализа ни. Накратко, всички те извършват операции именно в споделената памет, за която вече стана дума. Премахване на Linux/Cdorked.A Както вече казахме, блокираната памет е със свободни разрешения за употреба. Това позволява и на други процеси да я използват. Създадохме безплатен инструмент (dump_cdorked_config.py), с който системните администратори могат да проверят за присъствието на подобен регион от споделената памет и да съхранят съдържанието му във файл. Препоръчваме и използването на debsums за Debian или Ubuntu системи, както и `rpm -verify` за RPM базирани системи, за да гарантирате целостта на инсталацията на вашия Apache уеб сървър. Проверката за присъствието на непознати региони от споделената памет също е препоръчително.*Бекдор - вирус, който позволява на атакуващия да придобие администраторски права върху заразената машина