유리상자 속 이야기

17258.pdf

HTML5 는 기존의 특징과 API 들을 확장하고 새로 추가하여, 웹 어플리케이션의 새로운 미래를 정의하고 있습니다. HTML5 의 보안에 대해서는 아직 알려지지 않았는데, 이는 HTML5 이 아직은 웹 어플리케이션에 사용되지 않고 있으며(일부분에 대해서 실험적으로 사용하고 있을 뿐), 아직까지는 최종 사용자가 걱정할 거리가 없는 것으로 간주되기 있기 때문입니다.

이 문서는 '지금 당장' 웹 사이트 사용자에게 수행할 수 있는 공격의 범위를 토론하여, 이러한 추측들이 틀렸다는 것을 증명할 것입니다. 브라우져 벤더들은 서로 앞을 다투어 HTML5 스펙에 정의된 최근 기능들을 지원하려고 하고 있습니다. 이런 브라우저를 사용하는 사용자는 이 문서에서 다룰 공격들에 노출되어 있습니다.

이 문서의 첫 섹션은 저와 다른 리서쳐에서 올해 초에 조사한 통계와 공격을 포함하고 있습니다. 마지막 섹션은 전혀 새롭고 다른 공격을 다루고 있습니다.

문서에서 다루고 있는 공격 항목:

1) HTML5 를 이용한 Cross-site Scripting
2) COR 을 이용한 Reverse Web Shells
3) HTML5 를 이용한 Clickjacking
    a. Test-field Injection
    b. IFRAME Sandboxing
4) HTML5 Cache Poisoning
5) Client-side RFI
6) Cross-site Posting
7) Network 정찰
    a. 포트 스캐닝
    b. 네트워크 스캐닝
    c. 사용자 개인 IP 추측하기
8) HTML5 Botnets
    a. Botnet 생성
        i. Reaching out to victims
        ii. Extending execution life-time
    b. Botnets based attacks
        i. DDoS attacks
        ii. Email spam
        iii. Distributed Password Cracking




HTML5 은 새로운 이벤트 속성이 추가된 새로운 태그와 기존의 태그에 새로 추가된 이벤트 속성을 소개하고 있습니다.  이런 이벤트 속성들은 기존에 JavaScript 를 이용하여 수행했던 Cross-site Scripting 공격을 막기 위해서 디자인된 필터 기반의 블랙 리스트를 우회할 수 있습니다.

악의적인 태그를 확인하는 필터인 경우에는 HTML5 에서 새로 추가된 Audio, Video 태그를 사용하면 우회할 수 있습니다.

예:

'<' 와 '>' 자체를 막는 필터의 경우에는 대부분의 태그 인젝션을 막을 수 있습니다. XSS 의 경우, 만약 공격자가 스크립트 안에를 기존의 이벤트 속성이나 새로운 이벤트 속성을 추가할 수 있다면 여전히 공격이 가능합니다. HTML5 에서 새로 추가된 'onforminput' 과 'onformchage' 이벤트 속성을 사용하면, 이벤트 속성 목록을 차단하는 필터를 우회할 수 있습니다.

예:

필터를 우회하는 방법 이외에 HTML5 의 'autofocus' 처럼 스크립트가 자동으로 수행하는 속성을 이용하는 방법도 있습니다. 이 속성은 요소에 자동적으로 포커스가 갈 때, 세트됩니다.

일반적으로 데이터 인젝션이 가능한 경우는 Input 태그의 속성 섹션 내부 입니다. 전통적인 방법에서는 삽입될 JavaScript 가 태그의 'onmouseover' 나 'onclick' 에 들어가기 때문에, 스크립트가 수행되기 위해서 사용자의 인터렉션이 요구되었습니다. 하지만 HTML5 에서는 'onfocus' 에 스크립트를 삽입하고, autofocus 속성을 세팅하는 방법을 이용하여, 자동으로 스크립트가 수행 되도록 할 수 있습니다.

예:

Mario Heiderich 는 이러한 HTML5 의 새로운 매개체 리스트를 HTML5 Security CheatSheet 에 정리해 두었습니다.

HTML5 의 Cross Origin Request 는 a.com 에서 b.com 으로 Ajax 호출할 수 있고, b.com 에서 허용하는 길이만큼 응답을 수신할 수 있도록 해 줍니다. 이 특징은 Ajax 호출을 도메인 영역을 뛰어넘어 HTTP 트레픽을 뚫고, 브라우저를 리버스 쉘(Reverse Shell)로 만드는데 사용될 수 있습니다.

이를 이용하면 공격자는 희생자가 안티섹션 Http-Only 쿠키와 '세션 ID - IP 주소' 연결방식을 사용하더라도 XSS 를 이용해서 세션 하이제킹을 할 수 있습니다.

Cross-site Scripting 을 이용하든, 사용자에게 브라우저 주소창에 스크립트를 붙여넣게 만들든, 어떤 방법으로든 사용자의 브라우저에 JavaScript 를 삽입하고 나면, Cross Origin Requests 를 이용해서 공격자의 서버에게 데이터를 전송하기 시작할 것입니다. 이런 연결을 통해서 공격자는 자신의 페이지 요청을 마치 희생자의 브라우저가 요청하는 것 처럼 속일 수 있고, 따라서 피해자의 유효한 섹션을 사용하여 웹 서비핑을 할 수 있게 됩니다.

