웹 애플리케이션 취약점 공격 대응하기

이상현·2024년 12월 7일

고민 과정

목록 보기
3/3

자바 애플리케이션 로그에서 비정상적인 로그 발견

AWS EC2에 올려둔 스프링 부트 애플리케이션 로그에 다음과 같은 이상한 로그를 발견했다

2024-11-30T20:51:34.529Z  INFO 283793 --- [server] o.apache.coyote.http11.Http11Processor   : Error parsing HTTP request header
java.lang.IllegalArgumentException: Invalid character found in the request target [/index.php?s=/index/\think\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=Hello ]. The valid characters are defined in RFC 7230 and RFC 3986
  • [/index.php?s=/index/\think\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=Hello ].
    이 요청은 ThinkPHP 프레임워크의 취약점을 악용하는 공격이며, 해당 URL은 PHP의 call_user_func_array 함수를 사용하여 md5 해시 함수를 실행하려는 시도이다.

해당 취약점은 PHP 버전을 최신 버전으로 올리면 문제가 없다. 다행히 PHP를 사용하고 있지도 않아서 문제 없었다.

2024-12-01T21:27:47.221Z  INFO 283793 --- [server] o.apache.coyote.http11.Http11Processor   : Error parsing HTTP request header

java.lang.IllegalArgumentException: Invalid character found in the request target [/.env.{{DN}} ]. The valid characters are defined in RFC 7230 and RFC 3986
  • [/.env.{{DN}} ]
    이 요청은 [/.env.{{DN}} ] 공격으로 이는 .env 파일에 접근하려는 시도이다. 이는 환경 변수나 민감한 정보를 추출하려는 공격이다.

참고 기사: 최근 노출된 .env 파일 악용해 수천 개 기업 사이버공격한 정황 포착

NginX 로그에서 비정상적인 요청 확인

위 두 로그를 확인하고, EC2의 우분투 서버에 ssh로 접속하여 nginx 로그를 확인해 봤다.
/var/log/nginx/access.log

125.228.50.59 - - [01/Dec/2024:00:13:22 +0000] "GET / HTTP/1.0" 404 162 "-" "Mozilla/5.0 (Linux; U; Android 4.0.3; ko-kr; LG-L160L Build/IML74K) AppleWebkit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/53
4.30"
43.130.14.245 - - [01/Dec/2024:00:14:18 +0000] "GET / HTTP/1.1" 301 178 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/6
04.1"

비정상적인 요청 예시

위와 비슷한 몇천개의 비정상적인 요청이 확인되었다.

  • GET / HTTP/1.0, GET / HTTP/1.1
    서버 버전을 알아내기 위한 요청
  • GET /robots.txt HTTP/1.1, GET /sitemap.xml HTTP/1.1, GET /favicon.ico HTTP/1.1
    사이트 구조를 알아내려는 요청 (내 서버는 html이 없다)
  • HEAD /Core/Skin/Login.aspx HTTP/1.1
    로그인 페이지 탐색 (로그인 관련 취약점 찾기 위해)
  • GET /.env HTTP/1.1
    환경 설정 정적 파일 탐색 ex) 데이터베이스 비밀번호, API 키 등
    -GET /cdn-cgi/trace HTTP/1.1
    Cloudflare 를 사용하는 사이트에서 사용하는 경로로, CDN 설정 파악하기 위한 요청 시도

기타 등등 수많은 파일 요청 시도가 있었다. 전형적인 폴더 구조를 마구 떄려넣으면서 응답이 오기를 시도하는것 같다.

공격자의 아이피를 검색해본 결과 미국, 캐나다, 프랑스, 인도, 싱가포르 등 매우 다양했다.

공격자의 목적

공격의 목적은 민감 정보를 알아내어 본인의 서버로 사용하거나, 데이터베이스를 털어서 초기화 시킨 후 금전을 요구하거나 등등의 목적이 있다고 한다.

내 서버는 HTTP API 제외 모든 요청을 받지 않기 때문에 아무런 정보가 털리지 않았다.
또한 요청 양이 서버 CPU 점유율값이 유의미하게 바뀔정도로 많지는 않았다.

그래도 해당 공격에 대해 대응하는 방법을 알아보고 적용해보자.

대응

AWS WAF [공식 가이드]

AWS WAF는 보호된 웹 애플리케이션 리소스로 포워딩되는 HTTP 및 HTTPS 요청을 모니터링할 수 있는 웹 애플리케이션 방화벽이다.

매달 수십달러만 지출하면 대부분의 공격은 AWS WAF 설정만으로 방어가 가능하다.

IP를 국가 기반으로 차단하거나, 요청을 속도 기반으로 차단하거나, 특정 요청을 차단하는 등 커스텀 규칙을 설정할 수 있다.

ACL 설정으로 여러 가용영역에 각각 설정해줘야 한다. (CloudFront, LoadBalancer, API Gateway 등)

AWS Shield

AWS Shield Standard 는 무료이고 기본으로 활성화 되어있다.
애플리케이션 계층이 아닌 낮은 레벨의 네트워크 공격을 방어하고, 표준화된 디도스 공격을 완화한다.
AWS Shiled Advanced 를 활성화 하면 내 서비스에 맞춤화되어 더 다양한 네트워크 공격을 방어하고 모니터링 할 수 있다. 꽤 비싸서 사용하지는 않았다.

User-Agent 필터링

NginX 에서 정상적인 요청의 User-Agent 만 필터링 할 수 있다.
하지만 비정상적인 요청들은 User-Agent 를 변조하므로 큰 의미는 없다.

Fail2Ban

정규표현식으로 비정상적인 요청을 잡고 해당 ip를 서버에 접근이 불가능하도록 밴할 수 있다.

전형적인 몇가지 요청을 필터에 추가해서 밴했다. 이것으로 비정상적인 요청의 수를 꽤 줄일 수 있었다.

하지만 필터의 정규표현식을 너무 넓은 범위로 설정하면 정상적인 요청도 필터링 될 수도 있고, 공격 자체를 막는것은 아니므로 근본적인 방어책은 아니다.

웹서버 단에서 요청 필터링

NginX 에서 nginx.conf 같은 프록시 설정 파일에 다음과 같은 내용을 추가했다. (예시)

location ^~ /api/ {
    proxy_pass         http://localhost:8080;
    proxy_set_header   Host                $host;
    proxy_set_header   X-Real-IP           $remote_addr;
    proxy_set_header   X-Forwarded-For     $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Proto   $scheme;
}

location / {
    return 444;
}

위 코드는 /api/ 경로를 제외한 모든 요청을 즉시 차단해서 NginX가 1차 보안 필터 역할을 수행하게 했다.
본인의 서버 엔드포인트 구현에 알맞게 설정하면 된다. 물론 문제가 발생할 수 있으니 주의해서 구현해야 한다.

NginX 기본 경로 삭제

내 도메인은 REST API 만 제공하는 것이므로 NginX 에서 기본 파일 경로를 아예 삭제해서 디렉토리 탐색 공격 발생 가능성을 낮췄다.

기타

  • 로그 모니터링 (Elastic Stack, Grafana)
  • API Rate Limiting

결론

모든 IP에 공격하는 요청이 정말 많으므로 EC2 서버를 팠으면 WAF와 같은 기본저인 설정들은 꼭 해주자.
추가 참고 자료: 한국인터넷진흥원 - 주요정보통신기반시설 기술적 취약점 분석 평가 상세 가이드

0개의 댓글