locked
Investigation: ADFS-Benefits (ehr -> enwisen) RRS feed

  • General discussion

  • The trace of second SSO: RP: enwisen.com; IdP: ehr.com

    Benign Scenario   Scenario A   Scenario B   Scenario C


    ================================

    There are two major domain changes in the trace: first, my browser is signed into mymicrosoftbenefits.ehr.com through mymicrosoftbenefits.ehr.com/adfs, then it is signed into erc.enwisen.com through erc.enwisen.com/ASI/Thirdpartylogin.aspx?xml=2, so we are talking about two SSOs in this single case.




    • Edited by Rui Wang ISRC Monday, April 2, 2012 6:17 PM update trace
    • Edited by cs0317 Tuesday, April 3, 2012 7:58 PM
    Wednesday, March 28, 2012 6:35 PM

All replies

  • If you google "ehr.com", you can see a lot of companies are hosting their HR websites in this domain.

    About enwisen.com: here is a link http://www.enwisen.com/aboutus/partners

    Wednesday, March 28, 2012 6:48 PM
  • A very interesting part is XMLData in BRM1. It is the token that we want to steal or forge. It is encoded by urlencode and base64 encode. After decoding, I see it is a XML as follows. I sanitized part of my personal data.

    <Data>
        <Field name="tpuserid" value="MSDevOnly" />
        <Field name="tppassword" value="!ChangeMe1" />
        <Field name="subscribername" value="Microsoft" />
        <Field name="returnpage" value="https://mymicrosoftbenefits.ehr.com/Ess/Home/Logout.aspx" />
        <Field name="userid" value="******" />
        <Field name="lastname" value="WANG" />
        <Field name="firstname" value="RUI" />
        <Field name="sex" value="M" />
        <Field name="addressline1" value="******" />
        <Field name="addressline2" value="******" />
        <Field name="city" value="******" />
        <Field name="state" value="******" />
        <Field name="zipcode" value="******" />
        <Field name="country" value="US" />
        <Field name="hrstatus" value="******" />
        <Field name="employeetype" value="******" />
        <Field name="division" value="******" />
        <Field name="email" value="******@MICROSOFT.COM" />
        <Field name="location" value="******" />
        <Field name="jobtitle" value="******" />
        <Field name="rulestring" value="****** It is a long string ******" />
        <Field name="election" value="******" />
        <Field name="classification" value="EMP" />
        <Field name="employeenumber" value="******" />
        <Field name="custom1" value="ADFS" />
        <Field name="custom2" value="WA" />
        <Field name="ts" value="2012-03-28 16:47:52" />
        <Field name="key" value="****** a random token ******" />
    </Data>

    The data is the value sent from IdP to the RP.

    The only secret in the data is the field "key". We need to understand more on it.


    Rui Wang



    Wednesday, March 28, 2012 8:31 PM
  • note: decode XMLData by a URL decoder, then decode again by a base64 decoder.
    Thursday, March 29, 2012 12:44 AM
  • Suppose you have authenticated into enwisen recently, but click the "benefits" item on the drop-down list again, you will see the following two requests. The first is to GET http://mymicrosoftbenefits.ehr.com/adfs/. The second is to GET https://mymicrosoftbenefits.ehr.com/adfs/ (notice that the first request is http, while the second is https). Both requests contains cookie MSFTESSAuthenticationId.

    If MSFTESSAuthenticationId is security sensitive, then the whole sso scheme is vulnerable to a network attacker.


    • Edited by cs0317 Thursday, March 29, 2012 5:23 AM
    Thursday, March 29, 2012 5:10 AM
  • MSFTESSAuthenticationId is not an important cookie. forget about it.

    the important ones are _WebSsOAuth and _WebSsOAuth0.

    An observation which I don't know whether it is valuable: the above two cookies are appended on a request to https://mymicrosoftbenefits.ehr.com/adfs, and a request to http://mymicrosoftbenefits.ehr.com/adfsAnyStringYouLink, but they are not appended to https://mymicrosoftbenefits.ehr.com/nonadfsPrefixString

    Friday, March 30, 2012 5:02 AM
  • Assuming a network attacker, he should be able to read the cookie. Because he can inject script to http traffic of ehr.com, then read the cookie for https. David told me there are ways to do that (e.g., use Flash to read).

    Rui Wang

    Friday, March 30, 2012 5:18 PM
  • Both _WebSsOAuth and _WebSsOAuth0 are base64 encoded. By decoding them, I see binaries. They may not be encrypted, meaning that we may be able to fake them.

    Rui Wang

    Friday, March 30, 2012 5:32 PM
  • if you only see binaries, how do you know they are based64 encoded? Do these binaries look meaningful to you?
    Friday, March 30, 2012 5:58 PM
  • _WebSsOAuth and _WebSsOAuth0 are secure cookies, only attached to https requests.
    Friday, March 30, 2012 5:59 PM
  • if you only see binaries, how do you know they are based64 encoded? Do these binaries look meaningful to you?

    I tried use base64 to decode, and succeeded. Typically, when it is not base64 encoded, the decoding will fail. The binaries are not meaningful to me. But I guess they have structures.

    Rui Wang

    Friday, March 30, 2012 6:46 PM
  • From IdP to RP: wresult is XML data. First url decode it, then use http://www.shell-tools.net/index.php?op=xml_format to format the data. There are three pieces of data:

    1) <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">********@microsoft.com</saml:NameIdentifier>

    2) <ds:SignatureValue>QjDl56UKg6ao2******qjWjn3J6ow+6ZEHO4EU+T2alxypFZOF7GYI6rpRnixTGrOJ4+R4+nsknHVgrmQEfcNAIOnDOayxE7KcmJ4pkJPBorT5ttNrUiMoINk65s944N5sn1z8SvZlbW6kiQCuEIieYINWoinEzbBksAu1Pevmj7gl0DLvKhPJ8DaRPEvgf7vhS8CJ2RYBzdF0waDDXJ9BT+9tDxCYqlK2cvtljKxwPhmqSOpidmOin1G+foRKOZKhOIyjN7w5MSXFMey/a7qbfjKNMeB7XmZLx5lu6oHT1Cam1h4mtjUNSAcdE1igsmqaE8ARZkmw5JpW8NA5c3iaKA==

    </ds:SignatureValue>

    3) <X509Data>  <X509Certificate>MIIGpjCC********JzH0agAIAAG03DANBgkqhkiG9w0BAQUFADCBizETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIGCgmSJomT8ixkARkWBGNvcnAxFzAVBgoJkiaJk/IsZAEZFgdyZWRtb25kMSowKAYDVQQDEyFNaWNyb3NvZnQgU2VjdXJlIFNlcnZlciBBdXRob3JpdHkwHhcNMTAwOTIxMjIxMDU5WhcNMTIwOTIwMjIxMDU5WjBwMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDENMAsGA1UECxMETVNJVDEfMB0GA1UEAxMWY29ycC5zdHMubWljcm9zb2Z0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7pxTsEBxuYFMdB6jKWnYgfI1xHBQxyybSD29ddjtcEqdoPBBJhSvM8IDduMDwtlmCY38UGD/f6KXEJ/TmNQWosG6YUGFmvgclrXhWw3vmoiQdH/IV0b0SuxdpxhLdjnPyS5b7UHyAa61M33tH7VApKV8PQdQCLoO/4ioXcrlXCrYv9nmocBlVGBB9+dZXZmyqqmcO1zlbSPgLnrtzC2o677ycQQe9P1DF9JGO7/nk/YfWvA9CFBCJ3lfvCR/pw5NCI9RCwkyoeYHRbd5NpInZfV9SbVfrmhRRAGfC5tjJe5oo8E2CQvqtJB0qcSPIGMuUrvpuR7DZHuH+C2ozYA0sCAwEAAaOCAyQwggMgMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEweAYJKoZIhvcNAQkPBGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUZTAgq654oEU9cKKaz2Q7UGJQnRMwHwYDVR0jBBgwFoAUCELj204RZvO1CMVA21V8M0YRgzgwggEKBgNVHR8EggEBMIH+MIH7oIH4oIH1hlhodHRwOi8vbXNjcmwubWljcm9zb2Z0LmNvbS9wa2kvbXNjb3JwL2NybC9NaWNyb3NvZnQlMjBTZWN1cmUlMjBTZXJ2ZXIlMjBBdXRob3JpdHkoOCkuY3JshlZodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9jcmwvTWljcm9zb2Z0JTIwU2VjdXJlJTIwU2VydmVyJTIwQXV0aG9yaXR5KDgpLmNybIZBaHR0cDovL2NvcnBwa2kvY3JsL01pY3Jvc29mdCUyMFNlY3VyZSUyMFNlcnZlciUyMEF1dGhvcml0eSg4KS5jcmwwgb8GCCsGAQUFBwEBBIGyMIGvMF4GCCsGAQUFBzAChlJodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9NaWNyb3NvZnQlMjBTZWN1cmUlMjBTZXJ2ZXIlMjBBdXRob3JpdHkoOCkuY3J0ME0GCCsGAQUFBzAChkFodHRwOi8vY29ycHBraS9haWEvTWljcm9zb2Z0JTIwU2VjdXJlJTIwU2VydmVyJTIwQXV0aG9yaXR5KDgpLmNydDA/BgkrBgEEAYI3FQcEMjAwBigrBgEEAYI3FQiDz4lNrfIChaGfDIL6yn2B4ft0gU+Dwu2FCI6p0oVjAgFkAgEKMCcGCSsGAQQBgjcVCgQaMBgwCgYIKwYBBQUHAwIwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQEFBQADggEBAJy4a48I4KjxGIRBw7cRQeiWZfY7l9tA+DSRwxkChqZVz3/8lcHpTXubysXPnVkOG8WpKZ5eX/hCYltNWGKq0ab45Pqxpez8mhGjjelkUq6qfX9W5oKMc+ohVdq4jNPbLuWF503hTcmfTrGLJTMz6e7WWScxQcyIrMwceoK9p4VSdO9kURgMqHeXaGeI401Twl6VEQz/VXZ1ct2i92nxBB2yq9NFF0dV7Ik74ZEIaVvqim2jlKdStqjTqmxKEdcfXlLmcLib14R0SGNAiP9MFec3as1PemFZG4dwzKQMS8A5nvaBj8h0lgczWekMsPS8WdLTAlT8UQQp7TV1tssqaww=</X509Certificate>
    </X509Data>

    First piece is the user ID, which is email address. Second piece is the signature, and 3rd piece should be IdP's certificate.


    Rui Wang


    Sunday, April 1, 2012 3:07 AM