올해 초에 저는 이 아이디어를 실제로 구현한 'Shell of the Future' 라는 이름의 오픈소스 툴을 개발하였습니다. 이것은 공격 전체가 자동으로 이루어 질 만큼 매우 사용하기 쉬우며, 두 개의 기본 JavaScript 코드로 구성되어 있습니다.

Shell of the Future_v0.9.zip

ClickJacking 은 CSRF 보호기법을 우회함으로써 크로스 도메인으로 폼을 전송하는데 이용 될 수 있습니다. ClickJacking 을 이용하여 링크를 클릭하거나 버튼을 클릭하는 것은 매우 쉽지만, 타겟폼의 Input 필드에 값을 채워 넣는것은 상대적으로 어렵습니다.
HTML5 의 드래그 & 드랍(Drag & Drop) API 를 이용하면, 희생자에게 드래그 & 드랍을 유도함으로써 손쉽게 타겟 폼을 채워넣도록 유도할 수 있습니다. 공격자는 사이트에 마치 게임인 것처럼 코드를 만들어 넣습니다. 그리고 사용자에게 아이템을 드래그 & 드랍을 하도록 유도하는 것이죠. 실제 드그래 & 드랍이 수행될 때, 보이지 않는 뒷편에서는 데이터가 input 필드에 채워지도록 만드는 것입니다.

예:

 이 기법은 Paul Sone 이 BlackHat Europe 2010 에서 소개한 것입니다.



Clickjacking 공격을 막는 가장 좋은 방법은 사이트 내 모든 페이지에 Framebusting 코드를 모두 집어 넣는 것이라고 많은 사람들이 오해하고 있습니다. OWASP 가이드라인에서 이 방법의 단점에 대해서 명확하게 언급했음에도 불구하고, 이 방법은 가장 널리 쓰이는 해결책으로 인식되었습니다.
만약 웹 사이트들이 ClickJacking 공격을 방어하기 위해서 FrameBusting 만 사용한다면, 이 보호기법은 몇몇 다른 방법을 이용해서 우회할 수 있습니다. 그 방법 중 하나는 HTML5 에서 추가된 IFRAME 의 'sandbox' 속성을 이용하는 것입니다.

예:

iframe 에서는 이 JavaScript 속성을 사용할 수 없도록 설정하세요. 'framebusting' 은 JavaScript 에 의존적이기 때문에, 이 속성은 효과적으로 방어를 무력화시킵니다. eBay, WordPress, PayPal 과 같이 유명한 사이트들은 'framebusting' 을 보호기법만 사용하고 있기 때문에, 이 공격에 열려있습니다.




HTML5 에서는 Application Cache 또는 Programmable Cache 라는 이름으로 새로운 캐시 시스템을 소개하고 있습니다. 전통적으로 캐시라고 하면 페이지의 로드 시간을 향상시키기 위해서 사용되었으나, Application Cache 는 오프라인에서 웹을 브라우저 할 수 있도록 만들기 위해서 디자인 되었습니다. 그렇기 때문에 이 캐시는 전통적인 캐시보다 훨씬 오랫동안 지속됩니다.

이러한 HTML5 의 캐시 중독을 사용하면, 공격자는 그의 캐시된 페이지를 더 오랜 기간 살아있도록 만들 수 있을 뿐 아니라, 사용자의 신임장(역주: 세션 ID 같은 것)을 훔치는데도 사용할 수 있습니다.

올해 초 HTML5 Cache Poison 에 사용할 수 있는 Imposter 의 새 버젼을 발표하였습니다.
imposter_v0.9.zip



location hash 에서 언급된 URL 로 Ajax 리퀘스트를 보내고, 그 응답을 HTML 페이지에 포함시키는 웹 사이트는 COR 을 이용하여 공격할 수 있습니다. Location hash 에 있는 공격자가 컨트롤한 페이지의 URL 을 포함하는 링크를 사용자가 클릭함으로써, Cross-site Scripting 공격과 같은 client-side RFI 결과를 수행하도록 할 수 있습니다. 이 공격은 올해 7월 Matt Austin 에 의해서 소개되었습니다. Mobile.facebook.com 과 다른 수 많은 웹사이트들은 JQuery library 를 사용하고 있고, 이 공격에 취약한 것으로 확인 되었습니다.




이것은 일찍이 거론되어 왔던 Cleint-side RFI 공격의 변종입니다. Ajax 의 요청 주소가 만약 공격자에 의해서 수정될 수 있다면, location hash 경우처럼 공격자는 그의 사이트로 요청을 리다이렉트 할 수 있고, 세션 정보를 훔칠 수 있습니다. 비록 Ajax 요청에 대한 응답이 요청한 사이트에 의해서 바로 처리되지 않더라도 이 공격은 잘 유효할 것입니다.




