OWASP Top10 2017

웹 어플리케이션 2017.07.17 11:29 Posted by TEAMCR@K

OWASP TOP 10 - 2017 RC1 버전이 4월 10일 자로 공개되었습니다.


아직까지는 최종 버전이 아닌 RC(Release Candidate) 버전으로 2017년 8월 25일까지 의견 수렴 후 새로운 OWASP Top 10 2017는 2017년 11월 말에 공개될 예정입니다.


해당 내용은 아래의 URL에서 확인하실 수 있습니다.

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project



2013년 버전과 비교하여 내용적인 변화는 크게 없으며 일부 취약점이 통합되고 신규 취약점이 추가되었습니다.

변화된 내용은 아래와 같습니다.



통합된 항목:

A4 - Broken Access Control


추가된 항목:

A7 - Insufficient Attack Protection

A10 - Underprotected APIs



A4 - Broken Access Control (취약한 접근 통제)

2013-A4, 2013-A7의 내용이 2017-A4으로 합쳐지는 것으로 확인할 수 있습니다.

내용을 확인해보면 2013-A4 Insecure Direct Object References(취약한 직접 객체 참조)와 2013-A7 Missing Function Level Access Control(단계적 접근 제한 기능 누락) 이 두 부분이 통합되었습니다.

Broken Access Control은 OWASP TOP 10 - 2003/2004 버전에 있던 취약점 항목입니다.


인증되지 않은 사용자가 데이터에 접근하거나 기능들을 수행할 수 있는 취약점입니다.

신뢰할 수 없는 출처에서 직접 참조를 사용할 때마다 사용자가 요청된 자원에 대한 권한을 부여받았는지 확인하기 위해 액세스 제어 검사가 포함되어야 합니다.


A7 - Insufficient Attack Protection (불충분한 공격 방어)

대부분의 어플리케이션 및 API는 수동/자동화된 공격에 대하여 탐지, 예방, 대응할 수 있는 기본 기능이 부족합니다.

어플리케이션 소유자는 공격으로부터 보호할 수 있도록 신속하게 패치를 배포할 수 있어야 합니다.


A10 - Underprotected APIs (보호되지 않은 API)

최근 어플리케이션은 일종의 API(SOAP/XML, REST/JSON, RPC, GWT, 등)에 연결되는 브라우저 및 모바일 어플리케이션의 JavaScript와 같은 Rich Client Application과 API을 포함되는 경우가 많습니다. 이 API는 보호되지 않는 경우가 많으며, 다양한 취약점이 존재합니다.

클라이언트와 API 사이의 통신이 보호되고 있는지 확인해야 하며 API에 강력한 인증방식이 모든 인증 정보, 키 및 토큰이 보호되고 있는지 확인해야 합니다.

저작자 표시 비영리 변경 금지
신고

모의해킹을 하다 보면 제일 많이 겪게되는 것이 방지대책에 막히게 되는 것일텐데요.

이전에 말씀드렸다시피 모의해킹은 취약점 점검이랑 달라서 우회기법도 포함하는 개념입니다.

상황이 이렇다 보니 모의해킹 진행 중 Server-Side Script 레벨이나 WAF(Web Application Firewall) 정책에 막히는 경우가 허다합니다.

오늘은 저희가 활용하고 있는 우회기법 중, 자바스크립트 'with' 구문을 사용하는 XSS 방지 우회 기법에 대해서 잠시 말씀드릴까 합니다.


여러가지 XSS 공격 방지 케이스들 중 본 페이지에서 우회를 시도하는 케이스는 다음과 같습니다.


<?php

// vuln.php

...

        $msg = $_GET['msg'];

        $pattern = '/document.cookie/i';

        $output = preg_replace($pattern, '', $msg);

...

?>


위 케이스는 일반적으로 "document.cookie" 문자열을 삭제 해 버리는 코드로, 저희가 실제 우회했던 케이스는 WAF 정책이었으나, 설명을 하기 위해 PHP 코드로 구현해 보았습니다.

