Penetration Testing of Identity, Authentication & Authorization 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 to another episode of the Test Guild Security Podcast. Today we'll be talking with Prasad Salvi all about his pluralsight cost penetration testing of identity authentication and authorization mechanisms. Prasad is an application security consultant, a certified ethical hacker and a CISA Certified Professional with a primary focus on providing providing services across the secure development, lifecycle, application security and penetration testing spectrum. He's a part time bug bounty hunter and he's a blue team expert, delivering security training courses to developers and testers to make them proficient in application security and develop secure products. He has worked with major financial institutes and vouched to create a culture of security. He really knows his stuff. And extra bonus, at the time of this recording, pluralsight is offering free training or free access to all their courses for April. So you definitely want to check out its cost. You don't want to miss it. 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 defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution and 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 to the Guild.

Hi Joe, thank you for inviting me.

Great to have you. I'm really excited about your course because it touches on things I normally don't hear about. So I guess before we get into it, is there anything I missed in the intro that you'd like to share a little bit more about yourself?

No. You almost covered everything out there. It's just that I love application security. I've been in this domain for the past 10 years. It's my passion pen testing and I just want to grow in this. That's it.

So why are you so passionate about it? Because you really are seem really hardcore into it.

The thing that inspires me in this that I can help organizations fix their code vulnerabilities before an Excel hacker does it. I don't want organizations to get hacked tomorrow and then face reputation or financial loss As I spend most of my career into financial organization, I understand how important it is for them as a part of a reputation damage. But that's why I just want to help people, help the community from the bad guys, save them from hackers.

Nice. So is that one of the reasons why you created this course? I know it takes a lot of effort to create a video course. So why did you choose to do a course on this particular topic?

Well, when pluralsight got in touch with me to create content for them, this was one course which was not made or not created by any other authors. And I feel that this is the basic or the basis of any application which is identity authentication authorization. If your basics are not good or not secure, then there's a high probability that the hackers would try to attack you. So that made me instantly think about this course to spread the knowledge and also for budding white hat hackers who want to learn and again, similar to me, save organizations, they can go through this course and understand why it is important to secure identity authentication and authorization and at the same time how you can hack it so that you can get back to the organization with the vulnerabilities.

Great. Now I want to dive into all three of those areas. Identity management, authentication and authorization. But first, you had a really nice section on access controls and this podcast is more towards the beginning. So how would you explain access control?

Alright, so this is what I've done in my course as well. I like to give an example for access controls, Identity authentication and authorization fall under access controls. So access control as a name suggests, a layman term would be that who can access my data. Or let's consider an example, if I walk into a building in an organization, or there's a security guard at the reception, I just go and say that hey, I'm Prasad. So that is what I'm claiming, my identity. I'm just telling him that I'm Prasad. But probably the security guard doesn't know me because I'm not that famous. And he only allows people inside who have an active badge or an access card of the organization. So when I show him my access card, that would be proving, so I'm proving myself that I'm Prasad by showing something which resembles me. Probably in this case access card, or probably when you go on the airport you can show passports. Now, once he lets me in the organization or in the building, there might be some restricted areas in the organization which I'm not supposed to access, probably the server room or the UPS room. So that is called as authorization, which means that where I'm authorized to go inside the building using my access card or using my authentication. So identification or identity is claiming a user, authentication is proving yourself and authorization would come after authentication wherein what all things I can access in the website or in the organization and stuff like this.

Great. Now you also mentioned in the beginning of your course that you're focusing on these topics because a lot of times you said the penetration testers tend to sometimes focus on more high level, maybe I don't know if you said this word, superficial type activities. So is there a reason why access controls maybe is something that people may overlook in their security testing plan?

Yes. So the reason why I have mentioned that in the overview is because a lot of pen testers which I have seen only focus on the OWASP top 10 which are like cross scripting or SQL injection. So they focus heavily on those. So they don't go for the low hanging fruits probably I would say. Or they just want. So anyone who is new into the pen testing domain feels that if he finds a cross scripting vulnerability he's like the best hacker in the world. But that is not the case. There are a lot of different things which you can do in an application and everything, anything starts with identity and authentication. So that's why I've mentioned that not a lot of people focus on these three components in an application or while performing security testing. But then they go more for superficial or you know, the jargon that we hear across the scripting, ssrf, CSRF and stuff like that. But yeah, a lot of things in these three domains which you can actually explore and you would get a vulnerability in that.

Nice. I'd like to jump into each of these areas. So the first one is identity management. Maybe we could talk a little about, you know, what is it, what's some exploits. So what is identity management?

Identity management I would say is assigning a role to a user. For example, if I part of the identity and authentication mechanism team and I get a user or a manager comes up to me and says that hey, a new user, let's say Joe is joining my organization or my team and I want you to create his credentials or his user in the system. So he would be providing me with the form. Let's say Joe would be from the development team. So he would be having access to this development server. He doesn't need access to a production server, but he can go to the QA and stuff like that. So he would give me an access control metrics that we Call that what all things Joe would be needed access to and where he shouldn't get access. When I get this form, I would go through that form, I would need an approval for that. And then I will go ahead and create the user which is Joe. And once Joe joins the organization, he would have everything ready on day one so that he can start working. So that would be identity management.

