[침해사고분석] 웹 로그 분석하기 - 1

웹을 통한 침해사고 발생 시 웹 로그를 통해 공격자가 어떤 행위를 수행하였는 지 파악할 수 있다.

다만 웹 로그 용량이 100GB를 넘어가면 눈알이 빠질듯한 경험을 할 수 있는데.. 이것도 어느정도 요령껏 가능한 부분이다.

필자의 웹로그 분석 요령들을 공유해보고자 한다.

 

1. 웹 서비스 파악

 우선 어떤 종류의 웹 서버를 사용하는지(Windows IIS, Apache, Tomcat)등 에 따라 분석 요령이 약간씩 달라진다. 가장 편한것은 아무래도 Linux 기반의 APM 이다.

또한 VirtualHost 기능을 사용해서 하나의 웹 서버에서 다수의 웹 서비스를 제공하는 경우도 있기 때문에 침해가 발생한 웹 서비스를 정확하게 구분하는것도 중요하다.

 

2. 분석전략

 우리에게는 수십만-수백만 줄의 로그가 주어진다. 자 아무것도 모르는 깜깜 무소식인 상태에서 우리는 어떤 접근 방법을 사용할 수 있을까? 필자는 다음 방법들을 주로 사용했다.

구분 1	구분 2
악성 파일 존재	악성 파일 생성 시각 전후
	악성 파일 접근 IP
악성 파일 부재	접근횟수 기반 IP 필터링
	접근 경로(URL) 기반 필터링
	SQLI 구문 필터링
	특정 파일 기반 필터링
	XSS 구문 필터링

 

2-1. 악성 파일 존재시

 만약 공격자가 서버에 악성 파일을 생성했다면 분명히 업로드 경로에 악성 파일이 존재할 것이다. 또는 최초 업로드 경로에 악성파일 생성 후 다른 곳에 또다른 악성파일을 생성하고 업로드 경로에 존재하는 악성 파일은 지워버렸을 가능성이 있다.

 만약 의심스러운 악성파일(일반적으로 웹셸)이 존재한다면 웹셸 경로를 기반으로 어떤 IP가 접근했는지 필터링 해볼 수 있다.

만약 웹 로그 파일이 overwrite되지 않았다면 공격자가 악성파일을 업로드한 방법을 웹로그를 통해 추측할 수 있을 것이다.  (물론 다양한 이유로 불가능한 경우도 존재한다)

 

2-2. 악성파일 부재시

 만약 악성파일이 존재하지 않는다면? 필자는 다음 순서로 주로 분석을 진행했다.

1. 가장 먼저 관리자 로그인에 성공한 IP들을 필터링 해본다. 그리고 관리자가 사용하는 IP가 맞는지 확인한다.
   * 관리자 로그인 시간 정보도 중요하다. 업무시간대가 아니라면 의심해볼 수 있다.
2. 접근 횟수가 많은 IP부터 줄을세워본다.
3. 그 다음은 접근 경로(url)별로 필터링 해본다. 분명히 공격자가 많이 접근한 악성 파일이 확인 될 수 있다.
4. 서버에 있는 정상적인 기능들이지만 악용될 수 있는 파일들, 예를 들면 파일 업로드, file inclusion, query 실행 등 기능이 있는 파일에 접근한 IP들을 살펴본다.
5. SQLI 공격 정황이 확인된다면 SQLI 를 필터링하고 SQLI 공격을 수행 IP들을 대상으로 다시 필터링을 수행한다.
6. XSS 공격 이력을 확인해본다.

 

* 만약 root가 탈취 당했고 VirtualHost 기능을 사용해 다수 웹 서비스를 제공중이라면, 다른 웹 서버 경로에도 악성 파일이나 악성 스크립트가 생성되었을 수 있기 때문에 피해 범위를 파악하는 것도 중요한 작업이다.

 

3. 필터링

우리는 리눅스에서 제공하는 간단하고도 강력한 기능들을 분석에 사용할 수 있다.

명령	기능	설명
grep	문자열 필터링	다양한 옵션들로 파일 내부에 텍스트들을 필터링
awk	파일 포매팅	스크립트 언어를 지원하기 때문에 정말 활용도가 높지만, 포매팅 기능이 유용
sort	정렬	오름차순 or 내림차순 정렬에 유용
uniq	중복제거	중복제거와 함께 카운팅 기능이 유용

