Breaking and Fixing .NET Web Apps

[Music] check all right so i hope everybody can hear me and uh you can see my screen as well right

okay so let's start um so what this talk is about is it's a uh it's basically uh about the most common vulnerabilities uh that are usually identified in today's penetration testing while uh testing.net applications and and why why certain bugs uh occur and why do and how how do we fix them so fair disclosure to before before we get into the talk i was not a full-time programmer i have not done programming before uh actually i got into this thing after conducting a lot of penetration tests on on the web applications and then and just to try to make sense uh why developer do certain things and and why uh xyz issue occurred during during as uh in a specific

application well just to figure out what's uh what's the developer was thinking while developing the application and uh what might he have done wrong to cause such issues so a little bit about me um i'm a penetration testing consultant i've uh i'm working uh as a private uh contractor right now and and i've been working for financial organizations uh government organizations oil and gas sectors and whatnot so that's pretty much it about me and i've been into pen testing for like past five years or so and recently i got into this thing uh like to understand to get a better understanding of why bugs occur in the application so i decided to write a few set of vulnerable codes myself to in

order to understand uh why these things happen

so this talk uh is going to cover a lot of issues that that i personally experience you do during uh pen test and how how we can fix them we will be looking uh into a code a lot of times and then we'll be spending a lot of time in and looking into codes and then seeing what one line change can can do so let's get into it all right so the most common uh issues that uh are identified usually uh when testing a dotnet application is like um it's 2020 but still i i've seen a lot of applications that are not using secure channel they they are still deployed uh uh over http and then and they are

still communicating over http so pretty basic stuff but yes it's 20 20 and we are still seeing clear tax issues in production applications as well all right the next one is authentication and session management uh the other issues is the identify a lot as access control issues or or broken access control or you can secure object references things like these so this is one of the most common issue found in dotnet application a lot of uh input validation issues uh uh for example x sql xml injections crosstalk scripting these serializations uh sometimes command injections as well template injections uh another most common category of issues that are identified while testing.net application is is the file upload csrf

is like is not not that common nowadays but it's still it's quite prevalent open redirect yeah it is still there in a lot of dotnet applications misconfigurations and information disclosures okay all right so this is uh basically related to like informative headers uh enabled and then how easy yeah we will get into it and and see how easy it is to fix those minor issues as well all right so i will just quickly uh go through the insecure communication channel and uh basically what it does is your application is deployed on a server but the server is not configured uh to use uh secure transportation medium for example a tls certificate is not deployed and

your application is running over http protocol instead of suvps so this is one of the issue that's most common that's still identified on a lot of production applications so uh here is the sample screenshot i just took it uh from the internet uh what can go wrong here if anybody is sniffing over the network he can that that attacker can see your credentials what is being transmitted uh from the client side to the server and then he can even manipulate the communication between between the client and server as well next up all right this is this is uh this is where the good stuff will start and the furnace stuff will start and this is

where we actually look into the code code level implementation well what can uh go wrong at the core level implementations authentication and session management all right the most uh most common issues uh while we identify uh we identified you during the pentester is uh related to this session id management or or logout management things for example when you try to log into an application what happens in the background is you provide your credential and a server process it and it checks if the user credentials are valid and then it sends you back to some other page and and set sets a cookie in your browser so the next time you try to access any any of the page of that application

uh you provide the browser provides that cookie as well so uh server can identify that the user is already authenticated and does not need to provide uh the credentials again so as we can see here the first step was uh the user logging into the application the server redirects the the user and sets a cookie and then a user visits another page where he can see his profile information and server sends back this is this is the usual behavior and here is the attacking scenario when the user logs out server fails to invalidate uh the cookie but redirects the user to login page so the user tries to access the page again and and he can access the information

or view the information again because a server or or the programmer forgot to invalidate those cookies excuse me sorry so the programmer basically forgot to invalidate those cookies that were set at the time of login and since those cookies were valid server would gladly process all the requests from the users even when the user clicked on the logout button or logout function and will gladly provide all the information to user uh regardless if the user is authenticated or not because of this issue so we will quickly look into dummy code what it looks like and how how we can fix it so here we have a code code base or or a dummy code basically what it is doing is if we can