Great. I think you also brought up difference between identity management and access management. Sometimes people confuse the two. Is that, is that common?

Yes. As I mentioned in the example there's a thin line between identity authentication and authorization. So similarly, identity management would be only creation of the roles and access management would be providing access. So if you take the same access control metrics that I said, the manager gave me the username Joe. So I would say that would be identity management. And when I assign him a particular server to access, that would be access management. So it's a thin line.

Nice. So for identity management specifically, are there any common exploits or attacks you people could perform?

Yes. So the first and the most common attack I would say, or where people can dive in straight away is the guessable accounts. Like a lot of times out of box. A lot of servers have this common username and password which is admin admin. And if your server team is probably lazy in not securing or hardening your server, then there's a possibility that admin admin is still valid. And probably that would be a guessable user because that's very common. So you can go for that. If that's not the case, then you can go for root. Root. This is one of the case where you can try to see if identity management is penetrative.

Do you know how common that still is? People leaving the default admin admin is that, you know, in your normal experience, is that a common thing that people still to this day forget about changing?

Yes. So I haven't seen this in financial organizations, to be honest, but a lot of websites on the Internet today, or probably routers that people use at their home, WI FI routers, they still use the default out of box usernames and passwords.

So what I really liked about this course as well is I learned about some new tools. I love test sites. So people always ask me, do you have a site I can use to help test? Actually in this course you have one. It was a banking website. Can you just tell me a little bit more about. Is that like an OWASP project that you were using?

Yes. So I was using a banking application called AS Altoro Mutual, which has been developed by owasp, is maintained by OWASP for especially for hacking purposes. And it has a lot of vulnerabilities in there, probably whichever you can think of. So anyone who wants to learn ethical hacking or they want to find vulnerabilities in an ethical way, this is the website, which is good because it gives you a real sense of how a banking application would be and why it is important to find vulnerabilities and fix them nice.

And to run some of these exploits, you're using a tool called Burp Suite. So for the folks that don't know what is Burp Suite and is that your go to tool normally for this type of thing or is this more for the course? It was easy to demonstrate things using this particular tool.

So Burp Suite is a proxy tool, probably one of the best tools in the market for security testing. So what Burp Suite does is it turns your machine into a proxy server. So ideally what it means that all the traffic flowing through my machine would first go to Burp and then it will go out to the Internet. So a lot of websites or a lot of developers focus heavily on the client side control. So when I say client side control, it means the browser controls. For example, if you want to enter a phone number and you enter a character there and there you see a red line and it says that enter the correct characters or numbers. That means that client set controls have been implemented. But if you want to bypass this client set controls, probably you can enter a number in there, submit that form, but that form would then be sent to Burp Suite because that's your proxy server. You can edit your request there and probably change that phone number to a character and then send it ahead to the server. Now, once the server receives this request, if there are no server side controls implemented, the server would reply back with your phone number as a character. Let's say ABC for example, and not 1, 2, 3, 4. So basically, burp Suite is used to test for your server side controls while bypassing the client side controls.

Are you familiar with Fiddler and is it similar to Fiddler type of functionality it has?

Yes, it's similar, just that it's a different company and a different product.

What's great about this tool, I think, is people that are not familiar with security is they may be surprised by the amount of information being passed back and forth that actually can be seen with a tool like this that you may not think of when you're developing maybe a front end, in my experience. So I guess. Do these type of tools help you actually find exploits like cleartext to see if someone's passing real passwords without encrypting it?

No. So when I say that I'm running Burp suite on my own machine, as I said, all the traffic flowing through my machine would be sent to Burp because I run BURP on my local machine, which is on my local host, like 127001, which means that all the traffic going through my machine will first end up in burp, which also means that if I'm trying to access HTTPs website or SSL website, I would still see that traffic in clear text, but only on my machine. Now if you take a real life example where probably Joe is accessing SSL website and Prasad is having Burp on his machine, even if I'm able to capture the traffic or have a man in the middle attack because it's on ssl, the site that you're accessing, I would only see encrypted data. I won't be able to see any clear text data unless you're accessing any HTTP website. But on my own machine I see everything because I'm running it on the local host.

Very cool. So that was the first section you went over. The next one was authentication mechanisms. So once again, what is authentication mechanisms?

Authentication mechanisms are how your credentials have been given to the users. How are the passwords? Are they strong passwords? Have you implemented SSL so that your username and password isn't traveling in clear text across the Internet or across the network? And especially the password. If you have a strong password policy, which when I say strong, means that you have sufficient amount of length given for a strong password, you allow at least one capital character, uppercase, lowercase, special characters, and also numbers. So alphanumeric. And ideally I would say a strong password should be probably more than 20 to 32 characters.

Awesome. So for this particular layer, then, what are some common attacks you normally see?

