Are you infected?

Ever think you could never be a part of a botnet without knowing about it? There are millions of PCs out there infected. Most of the owners do not know about it, many don’t know enough about it to realize they have a problem and some just don’t care. But it is a serious issue.

I found some interesting activity on my website recently that really highlights how alive and well these botnets really are. I have a Wiki set up that I don’t really publicize since it really is only a collection of notes that I find convenient to have accessible online. A few months ago a spammer found it. Now, I am at fault for not initially disabling open registration which means anyone could sign up for an account and add content. Well, over a few weeks using a botnet the spammer posted about 50,000 spam articles before I noticed they were there.

I’ve since cleaned up the mess and disabled open registration. However, the botnet was still chugging away trying to create new accounts and post articles. Trying to ease the traffic I started blocking IP address ranges from the worst offending networks. This helped a lot but they were still chewing up bandwidth. Finally I just blocked everyone but my own IP address to see how long it would take before they gave up.

They are still trying harder and harder.

Monthly Traffic

So, normal traffic to my site was about 30 visitors a month. As soon as I noticed this jumped I knew exactly what happened. After I cleaned up the mess and blocked most of the offending networks my bandwidth dropped back down but I still can’t see normal visitors through the noise. Finally I gave up and just blocked everyone but my own IP address. If you try to access the Wiki now you will get a “403 Forbidden” error.

Daily Traffic

I noticed the traffic dropped significantly when people shut down the machines over the long 4th of July holiday weekend. So, your machines are infected but you don’t know or don’t care enough to figure it out and fix it? Hmmm…

Traffic Source

What did surprise me was the source of the traffic. Apparently most traffic is coming from Canada followed in second by France. USA is 4th… Why would the Canadian and French machines go down over the 4th weekend? I’m at a loss on that one. Now, even though the entire site is blocked returning a 403 error, instead of giving up and going away they seem to be trying even harder. After I blocked everyone the hits dropped to about 160k in May. However, in June this jumped to 1.2 million! And now about a third of the way into July it’s already passed that at 1.4 million? Geesh! That’s on track for almost 5 million hits this month. I may put it back online in a few weeks. However, the 15 byte error page takes up a lot less bandwidth than the actual site pages so we’ll see.

Securing WordPress

In light of the latest attacks on WordPress sites everywhere I thought I should probably step up security a bit here. Not that I thought I had a bad password or anything but I still had the default admin account enabled. This attack is being conducted by a huge botnet of about 90,000 computers trying a large dictionary of passwords against the admin account. I wasn’t too concerned but the fact that it was targeting the admin account and seeing a huge spike in access to wp-login.php I still had an uneasy feeling in my gut.

First, the admin account is now disabled. They can target it all they want! Second, no one should need to access wp-login.php from anywhere in the world. So I updated .htaccess to only allow access from my IP address.

<Files "wp-login.php">
  Order Deny,Allow
  Deny from all
  Allow from xxx.xxx.xxx.xxx/32
  ErrorDocument 403 "https://www.google.com"
</Files>

Third, installed the Limit Login Attempts plugin for WordPress which will automatically block an IP after so many failed login attempts.

Remove Drive Letter for Encrypted Partition

I created a TrueCrypt partition on my machine that is assigned a letter when mounted through TrueCrypt. Through this drive letter TrueCrypt gives access to the files as if they were on any other drive, performing the encryption and decryption behind the scenes.

However, the encrypted partition itself is also recognized by windows and is given its own drive letter. Windows sees the partition and thinks it is unformatted and gives you the option to format it. I’d rather this “unformatted” partition not show up in Windows Explorer at all.

To get rid of this drive letter do the following: (This is for Windows XP. Vista and Windows 7 may be slightly different. If they are VERY different, email me or leave a comment with the correct procedure and I’ll update this post.)

  1. Right-click “My Computer” and select Manage.
  2. Select “Disk Management”.
  3. Right-click the encrypted partitionand select “Change Drive Letter and Paths…”
  4. Click Remove.
  5. Click Yes to confirm.

Fun with Buffer Overflows

A question was asked on stackoverflow.com about using a buffer overflow to clobber the stack and alter the behavior of a program. It’s been a while since I’ve done anything like this so I thought I might give it a shot. This code is based on code snippets shown in the stackoverflow thread. This is very architecture and compiler dependent. If you are following along you may have to adjust accordingly.

#include <stdio.h>
void foo()
{
	int* p;
	p = (int*)&p;
	p[offset] = new return address;
	return;
}
int main(int argc, char* argv[])
{
	int x = 0;
	foo();
	x++;
	printf("%dn", x);
	return 0;
}

The idea behind this code is to clobber the stack in function foo() so when foo() returns, the x++ is skipped and 0 is printed. We have two things we need to do to make this happen. First, when a function is called, the address of the instruction immediately following the function is pushed on the stack. This is the address control jumps to when the function is finished executing and returns to the caller. It is this address on the stack that we need to change. Second, we need to know where to return to. To find this value, we need to look at the object code that is created by the compiler. If you are trying this at home, your compiler and produced assembly may be different as the produced output can be very version specific. For this example I’m using Cygwin with gcc version 3.4.4. The following is the disassembly of the object code for the main() function:

