Archive for October, 2009

Spawning A CMD Prompt From MS Word or Excel

October 15th, 2009

This is an old trick, but I still see a number of Administrators that think they have locked users out of the command prompt by simply removing the icon from the menu and disabling the Start–> Run option. In this post I’ll discuss how to create a command prompt with Visual Basic for Applications (VBA), as well as how to mitigate (although never completely eliminate) the risk of someone achieving access to the prompt.

Creating a command prompt with VBA

This technique will work with any application that supports VBA, but I’m specifically going to use Microsoft Word in my example. Here’s what you need to do:

  1. Launch Microsoft Word
  2. Press “ALT-F11” to launch the VBA editor
  3. Double click “ThisDocument” in the left pane
  4. When the editor window appears, type in the text shown in Figure #1
  5. Press the “F5” key
Figure 1: Our simple VB script

Figure 1: Our simple VB script

You should see a command prompt window appear in your task bar. Here’s a copy of the code you need in step 4 so you can copy/paste:

Sub GetCMD()

Shell “cmd.exe cmd.exe”

End Sub

How to prevent VBA from spawning a command prompt

Execution of the command prompt can be disabled with the Group Policy Editor tool. Here are the steps:

  1. Click Start –> Run
  2. Type in “gpedit.msc” (without the quotes)
  3. Click User Configuration –> Administrative Templates –> System
  4. Search down the list for “Prevent access to the command prompt” and double click it

You have two options available to you:

  • Enable/Disable access to the command prompt
  • Yes/No Disable command prompt scripting process

If you only disable the first option, direct access to cmd.exe is prevented but a smart user can still get to it via a batch file. To prevent script access, need to disable the second option as well. This prevents ALL scripting however and can play havoc in many environments. Also, both of these settings will apply to the Administrator account as well. This can make admin and troubleshooting far more difficult.

Even with both options disabled, a user can still get around these settings by using command.com instead of cmd.exe. To fix this, you need to restrict access to command.com via user permissions. If you are still running some old 16-bit apps, this fix will break them.

All of these steps do not completely solve the problem however. A user who knows what they are doing with debug can simply copy cmd.exe to another location and modify it so a prompt is achieved when using it to run a bogus command. So we also have to delete “debug.exe”.

Even then, a savvy programmer can create an executable to get around all of the above security checks. So we need to remove all ability to copy or write to the drive as well. Needless to say we have a pretty useless computer at that point.

Exec Summary

If someone smart has access to your system, it is doubtful you will be able to prevent him or her from getting to the command line. The Group Policy Editor can most certainly make it more difficult, but the tool simply reduces the risk of attack. You cannot completely eliminate the risk without severely hampering the system’s operation and usefulness.

1 comment »

Posted in 4-notice, Windows Security

Tags:

PDF of “Protecting Against Targeted Attacks” talk

October 14th, 2009

Over the next few weeks I’ll be giving this talk in a number of locations. For those who attended and requested a PDF version of the slides, here is the link I promised:  protecting-against-targeted-attacks-R2

3 comments »

Posted in 3-err, General Security

Tags:

Tshark Challenge – Uber-geek Answer

October 13th, 2009

In my last post I left you with a question: Given what we have seen in the decode file with tshark, what impact (if any) would there be if we place a stateful inspection firewall between the attacker and the Web server? In other words, if the attacker is running a packet sniffer, would they still see the Web server leaking out 404 errors?

And the answer is…

Maybe. :)

Not all stateful inspection firewalls are equal. Some handle packets slightly differently than others. For example some (like Checkpoint, Netscreen and others) let non-SYN packets to permit rules generate new state table entries. Some (Cisco, Netfilter and others) will only generate a state table with proper session establishment (must see TCP three packet handshake).

The NIPS sent a valid reset packet to the attacker on the Internet. Each of the above firewalls would see the reset packet and remove it’s entry from the state table. When the Web server continued to communicate however, only the first set of firewalls would let the packets leak out to the attacker. The second set of firewalls would simply drop the traffic. In fact if we set them up with a deny rule instead of a drop rule, they would kill the session on the Web server thus fixing the problem created by the NIPS.

Why do some vendors let acknowledgement packets generate new state table entries? This seems a bit counterintuitive as a legitimate session is always going to start with a SYN packet. There are two reasons this makes good functional sense:

  • Updating the firewall rules does not kill active sessions
  • Active-active setup will pass traffic prior to state table sync

Of course we’ve increased functionality at the cost of security. Unfortunately that is the typical trade off.

Hope you had fun with this challenge. If there is interest I will post more in the future.

2 comments »

Posted in 2-alert, Network Security, Packet Decoding

Tags:

Tshark Challenge – The Final Answers

October 9th, 2009

In my last post we had determined that the trace file contained a session where a single honed network based intrusion prevention system had attempted to stop an attack from an HTTP client to a Web server. We concluded that the client’s data request did look rather suspicious, and proved a third party system (the NIPS) was responsible for the reset packets transmitted during the session.