물론 많은 분들이 아시는 것 처럼 위 코드에는 다음과 같은 XSS 방지 우회 방안이 있을 수 있습니다.


vuln.php?msg=<script>alert(documendocument.cookiet.cookie);</script>

 := vuln.php?msg=<script>alert(document.cookie);</script>


필터링 후의 문자열 상태를 예상해 Payload를 구성하는 방법인데, 본 페이지에서 다룰 방법은 위와 같은 방법이 아니라 여기까지만 언급하도록 하겠습니다.


우회방안이나 공격방안을 구성할 때 제일 좋은 것은, 대상을 구성하고 있는 'Standard 한 규격'을 참조하고 이를 이용하는 경우입니다.

이를 위해 인터넷에서 자바스크립트 명세서(Specification; 줄여서 흔히 스펙문서라 부릅니다)을 검색해 보았습니다.

저희가 구할 수 있었던 자바스크립트 명세서는 96년 마지막으로 작성된 1.1 버전이었으며, 이를 참조하였습니다.

자바스크립트 명세서 1.1 버전 80페이지에 보면 6.4.8 The with Statement 라는 항목으로 with 구문을 설명하고 있습니다.

해당 항목의 일부를 발췌하면 다음 내용과 같습니다.


6.4.8 The with Statement


The with statement establishes the default object for a set of statements. 

Within the set of statements, any property references that do not specify an 

object are assumed to be for the default object.


... 생략 ...


Example

The following with statement specifies that the Math object is the default 

object. The statements following the with statement refer to the PI property 

and the cos and sin methods, without specifying an object. JavaScript assumes 

the Math object for these references.


var a, x, y

var r=10

with (Math) {

a = PI * r * r

x = r * cos(PI)

y = r * sin(PI/2)

}


위 내용을 참조해 보면 with 구문 사용 시 특정 object를 명시하도록 되어있고, 이후의 블록안에서는 명시된 object의 멤버를 참조할 때, member 이름만 가지고도 접근 가능하도록 되어 있습니다.


with 구문에 대해 테스트 해 볼 요량으로 다음의 코드를 작성하였습니다.

<?php

Header("Set-Cookie: A3Security=TeamCR@K;");

$msg = $_GET['msg'];

$pattern = '/document.cookie/i';

$output = preg_replace($pattern, '', $msg);

echo "<html><body><head><title>XSS Test</title></head>";

echo "Code: " . htmlspecialchars($output) . "<BR>";

echo "Execution: $output<BR>";

echo "</body></html>";

?>


위 코드를 작성하고 실행하는 순간 다음과 같은 에러가 발생하였습니다.


[그림 1] XSS 방지 (IE)


웹 브라우져 차원에서 특정 URL을 요청하는 사용자 입력 값을 검사하여 XSS 공격 패턴을 차단하고 있는 기능입니다.

PHP 실행 레벨에서 document.cookie 문자열은 삭제되었지만 웹 브라우져 레벨에서 스크립트가 차단당하여 alert 창이 실행되지 않는 모습입니다.

해당 기능은 다음의 설정을 통해 비활성화 할 수 있습니다.


[그림 2] XSS 방지 기능 비활성화 방법 (IE)


'XSS 필터 사용' 항목을 '사용 안 함'으로 설정하면 XSS 방지 기능을 비활성화 시킬 수 있으나, XSS 취약점이 사용자 입력 값에만 의존하고 있지 않기 때문에 그냥 소스코드를 수정하는 방향으로 테스트 해 보았습니다.


다음은 XSS 공격 방지를 우회하기 위해 테스트 한 자바스크립트 코드입니다.


<script>with(document) { alert(cookie); }</script>


아래 화면은 IE에서 테스트 한 화면입니다.


[그림 3] with 구문을 사용한 XSS 공격 방지 우회 (IE)


Chrome에서 테스트 한 화면입니다.

[그림 4] with 구문을 사용한 XSS 공격 방지 우회 (Chrome)


우회방안을 고민할 때마다 느끼는 것이지만, 시간이 지날수록 우회방안은 날로 발전하니 이에 대해 지속적으로 관심을 가지는것이 필요할 것 같습니다.


저작자 표시 비영리 변경 금지
신고

국내 PHP 기반인 많은 사용자를 보유하고 있는 익스프레스엔진(XE)에서 LFI 취약점이 발표되었습니다.

해당 취약점은 일반 사용자 권한으로 서버에 명령어를 실행하여 웹쉘을 업로드 할 수 있어 아래주소에서 패치하시길 바랍니다.

http://www.xpressengine.com/blog/textyle/21937678

 

 

 

<그림1. KISA 보안 업데이트 권고>

 

 

패치 소스 관련해서 아래 경로에서 확인할 수 있습니다.

https://code.google.com/p/xe-core/source/detail?r=13127

 

<그림2. 변경된 소스코드 확인>

 

 

다음은 LFI 취약점이 발생하는 코드 일부 입니다.

create_function 에서 취약점이 발생합니다.

 

<그림3. LFI 취약점 발생 코드>

 

 

패치된 1.7.3.3 버전에서는 create_function 함수를 사용하지 않습니다.

<그림4. 취약점 패치된 코드>

 

패치된 소스를 분석하고 발생한 취약점을 이용하여 exploit code를 작성 하였습니다.

  

<그림5. exploit code 실행 화면>

 

웹쉘을 공격자 서버에서 업로드합니다.

 

<그림6. 웹쉘 업로드 확인>

 

업로드된 경로를 접속하게 되면 웹쉘페이지로 접속할 수 있습니다.

 

<그림7. 웹쉘 실행 확인>

 

 

exploit code와 상세 공격 내역은 문제가 될 요지가 있어 공개하지 않겠습니다.

XE를 사용하는 유저는 해당 취약점을 패치하길 권고합니다.

감사합니다.

 

ps. thanks to indra, maz3

 

 

저작자 표시 비영리 변경 금지
신고

OWASP Top 10 2013

웹 어플리케이션 2013.03.04 22:10 Posted by blarees

3년을 주기로 배포하는 OWASP top 10 이 새로이 배포되었습니다.

해당 내용은 아래의 URL 에서 확인 하 실 수 있습니다.

https://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013%20-%20RC1.pdf

https://www.owasp.org/index.php/Top_10_2013-Main
https://www.owasp.org/index.php/Top_10_2013-T10


변화된 내용은 아래와 같습니다.


A6 Sensitive Data Exposure
A7 Missing Fuction Level Access Control
A8 Using Known Vulnerable Components


A6 Sensitive Data Exposure
2010-A7, 2010-A9의 내용이 2013-A6으로 합쳐지는 것으로 확인 할 수 있습니다.
내용을 확인해보면 2010-A7 Insecure Cryptographic Storage(안전하지 않은 암호화 저장)  2010-A9 Insufficient Transport Layer Protection (불충분한 전송계층 보호) 이 두부분을 통합하였다고 생각할 수 있습니다.

사용자의 민감한 정보(개인정보)는 최초 입력 시, 암호화 전송을 하여야합니다. 데이터 처리 및 암호화 저장 또한 기본적으로 server-side에서 이루어 져야 합니다.

A7 Missing Fuction Level Access Control
2010-A8 Failure to Restrict URL Access(URL 접근제한의 실패)를 2013-A7 Missing Function Level Access Control(단계적 접근 제한 기능 누락)로 확장되었습니다.
단순히 URL 접근제어 뿐만이 아닌, 모든 단계적(level) 접근 제한 기능을 내포하기 위해서 확장시켰다는 것을 확인 할 수 있습니다.

사용자의 식별 및 등급에 따른 기능의 구분이 존재할 경우, 사용자 접근 제어 또한 반드시 server-side에서 이루어 져야 합니다.

A9 Using Known Vulnerable Components

2010-A6 Security Misconfiguration (잘못된 보안 설정) 에서 기본적으로 내포하고 있었습니다. 하지만 component 기반 개발의 성장으로, 알려진 취약한 components 사용의(using known vulnerable components) 위험이 커짐으로써 하나의 카테고리로 만들어진 것을 확인할 수 있습니다.