Cross 영역에서 XMLHttpRequests 와 WebSockets 를 포트 스캔을 하는데 사용할 수 있습니다. Firefox, Chrome 그리고 Safari 의 최신버젼은 이 기능을 제공하며, 인트라넷 정찰에도 사용할 수 있습니다.

Cross 영역 XHR 은 5 종류의 readystate 상태를 제공하고, WebSocket 은 4 가지의 readystate 상태를 제공합니다. 어떤 서비스로 새로 연결이 되면, 연결 상태에 따라서 readystate 프로퍼티의 상태가 변경됩니다. 이들 상태가 변화는 것을 통해서 연결한 원격 포트가 열렸는지, 닫혔는지, 필터링하고 있는지를 알 수 있습니다.


WebSocket 또는 COR 의 연결이 네트워크를 통해서 특정 IP 의 특정 포트로 연결이 되면, WebSocket 의 상태는 readystate 0 가 되고, COR 은 readystate 1 이 됩니다. 원격 포트의 상태에 따라 readystate 의 상태가 빨리 변할 수도 느리게 변할 수도 있습니다. 아래 표에는 원격 포트의 상태에 따른 readystate 값과, 걸리는 시간이 나와 있습니다. readystate 가 변화하는 시간을 통해서 원격 포트의 상태를 추측할 수 있습니다.

포트 상태에 따른 행동:

Port Status	WebSocket (ReadyState 0)	COR (ReadyState 1)
Open (application type 1&2)	< 100 ms	< 100 ms
Closed	~1000 ms	~ 1000 ms
Filtered	> 30000 ms	> 30000 ms

이 방식을 이용해서 포트 스캔을 할 때 조금의 제약조건이 있습니다. 큰 제약은 모든 브라우저는 well known port 로의 커넥션을 차단하기 때문에, 이런 포트는 스캐닝을 할 수 없습니다. 다른 제약은 이 방식은 어플리케이션 레벨의 스캐닝이기 때문에 nmap 툴과 같은 소켓레벨 스캐닝보다 성능이 떨어집니다. 다시말해 어플리케이션에서 특정 포트의 응답을 가다리는 방식이며, 해석이 달라질 수 있습니다.

어플리케이션에서 발생할 수 있는 응답 4가지:

1. 연결 종료 : 프로토콜이 맞지 않아서 어플리케이션이 연결을 하자마자 바로 끊어버림
2. 응답과 연결 종료 : 1번과 비슷하지만, 연결이 종료되기 전에 기본 응답과 같은 것을 보내옴.
3. 연결은 되었으나 응답 없음 : 어플리케이션에서 프로토콜에 의해 데이터를 기다리거나 더 많은 데이터가 오기를 기다리면서 연결을 계속 열고 있음.
4. 응답과 연결 :  3번과 비슷하지만, 연결을 통해서 베너나 환영 메세지 같은 응답을 보내옴.

이런 경우에 따른 WebSocket 과 COR 의 동작은 아래 테이블과 같습니다.

어플리케이션 타입에 따른 행동:

Application Type	WebSocket(ReadySate 0)/COR(ReadyState1)
Close on Connect	< 100 ms
Respond & close on connect	< 100 ms
Open with no response	> 30000 ms
Open with response	< 100 ms (FF & Safari) | > 30000 ms (Chrome)

포트스캐닝 기술은 내부 네트워크에서 수평적 네트워크 스캔을 하는데 사용할 수 있습니다. 열려있는 포트나 닫혀있는 포트 모두 정확하게 구분되기 때문에, 수평적 스캔은 3389 와 같이 개인 방화벽이 필터링 하지 않는 포트에 대해서 스캔할 수 있습니다.

열려 있거나 닫혀있는 포트의 특징은 특정 IP 주소가 연결 되었다는 것을 알려줄 것입니다.



많은 사용자들은 집에서 192.168.x.x 영역의 IP 주소를 주는 WiFi 라우터에 연결을 하고 있을 것입니다. 그리고 라우터의 IP 주소는 대게 192.168.x.1 이고, 80 번 또는 443 포트를 통해서 관리용 웹 인터페이스 환경의 가지고 있을 것입니다.

이 두가지 사실은 아래 방법을 통해서 사용자의 개인 IP 주소를 예측하는데 이용될 수 있습니다.

Step 1: Identify the user's subnet
IP 주소 192.168.0.1 에서부터 192.168.255.1 까지 80 또는 443 포트로 스캔을 하면 알 수 있습니다. 만약 사용자가 192.168.3.x 서브넷에 있다면, 라우터인 192.168.3.1 에서 응답을 받을 수 있고, 서브넷을 알 수 있습니다.

Step 2: Identify the IP Address
서브넷을 구하면 우리는 포트를 통해서 서브넷 전체를 스캐닝 합니다. 30000 포트처럼 개인 방화벽에 의해서 막혀있을 수도 있습니다. 그렇기 때문에 192.169.x.2 에서부터 192.168.x.254 까지 탐색해 보면, 응답을 하는(열려있거나 닫혀있거나) IP 를 알 수 있고 이것이 사용자 IP 주소입니다. 개인 방화벽은 이 request 가 자신의 시스템 내부에 있는 사용자 브라우저에서 보내는 것이기 때문에 차단하지 않을 것입니다.