In this post we still need to answer two questions:

  1. Was the attack successful?
  2. Why did the Web server ignore the TCP reset packet transmitted by the NIPS?

Was the attack successful?

The attacker was looking to identify if the file “startstop.html” was located in the “Administrator” directory. Let’s take a look at one of the packets sent to the attacker after the reset packets were transmitted:

tshark -n -r challenge1.cap -x frame.number==11

11   0.711825  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

0000  00 50 8b ea 20 ab 00 b0 d0 20 7d e3 08 00 45 00   .P.. …. }…E.

0010  01 a7 37 47 40 00 40 06 73 8b 0c 21 f7 04 94 4e   ..7G@.@.s..!…N

0020  f7 0a 00 50 69 2a 3a 88 39 cd 6a 97 b9 4c 80 19   …Pi*:.9.j..L..

0030  19 20 8c d4 00 00 01 01 08 0a 3d 76 0e d3 00 ec   . ……..=v….

0040  48 4b 48 54 54 50 2f 31 2e 31 20 34 30 34 20 4e   HKHTTP/1.1 404 N

0050  6f 74 20 46 6f 75 6e 64 0d 0a 44 61 74 65 3a 20   ot Found..Date:

0060  54 75 65 2c 20 32 35 20 4a 75 6e 20 32 30 30 32   Tue, 25 Jun 2002

0070  20 30 30 3a 33 34 3a 35 38 20 47 4d 54 0d 0a 53    00:34:58 GMT..S

0080  65 72 76 65 72 3a 20 41 70 61 63 68 65 0d 0a 43   erver: Apache..C

0090  6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f 73 65   onnection: close

00a0  0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20   ..Content-Type:

00b0  74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 61 72 73   text/html; chars

00c0  65 74 3d 69 73 6f 2d 38 38 35 39 2d 31 0d 0a 0d   et=iso-8859-1…

00d0  0a 3c 21 44 4f 43 54 59 50 45 20 48 54 4d 4c 20   .<!DOCTYPE HTML

00e0  50 55 42 4c 49 43 20 22 2d 2f 2f 49 45 54 46 2f   PUBLIC “-//IETF/

00f0  2f 44 54 44 20 48 54 4d 4c 20 32 2e 30 2f 2f 45   /DTD HTML 2.0//E

0100  4e 22 3e 0a 3c 48 54 4d 4c 3e 3c 48 45 41 44 3e   N”>.<HTML><HEAD>

0110  0a 3c 54 49 54 4c 45 3e 34 30 34 20 4e 6f 74 20   .<TITLE>404 Not

0120  46 6f 75 6e 64 3c 2f 54 49 54 4c 45 3e 0a 3c 2f   Found</TITLE>.</

0130  48 45 41 44 3e 3c 42 4f 44 59 3e 0a 3c 48 31 3e   HEAD><BODY>.<H1>

0140  4e 6f 74 20 46 6f 75 6e 64 3c 2f 48 31 3e 0a 54   Not Found</H1>.T

0150  68 65 20 72 65 71 75 65 73 74 65 64 20 55 52 4c   he requested URL

0160  20 2f 63 66 69 64 65 2f 41 64 6d 69 6e 69 73 74    /cfide/Administ

0170  72 61 74 6f 72 2f 73 74 61 72 74 73 74 6f 70 2e   rator/startstop.

0180  68 74 6d 6c 20 77 61 73 20 6e 6f 74 20 66 6f 75   html was not fou

0190  6e 64 20 6f 6e 20 74 68 69 73 20 73 65 72 76 65   nd on this serve

01a0  72 2e 3c 50 3e 0a 3c 2f 42 4f 44 59 3e 3c 2f 48   r.<P>.</BODY></H

01b0  54 4d 4c 3e 0a 00 03 00 07                             TML>…..

So the answer to the attacker’s question; “Is the file located on the server?, is answered in every packet the server set to the client after the reset packets were issued. Now the question becomes, did the attacker see this information?

When the reset packet was sent to the attacker, the reset should have killed the TCP session. This means that when this data arrived, the receiving port (TCP/26922) should have been in a closed state. Had this in fact been true, I would expect to see a reset/ACK coming back from the attacker’s system telling us that TCP/26922 is now closed. We never see those packets.

So why didn’t the remote port close? The reset packet is valid, so it should have killed the session. A savvy attacker is going to run a packet sniffer in the background while performing their attack. It is possible that the attacker would have figured out what was going on and simply created a firewall rule on their attack system filtering out all inbound reset packets. This would have permitted their tool to continue functioning. Even without the firewall filter their packet sniffer would contain the answers they seek. So there is a very good chance the attacker has figured out what we are vulnerable to, despite the fact a NIPS is protecting the network.

Why did the Web server ignore the reset packet?

Our final question is why did the Web server ignore the reset packet sent by the NIPS. This is causing two problems:

  • The info the attacker wanted is continuing to leak out
  • If the attacker does multiple file probes, they could fill up the session table on the Web server

