HTTP/HTTPS 혼용에 따른 관리자로그인 페이지 접근 우회 (실제 사례)

HTTP는 기본적으로 문자열 기반의 통신규약이다. 정보가 평문으로 송수신되기 때문에 중간에서 가로채면 내용을 읽을 수 있다. HTTPS는 이러한 문제를 보완하기 위해 문자열을 암호화하여 송수신한다. NCSA 모자이크(Mosaic) 브라우저가 1993년에 개발되고 8개월 후인 1994년에 SSL 1.0이 발표되었다. 그리고 모자이크 개발자들이 설립한 넷스케이프사가 Netscape Communicator 1.0에 SSL 2.0을 적용하였다. 이것이 SSL 1.0이 발표된 지 5개월 후의 일이었다고 한다. 따라서 HTTP와 HTTPS는 거의 같은 깊이의 역사를 가지고 있는 셈이다.

그런데 왜 아직도 HTTP를 사용하는 누리집이 많은 것일까?

많은 사람들이 가장 우려하는 부분은 속도 문제이다. 암호화 키를 교환해야 하므로 HTTP에 비해 약간 느리다.
암호화 통신의 내용은 HTTP 프록시와 같이 캐싱(chaching)을 통해 통신을 빠르게 할 수 있는 방법을 원천적으로 차단하므로 또한 통신속도 감소에 영향을 미친다.
SSL(TLS) 인증서가 유료이다. 저가형 웹호스팅이 매우 많은 상황에서 유료 인증서는 부담이 될 수 있다.

장비의 성능이 고성능화되고 네트워크 대역폭이 크게 개선되면서 HTTPS의 부담은 점차 지엽적인 문제가 되고 있다. 또한 무료 TLS 인증서를 배포하는 움직임도 점차 발을 넓혀가고 있다. 웹검색엔진에서 "무료 인증서"로 검색하면 발급 홈페이지를 찾을 수 있을 것이다.

성능에 대한 우려 때문인지 많은 기업/기관에서 HTTP와 HTTPS를 혼용하는 경우를 발견할 수 있다. HTTPS는 주로 로그인이나 개인정보 관련 자료를 처리하는 일부분에만 사용한다. 다음은 이러한 HTTP/HTTPS 혼용 누리집에서 발견한 관리자 페이지 노출 취약점이다.

웹로봇접근제어파일 robots.txt에서의 중요정보 노출

홈페이지 취약점 점검 과정은 1차적으로는 구글과 같은 웹 검색 엔진을 이용하여 사전정보를 모은다. 2차적으로는 웹 서비스 설정과 관련된 페이지들을 조사하게 되는 데 /robots.txt 파일도 이 중의 하나이다.

robots.txt admin page disclosure
[ ↑ robots.txt 파일에 의한 홈페이지 관리자 페이지 경로 노출 ]

이 홈페이지의 robots.txt 파일에는 /member/와 /SiteMgt/에 대해서 웹로봇이 접근하지 말라는 disallow 정책을 명시하고 있다. 그 내용은 다음과 같다.

User-agent: *
Disallow: /member/
Disallow: /SiteMgt/

아마도 /member/ 경로에서는 회원 로그인과 관련된 기능들을 제공할 것이다. /SiteMgt/ 경로는 "Site Management"의 약자로 추정되므로 홈페이지 관리 기능을 제공할 것으로 보인다. 악의적인 공격자의 입장이라면 "이게 웬 떡" 하나를 주워 든 셈이다.

HTTP에서의 관리자 로그인 페이지 접근제어 - 웹방화벽

