OWASP Broken Authentication Breakdown with Prasad Salvi

Welcome to the Test Guild Security Podcast where we all get together to learn more about security testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome back to another episode of the Test Guild Security Podcast. Today, our in house security expert Prasad Salvi is back with his monthly installment of his breakdown of each security risk from the OWASP Top 10 Web Application Security Risk List. So in this episode Prasad will do a deep dive and breakdown of the second exploit on the OWASP list, Broken Authentication. If you missed his first episode on the first risk injection flaws, check out testguild.coms38. If you missed that episode and you don't know Prasad is a application security Consultant, a certified ethical Hacker and a CISA Certified Professional with a primary focus on providing services across the software development, lifecycle, application security and penetration testing spectrum. He is a part time bug bounty hunter. He's also a Blue Team expert delivering security training courses to developers and testers to make them proficient in application security and develop secure products. Prasad also has worked with major financial institutions to create a culture of security and he's also a pluralsight author that has a bunch of different courses around security as well. You definitely want to check that out. I'll have all his links in the show notes, so you don't want to miss that and you don't want to miss this episode. Check it out.

It's no secret that the number and complexity of applications are growing, but what is alarming is that 90% of security incidents result from exploits against against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fordify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify you could start security applications in a single day, including custom code, open source or commercial components and scale as your needs grow with an on premise as a service or hybrid implementation. Check them out. Head on over to micro focus.com app security.

Hey Prasad, welcome back to the Guild.

Thanks Joe. It's good to be back.

Great to have you. This is part two of our monthly installment of your breakdown of the OWASP top 10. So the second risk I think we're going to really dive into is broken Authentication. Before we get into it, into the nitty gritty like at a high level, what's quickly like the essence of what broken authentication is so we can set the stage for the next questions.

Broken Authentication stands for the session Management part, once I log in in an application, the server responds back with a session id, which is like the heart of my session until I log out. Now, that session ID will prove that I am authenticated and that would be used throughout my session. Now, it is important for every developer to make sure that session management has been implemented correctly, else it might give rise to different attacks like session hijacking, session fixation, session replay, also different password attacks. If you have less secure passwords, if you're storing them as clear text in a database. So everything that is related to authentication, if you don't have multifactor authentication, for example, then your application might be vulnerable to broken authentication.

Very cool. So, you know, like I said, I'm new to security. I just noticed OWASP has like a breakdown of this as well, and they have them in like three main buckets. One is threat agents and attack vectors. So they also give ratings for exploitability. So how, how common or how exploitable is this type of attack?

I would say it is pretty common in a lot of applications. So, for example, if a particular application is vulnerable to an attack called as cross process scripting, which we would be discussing in the later episodes, if your application is vulnerable, then I can write a script and I can trick you in clicking on that script. Once you do that, that particular script will send me the session ID that you're currently logged with, and I can use that session ID to log in as you, for example. So just to give you a layman example, we all book different tickets, maybe movie tickets or flight tickets online. So let's say I am booking a flight ticket on a website and I need to check with my friend who is traveling along with me, whether he's comfortable in the same flight or the same time. So what I do is I probably copy the URL and maybe it's my authenticated URL. I'm searching for a flight, I copy it and I either email or I SMS my friend that particular URL. Now when my friend clicks on that particular link, he directly logs in as Prasad in that application. So unintentionally, my friend has performed a session hijacking because he used my session ID to log in in his computer. This usually happens when you pass your session ID in the URL or in the GET request. That's very common. Usually session timeouts are not set in applications, so even if you keep your application running or idle for a long time, it doesn't log you out. Or to give you another example, if I'm using a Public computer, anywhere outside. And I don't log out, I use the application and I just close the browser. I've not logged out. So this means my session is still active. And let's say after an hour someone sits on that particular machine and opens the same URL and because my session was still valid, that person logs in as me. Now if you can imagine if that application could be my banking application where I have all my money stored, then that would be a big problem. So session expiration is also important as well as preventing your application from executing different scripts.

Absolutely. And I guess because most things of value have a front end that has some sort of session management, I would think that this would be kind of common or one of the first things people would try to exploit because they really have some sort of value of breaking in and doing this type of hack.

I assume exactly the session id. As I said, once I get a session id, it is supposed to be a random unique value per user. When I am implementing session management in my application as a developer, for example, I need to be sure that it is long and random enough so that no one can guess it. For example, if I keep my string, a very long string, or my session ID a long string, and the next user that logs in, he will get probably if my session, the first session ID will end with the 0 may be a very long session ID, but the second session ID that I'm giving to another user, it will end with one and then I'm incrementing the last octate or the last character just by one. So this is very predictable. Attackers can use different tools and guess what would be the next session id. So it is very important that it is unique, it is random and it is long enough. Ideally, OWASP recommends the session ID to be 128 bits, again long and random.

Okay, so when I hear things like brute force attacks is usually referring to a broken authentication because they're using a tool just to try to guess passwords.

Yeah, there's a attack called as credential stuffing attack, wherein let's say there are usernames and password which have been breached in an X application on the Internet. An attacker might post them on a particular website free of cost. Now other attackers or the same attacker, what he can do is take all that usernames and password and try it on different applications. Now I won't try that on X application because probably they have already known about the breach and they have asked their users to change their passwords. But because we are humans I might have the same password on different accounts as well. Like along with X application, I might have it on Y application or my Facebook password, for example. Now that is the reason we say that we shouldn't be having the same password for multiple accounts. Now, in credential stuffing attack, I will take that username and password combination and try to use it in different applications on the Internet and see if I can get into that user's account. Now, brute force would be to take n number of usernames and password from that list and try it on one particular application. Let's say Facebook for instance. I have thousand username and password combination and I just keep on entering that in an automated fashion through different tools in the username and password feed of Facebook. So that would be a brute force attack where I'm trying for different users to get into it.

Perfect. So I guess the next question then is obviously impacts, what are some impacts you think this has? I can think of multiple, but just, you know, why would someone normally do this type of attack?

There can be different reasons, right? So attackers can, they just want to take it down for fun, like script kiddies, or they want to have some ransomware installed or some malware install, or they want to create a backdoor so that they can do some malicious stuff. So I'll probably, if I'm an attacker, I'll try to go for the admin account which has most of the privileges. So there's something called as default passwords. So usually all the default passwords are admin, admin out of box for any server or any router, for instance. And if I'm not changing that, then I'm actually inviting different hackers to try the default passwords and get into without any security. So a good practice would be to change the default passwords that you have. Never keep admin, admin or root, root as a username and password for our admin accounts, change them, have strong passwords, and also implement multi factor authentication.

Great. So you give a few examples already of how you could tell if your application is vulnerable. But are there any other examples of how someone can say, oh my gosh, what can I look for to see if my application actually is vulnerable to this type of attack.

The first one would be to have a prevention for the brute force attack, like after five continuous attempts, maybe you can give a captcha to the user. Or if, let's say I'm using Joe's account with multiple passwords. So after five attempts I will have to lock Joe's account for let's say 30 minutes or 24 hours, depending upon the criticality of that application. Other examples could be I don't have strong passwords set in my application. I allow my users to set a password as their name, for instance, without any case sensitivity that would be inviting the attackers for these type of attacks. Or having a default username and password, as I said earlier. Or I'm having an interesting topic when I have to reset my password now I have forgotten my password. That is, we all see a link which says forgot my password or forgotten password. And that takes me to a security question and answer page. Now these security questions I'll have to set when I'm registering in the application. But most of the security questions are not really secure though we call them as security questions. Because the most common security question that we observe is what is your mother's maiden name? Now that's not something that is very secure and that only I as a person would know in this world. Now, security questions should have certain characteristics. So the first one should be it should be consistent. Second, it should be memorable. So if the users can't remember answers to the security questions, then it defeats the purpose. It should be universal so that it applies to a large audience and the answer shouldn't change over time. For example, what would be your better half's name five years from now? Or your girlfriend's name for instance, that might change after five years or six years. So that something that we have to make sure while developing the forgot password feature. But again, a lot of developers are in a misconception that asking security question is a form of multi factor authentication. It is not because that again falls under the knowledge based questions or something you know. Password is also something you know as well as the answers to a security questions, so then they would still fall under single factor and not multi factor authentication. The last example where I like to say if your application vulnerable is you're not invalidating the session IDs. Now even if I click on logout instead of closing the browser, the request that is sent for that logout click the response should have the session ID as null. That is the best practice. I shouldn't give a new session ID or return back the same session ID to the user once he has logged out, I should be able to invalidate that session ID so that no one can use that session ID again.

Awesome. So besides that, that way, are there other ways to prevent it? I know a lot of times lately I've been asked to do two way authentication or I log in from a different device as a VPN and I get an alert saying you're trying to log in from this other account. Is this you or not? Do you want them to to log in? Are those some ways to prevent it? Or like, as we get more and more into 2020 and beyond, I would think they're like, how? How can we prevent this? Are there newer ways to try to put into place if you're a developer to try to avoid this? And for future applications, the first one.

Would be to have, as I said, multi factor authentication. The second is what you just mentioned, wherein if the user has so there's a JavaScript which you can write to check if the user is logging in from the same machine or the same browser. If the browser and machine change, we can ask if he or she is indeed trying to log in instead of someone else. Those are the two mechanisms. Or we can either increase or decrease the delay in fail login attempt. If I have a very critical application, I can only allow the users to enter three wrong passwords. For some applications I can allow them to have five wrong passwords. But after that I have to make sure I lock that account and send out a notification to the admin or to the security team as well as the user that you know, did you try to log in? If yes, if not, then reset your password. If yes, then you know we'll have to wait for 30 minutes to re log in because you locked your account due to five consecutive login failure attempts. The second important part here, and this is again the tenth, we'll have the tenth episode on this where we'll talk about monitoring, insufficient monitoring. So the same example we'll be talking in the 10th episode that we are going to have and we're going to end the series about monitoring. But I'll definitely talk about this again.

If someone was actually hacked using this type of exploit, would they know? Because if I look in the news for broken authentication hack, a lot of times people say oh, my Twitter account was hacked into when they say something. Companies know when they've been hacked with this type of X player, there's anything that's left behind or because someone's actually using your username and password is it seems almost undetectable unless someone says, oh, someone stole my money, I guess. I don't know.