The second item is kind of scary because it would actually be the NIPS causing the DoS attack by only killing one side of the connection properly. So even if we were patched and up to date, vendor gear we paid money for would end up killing our Web server. Gee I hate it when I spend money to DoS myself. ;)

Let’s take another look at those reset packets:

tshark -n -r challenge1.cap frame.number==6 or frame.number==7

6   0.031319  12.33.247.4 -> 148.78.247.10 TCP 80 > 26922 [RST, ACK] Seq=1 Ack=222 Win=0 Len=0

7   0.031385 148.78.247.10 -> 12.33.247.4  TCP [TCP ACKed lost segment] 26922 > 80 [RST, ACK] Seq=1 Ack=222 Win=0 Len=0

Notice that tshark is telling us packet 7 is a lost segment. In other words, tshark is telling us that the TCP sequence number is not within the window the host is expecting. A look at the sequence and acknowledge numbers explains why. The values are identical to the ones in packet 6. You may remember from the last post that packet 6 and 7 also had the same IP ID value (45298).

So it appears that here is what happened:

  • Client sent an HTTP attack to our Web server
  • NIPS detected the attack
  • NIPS sent a valid TCP reset to the attacker to kill the session
  • NIPS swapped the source and destination IP addresses in the packet, recalculated the CRCs, and then sent the same reset to the Web server
  • Web server ignores the reset because it does not contain an acceptable sequence number

You may be asking yourself, “How did the vendor miss this?”. My best guess is that the vendor ran some simulated attacks; the attack tool did not show them vulnerable files, so they assumed everything was working OK. In other words, a vendor who created a product to protect networks on the wire never bothered to look at what their product was actually doing on the wire. Hummm…

Bonus question

OK, if you are having fun with this one, here’s a bonus question to answer that will definitively prove your uber-geek status upon the top of the secret pyramid:

Assume we place a stateful inspection firewall between this subnet and the attacker. Will the attacker still be able to see the answers with a packet sniffer?

I’ll post the answer next week.

No comments »

Posted in 2-alert, Packet Decoding

Tags:

Tshark Challenge – Hints 4

October 8th, 2009

In my last post we identified that the client system was probably running some kind of tool to probe for known to be vulnerable files. We still have to explain the reset packets however, as well as why the server was ignoring them.

Right now we don’t even know where this packet capture was taken in relation to the two end points. I’m going to run tshark using the “-T fields” switch to print out the TTL information. By analyzing the TTLs, we should be able to determine where we are sniffing in relationship to the client and the server. I’m also going to print out the IP IDs to see if there are any abnormalities in the packet order.

Here’s the command and output:

tshark -r challenge1.cap -T fields -e frame.number -e ip.src -e tcp.srcport -e ip.ttl -e ip.id

1       148.78.247.10   26922   49      0x2a6b

2       12.33.247.4     80      64      0×0000

3       148.78.247.10   26922   49      0x2a95

4       148.78.247.10   26922   49      0x2a96

5       12.33.247.4     80      64      0×3743

6       12.33.247.4     80      255     0xb0f2

7       148.78.247.10   26922   255     0xb0f2

8       12.33.247.4     80      64      0×3744

9       12.33.247.4     80      64      0×3745

10      12.33.247.4     80      64      0×3746

11      12.33.247.4     80      64      0×3747

12      12.33.247.4     80      64      0×3748

13      12.33.247.4     80      64      0×3749

14      12.33.247.4     80      64      0x374a

15      12.33.247.4     80      64      0x374b

16      12.33.247.4     80      64      0x374c

17      12.33.247.4     80      64      0x374d

148.78.247.10 is the client. We know that because it initiated the session and its communicating using an upper source port. 12.33.247.10 is our HTTP server communicating from port 80.

In packet 1 we see the client has a TTL of 49. The closest starting TTL match for a known operating system is 64, so this tells us the client is a Linux, UNIX, or Mac system sitting 15 hops away. In packet 2 we see the server with a TTL value of 64, so it must be one of the previously mentioned operating systems sitting on the local network. So, we are on the same collision domain as the server, but sitting 15 hops away from the client.

There is a problem however. Look at packets 6 and 7. Here we see the TTL of both systems changing to 255. An OS will never change it’s TTL during a session, so this looks extremely suspect. Further, we already determined that the client is sitting 15 hops away from us. 255 is the largest possible TTL value as the TTL field is only a single byte (byte 8 in the IP header). So even though the source IP address claims to be the remote client, there is no way that packet could have originated anywhere but from the local network. If the packet had crossed one or more routers, the TTL value would be lower.

The IP ID information does not look right either. In the first three packets from the client we see the IP ID values 0x2a6b (10859), 0x2a95 (10901), and 0x2a96 (10902). This tells us the client is possibly using a +1 incremental IP ID, we just didn’t see 42 of the packets between the first and second packet transmitted. The next IP ID we see from the client is 0xb0f2 (45298). OK, unless we missed over 34,000 packets, this IP ID does not jive.