한번 예시를 들어보자

 

3-1. grep

grep <filter string> <file name> 또는 cat <file> | grep <filter string> 으로 원하는 텍스트를 필터링 할 수 있다.

login.php 파일에 접근한 기록을 필터링해보자.

 

3-2. awk

awk는 파일 포매팅 기능을 지원한다고 했다. grep과 연결하면 필요한 정보만 추출해볼 수 있다. 필자는 ip, 시각, http method, 접근 파일 네 가지만 출력시켜 보겠다.

cat access.log.2 | grep login.php | awk '{print $1, $4, $6, $7}'

필자가 의도한대로 출력이 되었다. 중간에 login_check.php , favicon.ico 등이 같이 필터링 되었는데 이는 referrer 컬럼에 login.php라는 텍스트가 존재하기 때문에 grep 단계에서 걸러지지 못한 것들이다.

 만약 깔끔하게 걸러내고 싶다면 awk 를 앞단에서 사용해 먼저 필터링을 해볼수도 있다.

처럼 말이다.

 

3-3. uniq

해당기능은 중복 제거 기능을 제공한다. IP별로 필터링할때 정말 유용한 기능이다. 왜냐하면 카운팅 기능도 제공하기 때문이다. 다음을 보자

cat access.log.2 | awk '{print $1, $7}' | grep login.php | awk '{print $1}' | uniq -c

상당히 복잡해 보이지만 파이프를 기준으로 보면 매우 간단하다. 

1. awk 로 ip와 접근 파일 만 출력하도록 포맷팅
2. 그 중 login.php 에 접근한 컬럼만 필터링
3. ip만 출력하도록 포맷팅
4. 중복 을 제거하며 접근 횟수 카운팅

 

3-4. sort

sort 는 정렬기능을 제공한다. 특히 -r 옵션을 주면 내림 차순으로 정렬되어 많이 접근한 ip 순서로 필터링을 해볼 수 있다.

cat access.log.2 | awk '{print $1, $7}' | grep login.php | awk '{print $1}' | uniq -c | sort -r

 

이러한 과정들을 거쳐 의심스러운 활동 내역을 가진 IP별로 로그를 필터링 해볼 수 있다.

이렇게 말이다.

 

3-5. awk 응용하기

위에서 sort -r로 줄세운 결과중에 ip들이 중복되는 결과를 볼 수 있다. 이는 3-4에서 uniq 를 사용하기전 정렬해주지 않은 결과다.

따라서 uniq 전 한번 더 정렬해주면 된다.

cat access.log.2 | awk '{print $1, $7}' | grep login.php | awk '{print $1}' | sort | uniq -c | sort -r

깔끔하게 출력되는 것을 볼 수 있다. 

이 명령의 순서는 여러분들이 직접 한번 분석해보기 바란다.

 

* 사실 이 모든 기능들을 awk 만으로도 할 수 있지 않을까? 하는 생각이 들긴한다.

awk '$7 ~ /login\.php/ {count[$1]++} END {for (ip in count) print count[ip], ip}' access.log.2 | sort -nr

여러분이 awk에 익숙해진다면 이렇게도 해볼 수 있지 않을까?

 

3. File Upload 탐지

File Upload기능은 스마트 에디터의 올바르지 않은 파일 검사, 잘못된 php 설정, 또는 아주 오래된 null byte inejction등에 의해 발생한다. (필자의 기억에 아마도 PHP 5.1 이하) 또는.. 정말 이건 잘못된 것이지만, 파일 검사 과정을 JS로 수행하는 에디터도 있었다. 심지어는 계정정보 인증 과정을 JS로 처리하는 ERP도 있었다.

 이 외에도 다양한 파일 업로드 공격이 가능한데, 상세 사항은 다음 이글루의 글을 참고해보자.

https://www.igloo.co.kr/security-information/%ec%9b%b9%ec%89%98%ec%9d%84-%ec%9d%b4%ec%9a%a9%ed%95%9c-%ea%b3%b5%ea%b2%a9-%ed%8c%a8%eb%9f%ac%eb%8b%a4%ec%9e%84-%eb%b3%80%ed%99%94-%eb%b0%8f-%eb%8c%80%ec%9d%91%ec%a0%84%eb%9e%b5/

웹쉘을 이용한 공격 패러다임 변화 및 대응전략

 

일반적으로 클라이언트 단에서 서버로 파일을 업로드할때는 POST Method를 사용하기 때문에 POST 를 키워드로 삼아 필터링해볼 수 있다.

자 보면 뭔가 write.php 가 수상하다. write.php 파일을 확인해보면

파일 업로드 기능이 존재하는 것을 확인할 수 있다.

또 악성파일 이름을 알고있다면 파일 업로드전에 어떤 php 파일에 접근했는지 어떤 파일에서 업로드 기능을 제공하는지 추적해볼 수도 있을 것이다.

 

*PUT 또한 서버에 악성파일을 사용할 수 있는 method이나, 잘 사용되지 않는다.

 

4. SQLI 탐지

 SQLI는 XSS 만큼이나 variation이 다양하기 때문에 분석가의 역량에따라 분석 결과가 많이 달라진다.

 SQLI에는 종류가 많다. 기본적인 논리연산을 활용한 SQLI부터 Blind SQLI, Error Base SQLI, Union Base SQLI 등.. 이외에도 다른 기법이 존재할수도 있다.

 

4-1. Basic SQLI

  웹 로그에는 서버에서 클라이언트로 보낸 데이터 크기도 기록이 된다. 바로 bytes 컬럼인데, 만약 SQLI 공격이 발생했다면 해당 컬럼을 유심히 봄으로써 공격자가 SQLI에 성공했는지 성공하지 못했는지 여부를 파악할 수 있다.

 SQLI가 실패한 동안은 비슷한 크기의 데이터를 수신하겠지만, SQLI가 성공한다면 DB에 저장된 데이터를 불러오고 아마도 비슷한 크기의 데이터들 보다 확 튀는 크기의 데이터를 전송할 가능성이 크다.(물론 모든 경우에 다 그런건 아니다)

 

4-2. Blind SQLI

 Blind SQLI는 서버의 응답으로 데이터의 참 거짓 여부를 판단하는 공격 방법이다. 예를 들어보면 다음과 같다.

SELECT * FROM users WHERE id = '\$id' and pw='\$pw'; 이라는 쿼리가 있을 때

$id 에 admin' and len(pw)=1-- 이라는 값을 입력하면 어떻게 될까?

SELECT * FROM users WHERE id = 'admin' and len(pw)=1-- ' and pw='$pw';

라는 쿼리가 완성되고 -- 뒤는 주석처리 될 것이다.

그리고 pw 길이가 1이라면 true를 아니라면 false를 리턴한다. 이 방법을 반복함으로써 pw 길이를 알아낼 수 있다.

같은 방법으로 pw 첫자리부터 끝까지 한글자씩 ascii랑 비교해서 참 or 거짓을 판단한다면? 계정정보를 탈취할 수 있다.

그럼 웹 로그에서 Blind SQLI를 어떻게 탐지할 수 있을까? 사실 이건 마땅한 방법은 없다. 그냥 웹로그에서 SQLI 공격 기록들을 모두 필터링해서 살펴보는것이 최선이다.

 

4-3. Error Base SQLI

 DB 쿼리에 의도적으로 에러를 일으키고 이를 이용해 DB 데이터를 탈취하는 방법이다. 이 공격 또한 리턴되는 데이터 크기가 크다면 4-1과 유사한 관점으로 탐지할 수 있다.

 

4-3. Union Base SQLI

 DBMS에서 Union은 두 테이블을 합치는 명령이다. 예를 들면 product라는 테이블을 조회하는 쿼리에 UNION 을 사용한다면 user 테이블을 합쳐서 유저 정보를 함께 조회할 수 있다.

 이 또 한 리턴되는 데이터 크기가 달라지기 때문에 4-1과 유사한 방법으로 추정해볼 수 있다.

 

5. 주의할 점

웹 로그는 head의 내용만 기록을 남긴다. 따라서 만약 공격자가 Body에 페이로드를 싣었을 경우 웹로그 분석만으로는 페이로드 내용을 확인할 수 없다. 이 말을 좀 더 다르게 표현해보자면

POST 를 사용한 공격은 공격자의 상세 행위를 파악할 수 없다는 말과 같다. 만약 여러분들이 웹로그 분석을 해야하는데, 공격자가 POST 요청을 사용했다면 GET 요청과는 다른 관점으로 접근해야한다는 의미다.