none
Credentials are passed in clear text - Hacked credentials using Burp tool suite RRS feed

  • Question

  • Hi,

      We have integrated ADFS into one of our SharePoint application for authentication. When the user tried to access the portal, it will be redirected to AD Home page. The user will provide the credentials, and we started Burp tool and this tool retrieved the credentials which is passed through viewstate in clear text format. But when we used the same tool to access bank sites (they may use form based authentication and credentials are encrypted) and tool retrieved the credentials in encrypted form. 

    Does AD support Encrypted option and how we can set the credentials in encrypted mode in AD?


    Balaji R

    Thursday, March 9, 2017 11:57 AM

Answers

  • Well you are assuming that the machine is already compromised. Then even if FBA was doing a local encryption (and assuming that this encryption is asymmetrical) since the attacker owns the machine, it owns everything on it. SO there is no way to prevent the attacker to get the password directly from the memory (or less fancy, by doing a key logger kinda thing).

    And what about shoulder surfing? You will certainly not encourage your external user to log into the system while burying themselves under a blanket :) Well I think you are going on the wrong direction (@others, feel free to chime in if you think otherwise).

    Credentials theft is a serious matter. There are a lot of ways to improve your security posture against credentials theft. Regarding external access, you should opt for Multi Factor Authentication. In that case even if the attacker stole the users' password, it cannot use it on its own without also stealing the cellphone, or token, or the PIN etc... Or even better, as I previously mentioned, you can even not use passwords at all and then there is nothing to steal. That's the case of Certificate Based authentication (out of the box with ADFS) or MFA as a primary factor for authentication (that is available with ADFS 2016 and Azure AD premium).

    If you are using SharePoint Online (or any other workload in Office 365), you can also leverage Azure AD Identity Protection. This will enable you to detect abnormal logins activities and even associate policies to them (like forcing MFA for a user which connect to an unusual place - which could be a sign of compromised credentials being reused somewhere else). Even better, on the top of this, you can use Azure Information protection and you can track where your documents are being read (assuming that the compromised credentials lead to document leak).

    You can also force the machine connecting to ADFS to be registered (with on prem DRS or Azure DRS - in the later, you can also enforce the compliance of the device). So if somebody stole credentials they will have to be used on registered machine only. This sort of thing.

    I think you should opt for the defense in depth approach.

    If you or your customers (if you are a consultant) have a Premier support contract, I would highly encourage you to have a discussion with a Premier Field Engineer. We -PFEs- deal with those questions onsite on a daily basis. Hope this helps!


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Thursday, March 16, 2017 12:53 PM
    Owner