Note the above analysis would only be theoretical were it not for the inconsistent TTL values. With only three packets to look at, we cannot precisely identify the IP ID increment. It is also possible, but very highly unlikely, that the IP ID increment is completely random and the system just happened to assign two incremental IP IDs, one right after the other. Still, combine the TTL and IP ID information together and they indicate that this final packet could not have originated from the same system.

We have more IP ID data from the server to work with, so let’s take a look at that. The IDs are:

  • 0 (0)
  • 0×3743 (14147)
  • 0xb0f2 (45298)
  • 0×3744 (14148)
  • 0×3745 (14149)
  • 0×3746 (14150)
  • 0×3747 (14151)
  • 0×3748 (14152)
  • 0×3749 (14153)
  • 0x374a (14154)
  • 0x374b (14155)
  • 0x374c (14156)
  • 0x374d (14157)

Take a look at the third listed IP ID, which is from packet 6 in the trace. Note that all of the other IP IDs are incremental +1, but this IP ID does not belong. In fact we can show that the server increments it’s IP ID by +1 and that there is no way this packet originated from the server.

Humm. I wonder if these suspect packets line up with the strange resets we saw:

tshark -r challenge1.cap -T fields -e frame.number -e ip.src -e tcp.srcport -e ip.ttl -e ip.id -e tcp.flags.reset

1       148.78.247.10   26922   49      0x2a6b  0

2       12.33.247.4     80      64      0×0000  0

3       148.78.247.10   26922   49      0x2a95  0

4       148.78.247.10   26922   49      0x2a96  0

5       12.33.247.4     80      64      0×3743  0

6       12.33.247.4     80      255     0xb0f2  1

7       148.78.247.10   26922   255     0xb0f2  1

8       12.33.247.4     80      64      0×3744  0

9       12.33.247.4     80      64      0×3745  0

10      12.33.247.4     80      64      0×3746  0

11      12.33.247.4     80      64      0×3747  0

12      12.33.247.4     80      64      0×3748  0

13      12.33.247.4     80      64      0×3749  0

14      12.33.247.4     80      64      0x374a  0

15      12.33.247.4     80      64      0x374b  0

16      12.33.247.4     80      64      0x374c  0

17      12.33.247.4     80      64      0x374d  0

Ah ha! So if we look at the packets with the strange TTL and IP ID values, these were the strange reset packets sent during the session.

It looks to me like some third system is jumping into the conversation in order to transmit the reset packets. Since these strange packets have a TTL of 255, we know it must be on the same collision domain as where we are sniffing. Since it is on the same collision domain, the Ethernet header information might be helpful:

tshark -r challenge1.cap -T fields -e frame.number -e eth -e tcp.flags.reset

1       Ethernet II, Src: HewlettP_ea:20:ab (00:50:8b:ea:20:ab), Dst: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3)     0

2       Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

3       Ethernet II, Src: HewlettP_ea:20:ab (00:50:8b:ea:20:ab), Dst: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3)     0

4       Ethernet II, Src: HewlettP_ea:20:ab (00:50:8b:ea:20:ab), Dst: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3)     0

5       Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

6       Ethernet II, Src: D-Link_8f:e0:0c (00:50:ba:8f:e0:0c), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)       1

7       Ethernet II, Src: D-Link_8f:e0:0c (00:50:ba:8f:e0:0c), Dst: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3)       1

8       Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

9       Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

10      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

11      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

12      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

13      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

14      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

15      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

16      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

17      Ethernet II, Src: DellComp_20:7d:e3 (00:b0:d0:20:7d:e3), Dst: HewlettP_ea:20:ab (00:50:8b:ea:20:ab)     0

So when the client comes in from the Internet, it passes through an HP system acting as either a router or a firewall. Our Web server is running on Dell hardware. Note our resets (packets 6 and 7) are both being generated by the same system using a D-Link NIC.

So why did the D-Link system try to kill the session? This occurred just after the client sent the suspicious file request. It looks to me like the D-Link system is actually a single honed intrusion prevention system (IPS). When an attack is detected, the IPS attempts to prevent the attack by transmitting reset packets to both ends of the connection.

But we still have some unanswered questions. Was the attack successful and why did the server appear to ignore the IPS’s attempt to kill the session?

Turn in to the next episode to find out.

No comments »

Posted in 2-alert, Packet Decoding

Tags:

Tshark Challenge – Hints 3

October 7th, 2009

This is the third set of hints to the tshark decode challenge I issued last week. You can grab a copy of the decode file from the challenge page.

In my last post we spotted some discrepancies is the TCP stream. Let’s take a closer look at the payload to see if anything looks out of place. The command I’ll be using is:

tshark -r challenge1.cap -x | less

If you are running on Windows, replace the “less” command with the “more” command.

The “-x” switch will cause tshark to print the payload of each packet along with the header summary.  If you page down to packet 4 you should see:

4   0.030787 148.78.247.10 -> 12.33.247.4  HTTP GET /cfide/Administrator/startstop.html HTTP/1.0

0000  00 b0 d0 20 7d e3 00 50 8b ea 20 ab 08 00 45 00   … }..P.. …E.

0010  01 11 2a 96 00 00 31 06 cf d2 94 4e f7 0a 0c 21   ..*…1….N…!

0020  f7 04 69 2a 00 50 6a 97 b8 6f 3a 88 39 cd 80 18   ..i*.Pj..o:.9…

0030  ff ff 42 fc 00 00 01 01 08 0a 00 ec 48 4b 3d 76   ..B………HK=v

0040  0e 8b 47 45 54 20 2f 63 66 69 64 65 2f 41 64 6d   ..GET /cfide/Adm

0050  69 6e 69 73 74 72 61 74 6f 72 2f 73 74 61 72 74   inistrator/start

0060  73 74 6f 70 2e 68 74 6d 6c 20 48 54 54 50 2f 31   stop.html HTTP/1

0070  2e 30 0d 0a 48 6f 73 74 3a 20 31 32 2e 33 33 2e   .0..Host: 12.33.

0080  32 34 37 2e 34 0d 0a 55 73 65 72 2d 41 67 65 6e   247.4..User-Agen

0090  74 3a 20 4d 6f 7a 69 6c 6c 61 2f 35 2e 30 20 5b   t: Mozilla/5.0 [

00a0  65 6e 5d 20 28 57 69 6e 39 35 3b 20 55 29 0d 0a   en] (Win95; U)..

00b0  52 65 66 65 72 65 72 3a 20 68 74 74 70 3a 2f 2f   Referer: http://

00c0  31 32 2e 33 33 2e 32 34 37 2e 34 2f 0d 0a 58 2d   12.33.247.4/..X-

00d0  46 6f 72 77 61 72 64 65 64 2d 46 6f 72 3a 20 31   Forwarded-For: 1

00e0  34 38 2e 36 34 2e 31 34 37 2e 31 36 38 0d 0a 43   48.64.147.168..C

00f0  61 63 68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 6d 61   ache-Control: ma

0100  78 2d 73 74 61 6c 65 3d 30 0d 0a 50 72 61 67 6d   x-stale=0..Pragm

0110  61 3a 20 6e 6f 2d 63 61 63 68 65 0d 0a 0d 0a ce   a: no-cache…..

0120  f8 43 76                                                    .Cv

This is the “GET” request for the suspicious file name. There are a couple of fields in this payload that do not look right. The “HOST:” field should identify which Web server the client was attempting to access. This should always be a fully qualified domain name, like “www.fubar.com” or similar. The fact that the server’s IP address is listed tells me a Web browser was not used to generate this session.

It is possible to host multiple Web sites on the same physical server. The server figures out which specific site you want to access by analyzing this host field. If Web browsers didn’t follow this rule, co-location servers with multiple sites hosted on the same physical box would never work. So this tells me the client is going after the actual Web server process, not a Web site hosted on the system.

The “User-Agent:” field looks odd as well. While it is possible the client is still running Windows 95, it is unlikely.

The referer field is incorrect as well. This should show us the full URI the client was accessing when they were directed to this page. It should include the fully qualified domain name, as well as the exact page on the site that referred them to this page. In fact if the referer is a search engine, the field will also include what search parameters were used when they were directed to our site. Listing an IP address is completely incorrect.

There is one last interesting piece of information in this payload. The “X-Forwarded-For:” field tells us that the source IP address in the IP header is acting as an HTTP proxy for whatever IP address is listed in this field. It is not uncommon for attackers to bounce their attacks off of a public proxy server. This way if you detect the attack in your Web server access log, you will think the source IP address is the hostile entity as the X-Forwarded-For field will not be listed.

So we have a suspect file request, from an IP that is trying to hide their identity, using packets that have suspicious values. We don’t need a IDS to tell us this is probably an attacker looking for a known to be vulnerable file.

Now take a look at packets 8 through 17. Each one is the server attempting to tell the client “I’m sorry, I’m not running that vulnerable file. Please try a different vulnerable file if you want to compromise me”, via 404 error messages.

So the flow goes something like this:

  • Client sends a probe for a potentially vulnerable file
  • Server resets the connection
  • Client resets the connection
  • Server continually tells the client it does not have that file

So why the resets and why did the server ignore them? Tune in tomorrow to find out…

No comments »

Posted in 3-err, Packet Decoding

Tags:

Tshark Challenge – Hints2

October 6th, 2009

Yesterday we left off taking an initial look at the decode file. A first pass left us scratching our head because we saw a 404 error followed by multiple retransmissions. In this hint we’ll dig into the trace a little deeper.

Let’s go back to our initial decode and follow what happened packet by packet:

tshark -r challenge1.cap

1   0.000000 148.78.247.10 -> 12.33.247.4  TCP 26922 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=0 TSV=15485003 TSER=0