// _main
//  401071:       55                      push   %ebp
//  401072:       89 e5                   mov    %esp,%ebp
//  401074:       83 ec 18                sub    $0x18,%esp
//  ... skip unimportant stuff ...
//  40109b:       c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%ebp)
//  4010a2:       e8 a9 ff ff ff          call   401050 <_foo>
//  4010a7:       8d 45 fc                lea    -0x4(%ebp),%eax
//  4010aa:       ff 00                   incl   (%eax)
//  4010ac:       8b 45 fc                mov    -0x4(%ebp),%eax
//  4010af:       89 44 24 04             mov    %eax,0x4(%esp)
//  4010b3:       c7 04 24 00 20 40 00    movl   $0x402000,(%esp)
//  4010ba:       e8 a9 00 00 00          call   401168 <_printf>
//  4010bf:       b8 00 00 00 00          mov    $0x0,%eax
//  4010c4:       c9                      leave
//  4010c5:       c3                      ret

This disassembly is produced using the objdump command objdump -d test.exe. Breaking this down we see: Standard preamble stuff. Don’t worry about this. (yet)

//  401071:       55                      push   %ebp
//  401072:       89 e5                   mov    %esp,%ebp

Allocate space on the stack for our local variables (including x). This also allocates a temporary variable to store the address of our format string constant which we will come back to.

//  401074:       83 ec 18                sub    $0x18,%esp

Set x to 0.

//  40109b:       c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%ebp)

Call foo().

//  4010a2:       e8 a9 ff ff ff          call   401050 <_foo>

When this instruction is executed, the address of the next instruction is pushed onto the stack. In this case it is the address of the lea instruction 4010a7. The next block of instructions increment x. This is the block we want to skip.

//  4010a7:       8d 45 fc                lea    -0x4(%ebp),%eax
//  4010aa:       ff 00                   incl   (%eax)

These two instructions take up a total of 5 bytes. 3 for the lea instructions and 2 for the incl instruction. Once we find the return address on the stack, we need to increment it by 5. Our updated foo() looks like this:

void foo()
{
	int* p;
	p = (int*)&p;
	p[offset] += 5;
	return;
}

Note, we don’t want to skip these two instructions. They are responsible for putting a copy of x into a parameter already allocated on the stack to be passed to printf().

//  4010ac:       8b 45 fc                mov    -0x4(%ebp),%eax
//  4010af:       89 44 24 04             mov    %eax,0x4(%esp)

This instruction copies the address of our format string into the last reserved variable on the stack which is the first parameter to be passed to printf().

//  4010b3:       c7 04 24 00 20 40 00    movl   $0x402000,(%esp)

Finally, we call printf(), set our return value and exit the application.

//  4010ba:       e8 a9 00 00 00          call   401168 <_printf>
//  4010bf:       b8 00 00 00 00          mov    $0x0,%eax
//  4010c4:       c9                      leave
//  4010c5:       c3                      ret

The last thing we need to find is where the return address is stored on the stack. Let’s look at the disassembly of foo().

//  401050:       55                      push   %ebp
//  401051:       89 e5                   mov    %esp,%ebp
//  401053:       83 ec 04                sub    $0x4,%esp
//  401056:       8d 45 fc                lea    -0x4(%ebp),%eax
//  401059:       89 45 fc                mov    %eax,-0x4(%ebp)
//  40105c:       8b 55 fc                mov    -0x4(%ebp),%edx
//  40105f:       83 c2 08                add    $0x8,%edx
//  401062:       8b 45 fc                mov    -0x4(%ebp),%eax
//  401065:       83 c0 08                add    $0x8,%eax
//  401068:       8b 00                   mov    (%eax),%eax
//  40106a:       83 c0 05                add    $0x5,%eax
//  40106d:       89 02                   mov    %eax,(%edx)
//  40106f:       c9                      leave
//  401070:       c3                      ret

The first two instructions are the preamble which we’ve seen before with main().

//  401050:       55                      push   %ebp
//  401051:       89 e5                   mov    %esp,%ebp

This pushes the previous base pointer onto the stack and makes the current stack pointer the current base pointer. We know when this function was called, the return address was pushed. It is now “under” the base pointer we just pushed. Next, storage for our local variable p is allocated on the stack.

//  401053:       83 ec 04                sub    $0x4,%esp

Our stack should now look something like this:

//         ret addr
//         old ebp
// esp --> p

Next we store the address of p into p so that p is pointing to itself.

//  401056:       8d 45 fc                lea    -0x4(%ebp),%eax
//  401059:       89 45 fc                mov    %eax,-0x4(%ebp)

Now, with p pointing to itself, let’s have another look at the stack and see how we should offset p to get to the return address. Our stack should now look something like this:

//         ret addr <-- p + 8
//         old ebp  <-- p + 4
// esp --> p        <-- p

Note that I am using a 32-bit system so addresses and registers are stored as 4 byte values. Whatever address p is pointing to, we have to add 8 to that address. In foo() I declared p as an int * so we can treat p as an array of integers and access index 2 to clobber the return address:

void foo()
{
	int* p;
	p = (int*)&p;
	p[2] += 5;
	return;
}

Running this code produces the following output:

$ ./test.exe

]]>