PuZzLeS

Tuesday, June 9, 2020

URLCrazy - Generate And Test Domain Typos And Variations To Detect And Perform Typo Squatting, URL Hijacking, Phishing, And Corporate Espionage

URLCrazy is an OSINT tool to generate and test domain typos or variations to detect or perform typo squatting, URL hijacking, phishing, and corporate espionage.
Homepage: https://www.morningstarsecurity.com/research/urlcrazy

Use Cases

Detect typo squatters profiting from typos on your domain name
Protect your brand by registering popular typos
Identify typo domain names that will receive traffic intended for another domain
Conduct phishing attacks during a penetration test

Features

Generates 15 types of domain variants
Knows over 8000 common misspellings
Supports bit flipping attacks
Multiple keyboard layouts (qwerty, azerty, qwertz, dvorak)
Checks if a domain variant is valid
Test if domain variants are in use
Estimate popularity of a domain variant

Installation

Install from a package manager
If you are using Kali Linux, Ubuntu or Debian use:
$ sudo apt install urlcrazy

Install latest release
Visit https://github.com/urbanadventurer/urlcrazy/releases

Install current development version
Be aware the latest development version may not be stable.
$ git clone https://github.com/urbanadventurer/urlcrazy.git

Install Ruby
URLCrazy has been tested with Ruby versions 2.4 and 2.6.
If you are using Ubuntu or Debian use:
$ sudo apt install ruby

Install Bundler
Bundler provides dependecy management for Ruby projects
$ gem install bundler

Install Dependencies
$ bundle install
Alternatively, if you don't want to install bundler, the following command will install the gem dependencies.
$ gem install json colorize async async-dns async-http

Usage

Simple Usage
With default options, URLCrazy will check over 2000 typo variants for google.com.
$ urlcrazy google.com

With popularity estimate
$ urlcrazy -p domain.com

Commandline Usage

Usage: ./urlcrazy [options] domain

Options
-k, --keyboard=LAYOUT  Options are: qwerty, azerty, qwertz, dvorak (default: qwerty)
-p, --popularity       Check domain popularity with Google
-r, --no-resolve       Do not resolve DNS
-i, --show-invalid     Show invalid domain names
-f, --format=TYPE      Human readable or CSV (default: human readable)
-o, --output=FILE      Output file
-n, --nocolor          Disable colour
-h, --help             This help
-v, --version          Print version information. This version is 0.7

Types of Domain Variations Supported

Character Omission
These typos are created by leaving out a letter of the domain name, one letter at a time. For example, www.goole.com and www.gogle.com

Character Repeat
These typos are created by repeating a letter of the domain name. For example, www.ggoogle.com and www.gooogle.com

Adjacent Character Swap
These typos are created by swapping the order of adjacent letters in the domain name. For example, www.googel.com and www.ogogle.com

Adjacent Character Replacement
These typos are created by replacing each letter of the domain name with letters to the immediate left and right on the keyboard. For example, www.googke.com and www.goohle.com

Double Character Replacement
These typos are created by replacing identical, consecutive letters of the domain name with letters to the immediate left and right on the keyboard. For example, www.gppgle.com and www.giigle.com

Adjacent Character Insertion
These typos are created by inserting letters to the immediate left and right on the keyboard of each letter. For example, www.googhle.com and www.goopgle.com

Missing Dot
These typos are created by omitting a dot from the domainname. For example, wwwgoogle.com and www.googlecom

Strip Dashes
These typos are created by omitting a dash from the domainname. For example, www.domain-name.com becomes www.domainname.com

Singular or Pluralise
These typos are created by making a singular domain plural and vice versa. For example, www.google.com becomes www.googles.com and www.games.co.nz becomes www.game.co.nz

Common Misspellings
Over 8000 common misspellings from Wikipedia. For example, www.youtube.com becomes www.youtub.com and www.abseil.com becomes www.absail.com

Vowel Swapping
Swap vowels within the domain name except for the first letter. For example, www.google.com becomes www.gaagle.com.

Homophones
Over 450 sets of words that sound the same when spoken. For example, www.base.com becomes www.bass.com.

Bit Flipping
Each letter in a domain name is an 8bit character. The character is substituted with the set of valid characters that can be made after a single bit flip. For example, facebook.com becomes bacebook.com, dacebook.com, faaebook.com,fabebook.com,facabook.com, etc.

Homoglyphs
One or more characters that look similar to another character but are different are called homogylphs. An example is that the lower case l looks similar to the numeral one, e.g. l vs 1. For example, google.com becomes goog1e.com.

Wrong Top Level Domain
For example, www.trademe.co.nz becomes www.trademe.co.nz and www.google.com becomes www.google.org Uses the 19 most common top level domains.