component는 사용되어진 libray, apache 서버, iis 서버 혹은 freeware html 편집기등을 포함한 제공하는 서비스를 구성하는 모든 요소를 지칭합니다.
구성하는 component 들에 대한 최신 취약점과 패치를 항상 확인해야합니다.


신고

 


PHP File Upload Bug May Let Remote Users Overwrite Files

SecurityTracker Alert ID: 1025659

CVE Reference: CVE-2011-2202 (Links to External Site)
Date: Jun 14 2011
Impact: Modification of system information
Fix Available: Yes Vendor Confirmed: Yes Exploit Included: Yes


[SecurityFocus]
http://downloads.securityfocus.com/vulnerabilities/exploits/48259.php


[개요]
원격 대상에서 시스템에 있는 특정 파일을 덮어 쓸 수 있는 취약점 입니다.
$_FILES['upload_field_name']['name'] 에서 사용자로부터 업로드 path 를 받아들일때
악의 적인 사용자는 '/' 를 이용하여 원하는 경로를 포함함으로서 시스템 내부에있는 특정 파일에
직접 접근하여 기존에 존재하던 파일을 덮어 쓸 수 있습니다.


[상세내역 및 취약성의 영향]
$_FILES['contents']['name']; 에서 path 를 임의로 지정해주었을 경우 공격자는 이를 악용할 수 있습니다.
이유는  $_FILES['incle']['name'] 을 그대로 사용해 업로드 되는 폴더로 검증없이 직접 이동시키기 때문이며
사용자에게 홈 디렉토리에 대해 직접 접근 하여 파일을 엑세스 할 수 있는 권한이 있기 때문입니다.

테스트 하기 위해 구버젼 APMSETUP 을 이용하였습니다.
버젼별로 환경이 다르지만 5.3.6 버젼 이하에서의 PHP 버젼은 이번 취약성에 모두 영향을 받으므로 진행하기로 하였습니다.

 

 





[대응방안]

생각해 볼 수 있는 대응방안은 다음과 같습니다.

1.php 최신 패치를 한다.
2.업로드된 폴더를 사용자에게 노출되지 않은 디렉토리로 이동한다
3.웹어플리케이션 서버 사용자 권한관리를 한다.
4.일반적이지 않은 사용자입력값이 들어오면 에러처리를 한다.


패치 URL : https://downloads.php.net/ilia/php-5.3.7RC4.tar.gz



[정리]

대부분의 File Path injection 취약점의 경우 아주 위험한 취약점이 될 수 있지만
금번 분석한 취약점은 환경설정, 권한, php 버젼에 따라 달라질 수 있는 취약점이라
모든 환경이 갖추어지더라도 될수도,  되지 않을 수도 있을것 같습니다.
(php version, permission, uploadfile_path)  실제로 환경을 만들기위해 많은 시행착오를 겪었습니다.

CVE-2011-2202 의 취약성을 분석하며 많은 문서를 보면서 이번 취약성은 각각
해외 보안업체에서 다른리스크(High , Low) 레벨에 들어간다는것도 확인하였습니다.
하지만 분명한것은 웹 어플리케이션 서버에 영향을 준다는것이며 최신패치를 유지 해야한다는것입니다.





저작자 표시
신고

.NET 어플리케이션 개발 보안 가이드에 대해 명확하고 상세한 블로그가 있어 소개드립니다.

취약점 설명, 실 적용 예제 등 자세하게 나와 있습니다.

http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-1.html
http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-2.html
http://www.troyhunt.com/2010/07/owasp-top-10-for-net-developers-part-3.html
http://www.troyhunt.com/2010/09/owasp-top-10-for-net-developers-part-4.html
http://www.troyhunt.com/2010/11/owasp-top-10-for-net-developers-part-5.html
http://www.troyhunt.com/2010/12/owasp-top-10-for-net-developers-part-6.html
http://www.troyhunt.com/2011/06/owasp-top-10-for-net-developers-part-7.html

저작자 표시 비영리 변경 금지
신고

SHODAN for Penetration Testers

웹 어플리케이션 2011.04.01 15:25 Posted by TEAMCR@K

모의해킹 환경분석을 할 시에 Google 검색과 같이 유용하게 사용될 수 있는 SHODAN 검색입니다.

이전에 http://teamcrak.tistory.com/311 관한 글을 작성 했는데, 해당 발표자료가 정리가 잘 되어 있어 첨부합니다.

http://www.scribd.com/doc/26526911/SHODAN-for-Penetration-Testers

저작자 표시 비영리 변경 금지
신고

OWASP TOP 10에 대해서 WebGot 등을 이용하여 테스트 환경에서 보여주고 있는 동영상들입니다.

 

URL을 통해 들어가면 더 많은 동영상을 볼 수 있습니다.

 

URL : http://www.youtube.com/view_play_list?p=04732F5EE5F80FD4

 

저작자 표시 비영리 변경 금지
신고

OWASP TOP 10 문서가 나올때마다 한글로 번역하여 무료로 발간하는 Security Plus가 이번에도 OWASP TOP 10 2010 한글판을 배포하였습니다. 2010년도 부터는 위험 평가기준에 따라 순위로 결정되었고, 취약점의 각 범위가 변동된 부분이 있습니다.
(참고 : http://teamcrak.tistory.com/175 - RC1기준)

다운로드 URL : http://www.securityplus.or.kr/xe/?document_srl=25853


아래는 syngerss에서 최신 발간된 웹 어플리케이션 취약점 공격에 대한 책입니다. OWASP TOP 10 2010 문서 기준으로 설명이 자세히 되어 있어 해당 분야를 학습하는데 크게 도움이 될거라 생각합니다.

http://www.syngress.com/hacking-and-penetration-testing/Seven-Deadliest-Web-Application-Attacks/




그외에 "Seven-Deadliest" 시리즈 책들이 많이 있는데 관심이 가네요.^^)

저작자 표시 비영리 변경 금지
신고

기업에서 신규로 서비스를 개발 시 어플리케이션 보안을 위해 소프트웨어 라이프사이클의 초기 단계에서부터 보안성 검토를 수행해야 하며, 구축(도입) 전 단계부터 조직 정보보호를 위한 요구 사항들이 반영되어야 한다.


만약 구축 및 설계 단계에서 정보보호에 대한 요구사항이 반영되지 않은 경우 취약점 분석을 통하여 취약점을 제기하고, 운영 및 프로세스를 재순환해야 하며, 이 경우 개발 초기에 적용하는 것과 비교하여 많은 비용이 소모된다.

모의해킹 점검하는 방식 중에는 블랙 박스, 그레이 박스, 화이트 박스 등이 있다. 블랙 박스 점검은 외부에서 보여지는 웹 사이트만(URL정보만을) 으로 판단하여 취약점을 분석하는 것이고, 화이트 박스 점검은 소스 파일만을 보고 취약점을 분석하는 것이다.이 중간 단계에 그레이 박스 점검이 있으며, 이것은 웹 사이트에서 발견된 취약점과 소스파일을 비교하며 더욱 상세하게 분석하는 것이라 생각하면 된다.

소스코드 분석할시(Gray Box, White Box ) Secure Coding 에 대한 전문 지식을 습득해야 하며, 환경에 따라수동분석, 자동분석에 대한 활용법을 익혀야 한다.

아래 도서 및 URL은 관련 업무에 참고할만한 것들이다.

[참고 도서들]

CERT C 프로그래밍

로버트 C. 시코드 | 현동석 옮김

에이콘출판 2010.02.16

WRITING SECURE CODE 2 안전한 코드 작성 기술

마이클 하워드 | 지정기 옮김

정보문화사 2003.09.09

Secure Programming with Static Analysis Secure Programming with Static Analysis

Brian Chess|Jacob West

Addison-WesleyProfessional 2007.06.14

   
     [MS 관련 추천 URL]

       (제프리 리처의 Windows VIA C/C++ 참고)

     [PHP 소스코드 진단 관련]

 

저작자 표시 비영리 변경 금지
신고


 

티스토리 툴바