2   0.000080  12.33.247.4 -> 148.78.247.10 TCP http > 26922 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=1031147147 TSER=15485003 WS=0

3   0.029341 148.78.247.10 -> 12.33.247.4  TCP 26922 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0 TSV=15485003 TSER=1031147147

4   0.030787 148.78.247.10 -> 12.33.247.4  HTTP GET /cfide/Administrator/startstop.html HTTP/1.0

5   0.030841  12.33.247.4 -> 148.78.247.10 TCP http > 26922 [ACK] Seq=1 Ack=222 Win=6432 Len=0 TSV=1031147150 TSER=15485003

6   0.031319  12.33.247.4 -> 148.78.247.10 TCP http > 26922 [RST, ACK] Seq=1 Ack=222 Win=0 Len=0

7   0.031385 148.78.247.10 -> 12.33.247.4  TCP [TCP ACKed lost segment] 26922 > http [RST, ACK] Seq=1 Ack=222 Win=0 Len=0

8   0.031610  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

9   0.031664  12.33.247.4 -> 148.78.247.10 HTTP HTTP/1.1 404 Not Found  (text/html)

10   0.251838  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

11   0.711825  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

12   1.631812  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

13   3.471773  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

14   7.153143  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

15  14.511594  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

16  29.231324  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

17  58.670815  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

Our first three packets are the TCP handshake. This portion looks pretty normal. In packet 4, we see the client send a “GET” request for a file. This file request strikes me as suspicious. A file named “startstop.html” in the “Administrator” directory does not exactly sound like a file we would want to be serving up to the public at large. We’ll make a note of this and come back to it later.

In packet 5 we see the server acknowledge the data request. After this packet, things get a little odd. In packet 6, we see the server transmit a reset packet to kill the connection. This is an indication that the server feels something has gone wrong with the session and that it is unrecoverable. This is extremely odd behavior for TCP as it tries very hard to be reliable. It normally will transmit multiple attempts to reestablish a connection if it thinks something went wrong. You can see normal recovery behavior in packets 10 through 17, which more closely matches how TCP will attempt to maintain connectivity. There is a .5 ms difference in the timestamp between packets 5 and 6. A normal operating system would never determine in that short a period of time that the TCP session is unrecoverable.

In packet 7, things continue to act strangely. We see the client respond to the server’s reset packet with a reset packet of its own. This is certainly not normal IP behavior as the RFCs state you should never respond to an error packet. So during a normal session you would never see this type of error exchange. Something is obviously very wrong.

In packet 9, we see the server send a 404 error message. There are a couple of problems here. To start, the server already sent a reset indicating it considered the session to be unrecoverable. A system should never continue to send data after issuing a reset packet. In fact, the server continues to transmit all the way to packet 17. What makes this activity even stranger is that the client has issued a reset as well. So the server is not only ignoring the fact that it issued a reset, it is also ignoring the reset sent by the client.

So needless to say this is very strange TCP behavior. In my next post I’ll dig deeper into the payloads to get a better look at what is going on.

No comments »

Posted in 3-err, Packet Decoding

Tags:

Tshark Challenge – Hints1

October 5th, 2009

Last week I posted a Libpcap file and challenged you to figure out as much as you could about the trace using tshark. In this post I’ll start you through the process of analyzing the decode. I WIL NOT cover it completely. My goal here is to give a leg up to the folks who do not even know where to start. I’ll add more details as the week goes on.

Getting started

The first thing you should do is have a look at the contents of the file. I’ll use the –r switch to read in the contents of the file. This will override tshark’s default setting of sniffing on the first detected interface. Normally I would pipe the output through the “less” command (or “more” on Windows), but there are only 17 packets in the file.

tshark -r challenge1.cap

1   0.000000 148.78.247.10 -> 12.33.247.4  TCP 26922 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=0 TSV=15485003 TSER=0

2   0.000080  12.33.247.4 -> 148.78.247.10 TCP http > 26922 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=1031147147 TSER=15485003 WS=0

3   0.029341 148.78.247.10 -> 12.33.247.4  TCP 26922 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0 TSV=15485003 TSER=1031147147

4   0.030787 148.78.247.10 -> 12.33.247.4  HTTP GET /cfide/Administrator/startstop.html HTTP/1.0

5   0.030841  12.33.247.4 -> 148.78.247.10 TCP http > 26922 [ACK] Seq=1 Ack=222 Win=6432 Len=0 TSV=1031147150 TSER=15485003

6   0.031319  12.33.247.4 -> 148.78.247.10 TCP http > 26922 [RST, ACK] Seq=1 Ack=222 Win=0 Len=0

7   0.031385 148.78.247.10 -> 12.33.247.4  TCP [TCP ACKed lost segment] 26922 > http [RST, ACK] Seq=1 Ack=222 Win=0 Len=0

8   0.031610  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

9   0.031664  12.33.247.4 -> 148.78.247.10 HTTP HTTP/1.1 404 Not Found  (text/html)