Wrong Second Level Domain
Uses an alternate, valid second level domain for the top level domain. For example, www.trademe.co.nz becomes www.trademe.ac.nz and www.trademe.iwi.nz

Supported Keyboard Layouts
Keyboard layouts supported are:

QWERTY
AZERTY
QWERTZ
DVORAK

Is the domain valid?
URLCrazy has a database of valid top level and second level domains. This information has been compiled from Wikipedia and domain registrars. We know whether a domain is valid by checking if it matches top level and second level domains. For example, www.trademe.co.bz is a valid domain in Belize which allows any second level domain registrations but www.trademe.xo.nz isn't because xo.nz isn't an allowed second level domain in New Zealand.

Popularity Estimate
URLCrazy pioneered the technique of estimating the relative popularity of a typo from search engine results data. By measuring how many times a typo appears in webpages, we can estimate how popular that typo will be made when users type in a URL.
The inherent limitation of this technique, is that a typo for one domain, can be a legitimate domain in its own right. For example, googles.com is a typo of google.com but it also a legitimate domain.
For example, consider the following typos for google.com.

Count.	Typo
25424	gogle.com
24031	googel.com
22490	gooogle.com
19172	googles.com
19148	goole.com
18855	googl.com
17842	ggoogle.com

Known Issues

Macos File Descriptor Limit
If DNS resolution fails under Macos it could be due to the small default file descriptor limit.
To display the current file descriptor limit use:
$ ulimit -a
To increase the file descriptor limit use:
$ ulimit -n 10000

URLCrazy Appearances

Kali Linux
URLCrazy was a default tool in BackTrack 5, and later Kali Linux. https://tools.kali.org/information-gathering/urlcrazy

The Browser Hacker's Handbook
Authored by Wade Alcorn, Christian Frichot, and Michele Orru.
URLCrazy is included in Chapter 2 of this seminal work on the topic.

PTES Technical Guidelines
Penetration Testing Execution Standard (PTES) is a standard designed to provide a common language and scope for performing penetration testing (i.e. Security evaluations). URLCrazy is included in the Tools Required section.
http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines

Network Security Toolkit
Network Security Toolkit is a bootable Linux distribution designed to provide easy access to best-of-breed Open Source Network Security Applications. https://www.networksecuritytoolkit.org/

See Also
URLCrazy was first published in 2009, and for many years was the most advanced opensource tool for studying typosquatting. Since then multiple other tools have been developed by the infosec community.

DNSTwist
DNSTwist is developed by Marcin Ulikowski and first published in 2015. DNSTwist had a significant feature overlap with URLCrazy at the time, and introduced many new features.
Language: Python
https://github.com/elceef/dnstwist

URLInsane
URLInsane was developed by Rangertaha in 2018 and claims to match the features of URLCrazy and DNSTwist.
Language: Go
https://github.com/cybint/urlinsane

DomainFuzz
DomainFuzz was developed by monkeym4sterin 2017. Language: Node.JS
https://github.com/monkeym4ster/DomainFuzz

Authors and Acknowledgement

Authored by Andrew Horton (urbanadventurer).
Thanks to Ruby on Rails for Inflector which allows plural and singular permutations.
Thanks to Wikipedia for the set of common misspellings, homophones, and homoglyphs.
Thanks to software77.net for their IP to country database

Community
If you have any questions, comments or concerns regarding URLCrazy, please consult the documentation prior to contacting one of the developers. Your feedback is always welcome.

Download Urlcrazy

via KitPloit

Aircrack-ng: The Next Generation Of Aircrack

"Aircrack-ng is an 802.11 WEP and WPA-PSK keys cracking program that can recover keys once enough data packets have been captured. It implements the standard FMS attack along with some optimizations like KoreK attacks, as well as the all-new PTW attack, thus making the attack much faster compared to other WEP cracking tools. In fact, Aircrack-ng is a set of tools for auditing wireless networks." read more...

Website: http://www.aircrack-ng.org

CLOUDKiLL3R - Bypasses Cloudflare Protection Service Via TOR Browser

CLOUDKiLL3R bypasses Cloudflare protection service via TOR Browser !

CLOUDKiLL3R Requirements :

TOR Browser to scan as many sites as you want :)
Python Compiler

CLOUDKiLL3R Installation ?
Make sure that TOR Browser is up and running while working with CLOUDKiLL3R .
Make sure that the IP AND PORT are the same in TOR Browser preferences > advanced > Networks
Include the files below in one folder :

FILTER.txt
CK.pl

Make Sure The Modules Below Are Installed If NOT > use this command to install one : pip install [module name]

argparse
socks
socket
requests
sys

Contact :
Twitter.com/moh_security

Download CLOUDKiLL3R

More info

Practical Bleichenbacher Attacks On IPsec IKE

We found out that reusing a key pair across different versions and modes of IPsec IKE can lead to cross-protocol authentication bypasses, enabling the impersonation of a victim host or network by attackers. These vulnerabilities existed in implementations by Cisco, Huawei, and others.

This week at the USENIX Security conference, I will present our research paper on IPsec attacks: The Dangers of Key Reuse: Practical Attacks on IPsec IKE written by Martin Grothe, Jörg Schwenk, and me from Ruhr University Bochum as well as Adam Czubak and Marcin Szymanek from the University of Opole [alternative link to the paper]. This blog post is intended for people who like to get a comprehensive summary of our findings rather than to read a long research paper.

IPsec and Internet Key Exchange (IKE)

IPsec enables cryptographic protection of IP packets. It is commonly used to build VPNs (Virtual Private Networks). For key establishment, the IKE protocol is used. IKE exists in two versions, each with different modes, different phases, several authentication methods, and conﬁguration options. Therefore, IKE is one of the most complex cryptographic protocols in use.

In version 1 of IKE (IKEv1), four authentication methods are available for Phase 1, in which initial authenticated keying material is established: Two public key encryption based methods, one signature based method, and a PSK (Pre-Shared Key) based method.

Attacks on IKE implementations

With our attacks we can impersonate an IKE device: If the attack is successful, we share a set of (falsely) authenticated symmetric keys with the victim device, and can successfully complete the handshake – this holds for both IKEv1 and IKEv2. The attacks are based on Bleichenbacher oracles in the IKEv1 implementations of four large network equipment manufacturers: Cisco, Huawei, Clavister, and ZyXEL. These Bleichenbacher oracles can also be used to forge digital signatures, which breaks the signature based IKEv1 and IKEv2 variants. Those who are unfamiliar with Bleichenbacher attacks may read this post by our colleague Juraj Somorovsky for an explanation.

The affected hardware test devices by Huawei, Cisco, and ZyXEL in our network lab.

We show that the strength of these oracles is sufficient to break all handshake variants in IKEv1 and IKEv2 (except those based on PSKs) when given access to powerful network equipment. We furthermore demonstrate that key reuse across protocols as implemented in certain network equipment carries high security risks.

We additionally show that both PSK based modes can be broken with an offline dictionary attack if the PSK has low entropy. Such an attack was previously only documented for one of those modes (edit: see this comment). We thus show attacks against all authentication modes in both IKEv1 and IKEv2 under reasonable assumptions.

The relationship between IKEv1 Phase 1, Phase 2, and IPsec ESP. Multiple simultaneous Phase 2 connections can be established from a single Phase 1 connection. Grey parts are encrypted, either with IKE derived keys (light grey) or with IPsec keys (dark grey). The numbers at the curly brackets denote the number of messages to be exchanged in the protocol.

Where's the bug?

The public key encryption (PKE) based authentication mode of IKE requires that both parties exchanged their public keys securely beforehand (e. g. with certiﬁcates during an earlier handshake with signature based authentication). RFC 2409 advertises this mode of authentication with a plausibly deniable exchange to raise the privacy level. In this mode, messages three and four of the handshake exchange encrypted nonces and identities. They are encrypted using the public key of the respective other party. The encoding format for the ciphertexts is PKCS #1 v1.5.

Bleichenbacher attacks are adaptive chosen ciphertext attacks against RSA-PKCS #1 v1.5. Though the attack has been known for two decades, it is a common pitfall for developers. The mandatory use of PKCS #1 v1.5 in the PKE authentication methods raised suspicion of whether implementations resist Bleichenbacher attacks.

PKE authentication is available and fully functional in Cisco's IOS operating system. In Clavister's cOS and ZyXEL's ZyWALL USG devices, PKE is not ofﬁcially available. There is no documentation and no conﬁguration option for it and it is therefore not fully functional. Nevertheless, these implementations processed messages using PKE authentication in our tests.

Huawei implements a revised mode of the PKE mode mentioned in the RFC that saves one private key operation per peer (we call it RPKE mode). It is available in certain Huawei devices including the Secospace USG2000 series.

We were able to conﬁrm the existence of Bleichenbacher oracles in all these implementations. Here are the CVE entries and security advisories by the vendors (I will add links once they are available):

Cisco: CVE-2018-0131, Security Advisory
Huawei: CVE-2017-17305, Security Advisory
Clavister: CVE-2018-8753, Security Advisory
Zyxel: CVE-2018-9129, Security Advisory

On an abstract level, these oracles work as follows: If we replace the ciphertext of the nonce in the third handshake message with a modiﬁed RSA ciphertext, the responder will either indicate an error (Cisco, Clavister, and ZyXEL) or silently abort (Huawei) if the ciphertext is not PKCS #1 v1.5 compliant. Otherwise, the responder continues with the fourth message (Cisco and Huawei) or return an error notiﬁcation with a different message (Clavister and ZyXEL) if the ciphertext is in fact PKCS #1 v1.5 compliant. Each time we learn that the ciphertext was valid, we can advance the Bleichenbacher attack one more step.

A Bleichenbacher Attack Against PKE

If a Bleichenbacher oracle is discovered in a TLS implementation, then TLS-RSA is broken since one can compute the Premaster Secret and the TLS session keys without any time limit on the usage of the oracle. For IKEv1, the situation is more difﬁcult: Even if there is a strong Bleichenbacher oracle in PKE and RPKE mode, our attack must succeed within the lifetime of the IKEv1 Phase 1 session, since a Diffie-Hellman key exchange during the handshake provides an additional layer of security that is not present in TLS-RSA. For example, for Cisco this time limit is currently ﬁxed to 60 seconds for IKEv1 and 240 seconds for IKEv2.

To phrase it differently: In TLS-RSA, a Bleichenbacher oracle allows to perform an ex post attack to break the conﬁdentiality of the TLS session later on, whereas in IKEv1 a Bleichenbacher oracle only can be used to perform an online attack to impersonate one of the two parties in real time.

Bleichenbacher attack against IKEv1 PKE based authentication.

The figure above depicts a direct attack on IKEv1 PKE:

The attackers initiate an IKEv1 PKE based key exchange with Responder A and adhere to the protocol until receiving the fourth message. They extract the encrypted nonce from this message, and record the other public values of the handshake.
The attackers keep the IKE handshake with Responder A alive as long as the responder allows. For Cisco and ZyXEL we know that handshakes are cancelled after 60 seconds, Clavister and Huawei do so after 30 seconds.
The attackers initiate several parallel PKE based key exchanges to Responder B.

In each of these exchanges, they send and receive the ﬁrst two messages according to the protocol speciﬁcations.
In the third message, they include a modiﬁed version of the encrypted nonce according to the the Bleichenbacher attack methodology.
They wait until they receive an answer or they can reliably determine that this message will not be sent (timeout or reception of a repeated second handshake message).

After receiving enough answers from Responder B, the attackers can compute the plaintext of the nonce.
The attackers now have all the information to complete the key derivation and the handshake. They thus can impersonate Responder B to Responder A.

Key Reuse

Maintaining individual keys and key pairs for each protocol version, mode, and authentication method of IKE is difﬁcult to achieve in practice. It is oftentimes simply not supported by implementations. This is the case with the implementations by Clavister and ZyXEL, for example. Thus, it is common practice to have only one RSA key pair for the whole IKE protocol family. The actual security of the protocol family in this case crucially depends on its cross-ciphersuite and cross-version security. In fact, our Huawei test device reuses its RSA key pair even for SSH host identification, which further exposes this key pair.

A Cross-Protocol Version Attack with Digital Signature Based Authentication

Signature Forgery Using Bleichenbacher's Attack

It is well known that in the case of RSA, performing a decryption and creating a signature is mathematically the same operation. Bleichenbacher's original paper already mentioned that the attack could also be used to forge signatures over attacker-chosen data. In two papers that my colleagues at our chair have published, this has been exploited for attacks on XML-based Web Services, TLS 1.3, and Google's QUIC protocol. The ROBOT paper used this attack to forge a signature from Facebook's web servers as proof of exploitability.

IKEv2 With Digital Signatures

Digital signature based authentication is supported by both IKEv1 and IKEv2. We focus here on IKEv2 because on Cisco routers, an IKEv2 handshake may take up to four minutes. This more relaxed timer compared to IKEv1 makes it an interesting attack target.

I promised that this blogpost will only give a comprehensive summary, therefore I am skipping all the details about IKEv2 here. It is enough to know that the structure of IKEv2 is fundamentally different from IKEv1.

If you're familiar with IT-security, then you will believe me that if digital signatures are used for authentication, it is not particularly good if an attacker can get a signature over attacker chosen data. We managed to develop an attack that exploits an IKEv1 Bleichenbacher oracle at some peer A to get a signature that can be used to break the IKEv2 authentication at another peer B. This requires that peer A reuses its key pair for IKEv2 also for IKEv1. For the details, please read our paper [alternative link to the paper].

Evaluation and Results

For testing the attack, we used a Cisco ASR 1001-X router running IOS XE in version 03.16.02.S with IOS version 15.5(3)S2. Unfortunately, Cisco's implementation is not optimized for throughput. From our observations we assume that all cryptographic calculations for IKE are done by the device's CPU despite it having a hardware accelerator for cryptography. One can easily overload the device's CPU for several seconds with a standard PC bursting handshake messages, even with the default limit for concurrent handshakes. And even if the CPU load is kept below 100 %, we nevertheless observed packet loss.

For the decryption attack on Cisco's IKEv1 responder, we need to ﬁnish the Bleichenbacher attack in 60 seconds. If the public key of our ASR 1001-X router is 1024 bits long, we measured an average of 850 responses to Bleichenbacher requests per second. Therefore, an attack must succeed with at most 51,000 Bleichenbacher requests.

But another limit is the management of Security Associations (SAs). There is a global limit of 900 Phase 1 SAs under negotiation per Cisco device in the default conﬁguration. If this number is exceeded, one is blocked. Thus, one cannot start individual handshakes for each Bleichenbacher request to issue. Instead, SAs have to be reused as long as their error counter allows. Furthermore, establishing SAs with Cisco IOS is really slow. During the attack, the negotiations in the first two messages of IKEv1 require more time than the actual Bleichenbacher attack.

We managed to perform a successful decryption attack against our ASR 1001-X router with approximately 19,000 Bleichenbacher requests. However, due to the necessary SA negotiations, the attack took 13 minutes.

For the statistics and for the attack evaluation of digital signature forgery, we used a simulator with an oracle that behaves exactly as the ones by Cisco, Clavister, and ZyXEL. We found that about 26% of attacks against IKEv1 could be successful based on the cryptographic performance of our Cisco device. For digital signature forgery, about 22% of attacks could be successful under the same assumptions.

Note that (without a patched IOS), only non-cryptographic performance issues prevented a succesful attack on our Cisco device. There might be faster devices that do not suffer from this. Also note that a too slow Bleichenbacher attack does not permanently lock out attackers. If a timeout occurs, they can just start over with a new attack using fresh values hoping to require fewer requests. If the victim has deployed multiple responders sharing one key pair (e. g. for load balancing), this could also be leveraged to speed up an attack.

Responsible Disclosure

We reported our ﬁndings to Cisco, Huawei, Clavister, and ZyXEL. Cisco published ﬁxes with IOS XE versions 16.3.6, 16.6.3, and 16.7.1. They further informed us that the PKE mode will be removed with the next major release.

Huawei published ﬁrmware version V300R001C10SPH702 for the Secospace USG2000 series that removes the Bleichenbacher oracle and the crash bugs we identiﬁed. Customers who use other affected Huawei devices will be contacted directly by their support team as part of a need-to-know strategy.

Clavister removed the vulnerable authentication method with cOS version 12.00.09. ZyXEL responded that our ZyWALL USG 100 test device is from a legacy model series that is end-of-support. Therefore, these devices will not receive a ﬁx. For the successor models, the patched ﬁrmware version ZLD 4.32 (Release Notes) is available.

FAQs

Why don't you have a cool name for this attack?
The attack itself already has a name, it's Bleichenbacher's attack. We just show how Bleichenbacher attacks can be applied to IKE and how they can break the protocol's security. So, if you like, call it IPsec-Bleichenbacher or IKE-Bleichenbacher.
Do you have a logo for the attack?
No.
My machine was running a vulnerable firmware. Have I been attacked?
We have no indication that the attack was ever used in the wild. However, if you are still concerned, check your logs. The attack is not silent. If your machine was used for a Bleichenbacher attack, there should be many log entries about decryption errors. If your machine was the one that got tricked (Responder A in our figures), then you could probably find log entries about unfinished handshake attempts.
Where can I learn more?
First of all, you can read the paper [alternative link to the paper]. Second, you can watch the presentation, either live at the conference or later on this page.
What else does the paper contain?
The paper contains a lot more details than this blogpost. It explains all authentication methods including IKEv2 and it gives message flow diagrams of the protocols. There, we describe a variant of the attack that uses the Bleichenbacher oracles to forge signatures to target IKEv2. Furthermore, we describe the quirks of Huawei's implementation including crash bugs that could allow for Denial-of-Service attacks. Last but not least, it describes a dictionary attack against the PSK mode of authentication that is covered in a separate blogpost.

Media Coverage, Blogs, and more

English

German

Continue reading

Probing For XML Encryption Weaknesses In SAML With EsPReSSO

Security Assertion Markup Language (SAML) is an XML-based standard commonly used in Web Single Sign-On (SSO) [1]. In SAML, the confidentiality of transferred authentication statements against intermediaries can be provided using XML Encryption [2]. However, implementing XML Encryption in a secure way can be tricky and several attacks on XML Encryption have been identified in the past [3] [4]. Therefore, when auditing a SAML endpoint, one should always consider testing for vulnerabilities in the XML Encryption implementation.

This blog post introduces our latest addition to the SAML Attacker of our BurpSuite extension EsPReSSO: the Encryption Attack tab. The new tab allows for easy manipulation of the encrypted parts within intercepted SAML responses and can, therefore, be used to quickly assess whether the SAML endpoint is vulnerable against certain XML Encryption attacks.

Weaknesses of XML Encryption

Implementations of XML Encryption can be vulnerable to adaptive chosen ciphertext attacks. This is a class of attacks in which the attacker sends a sequence of manipulated ciphertexts to a decryption oracle as a way to gain information about the plaintext content.

Falsely implemented XML Encryption can be broken using:

an attack against the CBC-mode decryption (quite similar to a padding oracle attack) [3] or
a Bleichenbacher attack against the RSA-PKCS#1 encryption of the session key [4].

SAML makes use of XML Encryption and its implementations could, therefore, also be vulnerable to these attacks.

XML Encryption in SAML

To support confidential transmission of sensitive data within the SAML Assertion, assertions can be encrypted using XML Encryption. An EncryptedAssertion is shown in the abridged example below.

The EncryptedAssertion contains an EncryptedData element, which in turn is the parent of the EncryptionMethod, KeyInfo, and CipherData elements. SAML makes use of what is referred to as a hybrid encryption scheme. This is done using a session key which symmetrically encrypts the payload data (the example uses AES-128 in CBC mode), resulting in the ciphertext contained in the EncryptedAssertion/EncryptedData/CipherData/CipherValue child element. The session key itself is encrypted using an asymmetric encryption scheme. In our example, RSA-PKCS#1.5 encryption is used with the public key of the recipient, allowing the contents of the the EncryptedKey child element to be derived from the KeyInfo element.

Encryption Attacker

Our BurpSuite extension EsPReSSO can help detect vulnerable implementations with the newly integrated Encryption Attacker within EsPReSSO's SAML module.

Once a SAML response which contains an EncryptedAssertion has been intercepted, open the SAML tab, select the Attacks pane, and choose Encryption from the dropdown menu. This works in Burp's Proxy, as well as in the Repeater tool, and is depicted below.

As sketched out above, the symmetric session key is encrypted using the recipient's public key. Since the key is public, anybody can use it to encrypt a selected symmetric key and submit a valid encryption of arbitrary messages to the recipient. This is incredibly helpful because it allows us to produce ciphertexts that decrypt the chosen plaintexts. To accomplish this, one can purposefully send invalidly padded messages, or messages containing invalid XML, as a method to trigger and analyze the different reactions of the decryption endpoint (i.e, turning the endpoint into a decryption oracle). To facilitate these investigations, the new Encryption Attacker makes this process dead simple.

The screenshot above shows the essential interface of the new encryption tab:
At the top, the certificate used to encrypt the symmetric session key can be pasted into the text field. This field will be pre-filled automatically if the intercepted SAML message includes a certificate in the KeyInfo child element of the EncryptedData element. The Update Certificate checkboxes above the text area can be used to include the certificate in the manipulated SAML message.
In the Symmetric Key text field, the hexadecimal value of the symmetric session key can be set. Choose the asymmetric algorithm from the dropdown menu and click Encrypt key -- this will update the corresponding KeyInfo elements of the intercepted SAML message.

The payload in the text area labeled XML data can now be entered. Any update in the XML data field will also be reflected in the hexadecimal representation of the payload (found on right of the XML data field). Note that this is automatically padded to the blocklength required by the symmetric algorithm selected below. However, the payload and the padding can be manually adjusted in the hex editor field.

Eventually, click the Encrypt content button to generate the encrypted payload. This will apply the changes to the intercepted SAML message, and the manipulated message using Burp's Forward or Go button can now be forwarded, as usual.

Probing for Bleichenbacher Oracles

Bleichenbacher's attack against RSA-PKCS1 v1.5 encryption abuses the malleability of RSA to draw conclusions about the plaintext by multiplying the ciphertext with adaptively chosen values, and observing differences in the received responses. If the (error-) responses differ for valid and invalid PKCS1 v1.5 ciphertexts, Bleichenbachers' algorithm can be used to decrypt the ciphertext without knowing the private key [6].

To determine whether or not a SAML endpoint is vulnerable to Bleichenbacher's Attack, we simply need to check if we can distinguish those responses received when submitting ciphertexts that are decrypted into invalidly formatted PKCS1 v1.5 plaintexts, from the responses we receive when sending ciphertexts that are decrypted into validly formatted plaintexts.

Recall that PKCS1 v1.5 mandates a certain format of the encrypted plaintext, namely a concatenation of a BlockType 00 02, a randomized PaddingString (PS) that includes no 00 bytes, a 00 (NULL-byte) as delimiter, and the actual plaintext message. The whole sequence should be equal in size to the modulus of the RSA key used. That is, given the byte length k of the RSA modulus and the message length |m|, PS has the length |PS| = k - 3 - |m|. Furthermore, PKCS1 v1.5 demands that |PS| to be at least eight bytes long [5].

In SAML, the recipient's public key is usually known because it is published in the metadata, or even included in the EncryptedAssertion. For this reason, we do not need to fiddle around with manipulated ciphertexts. Instead, we simply submit a validly formatted RSA-PKCS1 v1.5 encrypted message and an encrypted message which deciphers into an invalidly formatted plaintext. As an example, assume an RSA public key of 2048 bits which we want to use to encrypt a 16 byte session key `01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10` (hexadecimal representation). |PS|$ is $2048/8 - 3 - 16 = 237, so a valid PKCS1 v1.5 plaintext, ready to be encrypted using `AA` for all 237 padding bytes, could look like the listing shown below.

00 02 AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 00
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10

In the Encryption attack pane of EsPReSSO, ensure that the correct public key certificate has been added to the Certificate field. Insert a valid plaintext, such as the one above, into the Symmetric Key field and select Plain RSA encryption from the Algorithm drop down menu. Click the Encrypt button to compute the RSA transformation and apply the new EncryptedKey element to the intercepted SAML message. Now, submit the message by clicking Burp's Go or Forward button and carefully inspect the response.

Next, repeat the steps outlined above, but this time submit an invalid PKCS1 v1.5 message. For example, consider using an invalid BlockType of `12 34` instead of `00 02`, or replace the `00` delimiter so that the decryptor is unable to determine the actual message after decrypting the ciphertext. If you are able to determine from the recieved responses whether or not the submitted ciphertext decrypted into a valid PKCS1 v1.5 formatted plaintext, chances are high that the decryptor can be used as a Bleichenbacher oracle. Don't forget to take into account the actual XML data, i.e., the assertion encrypted with the new session key; by submitting valid or invalid XML, or by removing signatures from the SAML message or the assertion you may increase your chances of detecting differences in the returned responses.

Probing for Oracles in CBC-Mode Decryption

Another known attack on XML Encryption is aimed at the Cipher Block Chaining (CBC) mode, which can be used with the block ciphers AES or 3DES [2]. The attack is described in detail in this referenced paper [3] and is quite similar to Padding-Oracle attacks on CBC mode; the malleability of CBC mode encryption enables the attacker to perform a bytewise, adaptive manipulation of the ciphertext blocks which are subsequently sent to the decryptor. In most cases, the manipulated ciphertext will not decrypt to valid XML and an error will be returned. Sometimes, however, the plaintext will be parsed as valid XML, in which cases an error is thrown later on at the application layer. The attacker observes the differences in the responses in order to turn the decryptor into a ciphertext validity oracle which can be used to break the encryption. Due to some particularities of the XML format, this attack can be very efficient, enabling decryption with about 14 requests per byte, and it is even possible to fully automate the process [7].

In order to determine if a particular SAML service provider is vulnerable to this attack, we can avoid the cumbersome ciphertext manipulation, if we are in possession of the decryptor's public key:
In the Encryption Attacker tab of EsPReSSO, add the public key certificate to the Certificate field (if necessary) and insert a symmetric key of your own devising into the Symmetric Key text field. Select an appropriate RSA encryption method and click the Encrypt button to apply the new EncryptedKey element to the original SAML message.

An XML message can now be inserted into the XML data text field. Select a CBC mode encryption algorithm and click Encrypt to apply the changes. As in the example above, press Burp's Go or Forward button to send the message and carefully inspect the response. Try sending invalid XML, e.g., by not closing a tag or using the `&` character without a valid entity and keep an eye open for differences in the returned responses. To manipulate the padding, the text field on the right side shows the hexadecimal representation of the plaintext, including the CBC padding. If you send a single block and set the last byte, which indicates the padding length to the blocksize, i.e. 16 or 0x10 for AES, the ciphertext should decrypt into an empty string and is generally considered "valid" XML.

Please refer to the original paper for more details, tips, and tricks for performing the actual attack [3].

Summary