SQL injection also falls under authentication mechanism if you're doing it on the login page. So if your website's login page is vulnerable to SQL injection, can actually bypass the authentication mechanism and actually get in using SQL injection even if you don't know the password or the username. Secondly, you can test for, probably for the password, how strong the passwords are. Probably you can log into the application, try to change your password, give your password as abcd, or if it says that it's too short, probably you can give a password as the word password, which is a dictionary word. And if it accepts it without any lowercase, uppercase, or alphanumeric characters, then it means that it's actually lacking a strong password policy in the application, and you can raise that too. Other thing would be checking the browser cache. For example, even if I say that my website is on ssl, my username and password are encrypted. But if my server doesn't send back the appropriate cache control directives, which is no cache, no store, the browser actually stores everything in clear text in the volatile section, which means that if I close the browser, I cannot see it again when I reopen. But if I have my browser open and the server responds back without any directives, if I go to the cached pages of my browser, I could actually see the request and response in clear text in the browser. So that's one of the important things that probably we could check in authentication mechanisms.

Awesome. And now the last section was authorization. So what's authorization?

Authorization in terms of a website or an application would be what all things I can access. For example, if I'm an admin user, I'm able to add users, delete users, create users. But if I'm just a normal user of the application or a consumer, I can just log in and do the things that I'm supposed to do. A lot of times we see that the admin URL of an application would be probably example.comadminhome.jsp. but when a normal user logs in, he would probably see example.comhomejsp. so what we can try while performing security testing is to change the URL. Try to see if you can just put a slash admin in there and see if you can access admin speech, which means that a user has elevated his privileges and tried to access an admin user's page. So if he's able to see that, then we can say that the authorization mechanism is not correctly implemented or it can be bypassed. And the second test case which we can try in here would be directory traversal attack, which usually also called as the dot dot slash attack. So ideally when I say my application is hosted on a server, it means that I have a machine wherein in a particular folder I have given all my source code and my JSP files or my.netC sharp ASP files, and I'm giving a URL or a path for my users to access on that server. So if the access controls are not properly configured or the authorization for the user is not properly configured, the users can actually traverse to different directories on that Server. So in the similar way if I enter let's say slash admin probably etc password if it is not currently configured, I could actually see all the passwords on my screen on the browser.

Great. So out of the three areas, is there one that's more vulnerable than the others or one that's easier to hack than the other three? Are they all similar? And you never know I guess.

No. I would say as we talk about identity authentication and authorization, identity would be the easiest to find out because a lot of times you don't need to log into a website. If I want to test one of the test cases in identity would be testing the user registration process, how stringent it is, what all details it is asking from a user, what will permission it is asking from a user. So for that I don't actually need access to the website. So that would probably be the easiest of low hanging fruit for authentication. If you know by authentication bypass. If a lot of security controls already implemented, that becomes tougher to find it out. And after you log in you go to the authorization section or even if you don't log in, try to direct to traversal. But if they have this web application firewalls or a lot of security was in place, that becomes more tough and you need advanced knowledge about having some payloads in there. So as you move from identity to authentication and to authorization, the actual level of difficulty increases.

Great. Now I know you have a limited time to create a course you can't do to an affinity. Is there anything you wish you added to your course that that's not covered that you think also people should be aware of?

I have actually included most of the things. It's just that I haven't given a lot of demos I have but I would say that a lot of things could be implemented. But I had to make a one hour course so I had to shrink a lot of demos for authorization. We can have some other experts as well, which I haven't done. So this is an intermediate course. So I had a defined proposal from pluralsight which I had given and these were the only things which were expected for this course. But for that once level I'll have to create another course which I'm already working on.

Oh, nice. So do you ever get questions by people that viewed your course that want to clarify on something or more info like common questions you might be getting asked about this.

So far the reviews have been good. The people have said that the way I have explained things with the help of examples and the demos have really helped them so they don't really come up with questions. The only question that I get is when I'm coming up with my next course.

So what's your next course going to be on?

My next course is going to be client side testing, which is again browser side testing like Dom based access attack, JavaScript injections, HTML injections and other injections on the browser. So what are the things that you can do on the client side without reaching to the server?

All right, cool. All right. Okay Prasad, before we go, is there one piece of actual advice you can give someone to help them with their security testing efforts and what's the best way to find or contact you?

They can reach out to me on Twitter, my handle is here at Prasad Salvi. Or they can send me an email on my owasp email id which is prasad salviwasp.org and Prasad, you have a.

Lot of experience in security testing in general, so do you have any like one piece of actual advice you can give someone to help them with their security testing efforts that they could put into place right away?

Well, I would say read the basics. Don't go for the jargons or the advanced attacks. Unless you find something basic vulnerability, you won't get motivated to find the next piece. So if you are able to bypass the authentication then you will focus on going for authorization. If you go for authorization then probably will be focusing more on finding cross scripting or SQL injection or the attacks. So stick to the basics, keep reading, do a lot of hands on. Yeah, that was it.

Have thank you Prasad for security testing awesomeness for at least everything of value we covered in this episode. Head on over to testguild.com S1E 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. So that's it for this episode of the Test Guild Security Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack 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.