10   0.251838  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

11   0.711825  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

12   1.631812  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

13   3.471773  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

14   7.153143  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

15  14.511594  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

16  29.231324  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

17  58.670815  12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]

Some details that immediately grab my attention:

  1. This is an HTTP session
  2. The connection attempted to access a file that does not exist (404 error in #9)
  3. There were communication issues with the session (#10-17 are retransmissions)

So right away this trace leaves me asking a few questions:

  1. What’s up with the request for a file that does not exist?
  2. Why are we having communication problems?

That’s it for now. Tomorrow I’ll post another hint.

No comments »

Posted in 3-err, Packet Decoding

Tags:

Tshark Decode Challenge

October 2nd, 2009

In my last post I covered tshark and discussed how to manipulate the output during a decode. There is no better way to learn than by doing, so I decided to post a challenge. In this post I’ll provide a Libpcap file. Your mission Mr. Phelps, should you choose to accept it, is to attempt to identify what is going on within the decode file using tshark.

Installing tshark

In order to install tshark, you need to install Wireshark. You can grab a current copy from the download page. Once you do, the installation process is dependent on what platform you are using:

Linux/UNIX

If you are running Fedora or Red Hat, you do not need to visit the download page. You can install Wireshark directly through Yum:

su –

yum –y install wireshark.i586

If you are running a UNIX flavor or some other Linux distro, you may need to grab the tar archive from the above link and compile Wireshark for your system. Pay close attention to the dependencies as there are a lot of them. Ensure that “./configure” completes successfully before building your binaries.

Windows

  1. Download the self-extracting executable
  2. Run the executable
  3. Accept Unknown Publisher screen by clicking “run” button
  4. Follow the on-screen prompts accepting the defaults
  5. Install WinPcap (make sure box is checked)
  6. Install NPF service if non-Administrator users will be running the tool
  7. Add “C:\Program Files\Wireshark” to the end of your path statement

OS X

  1. Select the image that matches your processor type (Intel or PPC)
  2. Open with DiskimageMounter
  3. Open the “Read me first.rtf”
  4. Follow the “Quick Setup” instructions

The challenge

Here’s the challenge file:

challenge1.cap

And here are the hashes of the file to verify your download:

MD5: ea92f08d9ba104c6cf7756564eb5aef9  challenge1.cap
SHA-1: 71041ab0f670c5b9558183a56fe1bb80e8b10506  challenge1.cap

Good luck and starting next week I’ll post a little more info about the file every day to help move you through the decode process.

No comments »

Posted in 3-err, Packet Decoding

Tags:

Analyzing packets with tshark

October 1st, 2009

In an earlier post I discussed how to adjust the display output in tshark. The post generated a lot of interest, so I decided to add some additional information on using tshark to decode packets. This post assumes you have read the one linked to above.

Why use tshark instead of tcpdump/windump?

Many old time decoders swear by tcpdump, and it’s Windows counterpart windump. Both are great tools, but they have become a little dated. While patches are still released from time to time, little has been done to update or expand their decode capability. Wireshark on the other hand, as well as it’s included tools such as tshark, include decode support for hundreds of protocols and the list is growing all of the time. While you can certainly analyze packets without the decoders, they make the process go far quicker.

Why use tshark instead of Wireshark?

Wireshark is a great tool when you are doing an in-depth payload analysis. It can be a little tedious however if you wish to follow a specific field over multiple packets. For example let’s say we wish to watch the TCP sequence number increment over multiple packets. With Wireshark, I would have to note the sequence number location in the middle pane and page through each packet. Since there is no way to line up the value over multiple packets, I’m forced to remember previous values when performing my calculations. With tshark however, we can do something like this:

tshark -n -T fields -e ip.src -e tcp.seq -e tcp.len

64.111.96.38    0        0

64.111.96.38    1        0

64.111.96.38    1        363

64.111.96.38    364     1448

64.111.96.38    1812    1448

64.111.96.38    3260    1448

64.111.96.38    4708    1448

64.111.96.38    6156    1448

64.111.96.38    7604    1448

64.111.96.38    10500   310

64.111.96.38    9052    1448

64.111.96.38    10810   0

Remember that the TCP sequence number (the second field) should increment based on the size of the payload (the third field). Note that packets 10 and 11 where received out of order. This could mean there are multiple paths available between our location and the identified IP address. While Wireshark would show us this information as well, in this view it is a bit easier to follow the flow.

More on displaying fields

As discussed in my earlier post, as well as shown above, the “-T” switch can be used to manipulate the output being displayed. You can choose from XML, Postscript or plain text. The most useful option is “fields” as it lets you pick and choose which specific fields you want printed out. As shown above, the “-e” switch can then be used to identify which fields you wish to display. The complete list of filters can be found here. A nice cheat sheet of the most commonly used values can be found here.

If you define a specific protocol, tshark will display some of the more important fields from that header. For example to look at only the Ethernet header:

tshark -T fields -e eth

Ethernet II, Src: TyanComp_56:3b:14 (00:e0:81:56:3b:14), Dst: Dell_d1:fe:ef (00:12:3f:d1:fe:ef)

Ethernet II, Src: TyanComp_56:3b:14 (00:e0:81:56:3b:14), Dst: Dell_d1:fe:ef (00:12:3f:d1:fe:ef)

Ethernet II, Src: TyanComp_56:3b:14 (00:e0:81:56:3b:14), Dst: Dell_d1:fe:ef (00:12:3f:d1:fe:ef)

Note the type and CRC fields are not displayed, as they are not as “interesting” as the source and destination MAC address. We would have to define these fields specifically (ip.type and ip.trailer) if we wish to see them.

One side effect of printing fields is that tshark will add a blank line for any packet that does not contain the specified field. This can be a pain when analyzing HTTP packets as not every packet will contain a URI. An easy way to clean this up is to pipe it through grep. For example:

tshark -T fields -e http.request.uri | grep -v “^$”

/

/styles.css

/templates/classic/images/starsnstripes.gif

/templates/classic/images/unionjack.gif

/templates/classic/images/amazon.header.gif

/c_images/2009/05/07/71090.2.jpg

In my last post I discussed grep as well as where to grab a free version for Windows. The above grep command uses the “-v” switch to match all lines that do not contain the specified value. “^$” defines a blank line. So the above grep command filters out all blank lines.

More display options

Tshark has a number of other useful display options. For example you can print headers at the beginning of the output:

tshark -n -T fields -e ip.src -e ip.dst -E header=y

ip.src  ip.dst

64.111.96.38    12.5.200.100

64.111.96.38    12.5.200.100

64.111.96.38    12.5.200.100

If you plan on importing the information into a spreadsheet or database, you can define which character to use between fields:

tshark -T fields -e ip.src -e ip.dst -e tcp.dstport -E header=y -E separator=;

ip.src;ip.dst;tcp.dstport

64.111.96.38;12.5.200.100;34831

64.111.96.38;12.5.200.100;34831

64.111.96.38;12.5.200.100;34831

Packet statistics

Tshark has solid statistical capability as well. If you need to process a lot of files, sometimes it is help to start with looking at the raw stats. The “-z” switch is used to specify the statistics you wish to analyze. Normally these will be printed at the end of the decode information, but if you use the “-q” switch only the stats will be printed. Here’s an example:

C:\testing>tshark -q -z http,stat, -z http,tree -r test.cap

===============================================================

HTTP/Packet Counter           value            rate         percent

——————————————————————-

Total HTTP Packets            64915       0.048999

HTTP Request Packets           459       0.000346           0.71%

GET                                       24       0.000018           5.23%

HEAD                                   433       0.000327          94.34%

OPTIONS                                 2       0.000002           0.44%

HTTP Response Packets          448       0.000338           0.69%

???: broken                            0       0.000000           0.00%

1xx: Informational                    0       0.000000           0.00%

2xx: Success                         12       0.000009           2.68%

200 OK                                12       0.000009         100.00%

3xx: Redirection                   0       0.000000           0.00%

4xx: Client Error                436       0.000329          97.32%

404 Not Found                  432       0.000326          99.08%

403 Forbidden                      4       0.000003           0.92%

5xx: Server Error                  0       0.000000           0.00%

Other HTTP Packets           64008       0.048314          98.60%

===============================================================

===============================================================

HTTP Statistics

* HTTP Status Codes in reply packets

HTTP 200 OK

HTTP 403 Forbidden

HTTP 404 Not Found

* List of HTTP Request methods

GET  24

OPTIONS  2

HEAD  433

===============================================================

A couple of things stick out in this output. First, we have four 403 errors indicating that someone was attempting to access something they did not have permission to. Also, out of 459 HTTP requests, 432 of them were for non-existent files. We are also seeing a lot of “HEAD” requests which could be a proxy, or could be an attacker attempting to keep from being logged to the Web server’s access log. Clearly this capture file includes some suspect traffic that warrants further investigation.

Tshark can even produce general throughput statistics if you need them. This is an excellent way to check for DoS attacks:

tshark -q -z io,stat,10 -r test.cap

===============================================================

IO Statistics

Interval: 10.000 secs

Column #0:

|   Column #0

Time            |frames|  bytes

000.000-010.000     254    145081

010.000-020.000     145     80003

020.000-030.000     125     65527

030.000-040.000       4       264

===============================================================

Note tshark will print the frame and byte count for any interval specified, defined in seconds. The only problem is that if you are capturing packets off of the wire, stats are not displayed until the capture ends.

Exec Summary

Tshark is an extremely capable packet analysis tool that has surpassed it’s counterparts tcpdump and windump. Combine the extensive decode capability along with the flexible output display, and tshark has become the tool of choice for many packet decoders.

No comments »

Posted in 2-alert, Network Security, Packet Decoding

Tags: