This vulnerability has been in market for a very long time, but what makes me write about this actually comes from my new project which is a simple desktop application developed in VB. Wont be talking much about this application but would be describing the attack [PTMP] with few web applications on the internet.
Memory is a vital component for any application be it a web app or a simple desktop app. And most of the time our loggin passwords are kept unencrypted in the process memory. This blog would discuss the most easy ways to extract plain text passwords from any application that is not encrypting user passwords before storing in the process memory.
More Insight!!
Take a simple web application which would prompt a user to enter his/her userId and password in its login page ( take for eg gmail )
So coming back! After the authentication phase the password is stored in the process memory which can be easily extracted using tools like userdump or memory viewers like WinHex.
Here is a small POC on PTMP:
Shtep bi shtepp!!
1) I closed all instances of my awsum firefox and opened up my firefox's pentesting profile which i have created ( prbly i wud write about how to create one in one of my future blogs ).
2) Navigated to the website {https://www.google.com/xyz} and entered my login credentials
3) Now its time to dump the process for this i used userdump could be found at (http://www.microsoft.com/en-in/download/details.aspx?id=4060)
and listed all the running processes [ userdump.exe -p ]
This will list out all the running process on my system but what i am more intrested is a dump of my firefox.exe
The command to dump is "userdump firefox.exe" ( it is also allowed to give the particular PID of the process which is 5724 in this case )
4) Now after having the dump i extracted the readable strings from it using a tool from the Sysinternal suite called strings.exe ( strings.exe firefox.dmp > test.txt )
Cross site scripting is a type of attack wherein a malicious script is injected and executed in a users browser and the payload can be as dangerous as hijacking a users valid session. XSS does not really rely on web browser or operating system vulnerability but it specifically targets the web application flaws in handling inputs. In this post i will highlight some of the mitigation's and some well known facts about XSS.
When this vulnerability was first discussed it was considered as a lame horse in front of big giants like SQL injection until in October 04 2005 when the sammy worm took myspace in just few hours. More details on this xss worm can be found here
Its not always required to insert a <script> tag for xss to work, sometimes <script> tag may be stripped off by application filters making your payload useless.
Few more ways:
a)<IMG SRC=jAvascript:alert('hello')>
b)<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>
c)';alert(String.fromCharCode(88,83,83))//\';alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//\";alert(String.fromCharCode(88,83,83))//--></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
For more awesome vectors see this link Rsnake XSS
This portion of the article would benefit most of the developers who would think of security as a
major aspect than a fancy UI. Some of the important things that a developer should keep in mind
before starting any web application assignment is that whatever input is collected from the client
side cannot be trusted. Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS in a fairly straightforward manner.Have a look at XSS prevention cheat sheet here. The OWASP Esapi Library is highly recommended for preventing Cross site scripting attacks.
Some new attack vectors:
Recently i came across this blog entry which describes a new way of looking into XSS attacks.
Here the attack is more towards tweaking parameter names rather than the parameter values.
The conventional way an attacker would try!
http://abc/test.aspx?a=<script>
alert('xss')</script>
But in ASP.Net application the ValidateRequest is enabled by default which would strip out the HTML
mark ups and pop up an error as shown below.
However, if we instead place our attack payload into a parameter name, then ValidateRequest allows
our input through and we hit the vulnerable code:
http://abc/test.aspx?<script>
alert('xss')</script>=a
Few websites Xssed by me:
Adobe
Symantec
Mcafee
Post credits: Owasp, Rsnake, Portswigger
Title credit: Rowdie Rathore (2012)