All replies

  • Hiya,

    If your integration between ADFS and SharePoint uses Basic authentication, you have gone through some effort to do so. Out of the box ADFS and SharePoint both uses Windows Authentication. Further each claim is encrypted using the ADFS Server encryption certificate.

    Basically you should never have to use Basic authentication, unless it's legacy applications. And even if your are using basic authentication, you should always use certificates to encrypt the traffic between the two ends.

    Below is are guide on how to configure SharePoint with ADFS.

    https://technet.microsoft.com/en-us/library/hh305235.aspx

    At some point in  your ADFS implementation, someone has forced it to use basic authentication, as default would be either Forms based login or Windows Authentication, neither of which are using the basic authentication protocol. This would apply for any newer version of ADFS(2.0 and newer) and SharePoint(2010 and newer)


    Which version of ADFS are you using?
    Thursday, March 9, 2017 2:20 PM
  • Credentials are passed in clear text? You mean inside the TLS tunnel?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Thursday, March 9, 2017 2:50 PM
    Owner
  • Yes Pierre. We used TLS 1.1 and configured at NetScaler.

    Balaji R

    Thursday, March 9, 2017 3:04 PM
  • Hi Jesper,

      We have used ADFS 2.0 and used SSL certificate. Basic authentication also disabled in IIS. We followed the same url for ADFS configuration.


    Balaji R


    Thursday, March 9, 2017 3:06 PM
  • Form Based Authentication is sending the username and the password in clear text the body of the POST message. However, the HTTP connection is protected with TLS. So the password cannot be read during the transit.

    Now if the workstation used by the client is owned by an attacker, yes they can access what the user typed, like they can have key loggers, decrypt the TLS tunnel with Fiddler, or worst if they have the debug privilege on their machine they could do any kind of credentials theft attacks. Is that what you mean?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Thursday, March 9, 2017 8:11 PM
    Owner
  • Yes Pierre. As I mentioned earlier, we have enabled TLS/SSL etc. but using Burp tool, I can see password in viewstate information. But when I checked with some bank websites, the credentials are encrypted. The only difference is we have used AD default login page and they used custom Form based authentication page. My question is from AD login page for authenticating the user, why credentials are sent in clear text. As you said, may be tool get the form data from the page, but it should be restricted, right. Please correct my understanding.

    Do we have any option from AD login page to encrypt the user credentials before pass to Server.


    Balaji R

    Friday, March 10, 2017 6:01 AM
  • Hi Balaji,

    Sending credentials in clear text within the HTTPs packet is standard practice. Most likely those banks are merely obfuscating the password - not encrypting it in any meaningful way - although there are protocols (such as Kerberos) that do not require the password to be transmitted on the wire, they generally aren't used in HTTPs secured traffic. 

    Consider the fact that any attacker that has successfully built an MITM between you and the ADFS could simply issue you an ADFS login page to enter your credentials into and then collect the password that way.

    That said, there is more that Microsoft could do to ensure that ADFS was secure (implement HSTS for example)

    Good Luck!

    Shane

    Saturday, March 11, 2017 8:54 PM
    Moderator
  • Form based authentication or even HTTP basic authentication are inherently unsecure. They rely on the encryption provided by another layer. Either TLS (so HTTPS in this case) or IPsec (or any other encryption thing at the network level). And even if you secure the transport it still has 2 main problems:

    1. The user is typing its password (so vulnerable to key loggers or to any processes on the client able to read the machine memory).
    2. The endpoint is provided with the password in clear text (so you need to really trust the endpoint not to be compromised and not to do stupid things with the password -not store it somewhere, not to cache it in its memory etc...)

    For these reasons, you should use Windows Integrated Authentication as long as you can (clients ant user-agents have to support it). In the WIA scenario, you do not type nor send the password. They are still few men in the middle attacks which are technically possible (though it means that high value infrastructure component would also be compromised - DNS for example). For this, ADFS uses Channel Binding Token (but again, the client OS and the user-agent have to support it) to ensure end to end security.

    Ultimately, you can also avoid using passwords all together. This is the case of certificate based authentication (out of the box option with ADFS - as long as you have certificates) or Azure MFA as a primary authentication method in ADFS 2016.

    Regarding HSTS it is arguable that it would have additional value for ADFS since all authentication endpoints are exposed solely over HTTPS enabled endpoints. There are unencrypted endpoints available (WID "replication" and non-SNI monitoring endpoints) but those are not providing any security services nor transporting user's session data. Though there are some cases with some DNS spoofing could lead to unsecure situation if the attacker were to redirect the client to a fake ADFS farm for which authentication services would be purposely available without TLS (but again, it is assuming that some infrastructure part of the environment have been compromised, network physical security - case of ARP cache poisoning, or name resolution servers issues - case of DNS cache poisoning or any other attack DNS based including WPAD misconfiguration etc...).

    Regarding encryption at the presentation level, it is impractical since it would imply that we are able to negotiate encryption keys in a secure fashion prior providing authentication - hence with no authentication, or assume pre knowledge of a key with the user agent (hard to achieve though not impossible but then comes the issue of exchange of that key). 


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.



    Sunday, March 12, 2017 9:11 PM
    Owner
  • Do you need more detailed info?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, March 14, 2017 5:52 PM
    Owner
  • Thanks Pierre for your reply. Can we achieve through ADFS 2016. As you mentioned, BURP tool retrieved all  data in the presentation form, can we restrict it through ADFS 2016. If yes, please give some ideas and need some detailed information.

    Balaji R


    Wednesday, March 15, 2017 6:55 AM
  • You can "achieve" that by not using form based auth :)

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, March 15, 2017 8:36 PM
    Owner
  • Yes Pierre. I understand in order to meet our requirement we need to proceed with Windows based authentication. But our requirement is different. We have 2 ADFS, 1 for internal and another for external. For Internal users, as you mentioned, we can go with Windows Credentials, but for external we need to go with ADFS Forms based authentication. As you mentioned, Form based authentication has some security loopholes, and how many organization using ADFS for authentication. If ADFS not encrypted the credentials, then it is very serious issue.  Consider an example for hacking,

    1. If hacker got the user machine, and he tried to access the portal. Suppose, user saved the credential in browser mode. By installing this tool in user machine, he can crack the password right. My question is, why ADFS are not encrypted the Form Data. Even I have enabled ViewStateEncryption = Always in both ADFS and SharePoint end, but Viewstate is not encrypted in presentation layer.

    Please confirm that this is the issue With ADFS design or I am in the wrong direction.


    Balaji R

    Thursday, March 16, 2017 7:14 AM
  • Well you are assuming that the machine is already compromised. Then even if FBA was doing a local encryption (and assuming that this encryption is asymmetrical) since the attacker owns the machine, it owns everything on it. SO there is no way to prevent the attacker to get the password directly from the memory (or less fancy, by doing a key logger kinda thing).

    And what about shoulder surfing? You will certainly not encourage your external user to log into the system while burying themselves under a blanket :) Well I think you are going on the wrong direction (@others, feel free to chime in if you think otherwise).

    Credentials theft is a serious matter. There are a lot of ways to improve your security posture against credentials theft. Regarding external access, you should opt for Multi Factor Authentication. In that case even if the attacker stole the users' password, it cannot use it on its own without also stealing the cellphone, or token, or the PIN etc... Or even better, as I previously mentioned, you can even not use passwords at all and then there is nothing to steal. That's the case of Certificate Based authentication (out of the box with ADFS) or MFA as a primary factor for authentication (that is available with ADFS 2016 and Azure AD premium).

    If you are using SharePoint Online (or any other workload in Office 365), you can also leverage Azure AD Identity Protection. This will enable you to detect abnormal logins activities and even associate policies to them (like forcing MFA for a user which connect to an unusual place - which could be a sign of compromised credentials being reused somewhere else). Even better, on the top of this, you can use Azure Information protection and you can track where your documents are being read (assuming that the compromised credentials lead to document leak).

    You can also force the machine connecting to ADFS to be registered (with on prem DRS or Azure DRS - in the later, you can also enforce the compliance of the device). So if somebody stole credentials they will have to be used on registered machine only. This sort of thing.

    I think you should opt for the defense in depth approach.

    If you or your customers (if you are a consultant) have a Premier support contract, I would highly encourage you to have a discussion with a Premier Field Engineer. We -PFEs- deal with those questions onsite on a daily basis. Hope this helps!


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Thursday, March 16, 2017 12:53 PM
    Owner