see this is a function or action you can see uh it's it's uh basically checking uh it's basically used for viewing your profile information all right and it checks for for different parameters where it's it's a processing email id as from the user as input and sending the response back to the users but the problem here is at the log out button we only use session.clear uh which will not invalidate and log on the user sessions even after log out properly

so in order to fix it we have to remove the cookies and and set a blank cookie and then destroy the cookies and make sure that cookies are destroyed before before login in when the user is trying to log in uh make sure that user does not have any previously stored cookies or we have to clear it manually and and at the log out instant we also have to make sure the same

so this is the actual page sorry i have to like go back and forth in order to explain this example this is this is the controller view and this is uh this is the this is actual user view so this page is not checking the if the session is valid or not and because of that a user is able to access this page which he was not supposed to access before before logging in so a simple check if a simple check that if the session is valid or not we can uh based on that we we can decide if the session is valid we can redirect the user or if they say or if the session is

invalid we can redirect the user to provide its credentials again so he can access this page so just by skipping a check here uh we introduce our vulnerability that that can lead to information disclosure notice here we are not checking the session as highlighted in the red box this could be this could have been mitigated if we if the developers uh check the user session is valid or not so let's say the user uh the request got processed and it hits this control this function in the controller so here we have another issue which we will discuss later on but combining those two issues uh this provides a very safer vulnerability you can access and

retrieve information of users without providing any login without knowing any valid login credentials if at the end of the talk if we get if we have enough time we will get get into the demos as well so how do we fix this uh the fix is uh quite simple and what we have to do is to make sure that the pages are well protected and and the pages uh should check if the user session is valid or not uh in this case how i mitigated this issue i was i implemented a simple check uh or based on the email ids because uh if i was restoring email id in in the session variable and and if i i checked if the session

variable contains email id or not if the session email if the session does not contain email id that means the session is invalid or the session is blank so it will redirect the user to login at the at the time of login i was saving email id in the session variable so this way it can be mitigated similarly if we can see on line number 120 a simple check on session variable since we are saving the session variable at the at the time of login a simple check if the session contains email id or not could have mitigated this issue all right uh broken access control all right so this is uh more uh this is

this uh class of issues often called insecure object reference sometimes it is referred to as broken access control sometimes we call it elevation of privileges because there are multiple names for this class of bug depending uh upon the the situation if if the use if if the user one let's say it could it could be called elevation of privilege if not uh user can access or modify uh information of a privileged user in the web application in that case it is usually called elevation of privilege uh uh i mean horizontal uh elevation of privilege uh sorry it's vertical um uh elevation of privilege if uh a user can change or view or modify information of

of the same role i mean let's say there are two users who have like same rights but a user one can modify or view information of user 2 this is usually considered as a horizontal elevation of privilege this can be mitigated by implementing uh but just by implementing a proper access control the code example or the dummy code we are going to look into is quite similar to the previous one so just before we go into into the code here is an example an illustration so let's say a user tries to access following your example.com index.esp question mark id is equal to one and and the server responds right with a welcome exercise user xyz and then any when the same user

or that hacker tries to manipulate the id value uh the server responds back with a different value and then and shows that the information about different user so this is this is a very trivial example or simple example for for a broken access control um i hope uh everything uh is fine because uh the screen is flickering at my end so i i just thought i should check if there is an issue with the viewers as well or not

let me check quickly

right right so again back uh back into the code this is this code is very similar in fact it's a copy of the previous code and we are looking at the same example here this function is basically checking email id and based on that it will return profile information and then a user could view his profile information if he provides his email id what's the problem here the problem is there was no check implemented by the developer and that makes sure that the user is providing his own email id or or if he is providing someone else email id that there was no check at all so what will happen is let's let's say that there is

it is a user user uh user one at three example.com if he wants to view uh his information he would type in user one at the example.com and this would uh flow through this function or action and it will written the results for user one but if the user one tries to pass user two at three example.com the function would gladly return all the information about user two as well why because there is no check implemented there were uh to make sure that user one is actually requesting his information or user one is trying to view someone else's information so in this case we can simply check we can simply implement a small check by again by

tagging email id for example let's say i marked email id as a primary key and i saved it uh in the session variable so i can use that same email id to check if that use if the user is trying to view his own data or someone else's data so when the user submits the request he will also submit his cookie which will be uh matched against the session session id so uh the server will check what value is there in in that specific session id and what value or what email id user has provided to check so this way you can the developer can check if the user is trying to view his own id

uh his own details or if he's trying to uh view the details of some other user all right okay i missed a few things about broken access control what what could be the implication in this case all right uh depending upon the implementation and uh and and depending upon the implementation uh the impact could could vary and let's say if if if the uh if this this is a view only it is it still can leak a lot of information uh about the users let's say uh the user could just manipulate or temper the parameter ids to view details of all users stored in the applications database it could get even worse if if if

if such kind of access control is missing while updating user information this this way an unauthorized user can update data of an another user of the same application which is sadly quite common [Music] in in applications today

all right good old sql injection uh i think i really don't need to like dive into uh what is sql injection and what could go wrong here uh what can be done with sql injections or but i would still reiterate a few things about sql injection so why does it happen in the first place uh it's usually because uh of uh the lack of input sanitization input validation and an untrusted user input becomes part of developers sql query which can which an attacker can exploit to modify the data or retrieve the application data or sometimes if the database is misconfigured or is running under a higher privileged user this can also result in a complete compromise of the application

server as well how it can be avoided it can be avoided in multiple ways and like we can use input validation we can use parameterized queries and we can use the source procedures but uh again those all have their own constraints while implementing so i'm just going to demonstrate a very trivial example where an inline theory was used and how it can be mitigated by using a parameterized query

okay so here's uh here's an example code uh basically it's it's processing a user input and as you can see on line number 56 there is no uh input validity performed on the id uh parameter value and this way tracker can terminate the developer theory and append his own query to extract data or modify the data whatever he wants to do so in order to mitigate this issue we can use prepared statements here's a simple example i'm sorry just hold on for a minute

i'm really sorry guys that's that's my

knees

all right so we were on sql injection so this way if if the developer used a parameter security he could have prevented again if we at the end of the talk if we get enough time we will get into the demonstration as well

template injection all right this is this is an interesting topic and what happens is uh nowadays we are used a lot of web applications are using templates template engines for for for a lot of uh data processing ah let me just give me

hello

all right sorry uh that was my knees again she just got up so you know the kids so we were discussing template injection all right so this this happens because uh an interested user input gets passed to the template engine and depending on the template engine there is there are a lot of possibilities and it can result in server side code execution and in some in some cases client-side code executions as well so how it can be avoided again it can be avoided by implementing some sort of white listing or input validation or you can implement rejects to avoid such issues and here is an illustration for example uh user input is passed to web application server and it it gets

processed by the template engine it will send you back the results for in order to detect it an attacker would try to send some something like uh add the rate curly brackets and then some some mathematical operation and then it would it would check uh what's the response of the application if it gets evaluated if this seven static seven gets evaluated and that means that a template engine is in use and probably the input is not being validated properly so uh i borrowed this code from from internet and and i've clearly given incredits who actually wrote uh blog about this one uh i'm really sorry i i couldn't remember the name of the guy who who

wrote this blog but i have mentioned his blog and and his github uh as well so basically the this code is an implementation of his code but here we what we are doing is as as basically it's it's uh taking input from the user and the template engine is processing the user input without any any sort of uh input validation at all so here we can see the string name gets assigned from collections which is passed from the client end to this code and then if we if we basically filter out the vectors that we could have avoided and the server side template injections all right another class of work is command injection it is

again caused by the lack of input validation in this case uh what's happening in the back end is the user inputs becomes part of operating system commands as an argument in most cases sometimes it is used to launch a specific command or run a specific command so what happened is uh for example this uh let's look at this one so there is a page where you can go and type an ip address or type a domain name and and the server will go and try to ping that domain or ip address but if the user input is not validated properly what an attacker would do is he would append special characters or windows operating or