Absolutely. So it's very difficult to understand if you have been attacked or you have compromised or someone has compromised your session id, for instance. The only solution to this is awareness wherein you're not supposed to click on random links, for example, I get a phishing email which says that your account would be locked. So usually it has a sense of urgency and I might see my account is being locked and I click on that particular link and that's when I might lose my session ID to a particular attacker. So awareness is very important, not clicking on random links. An attacker would only have my session ID when I click on something and invite him to take my session id. If I don't do that, and as a developer again I have to make sure that my session IDs are being invalidated after logout, there is a session expiry time set. There are two things when we log into an application. First is I hit the URL, let's say abc.com so when I type abc.com in my browser, a request is sent to ABC server and then the server replies back saying that okay, you can visit a 200ok response and it also has a session ID along with it. Now that session ID is only for me to reach the login page. Now let's say that session ID is ABCD for example. Now I see the login page, I log in with my correct username and password. Again a second request would be generated that would go to the server. Again the server will check okay is the right username and password. Now when the server responds, the server should make sure that it is a different and a new session ID that it is sending back to the user. Because if it sends back ABCD then it actually defeats the purpose because if I'm the attacker I would know that on the login page it was ABCD and the server still continues that. So I can try to change ABCD through a proxy tool. And let's say I type PQRS for instance and if the server responds back with pqrs it means that the server is not validating the session ID and just accepting any value that the user is providing. And this is called as a session fixation attack wherein I have fixed my session that I would be needing only PQRS as my session id. I don't need any other value from the server. So this is also important while developing a session management wherein you have to make sure that after the user logs in he should get a new session id.

Great. Now I also think that when I think of this I think of like a customer facing ui, like a banking account where you're just trying to add someone's username and password. But do you know as developers use more and more third party applications are there any like backdoor APIs that could be exploited this way as well that people may not think about because it's not so customer facing.

Do you mean about the federated logins that we use instead of the authentication of the application? Like I can log in through Gmail or Google or Facebook for instance?

Well, that's one way. I was thinking maybe someone's using a third party API in their application that also maybe has a way that people can log in, but because it's headless and it's not part of the customer facing type, it could still be exploited. I don't know if that makes any sense.

Absolutely. So again, maybe a backend API or. So there might be different implementation strategies by the developers, but whatever they implement for session management, they have to make sure that the controls or the prevention techniques that we have discussed so far have been implemented.

And so you did bring up a point then. When I go to certain applications, it gives me an option to use my Gmail account or my, my Twitter account. Does that make me more vulnerable to this type of attack? Because I would think that would be a higher risk or a more well known username password to grab. So if someone had my Gmail account, I used it for all my other accounts and I'd be really easy to hack.

I would think there's one way. I mean, you're right in a way. But secondly, if let's say I am that third party application and I'm giving you that option to log in with Gmail, I'm actually transferring that risk from myself to Gmail because I don't have to code for that authentication part. I'm just using the API that I'm getting from Google and Facebook and I'm asking you to get into my application through that API. If tomorrow, if something goes wrong or something is breached in my application, I am free to blame that API that has come from Facebook or Google. So you can't sue me in that case. But I personally don't recommend to use federated logins. If there's an option only to go for Facebook or Gmail and you can't create your own account and I'll probably not use that application in the first place.

A lot of times when we talk about security, it's always from like an attacker's perspective and it's already in the wild and it's being attacked as a developer as we try to shift left these type of activities. Are there anything built into the IDEs nowadays that says, hey, this is a possible broken authentication line of code you just wrote. Do you know if developer tools are this sophisticated yet? Or are there tools that developers can use as their coding to help them? Give me some sort of a telesense to say this may not be the most secure way of doing this type of authentication.

The developers can certainly use Micro Focus Spotify on demand code scanning tool that actually tells you if there is anything missing in your session management code that you have written. So it scans your code and gives you all the details of the vulnerability that is observed related to session management as well.

Awesome. So Prasad, are there any resources people can go to to learn more about broken authentication?

They can certainly go to the owasp.org website. They will also find the attack vectors and the mechanisms that attackers use. And also there is something called as the OWASP Cheat Sheet series which talks about secure coding or how developers can implement good and secure session management. So these two other links which I would definitely recommend the viewers to go.

And see okay Prasad, before we go, is there one piece of actual advice you can give to someone to help them with their broken authentication security testing efforts? And once again, what's the best way to find or contact you?

Yeah, so if they want to test they'll have to make sure to check for session fixation attack that we discussed Session two replay and also session hijacking. If I can get any users session by executing different scripts and if anyone wants to reach out to me they can follow me on Twitter or they can connect with me on LinkedIn and I'll be happy to help.

Thanks again for your security testing awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com S40. And while you're there, make sure to click on the Try Today link under the Exclusive Sponsor section to learn all about Micro Focus Fortify, which is the recognized market leader in application security. And if the show has helped you in any way, why not rate and review it in itunes? Reviews really do matter in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Security Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack security testing awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Security Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.