해킹당했습니다. 방법을 이해하고 싶다


40

누군가가 두 번째로 내가 실행하는 사이트에 자바 스크립트 덩어리를 추가했습니다. 이 자바 스크립트는 Google 애드 센스를 가로 채어 자신의 계정 번호를 삽입하며 광고를 계속 고집합니다.

코드는 항상 하나의 특정 디렉토리 (제 3 자 광고 프로그램에서 사용하는 디렉토리)에 항상 추가되며이 하나의 ad dir (20 개 정도) 내의 여러 디렉토리에있는 많은 파일에 영향을 미치며 밤새 거의 동일하게 삽입됩니다. 시각. 이 애드 센스 계정은 중국 웹 사이트에 속해 있습니다 (다음 달에 중국에있을 시간에서 한 시간이 아닌 거리에 위치합니다. 어쩌면 내가 흉상을 타야합니다. 사이트 : http://serversiders.com/fhr.com.cn

그렇다면 어떻게이 파일에 텍스트를 추가 할 수 있습니까? 파일에 설정된 권한 (755에서 644까지)과 관련이 있습니까? 웹 서버 사용자에게 (MediaTemple에 있으므로 안전해야합니까?)? 권한이 777로 설정된 파일이 있다면 원하는대로 코드를 추가 할 수 없습니다. 어떻게해야합니까?

다음은 시청의 즐거움을위한 실제 코드 샘플입니다.

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

많은 사람들이 그것을 언급 했으므로 여기에 내가 확인한 것이 있습니다 (그리고 체크하면 파일이 이상한 것으로 수정 된 시간을 살펴보고 POST 문과 디렉토리 탐색을 위해 파일을 가져 왔습니다.

  • access_log (정상적인 (즉, 과도한) MSN 봇 트래픽을 제외하고 시간 내내 아무것도 없음)
  • error_log (아무것도없는 파일에 대한 오류는 없지만 일반적인 파일은 없습니다)
  • ssl_log (아무것도 아닌 것)
  • messages_log (나를 제외하고는 여기에 FTP 액세스가 없습니다)

* 업데이트 : ** 좋아, 해결했다. 중국의 해커들은 물리적으로 모든 종류의 관리 작업 (데이터베이스 액세스, 파일 및 디렉토리 삭제 및 생성, 이름, 액세스 권한)을 수행 할 수있는 파일을 사이트에 실제로 배치했습니다. 우리는 그들이 더 파괴적인 일을하지 않았기 때문에 운이 좋았습니다. 일반적인 아파치 로그 파일에는 아무것도 없었지만 웹 서버 로그 분석기에서 다른 로그 파일 세트를 발견했으며 그 증거가 있습니다. 그들은 자신의 관리자 사용자 이름과 비밀번호로이 파일에 액세스 한 다음 서버에서 필요한 모든 것을 편집했습니다. 우리 사이트의 다른 모든 파일은 다른 사용자 이름을 가지고 있지만 파일은 "apache"로 설정되어 있습니다. 이제 그들이 실제로 어떻게이 파일을 우리 시스템에 가져 왔는지 알아 내야합니다. 나는 이것이 우리의 웹 호스트 (Media Temple)와 함께 휴식을 취해야 할 책임이 있다고 생각합니다.


6
잘 모르겠습니다. 다른 사람에게 비밀번호를 알려주셨습니까?

4
이것이 정확히 언제 발생하는지 아는 경우, access_log에서이시기에 특이한 모든 것을 검색하십시오. 특히 모든 POST 요청을 기록하십시오. 어디로 가고, 무엇을했는지.
sanmai

3
Thx WhirlWind ... 매우 도움이되었습니다.
Lothar_Grimpsenbacher

2
실제로 알고 있다면 스팸 방지 사이트에 주소 세부 정보를 붙여 넣으십시오. 그물이 그들에게 "말하기"를하도록하고 그들 자신의 메다 시네의 맛을냅니다. :-)

4
@ gaoshan88 — 생각하면 도움이 될 것입니다. 하나의 공격 경로는 개발자의 ftp 클라이언트에서 비밀번호를 스니핑하는 트로이 목마입니다.
Quentin

답변:


9

chmod 744무엇 보다도 당신이 원하는 것이 아닙니다. chmod의 요점은 시스템의 다른 계정에 대한 액세스를 취소하는 것입니다. Chmod 700는 chmod보다 훨씬 안전 744합니다. 그러나 Apache는 PHP 응용 프로그램을 실행하기 위해 실행 비트 만 필요합니다.

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-data는 일반적으로 PHP를 실행하는 데 사용되는 Apache 계정으로 사용됩니다. 이 명령을 실행하여 사용자 계정을 볼 수도 있습니다.

`<?php
print system("whoami");
?>`

FTP는 매우 안전하지 않으며이 방법으로 해킹 당했을 가능성이 높습니다. FTP를 사용하면 파일을 쓸 수있게 만든 다음 다시 감염시킬 수 있습니다. FTP 액세스 권한이있는 모든 시스템에서 안티 바이러스 를 실행하십시오 . FTP 사용자 이름 및 비밀번호에 대한 로컬 트래픽을 스니핑 한 후 로그인하여 파일을 감염시키는 바이러스가 있습니다. 보안에 관심이 있다면 SFTP를 사용하여 모든 것을 암호화합니다. 일반 텍스트로 유선으로 소스 코드와 암호를 보내는 것은 완전한 광기입니다.

또 다른 가능성은 오래된 라이브러리 또는 응용 프로그램을 사용하고 있다는 것입니다. 소프트웨어 공급 업체 사이트를 방문하여 최신 버전을 실행하고 있는지 확인하십시오.


6
+1, 전염병과 같은 FTP를 피하십시오. 암호 스니퍼 트로이 목마는 컴퓨터를 감염시키고 자격 증명을 사용하여 파일을 변경할 수 있습니다. 또는 라우터를 감염시킬 수 있습니다. 또는 보안되지 않은 Wi-Fi 네트워크가있는 netcafe의 이웃 컴퓨터. clearext로 비밀번호를 보내는 것은 좋지 않습니다.
Tgr

1
FTP 에는 SSL이 포함되어 있습니다.
grawity

1
@grawity 대부분의 사람들은 "ftps"를 사용하지 않지만 해킹 당하지 않습니다. sftp가 더 유명합니다.
루크

2
www-data는 웹 디렉토리에 파일을 소유 하지 않아야 합니다. 서버에서 잘못 작성된 스크립트로 www-data 가 업데이트되는 모든 항목
Zoredache

9

내 Media Temple Grid Server 계정은 이와 같이 "해킹되었습니다". 보안은 매우 열악합니다. 작년에 일반 텍스트 비밀번호로 시작하여 오늘까지 계속됩니다 (기술 지원 부서에 문의하면 "비밀번호는 무엇입니까?"). 계정 비밀번호를 어떻게 변경했는지에 대한 월별 이메일을 받고 해킹 당할 때마다 실제로 데이터베이스 비밀번호를 입력하고 변경하기 때문에 알고 있습니다. 그 회사는 표면에 지옥처럼 보이지만 그리드 서버는 엉망입니다. 즉시 전환하는 것이 좋습니다 .

작년부터 원래의 실패대해이 게시물을 참조하십시오 (경고, 당신을 화나게 할 것입니다). 거기에서 내리막 길로 갔다. 작년에 가족과 떨어져 추수 감사절을 보내고 웹 사이트에서 포르노 링크를 제거했습니다. 아름다운.

상태 페이지 에서 재미를 추적 하십시오 : 최신 익스플로잇에 대해 모두 알려줍니다 (예, 실제로 "가능한 익스플로잇"이 있습니다).


하하. 내 gs 사이트가 모두 다운되었습니다. 이메일이 없습니다. weblog.mediatemple.net/weblog/category/system-incidents/…
typeoneerror

2

액세스 로그 등의 활동 부족과 거의 동시에 발생한다는 사실을 기반으로 서버를 손상시키고 추가를 실행하기 위해 일종의 쉘 스크립트가 실행되는 것처럼 보입니다.

crontab에서 이상한 점을 확인 했습니까?

디렉토리와 디렉토리의 이름을 바꾸려고 했습니까 (쉘 스크립트가 손상 될 수 있습니까)?


이름을 바꾸는 것이 좋습니다. 사이트에 어떤 영향을 미치는지 확인한 후에 시도해 보겠습니다. Crontab에는 약간 이상한 점이 있었는데, 파일이 변경된 시간에 대한 항목이 있지만 Plesk 백업 관리자입니다. 컴파일 된 응용 프로그램입니다. 그것이 타협되면 미디어 템플은 큰 문제가 있습니다.
Lothar_Grimpsenbacher

1

예, 파일 권한과 관련이있을 수 있습니다. 웹 프로세스에서 쓸 수있는 파일이 있으면 실행중인 웹 응용 프로그램의 보안 취약점에 노출됩니다. 웹 프로세스가 필요한 것 이상을 읽거나 쓸 수 없도록 모든 것을 잠급니다.

다른 구성 요소는 파일 수정 방법을 정확하게 추적합니다. 웹 서버의 액세스 로그를 확인하는 것이 좋습니다. 다양한 사용자의 마지막 로그인 시간을 확인하십시오. 또한 수정을 위해 파일을 모니터링하고 알려주는 범죄자를 적발 할 수 있도록 스크립트를 설정할 수도 있습니다.


1

이것은 최근 수많은 네트워크 솔루션 사이트를 공격하는 Wordpress 해킹에 매우 익숙합니다 . 미디어 템플을 사용하고 있기 때문에 컴퓨터를 공유하는 다른 사용자가 일부 파일을 볼 수 있습니다. POST 또는 eery Apache 로그 추적이 부족하다는 것을 설명합니다. 이 경우 명령 행에 코드를 삽입하는 것은 매우 간단합니다.


로그는 이러한 파일이 수정 된 시간에 대한 트래픽을 보여 주지만 다음과 같은 무해합니다. 207.46.13.43--[05 / May / 2010 : 01 : 42 : 26 -0700] "GET /oped/bpr.php?edid= 211 & page = 4 HTTP / 1.1 "404 257"- ""msnbot / 2.0b (+ search.msn.com/msnbot.htm ) "
Lothar_Grimpsenbacher

Wordpress 핵이 어떻게 작동했는지 알고 있습니까? 내 문제를 해결하는 방법을 알려줄 수 있습니다.
Lothar_Grimpsenbacher

2
예. 공유 상자에 대한 권한이 잘못 되었기 때문에 네트워크 솔루션의 일부 기본 구성이 잘못되었을 수 있습니다. 권장 수정 사항은 폴더에서 755로, 파일에서 644로 권한을 잠그는 것입니다.

1

코드는 항상 하나의 특정 디렉토리에 추가됩니다.

파일에 설정된 권한 (755에서 644까지)과 관련이 있습니까? 웹 서버 사용자에게

공유 서버에 있습니까? 그렇다면 (혹은 그렇지 않더라도) 누군가 누군가가 FTP 암호를 강제로 사용하고 직접 사용할 수있는 파일을 추가 한 스크립트를 업로드했을 수 있습니다.

타사 광고 프로그램에서 사용되는 광고

또는이 프로그램은 악용 될 수 있습니다.


타사 코드에 악용이 있다고 가정합니다. 그것은 공유 서버에 있지만 나는 (그들이 그것을 업로드 그것을 사용 후 삭제하지만 그렇다하더라도 내가 그들의 FTP 연결을 보여주는 로그 파일에 무언가를 발견하지 않는 한) 모든 업로드 된 스크립트를 발견 한 것
Lothar_Grimpsenbacher

1
웹 서버에서 파일을 쓸 수있는 경우 서버의 모든 웹 사이트에 스크립트를 업로드하고 파일을 덮어 썼을 수 있습니다. 그러나 해당 타사 앱도 자세히 살펴 보겠습니다.

타사 코드는 ... 그것은 실행 스크립트하거나 자바 스크립트 코드 조각인가? JavaScript는 서버에서 파일을 수정할 수 없습니다.
살만 A

@Salman A-광고를 관리하는 PHP 스크립트 모음입니다.
Lothar_Grimpsenbacher

좋아, 그런 코드를 조사했으면 좋겠다.
살만 A

1

적절한 액세스 권한 (및 커널 지원)이있는 경우 inotify 또는 dnotify 를 기반으로 모니터링 데몬 을 설정하여 파일 변경을 감시 한 다음 (빠른) "lsof"를 사용하여 파일이 열린 프로세스를 확인하십시오. 쓰기 권한. strace 를 사용 하여 모니터링 할 수도 있습니다 . 그것은 어떤 실행 파일이 악용되고 있는지에 대한 단서를 제공해야합니다.


1

FTP 검사 로그가 가장 먼저 시작됩니다. 로그에는 타임 스탬프와 함께 모든 작업이 아닌 대부분의 작업이 포함되므로 파일이 수정 된 시간을 알고 있으면 FTP 계정이 손상되었는지 여부를 확인할 수 있습니다.

다음으로 웹 서버에서 해당 코드를 주입하는 스크립트 일 수 있습니다. 공유 호스팅 시나리오에서는 가능한 일이라고 생각합니다 cat /web/malicious.com/script.js >> /web/innocent.com/index.php. 이것은 httpd 사용자에 의해 실행되는 명령과 같은 특정 조건 하에서 작동 할 수 있으며 index.php 파일도 해당 사용자가 소유 / 기록 할 수 있습니다. 이 경우 스크립트를 주입하는 데 사용되는 계정을 추적하도록 호스팅 제공 업체가 있어야합니다.


1

대부분의 사이트 파일은 웹 서버에서 읽을 수 있어야합니다. 읽기 전용 사이트에서는 웹 서버가 로그 만 쓸 수 있어야합니다. 웹 서버에서 사용하지 않는 다른 사람으로 소유자를 설정하십시오. 스크립트를 제외한 모든 파일에 보호 640을 설정하십시오. 스크립트 및 디렉토리 설정 750. 웹 서버가 작성해야하는 파일 또는 디렉토리의 경우 소유자를 웹 서버로 변경하거나 chmod g + 2 관련 파일 또는 디렉토리를 설정할 수 있습니다.


많은 스크립트가 인터프리터에 전달되므로 CGI 이외의 스크립트는 파일 소유자 및 그룹 및 웹 서버가 실행하는 사용자에 따라 600 또는 640 모드를 가질 수 있습니다.
outis

0

사이트를 크랙 할 수있는 방법은 여러 가지가 있습니다. 스크립트에서 취약점을 사용하고, 암호를 도난 당하고, 공동 호스팅 사이트의 취약점을 사용하고 (저렴한 호스트 인 경우) 웹과 관련이없는 서비스의 일부를 서버 시스템에서 사용했을 수 있습니다. .

첫 번째 단계로 파일 수정 날짜를 확인하고 그 당시 의심스러운 활동이 있는지 액세스, 오류 및 ftp 로그를 확인하십시오.


0

나에게도 같은 일이 일어났다. 워드 프레스는 내가 아는 한 이런 일을 일으킨 유일한 소프트웨어였습니다.


여기에는 워드 프레스가 없습니다.
Lothar_Grimpsenbacher
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.