operating system meta corrector that are used to terminate or or indicate that there is a new command for example in this case an attacker could simply implement ampersand sign and then uh type another command to execute a calculator or maybe a powershell reversal so how would it look like in terms of code so here is a very simple example this function is basically processing user input as we can see the variable ip gets assigned the value from uh which is submitted from from from the user end and since there was no validation it could uh easily result in code execution at line number 48 so how can we fix this uh we could have like fix it easily by

implementing a regex and and a white list which basically says allow all character from a to c and 0 to 9 dot and dash because you have numbers and uh domain names usually contains dots and names and dashes i'm not talking about ipv6 here otherwise we could have added columns as well

all right xml injections uh this one is uh interesting uh class of work uh there are a lot of libraries that provide xml data processing we will look at one specific implementation and we will see how easy it is to fix that xml issue first of all why why does it happen it happens because the user uh the parser uh the parser are not configured properly or they are allowed to load external entities which which results in in information leaks and denial of service attacks or resource uh resource draining attacks and cpu cpu hogging issues things like these how we can avoid these kind of issues we can disable dtd loadings and use safer implementation methods

uh it's time to like quickly dive into the code as well and and we will quickly look at how what a vulnerable code looks like and how we can fix it but again just before we uh pop into the code let's look at a basic illustration i i don't know but i i just love creating these user and web app web server interactions so basically here's an example user is providing some data and servers processors processing it and sending back the results but if the user tries to introduce his own entities and and send send to the server and if the parser is not configured properly it would it would uh process all those entities external

entities or and and send back those as as as part of the result uh in this case we we are trying to access xc host files and then it can lead to information disclosure uh if if that was a real-world attack attacker would probably try to read your web.xml i mean sorry web.config files or maybe some backup files there are a lot of things that can go wrong in case of information disclosure

so again this code was uh taken from utah and modified it and modified but i would like to mention where i where i actually stumbled upon the code and then uh modified it according to my needs so uh let's look into what uh just wanted to give a quick update i know that you're winding down um we did have one question from the feminine from an attendee i was wondering if you had time to take that before you wrapped up about the presentation yeah so the question was what tools are you using to test uh when you when you start to try to break net applications all right so uh from from the testing perspective uh i

basically use verb suit and and and a few extinctions and that's more than enough to test web applications yeah and if you are looking into the code site and visual studio along with some code scanning tools but again that i won't go into the static scanning and solutions because the law falls positive and well that's that's another debate but typically i use burp suit for for the assessment and if if you are trying to recover the code then then dot peak and telricks have great tools to recover the source code and you can do the manual code auditing there as well all right so we were at xml attacks right and right after example attacks uh we were

looking into this dummy code so this code is vulnerable to xml attack and just one line of change one one minor change could have uh mitigated this issue if if we set the dot xml resolver to null it could have prevented xml in external entity injections attacks in this case

this is this is one of the most prevalent issue again it happens because of uh lack of the input validation and this this is not as safer as the server-side code execution but it is still severe and has been used in a lot of high profile attacks as well we will quickly look how uh it looks like and so an attacker basically sends a malicious script to the application application processes it and it stores it and when the attacker visits that same page and it the scripts get executed in the user's browser context and the data script can send users cookies to attacker or perform attacks or perform different kind of attacks for example internal port

system scanning or maybe perform actions in the applications hi sorry how we can mitigate it yeah sorry to interrupt m is like you know you're over time so all right yeah just give me two more minutes so i will just wrap this up okay uh i'm just i just want to talk about the uh communication of crosstalk scripting so i hope you don't mind yeah thank okay so how how we can mitigate it uh the medication is quite uh simple in this case we can use uh we can use uh do not use html dot raw methods while echoing out the user input and and and use input input validation again html provides uh great mitigations

against crossfire scripting attack but if the user input is landing somewhere in in html attribute it won't save you from from those attacks so always be careful while using html dot raw all right that's that's all i have to share any questions so