Spoofing Source ports and getting in

An interesting but probably reasonably known technique of getting past firewalls. Incase there's a firewall out there which has ..for some reason been "configured" to allow traffic from source port 23 through. Why would it do this? Well .. ideally due to loads of firewalls being stateful these days you don't need to have bi-directional rules allowing all traffic with say.. a source port of 23 through if you've already allowed it outbound. So to explain things a bit more clearly:

If you have already a rule like:
Internal Network -- Internet -- allow traffic with a destination port of 80

Then you don't need to have a rule like:
Internet -- Internal Network -- allow traffic with a source port of 80

Thats what a stateful firewall does; keeps track of which client issued which connection to port 80 of which client and makes sure that it returns the response to that very client. So ideally a bi-directional rule is most probably a misconfiguration.

Still I won't be shocked to see many people outside still doing stuff like this so incase you happen to come across a firewall which lets traffic in based on a source port; you could use fpipe to spoof the source port and try and access traffic on other restricted ports inside but are "inaccessible' from the outside.

I wont go into the details of how to use "fpipe" coz that's easily obtainable at Foundstone. Effectively though --

You are on Machine 1
You set Fpipe to listen on 5555 on Machine 2 and connect to 3389 on Machine 3(VICTIM)
You set Fpipe to use port 22 as its source port because inbound SSH has been allowed

So when you connect to Machine 2:5555 , Machine 2 will initiate a connection using source port 22(ALLOWED BY THE FIREWALL) and make a connection to Machine3:3389. Once done it'll forward the connection over to Machine 1 where you're doing your pen-testing. Quite cool ...but really it really can be exploited only incase of some really lazy sysadmins or a firewall thats as old as Fred Flintstone is being used ;)

Hidden Cache in IE??

This one's a pretty old one which we rediscovered during a recent assessment. We were checking whether private user information or data was getting cached offline. We used both IE and Firefox to check this. While Firefox offers the eay to use about:cache to see what's got stored offline IE doesnt do the same and you need to actually go inside the "Temporary Internet Files" to find out if its stored anything there. Now there are times when you "Work Offline" and go Ctrl+H to see all your browser history and click on it to see if you can view it. Now sometimes you'll find that there's a cached page but you are not able to see it in Temporary Internet Files at all.

So what we did was to fire up FileMon , a cool program which tracks what files get accessed on your disk each time you do something. So for example say you click on a page in History and can see its contents. Using FileMon and by setting the appropriate filters you can actually pinpoint the exact file that is storing the cached resource. So when we did this for this application we found there were files from the L:\Documents and Settings\arvind\Local Settings\Temporary Internet Files\Content.IE5 directory which were being referenced each time something in history is accessed. This is actually a fairly old location in which IE stores its files to "improve performance" and on which there was an article by The Riddler a long time ago. That article can still be found here:
http://sillydog.org/mshidden21b.html#9.1

Anyway the point here is : Dont forget to look into content.ie5 and history.ie5 when you next do an appsec assignment. You might be surprised at what you find :)

Firefox -- An RFC violation??

The "no-store" directive says that no information should be stored on your hard disk and the application must make a best effort to remove the information from browser memory(volatile storage) as soon as possible. Now the "as soon as possible" is a dangerous phrase; as it could mean different things to a developer and a security consultant. However we came to the conclusion that the least that needs to happen is that all private pages shouldn't be cached at all on disk. Also in the event of the pages remaining in browser memory there is a high possibility of the pages remaining in the browser memory even after logging out. So ideally the moment you logout the browser needs to close the window itself thus flushing any pages in memory. However there have been places where this doesn't happen and pages are cached on disk even after a Firefox browser close. This doesn't happen with IE though strangely enough. Wonder why?

The "no-cache" directive says that some specific pages must not be cached at all and every time a request is made for that resource it should be revalidated against the server before the page is served. However in a recent appsec assignment we saw Firefox caching pages irrespective of the "no-cache" directive. So when we did a "Work Offline" in Firefox we were still able to access the pages. However on browser close these pages disappeared. This only proves that the pages were in browser memory for Firefox. This behavior was not repeated with IE or Opera where it refused to let us see pages on Working Offline? So why the discrepancy with Firefox? Why doesn't the browser try and contact the server before serving the page? More later when I get time to hack around ...Do reply if you know why!!

NTLM authentication using Burp proxy

Hey buddies,

Just wanted to share my experience while doing an appsec for one of our clients.

I was doing appsec of an application which worked on NTLM authentication. With every request I was sending, the NTLM variables were queried and if authenticated I get a response.

After opening the browser, if I want to login to the application I have to provide my local domain password. This fetches the login page of the application where using my logins I can login to the application.

Here, I was struggling to setup a local proxy because whenever I setup a local proxy and send a new request, my NTLM variables were queried and I was not authenticated as local proxy has broken my NTLM authentication.

After struggling for some time, I found an option in BURP PROXY, under tab comms there is a check box asking for ‘do WWW authentication’. Basically we have to select this check box and select NTLM authentication here and provide the destination IP, Domain name, Domain password etc.

This way, working through BURP I solved the problem and continued the testing. But again remember that closing BURP removes this setting and you will have to again do the same settings to continue testing.

Cheers,
Prashant