이 누리집이 일반적으로는 HTTP를 사용하므로 robots.txt에서 파악한 /SiteMgt/ 경로에 웹 브라우저로 접근한다(http://www.k-target.kr/SiteMgt/). 외부 IP주소에서 접속한 결과는 다음과 같다.

HTTP admin page block by WAF
[ ↑ 웹방화벽(WAF)에 의한 HTTP 관리자 로그인 페이지 접근 차단 ]

정상적인 서버의 응답과 위와 같이 Block된 경우의 HTTP 헤더를 비교해보았다.

HTTP/1.1 200 OK
Server: Resin/3.1.10
Content-Type: text/html; charset=EUC-KR
Connection: close
Date: Wed, 14 Dec 2016 10:44:22 GMT

HTTP/1.1 200 OK
Connection: close
Content-Length: 2363
Content-Type: text/html
Date: Wed, 14 Dec 2016 10:40:58 GMT
Pragma: no-cache

[정상적인 접근의 HTTP 헤더]

[Block된 경우의 HTTP 헤더]

Block된 HTTP 응답에서는 정상적인 HTTP 응답에 비해서 Server: 헤더가 사라지고 Content-type: 헤더가 조금 다르게 표현되는 것을 관찰할 수 있다. Nikto와 같은 웹 취약점 스캐너들은 이러한 HTTP 헤더의 변화를 감지하여 WAF/IDS/IPS 등의 존재여부를 일부 파악하는 것으로 보인다. 접근시 "웹 보안 정책 위반"에 의한 접속차단이라고 알려주는 것으로 보아 HTTP로 /SiteMgt/index.jsp 경로 접근을 차단하는 장비는 웹방화벽(WAF, Web Application Firewall)이라고 거의 확신할 수 있다.

HTTPS에서의 관리자 페이지 접근제어 실패

Nmap 스캔 결과나 회원 로그인 등에서 - 일부나마 - 이미 SSL이 적용된 사이트인 것을 알고 있으므로 HTTPS로 /SiteMgt/ 경로 접근을 시도해본다.

HTTPS admin page access allowed, WAF bypass
[ ↑ HTTPS로 접근시 관리자 로그인 페이지 접근 허용 ]

외부 IP 주소에서도 "관리자 로그인" 페이지에 접근할 수 있다. 이런 현상은 HTTP에 대해서만 WAF가 적용되고 HTTPS에서는 WAF가 적용되어 있지 않다는 것을 의미한다. 웹방화벽(WAF)으로 적용하는 모든 웹 보안 정책이 HTTPS에서는 무용지물이 된다. HTTP/HTTPS를 혼용하면서 HTTP와 HTTPS에서 각기 다른 보안정책을 적용했기 때문에 이러한 결과가 초래된다.

IBM AppScan과 같은 상용 웹취약점 스캐너의 결과를 보면 "HTTPS 강제화 미적용"이라는 항목이 발견된다. 바로 이러한 경우에 탐지되는 취약점이다. HTTP와 HTTPS의 서버 응답이 동일하다면 하나를 포기하는 것이 좋다. 그것이 HTTP인 것이 더 바람직하다. 강제로 HTTP를 HTTPS로 경로재지정을 하고 HTTPS에 대해서만 보안정책을 적용하면 관리지점을 일원화시킬 수 있다.

홈페이지 관리기능의 경로가 노출된 것도 중요한 취약점이지만 이보다는 근본적인 문제점이 있다. HTTP에서 접근할 수 있는 모든 기능을 HTTPS로도 접근할 수 있다는 것을 공격자가 알게 되었다는 점이다. 이제 공격자는 모든 추가공격을 HTTPS 상에서 수행할 것이다. 웹방화벽의 모든 보안정책을 우회할 수 있게 되었다.

덧붙임: 동향 - HTTP, HTTPS, HTTP/2

거대 인터넷 기업들인 구글, 유튜브, 페이스북, 트위터 등 HTTP/2를 기반으로 서비스를 제공하고 있다. 2016년 12월 현재 전세계 HTTP/2 통신량은 전체 통신량의 11%에 달한다(참고자료: Usage Statistics of HTTP/2 for Websites, December 2016 - W3Techs).

HTTP/2 표준에는 HTTP와 HTTPS를 모두 포용하고 있다. 그런데 업계에서는 HTTPS만을 지원한다. Firefox, Chrome, Safari, Opera, MSIE 11, MS Edge 모두 브라우저 단에서 HTTP/2 over TLS만을 지원한다. 따라서 HTTP/2에서는 "HTTPS가 사실상의 표준"이 되는 셈이다. HTTP/1은 평문 규약(plain text protocol)이어서 사람이 읽을 수 있었다. 반면, 통신 데이터 압축과 암호화에 의해 HTTP/2는 바이너리 규약(binary protocol)으로 변신하게 되면서 보다 보안수준이 높아질 것으로 보인다.

암호화 통신의 비율이 높아질수록 급격하게 보안관제 시장은 축소될 것이다. 보안관제 전문회사들은 이제 새로운 먹거리를 찾아야 할 시기이다.

HTTP/2는 HTTP/1.x에 비해서 80~130% 정도 속도가 더 빨라졌다고 한다. 이 때문인지 HTTP/2가 2015년에 표준이 되었음에도 불구하고 그 적용속도는 매우 빠르다. 주요 인터넷 서비스는 수 년내로 HTTP/2로 이전할 것으로 보인다. 그 과정에서 HTTP/HTTPS 혼용 문제는 한시적이나마 잔존할 수 밖에 없는 취약점이 될 것이다.

[처음 작성한 날: 2016.12.14] [마지막으로 고친 날: 2016.12.14]

> 이 글을 목록없이 인쇄하기 편하게 보기

< 이전 글 : 이중 서버스크립트 혼용을 이용한 웹방화벽/확장자검증 우회 (실제 사례) (2016.12.19)

> 다음 글 : 경로재지정 취약점: 자바스크립트를 이용한 검증과 그 우회, 그리고 XSS (실제 사례) (2016.12.14)

이 저작물은 크리에이티브 커먼즈 저작자표시 4.0 국제 라이선스에 따라 이용할 수 있습니다.
잘못된 내용, 오탈자 및 기타 문의사항은 j1n5uk{at}daum.net으로 연락주시기 바랍니다.
문서의 시작으로 컴퓨터 깨알지식 웹핵 누리집 대문

.. -- -- | - .. .... | ... / .. .../ ... {] . .. .. .. ..| ...... .../ .../ .. ...... ... ... ] .. [ .../ ..../ ......./ .. ./// ../ ... .. ... .. -- -- | - .. .... | ... / .. .../ ... {] . .. .. .. ..| ...... .../ .../ .. ./// ../ ... .. ... ...| ..../ ./ ... / ..| ....| ........ / ... / .... ...... ... ... ] .. [ .../ ..../ ......./ .....| ..../ ./ ... / ..| ....| ........ / ... / .... ...| ..../ ./ ... / ..| ....| ........ / ... / .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .