Some single sign-on (SSO) systems that use SAML are vulnerable to a newly discovered attack that can allow hackers to authenticate as other users without knowing their passwords.
SSO systems allow users to authenticate to various services using a single account, for example, their Google or Microsoft account, or, inside enterprises, an account issued and maintained by their company. There are three parties in an SSO authentication exchange: the service provider (SP), the user and the identity provider (IdP).
When users want to authenticate to an SP that supports SSO, their browser is redirected to an IdP for authentication. After they authenticate, the IdP returns a digitally signed response written in Security Assertion Markup Language (SAML) to the user’s browser, which then forwards it to the SP as proof of authentication.
The SAML response contains a field called NameID that identifies the authenticated identity and a digital signature. The signature is needed to make sure that the response has not been modified on the client side before it’s sent to the SP.
Researchers from Duo Security, a provider of authentication services for enterprises, have found a way to modify the NameID in a way that doesn’t invalidate the signature of the SAML response. This, in effect, allows attackers who have a valid account with the IdP to swap it in the response and trick the SP into giving them access to a different account.
The attack works because of unexpected XML parsing behavior in various SAML libraries used by SSO implementations, SAML being a specialized language based on XML.
Before it gets signed, XML content is first canonicalized, which means that unnecessary information is stripped from it. The most commonly used XML canonicalization method strips code comments among other things, so adding comments to a SAML response after it’s been signed shouldn’t break its signature.
However, it turns out that when extracting text from an already signed SAML response, some XML parsers will stop if they encounter a comment tag.
Take, for example, a signed SAML response in which the original NameID value has been changed from firstname.lastname@example.org to email@example.com<!—->.evil.com by adding a comment. When checking its signature, the SAML library will first canonicalize the document, so the comment tag will be stripped. The signature will be valid because the content will now contain the original firstname.lastname@example.org.
However, in the next step, when the library attempts to extract the value indicating the account authorized for authentication, it will parse the non-canonicalized content and extract only email@example.com, which comes before the comment tag. The attacker authenticated on the IdP as firstname.lastname@example.org but tricked the SP into authenticating him as email@example.com.
Duo Security worked with US-CERT to notify potentially affected SSO vendors and SAML library maintainers, and some of them have already released fixes including Duo Security itself, Clever, OmniAuth, OneLogin and Shibboleth Consortium.
“The best remediation is to ensure your SAML processing libraries are not affected by this issue,” the company’s researchers said in a blog post. “We identified several SAML libraries that either leveraged these unintuitive XML APIs or did faulty manual text extraction, but I’m sure there are more libraries out there that don’t handle comments in XML nodes well.
“Additionally, if your SAML Service Provider enforces two-factor authentication, that helps a lot because this vulnerability would only allow a bypass of a user’s first factor of authentication,” they added. “Note that if your IdP is responsible for both first factor and second factor authentication, it’s likely that this vulnerability bypasses both!”
Exposed Memcached Servers Hijacked for DDoS Attacks
Attackers are abusing publicly exposed Memcached servers to launch massive distributed denial-of-service (DDoS) attacks by using reflection and amplification techniques.
Memcached is a software package used for implementing high-performance caching servers that store data in RAM. They’re used to speed up database and API queries for large web applications.
Because they store potentially sensitive data, Memcached servers are generally used internally, on private networks. However, last year security researchers from Cisco Talos found more than 80,000 such servers exposed to the internet without authentication.
And according to content delivery network Akamai, hackers have now started to take advantage of those servers to launch very large DDoS attacks. That’s possible because Memcached servers listen for queries on UDP port 11211, and UDP allows for source address spoofing.
An attacker can send a request to a Memcached server that appears to originate from the IP address of his intended victim. The server will then return the requested data to the victim’s IP address, flooding it with unsolicited traffic in what is known as a reflection attack.
Not only that, but the response will typically be much larger in size than the original request that triggered it, so it will have an amplification effect. This gives the attacker the ability to generate more traffic than what his existing bandwidth would otherwise allow.
In an alert issued this week, Akamai warned that it has seen recent Memcached-based DDoS attacks exceeding 190Gbps and other organizations have reported even larger attacks, of 500Gbps.
What’s even worse is that, since most of these servers don’t use authentication, attackers can intentionally place large values in their data stores and then request them.
“It is possible that an attacker could purposely place a 1MB value in the data store, and using a spoofed UDP packet request that single 1MB value hundreds of times per request,” the Akamai researchers said. “This would result in a massive amplification factor where a 203 byte request results in 100MB response of reflected traffic, per request. It doesn’t take much imagination to see how this could be and is being abused, resulting in considerable DDoS attacks.”
Companies that run Memcached servers should make sure that port 11211 is blocked on their edge firewalls, so they cannot be abused. However, a large number of these servers are likely to remain exposed on the internet for a long time so Memcached-reflected DDoS attacks are probably here to stay.