Zal.:.

Zal Walt

In this post, we present our new Burp Suite extension "TLS-Attacker".
Using this extension penetration testers and security researchers can assess the security of TLS server configurations directly from within Burp Suite.
The extension is based on the TLS-Attacker framework and the TLS-Scanner, both of which are developed by the Chair for Network and Data Security.

You can find the latest release of our extension at: https://github.com/RUB-NDS/TLS-Attacker-BurpExtension/releases

TLS-Scanner

Thanks to the seamless integration of the TLS-Scanner into the BurpSuite, the penetration tester only needs to configure a single parameter: the host to be scanned. After clicking the Scan button, the extension runs the default checks and responds with a report that allows penetration testers to quickly determine potential issues in the server's TLS configuration. Basic tests check the supported cipher suites and protocol versions. In addition, several known attacks on TLS are automatically evaluated, including Bleichenbacher's attack, Padding Oracles, and Invalid Curve attacks.

Furthermore, the extension allows fine-tuning for the configuration of the underlying TLS-Scanner. The two parameters parallelProbes and overallThreads can be used to improve the scan performance (at the cost of increased network load and resource usage).

It is also possible to configure the granularity of the scan using Scan Detail and Danger Level. The level of detail contained in the returned scan report can also be controlled using the Report Detail setting.

Please refer to the GitHub repositories linked above for further details on configuration and usage of TLS-Scanner.

Scan History

If several hosts are scanned, the Scan History tab keeps track of the preformed scans and is a useful tool when comparing the results of subsequent scans.

Additional functions will follow in later versions

Currently, we are working on integrating an at-a-glance rating mechanism to allow for easily estimating the security of a scanned host's TLS configuration.

This is a combined work of Nurullah Erinola, Nils Engelbertz, David Herring, Juraj Somorovsky, Vladislav Mladenov, and Robert Merget. The research was supported by the European Commission through the FutureTrust project (grant 700542-Future-Trust-H2020-DS-2015-1).

If you would like to learn more about TLS, Juraj and Robert will give a TLS Training at Ruhrsec on the 27th of May 2019. There are still a few seats left.

More articles

Zal Walt

An HTTP Request Smuggling / Desync testing tool written in Python 3

IMPORTANT

This tool does not guarantee no false-positives or false-negatives. Just because a mutation may report OK does not mean there isn't a desync issue, but more importantly just because the tool indicates a potential desync issue does not mean there definitely exists one. The script may encounter request processors from large entities (i.e. Google/AWS/Yahoo/Akamai/etc..) that may show false positive results.

Installation

git clone https://github.com/defparam/smuggler.git
cd smuggler
python3 smuggler.py -h

Example Usage

Single Host:

python3 smuggler.py -u <URL>

List of hosts:

cat list_of_hosts.txt | python3 smuggler.py

Options

usage: smuggler.py [-h] [-u URL] [-v VHOST] [-x] [-m METHOD] [-l LOG] [-q]
                   [-t TIMEOUT] [--no-color] [-c CONFIGFILE]

optional arguments:
  -h, --help            show this help message and exit
  -u URL, --url URL     Target URL with Endpoint
  -v VHOST, --vhost VHOST
                        Specify a virtual host
  -x, --exit_early      Exit scan on first finding
  -m METHOD, --method METHOD
                        HTTP method to use (e.g GET, POST) Default: POST
  -l LOG, --log LOG     Specify a log file
  -q, --quiet           Quiet mode will only log issues found
  -t TIMEOUT, --timeout TIMEOUT
                        Socket timeout value Default: 5
  --no-color            Suppress color codes
  -c CONFIGFILE, --configfile CONFIGFILE
                        Filepath to the configuration file of payloads

Smuggler at a minimum requires either a URL via the -u/--url argument or a list of URLs piped into the script via stdin. If the URL specifies https:// then Smuggler will connect to the host:port using SSL/TLS. If the URL specifies http:// then no SSL/TLS will be used at all. If only the host is specified, then the script will default to https://

Use -v/--vhost <host> to specify a different host header from the server address

Use -x/--exit_early to exit the scan of a given server when a potential issue is found. In piped mode smuggler will just continue to the next host on the list

Use -m/--method <method> to specify a different HTTP verb from POST (i.e GET/PUT/PATCH/OPTIONS/CONNECT/TRACE/DELETE/HEAD/etc...)

Use -l/--log <file> to write output to file as well as stdout

Use -q/--quiet reduce verbosity and only log issues found

Use -t/--timeout <value> to specify the socket timeout. The value should be high enough to conclude that the socket is hanging, but low enough to speed up testing (default: 5)

Use --no-color to suppress the output color codes printed to stdout (logs by default don't include color codes)

Use -c/--configfile <configfile> to specify your smuggler mutation configuration file (default: default.py)

Config Files

Configuration files are python files that exist in the ./config directory of smuggler. These files describe the content of the HTTP requests and the transfer-encoding mutations to test.

Here is example content of default.py:

def render_template(gadget):
	RN = "\r\n"
	p = Payload()
	p.header  = "__METHOD__ __ENDPOINT__?cb=__RANDOM__ HTTP/1.1" + RN
	# p.header += "Transfer-Encoding: chunked" +RN	
	p.header += gadget + RN
	p.header += "Host: __HOST__" + RN
	p.header += "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36" + RN
	p.header += "Content-type: application/x-www-form-urlencoded; charset=UTF-8" + RN
	p.header += "Content-Length: __REPLACE_CL__" + RN
	return p


mutations["nameprefix1"] = render_template(" Transfer-Encoding: chunked")
mutations["tabprefix1"] = render_template("Transfer-Encoding:\tchunked")
mutations["tabprefix2"] = render_template("Transfer-Encoding\t:\tchunked")
mutations["space1"] = render_template("Transfer-Encoding : chunked")

for i in [0x1,0x4,0x8,0x9,0xa,0xb,0xc,0xd,0x1F,0x20,0x7f,0xA0,0xFF]:
	mutations["midspace-%   02x"%i] = render_template("Transfer-Encoding:%cchunked"%(i))
	mutations["postspace-%02x"%i] = render_template("Transfer-Encoding%c: chunked"%(i))
	mutations["prespace-%02x"%i] = render_template("%cTransfer-Encoding: chunked"%(i))
	mutations["endspace-%02x"%i] = render_template("Transfer-Encoding: chunked%c"%(i))
	mutations["xprespace-%02x"%i] = render_template("X: X%cTransfer-Encoding: chunked"%(i))
	mutations["endspacex-%02x"%i] = render_template("Transfer-Encoding: chunked%cX: X"%(i))
	mutations["rxprespace-%02x"%i] = render_template("X: X\r%cTransfer-Encoding: chunked"%(i))
	mutations["xnprespace-%02x"%i] = render_template("X: X%c\nTransfer-Encoding: chunked"%(i))
	mutations["endspacerx-%02x"%i] = render_template("Transfer-Encoding: chunked\r%cX: X"%(i))
	mutations["endspacexn-%02x"%i] = render_template("Transfer-Encoding: chunked%c\nX: X"%(i))

There are no input arguments yet on specifying your own customer headers and user-agents. It is recommended to create your own configuration file based on default.py and modify it to your liking.

Smuggler comes with 3 configuration files: default.py (fast), doubles.py (niche, slow), exhaustive.py (very slow) default.py is the fastest because it contains less mutations.

specify configuration files using the -c/--configfile <configfile> command line option

Payloads Directory

Inside the Smuggler directory is the payloads directory. When Smuggler finds a potential CLTE or TECL desync issue, it will automatically dump a binary txt file of the problematic payload in the payloads directory. All payload filenames are annotated with the hostname, desync type and mutation type. Use these payloads to netcat directly to the server or to import into other analysis tools.

Helper Scripts

After you find a desync issue feel free to use my Turbo Intruder desync scripts found Here: https://github.com/defparam/tiscripts DesyncAttack_CLTE.py and DesyncAttack_TECL.py are great scripts to help stage a desync attack

License

These scripts are released under the MIT license. See LICENSE.

Download Smuggler

Related news

Zal Walt

Hackerhubb.blogspot.com

Cynet's Keys for Threat Visibility

Einstein said that the definition of insanity is doing the same thing over and over while expecting a different outcome. The old approach to threat visibility involving multiple protection technologies and trying to sift through a sea of alerts and information is obviously not working well. Cynet's different – and seemingly saner – approach to prevent, detect, and respond to modern-day threats involves several integrated capabilities.

According to the new Cynet solution overview, the following key technologies are used to provide extended threat visibility along with enhanced response capabilities.

Include Multiple Threat Detection Technologies

Cynet includes multiple prevention and detection technologies, all natively orchestrated in the platform:

NGAV – Fundamental endpoint protection based on known bad signatures and behaviors.
EDR – To detect and prevent more complex endpoint threats that bypass NGAV solutions.
NTA – To detect threats that have made their way into the network and so-called lateral movement.
UBA – To detect unusual activity that could signal stolen credentials, a rogue insider, or bots.
Deception – To uncover intrusions that have bypassed other detection technologies
CLM – To mine the extensive log data generated by IT systems.
SSPM – To find and correct configuration errors in SaaS applications.

Coordinate All Signals

Making sense out of multiple detection technologies by integrating, coordinating, and prioritizing information was supposed to be the realm of Security Incident and Event Management (SIEM) technologies. Unfortunately, SIEM doesn't do well with real-time data and requires significant care and feeding.

XDR solutions, like Cynet's, are purpose-built to integrate real-time signals from multiple points of telemetry on a single platform. Cynet even includes an Incident Engine that automatically investigates threats to determine the attack's full scope and root cause.

Automate All Response Actions

Quickly and accurately identifying threats is a game-changer. The ability to automatically and fully eradicate identified threats is, well, a game-changer changer. This means security teams won't have to be burdened with lengthy investigations, which many don't have the time or skills to undertake. Cynet provides an extensive set of remediation actions across files, hosts, networks and users as well as remediation playbooks that can be configured to be invoked manually or automatically.

Provide Full MDR Oversight

Beyond the technology platform, Cynet offers all clients a full, 24x7 MDR service at no additional cost. This team continuously monitors client environments to ensure nothing dangerous is overlooked or mishandled. Having an expert team watching out for issues should put smaller organizations with smaller security teams at ease, knowing an expert team of cybersecurity experts has their backs.

In With the New

With the time required to identify and contain data breaches steadily increasing, we need to rethink the traditional cybersecurity approach. It seems companies keep throwing more money, more technology, and more bodies at the problem, yet achieving the same (or worse) results. Cynet is one company that seems to be approaching the problem differently by combining multiple prevention, detection, response, and automation capabilities on a single, unified breach protection platform. Rather than buying all this stuff separately and munging it all together, the Cynet platform seems to expand and improve threat visibility out of the box.

Download the solution brief here