Monday, December 22, 2014

Exploiting CVE-2014-9390

On the face of it,  CVE-2014-9390 seems like quite a nasty vulnerability. It gives an attacker the ability to modify a local git repo's .git directory (where all your config and other fun things, including scripts) are stored. This directory should be protected from modifications via the contents of a remote repo, owing to checks performed by git when performing the copy.

The git client should ignore .git directories on the remote server, however its been discovered that although .git will be ignored, .gIT, .GIT, .git~123 etc will happily be pulled to the local file system. Now, if that filesystem is case sensitive, no issue: the local .git will remain intact, and the new folder will snuggle up alongside it. However... in case insensitive filesystems (Mac HFS+ and Windows NTFS) the example .gIT is for all intents identical to .git, and hopefully you can see where the problem lies.

How easy is this to exploit? Lets find out...

After quickly setting up a git server and evil repo, we can can create some evil content for that repo. In this case, I'm using a post-checkout script, which does pretty much what it says on the tin: executes  on the client every time a branch is checked out. The script calls the oh-so-evil executable notepad.exe, but this could easily be something far more worse:



Add the evilness and commit to the remote repo:


Attempt a clone to a local Windows repo:



And BOOM! There is notepad.exe, called in from the post-checkout script hosted in our evil repo. Git failed to identify that our evil .gIT was something it shouldn't be cloning, Windows NTFS ignored the case of the pulled-in evil directory, and our evil post-checkout script was merged into the local .git/hooks directory (which got created with default values the instant we ran the clone command)

Git client used for this test was version 1.8.3 

So, is this bad? Yes... oh yes... Should you update your local git clients? Yes. 

Go on, go update now. 



Thursday, October 2, 2014

Analysis aware malware

Nice sample of... something... for you here. Analysis aware malware, as per the Cuckoo snippet below, the exe has a good sniff through the registry at the usual telltale keys, before deciding that it is indeed being sandboxed, and this world of pain is too much to bear and terminating itself.


https://www.virustotal.com/en/file/7dc0d616257061c3bdbbdd59e6a035bea4694e0ef8daea420b773446ad2f6ae2/analysis/1412282302/

When I have time, I'll change around some of these settings, as suggested here and see if I can get this little sucker to run... http://blog.prowling.nu/2012/08/modifying-virtualbox-settings-for.html 

Saturday, September 27, 2014

Thoughts on dhclient and Shellshock

In the wake of Shellshock, any service, process, daemon, app etc which passes strings to the shell (and if your default shell is bash) is a likely attack vector for Shellshock. Immediately after the bug was disclosed, thoughts began to drift towards DHCP, and specifically dhclient on linux systems.

Dhclient will pass a set of values to bash to write to system variables, as well as noting them down in resolv.conf, from parameters in the BOOTP unicast DHCP OFFER packet offered up by a DHCP server, following the discover and request packets:



We all knew that anyway, right? And that's an pretty obvious vector for a Shellshock attack:



Which works pretty well against dhclient 3.0.4 in Fedora 6 (and probably RHEL4, CentOS4 etc...):



Now, in dhclient 4.1, it looks like those variables, prior to being passed to bash and written to resolv.conf are validated by code in dhclient, and the attack fails (bash is still unpatched on the target system, and is still vulnerable):



Right. So what? Well... Clearly, someone has implemented this string validity check into dhclient to prevent malicious strings being passed to bash as system variables (or other nefarious reasons) (4.3 source):



This is the interesting bit, as it points towards an early missed opportunity to discover Shellshock.

Looking through the release notes, it seems that the change in question to bring in the validation was introduced to close CVE-2011-0997: https://kb.isc.org/article/AA-00455/0/CVE-2011-0997%3A-dhclient-Does-Not-Strip-or-Escape-Shell-Meta-characters.html

How close did we come then to discovering Shellshock? I don't know. The good news is that any dhclient patched up against CVE-2011-0997 is seemingly protected against Shellshock delivered via the DHCP route, but its frustrating that perhaps with a little more digging, we could have uncovered a fundamental flaw in bash a little earlier.

**Update**

The diff for adding a validation check in 3.0.5 to close CVE-2011-0997 can be found here,: http://sophie.aero.jussieu.fr/distrib/Scientific%20Linux/5x/x86_64/by-pkgid/0546855d7431d3fdfce69d4cced3d294/files/1

You can see most non-alphanumerics being nuked half way down.

Tuesday, September 16, 2014

Packed rootkit?

New possible packed rootkit for your consideration, VT and JoeSandbox below, I'll post Cuckoo results when I can:

https://www.virustotal.com/en/file/6be8c86437b1e1f7620976450306d1c8a68f4dcb89a1f22fbe727c3f7405adde/analysis/1410874043/

http://www.file-analyzer.net/analysis/4865/14484/0/html


Tuesday, August 19, 2014

Another Aspxor sample

Will spin this up in Cuckoo later, in the meantime...

https://anubis.iseclab.org/?action=result&task_id=18e0fb84de0adfe14d9f0e20f41bf788d&format=html

https://www.virustotal.com/en/file/66c47994db86b6ad15767539d4aaa16874a5f33a1e6db2bfa3bf36156b2c6370/analysis/1408433377/

MD5: df4fd11999a8ceb85959c46394fca864

Wolfy.