security research notes

It begins as always with a bug that crashes Internet Explorer.

From: http://lists.grok.org.uk/pipermail/full-disclosure/2006-March/044297.html

http://www.computerterrorism.com/research/ct22-03-2006

From their advisory:

As per the publication, the bug originates from the use of a createTextRange() method, which, under certain circumstances, can lead to an invalid/corrupt table pointer dereference.

As a result, IE encounters an exception when trying to call a deferenced 32bit address, as highlighted by the following sniplet of code.

0x7D53C15D MOV ECX, DWORD PTR DS:[EDI]
..
0x7D53C166 CALL DWORD PTR [ECX]

Due to the incorrect reference, ECX points to a very remote, non-existent memory location, causing IE to crash (DoS). However, although the location is some what distant, history dictates that a condition of this nature is conducive towards
reliable exploitation.

Anyway, I ported the sample Exploit code I found to the Metaspoit Framework, and you can find my module at http://www.rhce2b.com/ie_checkbox.pm

Nmap has the capability to perform idle scanning. Say you want to do a SYN scan of machine B, but you do not want machine B to know your ip address. You can use an intermediate machine that has predictable IPID numbers to act as a zombie and help you establish whether or not each TCP port is open on machine B.

There is a good explanation of how this works at http://www.insecure.org/nmap/idlescan.html.

The idea is that every time a machine sends a packet, it increases it's IPID value by one. If you send a SYN to a port that is open, the machine will send a SYN/ACK back. If a machine recieves an unsolicited SYN/ACK then it will send a RST back (and thus increment the IPID number). If a machine gets an unsolicited RST, however, it ignores it. The following procedure will scan machine B, while making it look like the scan came from host Z.

1. Send a SYN packet to a port on host Z that is open. It will respond with a syn|ack. Make note of the IPID number.
2. Send a SYN packet with a source of host Z to host B on some port. If the port is open, host B will send a syn|ack back to host Z. Since host Z was not expecting a syn/ack, it will send a RST packet back to host B and it will increment its IPID number.
3. Wait a bit
4. Send a Syn packet to a port on host Z that is open. Make note of the IPID number. If it is one more than the IPID number noted in step one, then the port on machine B is closed. If it is two more than it was in step one, then the port is open.

Ofcourse, this assumes that the machine didn't get any more traffic. But, even if it does, you can still use this technique with a slight modification. Say that host Z typically increments its IPID number 10 times per minute. Then, by sending 100 probes, we can see if the IPID has incremented more than 100. If not then the port is closed. If so then the port is open.

So, the hard part is finding hosts in which the TCP stack on the machine increments the IPID number sequencially for each outbound packet. Linux, for example, sends all of it's SYN/ACK packets with a IPID number of zero. This technique is explained in detail at http://www.blackhat.com/presentations/bh-usa-01/ThomasOlofsson/bh-usa-01-Thomas-Oloffson.ppt

However, someone just discovered that even the latest 2.6 kernels will increment their sequence numbers sequentially if you send SYN|ACK packets to them. Hence, virtually all Linux machines using version 2.6 of the Linux kernel can be used for idle scanning. The only issue is that Nmap sends syn's when it is testing whether a machine will work for idle scanning, but syn/ack's for the actual test.

In any case, someone ought to be able to scan for a bunch of zombie hosts, then rotate through them doing idle scans. If you had enough of them, you could potentially bypass intrusion detection by having only a small number of probes from each zombie host.

Introduction

According to a presentation entitled “Towards Evil Honeypots ?! When they bite back...” (http://cansecwest.com/csw04/csw04-Oudot.pdf)

that was at Cansecwest in 2004 it is possible to hack back at attackers in some cases. For example, it is possible to capture the keystrokes and view the screen of an attacker who has SSHd into your machine, if they have x-11 port forwarding enabled.

These are the commands mentioned in the presentation:

sshd -i … & #this sshd should be jailed
sleep 15
xwd -display localhost:10 -silent -out $ipsrc.pic
xspy -display localhost:10...

A normal X-11 connection

To understand how this works, we must first understand how X Windows normally works, and how it works under SSH. The following diagrams were taken from a lecture from the University of South Carolina. (http://www.cse.sc.edu/~matthews/Courses/815/Lectures/lec26.ppt)

In a normal X connection, the user starts an application on the remote host with the DISPLAY environment variable set to local:0. The remote host will connect back on port

6000 on the local host. Port 6000 corresponds to local:0 in the on the remote host.

A X-11 connection using SSH with X11 forwarding

Under secure shell, it works a bit differently. The local host connects to port 22 (sshd) on the remote. SSHD on the remote host then forks a process that listens on port 600n and forwards that to the through an ssh tunnel to port 6000 on the local host. The DISPLAY environment variable would be set to remote:600N on the remote host. (It will use the first port available past 6000.

Magic Cookies

Magic Cookies are designed to prevent other users from being able to run X-11 applications on your machine. The way it works is that there is a secret number called the Magic Cookie. It is stored in the .Xauthority file. Whenever an x-client application wants to talk to the X-server, it must provide this value or it will not be allowed to do so.

According to http://csociety.org/~sigos/projects/ssh/forwarding/, when using X-11 port forwarding under SSH, it will automatically place a Magic Cookie into your .Xauthority. file. This is different than the magic cookie that you have on local. Instead, this magic cookie is specifically for the fake X-11 server that SSHD runs on remote.

The following is an example from http://www.acm.uiuc.edu/workshops/cool_unix/xauth.html shows how to use the xauth command:

dwalin[17]:xauth list                                                         

dwalin.acm.uiuc.edu:0  MIT-MAGIC-COOKIE-1  3bbdd486c11d2ddfbb7111ab088e69c6

dwalin.acm.uiuc.edu/unix:0  MIT-MAGIC-COOKIE-1  3bbdd486c11d2ddfbb7111ab088e69c6

In this case, the first cookie is used for inet sockets, and the second for UNIX sockets. You can say

xauth add dwalin.acm.uiuc.edu:0 MIT-MAGIC-COOKIE-1 3bbdd486c11d2ddfbb7111ab088e69c6

This will add the magic cookie to your .Xauthority file.

So, in theory, if a hacker has brute forced the “hacker” account on our local machine. Then the following commands ought to allow us to run X-applications on their display:

xauth –f ~hacker/.Xauthority extract ~/auth remote:11.0

xauth merge ~/auth

This was abstracted from http://www-acs.ucsd.edu/home-pages/bparent/ssh-x11.ps . Actually, the scenario is slightly different, but this should work.

The “11.0” part will depend on their display number. If the hacker logs in just after you do, then their display number will be one more than yours.

Once you have stolen their magic cookie, you should be able to connect to their X-Server and watch what they are doing.

A few useful programs:

Xkey (http://www.deter.com/unix/software/xkey.c) is a remote X-windows keyboard logger.

Xspy (http://www.deter.com/unix/software/xspy-1.0c.tgz) tricks X-windows into giving up passwords from the xdm login window or xterm secure-mode.

XWatchWin (http://www.deter.com/unix/software/xwatchwin.tgz) will connect via a network socket and display the window on your X server.