The new XML Encryption attacker included in EsPReSSO can help security auditors to quickly assess if a SAML endpoint is vulnerable to known attacks against XML Encryption. To this end, the decryptor's public key is used in order to send suitable test vectors that can be provided in plaintext. Ciphertext manipulation is, therefore, not required. The actual process of decrypting an intercepted SAML message is, however, considered out of scope and not implemented in EsPReSSO.

In case you wonder how XML Encryption can be used in a secure fashion, here are some considerations [6]:

Always use an authenticated encryption mode such as AES-GCM instead of the CBC-mode encryption.
Using RSA-PKCS1 v1.5 within XML Encryption is particularly difficult to do in a secure manner, and it is recommended to use RSA with Optimal Asymmetric Encryption Padding (OAEP) instead [2].
Apply a digital signature over the whole SAML response, and ensure it is properly validated before attempting to decrypt the assertion. This should thwart the attack as a manipulated response can be recognized as such and should be rejected.

----------

[1] https://www.oasis-open.org/standards#samlv2.0
[2] https://www.w3.org/TR/xmlenc-core/
[3] https://www.nds.ruhr-uni-bochum.de/research/publications/breaking-XML-Encryption/
[4] https://www.nds.ruhr-uni-bochum.de/research/publications/breaking-XML-Encryption-pkcs15/
[5] https://link.springer.com/chapter/10.1007%2FBFb0055716
[6] http://www.w3.org/2008/xmlsec/papers/xmlEncCountermeasuresW3C.pdf
[7] https://web-in-security.blogspot.com/2015/05/how-to-attack-xml-encryption-in-ibm.html

More information

RFCrack Release - A Software Defined Radio Attack Tool

RFCrack uses the following hardware with RFCat libraries:

YardStick One:

https://goo.gl/wd88sr

I decided to cleanup my RF testing harness and release it as a tool named RFCrack

Mostly because it has been pain to set up use-case scenarios from scratch for every device I am testing. Rather then release a tool no one knows how to use. The below video will be a quick but comprehensive tutorial to get you started If you've been following the blogs, this will greatly simplify your testing, in the following ways:

RFCrack handles all of your data conversions.
It allows you to capture, replay and save payloads for use anytime
It will handle rolling code bypass attacks on your devices.
You can jam frequencies and fuzz specific values
It will also allow you to scan specific frequencies in discovery mode or incrementally probe them
RFCrack will hopefully have keyless entry & engine bypass support in the near future

This is the first release, everything works as intended but there will be plenty of updates as I continue to do research and find reasons to add features needed for testing. I am still making changes and making it more flexible with modifiable values and restructuring code. If you have any legitimate use case scenarios or need a specific value to be modifiable, hit me up and I will do my best to update between research, if its a legitimate use case.

You can reach me at:
Twitter: @Ficti0n
http://cclabs.io , http://consolecowboys.com

GitHub Code for RFCrack:

https://github.com/cclabsInc/RFCrack

Full RF Hacking Course in Development:

Not all of the attacks in the tool have been covered in the RF hacking blog series and a few more are in research mode, as such, not yet added to the tool but will probably be covered in a full length online class on Hacking with RF which includes all targets and equipment. Send an email to info(at)cclabs.io if your interested.

Walkthrough Training Video:

Until Next time:

Cheers, and enjoy the tool for your personal use testing devices, feedback and bug reports are appreciated. I have another RF blog coming out shortly based on my friends research into hacking garages/gates and creating keyfobs. I will post when its ready.

Networking | Switching And Routing | Tutorial 3 | 2018

Welcome to my 3rd new tutorial of networking (Routing and Switching). In this blog you will able to watch an interesting video about basic device navigation such as changing device (router or switch) name, configuration of login password, configuring a device information, router IP addresses and many more.

What is router?

Router is a network layer device which is the 3rd layer in the OSI model which is used to communicate different networks. It is an intelligent device fixed at the boundary of network that connects to other networks and responsible for end to end delivery of the packet that requires an IP address which is known as the logical address which is the basic identity of the device just like our identity card number or roll number and so on, for the identification of source and destination devices. Router is the gateway of the network having two interfaces such as inbound and the outbound interface through which the traffic comes in from different networks and comes out traffic to the different networks.

What is an IP address?

Internet protocol (IP) address is a numeric label given to each and every device in the network for the identification of the device just like our roll numbers in collages, universities which identity each and every student uniquely everywhere. So same concept here, it is a logical address which is used whenever the device want to communicate outside the network that means to another network.

What is Switch?

Switch is basically layer 2 device, which is used to connect two or more than two devices with each other in the same network. It is an intelligent device which doesn't allow the broadcast. It requires Media access control (MAC) address to communicate within the network. Now let's move to the video for further.