SecurityFeed.info » DVLabs: Blogs

« Expand/Collapse

DVLabs: Blogs (10 unread)

September 05, 2008
18:17
ThreatLinQ: Taking Out the Trash
» ‎ DVLabs: Blogs

Posted by Mike Dausin
One of the often cited benefits of IPS is the ability to keep ancient attacks from 'polluting' your otherwise pristine network. The fact is, attacks such as Code Red and SQL Slammer are still out there in force. And while there may be literally a 0% chance of these attacks being successful on a machine in your environment, there is simply no reason to let them into your network.

Of course, when we tell people this, the first question we often get asked is "are these attacks REALLY out there still?" The answer is definitely "Yes!"

Take Slammer for instance. Over the last month, ThreatLinQ has detected no less than 73,300 infected slammer sources which produced tens of millions of packets. Sure, slammer packets are small, and not likely to cause too much congestion. But why let Slammer on your network at all, when it can be easily blocked?

Also, I should also point out that although slammer would never appear on YOUR network (our readers/customers tend to be on the ball,) infections do still occur. Below is a graph of a host that was clearly infected on 8/22/2008.

I wonder if the admin of this network has pulled out all his/her hair yet trying to figure out why the net is so slow...
September 04, 2008
21:36
MindshaRE: Using Structures
» ‎ DVLabs: Blogs
Posted by Cody Pierce
This week on MindshaRE we take a quick look at structures. I often see new reverse engineers skipping the creation of structures they encounter when disassembling a binary. While it is true that they can be slightly time consuming to create, the payoff in the end can far outweigh the minimal time investment. The biggest benefit will be during such things as OO method invocation, file format parsing, or packet tracing. Hopefully the examples I have will convince you to spend those extra 20 minutes defining clean structures next time you run across them in a binary.

MindshaRE is our weekly look at some simple reverse engineering tips and tricks. The goal is to keep things small and discuss every day aspects of reversing. You can view previous entries here by going through our blog history.

Everyone knows what a structure is. A defined container for structured data that will be programmatically accessed. In a higher level language access to these elements is typically by name, for instance sk_buff->len. However, in assembly, we have to use an offset from the start of the structure. This may be where new reverse engineers go cross-eyed. It's easy to understand that accessing sk_buff->len gets the length of the packet data in our structure. But when you encounter "mov eax, dword ptr [ebx+30h]" things may get a little confusing (Note: I didn't look up the actual offset for sk_buff->len). No need to fret though, assembly can be much easier to understand if we spend time defining structures, and their members, into a more readable form.

First, lets look at the structures window in IDA (Shift+F9). Opening that up doesn't look to inviting, sans some help text. Here is what you probably see.
```
 ; Ins/Del : create/delete structure
```
```
 ; D/A/*   : create structure member (data/ascii/array)
```
```
 ; N       : rename structure or structure member
```
```
 ; U       : delete structure member
```
If you have loaded symbols you may have some additional structures listed, but in general this window is empty when disassembling a new binary. The commands should be straight forward. When we want a new structure we use Ins/Del (Sorry Apple laptops!) to create it. Doing so will ask us for a name. There also exist some extra options like "Create before current structure" and "Don't include in the list" which are useful, but in most cases will not be needed.

Before we finish with this window by hitting "OK" click the "Add standard structure" button. A slew of important data structures should populate the window. The almost 10k structures listed are for common structures that occur in various SDK's like the Windows Platform SDK. Choosing one of the structures will automatically add it, and all of its associated members which can be extremely helpful. You can experiment with these later, for now hit "Cancel" and create your new structure. You should get the following.
```
00000000 example         struc ; (sizeof=0x0)
```
```
00000000 example         ends
```
This is our empty structure. Not very exciting, so lets add a member. Clicking the top of the example structure and hitting "D" gives us a new field, or member. The default size of newly created members/fields is one byte. We can easily change this by selecting the field, and hitting "D" again. Just like working with data in the disassembly window, repeated "D" keystrokes will cycle this between the supported data types (Byte, Word, Dword). Also notice the size of the structure will update accordingly. Let's add a few more just for fun. Here's mine.
```
00000000 example         struc ; (sizeof=0x10)
```
```
00000000 field_0         dd ?
```
```
00000004 field_4         dd ?
```
```
00000008 field_8         dd ?
```
```
0000000C field_C         db ?
```
```
0000000D field_D         db ?
```
```
0000000E field_E         db ?
```
```
0000000F field_F         db ?
```
```
00000010 example         ends
```
The automatic naming of members is handy. As you can see they are named according to their offset as well. For instance field_4 will be "example+4" in assembly. Let's say that through our reversing efforts we know that example+4 is a dword containing a type. We can change this name and get that much closer to a readable structure we can use in our disassembly. To achieve this highlight field_4 and hit "N". This brings up a name window. Let's put in "type" for the name.
```
00000000 example         struc ; (sizeof=0x10)
```
```
00000000 field_0         dd ?
```
```
00000004 type            dd ?
```
```
00000008 field_8         dd ?
```
```
0000000C field_C         db ?
```
```
0000000D field_D         db ?
```
```
0000000E field_E         db ?
```
```
0000000F field_F         db ?
```
```
00000010 example         ends
```
Fine. We have a structure represented in our structures window. Now we must use it. One of the most important things to keep in mind when we start to use these structures is to be certain we are applying them correctly. It does you zero good to apply this example struct to something that is actually an exception handler structure. Let's pretend this assembly snippet is accessing our newly created structure.
```
.text:01004130     push    dword ptr [eax+4]
```
```
.text:01004133     call    _createnum
```
This is typical structure access. Without applying a type to it the argument seems ambiguous. Let's fix that by highlighting the offset "4" in "eax+4" and hitting "T". This brings up our defined structures. You should see the following.

Selecting our example.type member will convert the meaningless "eax+4" into the easily readable assembly below.
```
.text:01004130     push    [eax+example.type]
```
```
.text:01004133     call    _createnum
```
Creating and applying structures may seem tedious. But I promise it will make your life much easier when you start applying your newly created structures to your binary. Creating structures can indeed get overwhelming when dealing with large structures. For instance, creating a structure with over 30 members by hand is a nightmare. In this case we can automate the task.
```
#include <idc.idc>
```
```
static main()
```
```
{
```
```
    auto id, rc;
```
```
    auto i, count;
```
```
    auto sname, oname;
```
```
    
```
```
    sname = AskStr("user_struct", "Structure name");
```
```
    count = AskLong(64, "Number of dword sized members") / 4;
```
```
    
```
```
    id = AddStrucEx(-1, sname, 0);
```
```
    for (i=0; i <= count; i++)
```
```
    {
```
```
        oname = "field_" + ltoa(i * 4, 16);
```
```
        rc = AddStrucMember(id, oname, i*4, 0x20000400, -1, 4);
```
```
    }
```
```
}
```
Running this will create a structure with your name and number of dword elements. Writing IDC scripts to define structures can be very powerful. Lets take another look at a more complex example combining all of these techniques.

Adobe Acrobat's plugin architecture makes extensive use of structures in the form of classes. Taking a look at the assembly will give you nightmares at night if you do not define and apply structure labels. Take a look at a small example.
```
.text:23834076     mov     esi, dword_239345BC
```
```
.text:2383407C     mov     eax, dword_2393459C
```
```
.text:23834081     add     esi, 18h
```
```
.text:23834084     call    dword ptr [eax+600h]
```
```
...                
```
```
.text:238340A7     movzx   eax, ax
```
```
.text:238340AA     mov     [ebp+var_4], eax
```
```
.text:238340AD     mov     eax, dword_239345BC
```
```
.text:238340B2     push    esi
```
```
.text:238340B3     call    dword ptr [eax+30h]
```
```
.text:238340B6     add     esp, 24h
```
```
.text:238340B9
```
```
.text:238340B9 loc_238340B9:
```
```
.text:238340B9     mov     eax, dword_23934560
```
```
.text:238340BE     call    dword ptr [eax+0Ch]
```
With nothing labeled this is nonsense. Fixing up the names and adding structures gives us the following.
```
.text:23834076     mov     esi, pASExtraHFT
```
```
.text:2383407C     mov     eax, pAcroViewHFT
```
```
.text:23834081     add     esi, 18h
```
```
.text:23834084     call    [eax+s_acroviewHFT.AVAppGetLanguageEncoding] ; AVProcs.h
```
```
...                
```
```
.text:238340A7     movzx   eax, ax
```
```
.text:238340AA     mov     [ebp+var_4], eax
```
```
.text:238340AD     mov     eax, pASExtraHFT
```
```
.text:238340B2     push    esi
```
```
.text:238340B3     call    [eax+s_asextraHFT.ASTextDestroy] ; ASExtraProcs.h
```
```
.text:238340B6     add     esp, 24h
```
```
.text:238340B9
```
```
.text:238340B9 loc_238340B9:
```
```
.text:238340B9     mov     eax, pCoreHFT
```
```
.text:238340BE     call    [eax+s_coreHFT.ACPopExceptionFrame] ; AcroRd32.ACPopExceptionFrame
```
Much better. We can now focus on what this function is doing, instead of the methods it is invoking. Also notice when we apply a name we get a comment inserted. You can do this by adding comments to members in your defined structure. All of these names were automatically added to the IDB via a script. A little research and work before reversing has saved countless hours.

There are many other facets to adding and using structures. I have touched on their basic usage. Try to play around with creating structures and applying them to your IDB. I cant stress enough how important it is when getting into larger projects. Hope this gave you a good starting point.

-Cody

[UPDATE] I uploaded the vt2st.idc IDC script that Ali mentioned below in the comments.
August 30, 2008
3:04
Three Letter Acronyms and the Imminent Death of the Net
» ‎ DVLabs: Blogs

Posted by Rob King

Years ago, I was much more heavily involved in the network engineering side of the network world. Don't get me wrong, there's still plenty of groveling through packet captures here at TippingPoint's orbiting HQ, but I used to actually design networks and configure routers and do all of the nuts-and-bolts stuff that makes networks run.

As a result of this, I know a reasonable amount about various low-level network protocols, including the wonderful, critical, byzantine, and obscure Border Gateway Protocol (BGP).

BGP is an example of an Exterior Gateway Protocol (EGP), as opposed to an Interior Gateway Protocol (IGP). There, see? That clears things up.

Seriously, though. The difference between interior and exterior gateway protocols is whether they are designed to maintain routing for nodes within an Autonomous Systems (ASes) or nodes between ASes.

An Autonomous System is, well, an autonomous system. It is a network that, at the lowest layer of the Internet, is distinct from all other networks. Basically, an autonomous system is supposed to be entirely responsible for traffic within its borders. If you know in what AS your traffic's destination lives, once it hits that AS, it ceases to be anyone's responsibility but theirs to get that traffic properly routed.

Interior gateway protocols are designed to handle routes within ASes. Common protocols include Open Shortest Pathway First (OSPF), Interior Gateway Routing Protocol (IGRP) and Enhanced Interior Gateway Routing Protocol (EIGRP). These protocols are used to maintain routing tables and figure out the best paths between hosts in one AS - such as between campuses in a large corporation or points-of-presence in a telecommunications network.

EGPs handle the problem of routing traffic between different ASes. For example, a multi-homed host may be reachable via both Time Warner's network and Sprint's network. That means that the multi-homed host is reachable via two autonomous systems. Which route should be chosen to get there?

ASes use EGPs to advertise the ranges of IP addresses that their autonomous system knows how to route to, and how well they can route traffic to them.

The only EGP currently in use is the Border Gateway Protocol. BGP is considered to be the core routing protocol of the Internet; it maintains all of the routes between all of the networks that, together, comprise the modern Internet. It is therefore very important.

Well, BGP was designed in a simpler time, a time when you felt like you could trust your neighbor. Therefore, security wasn't really its strong point. In fact, its security is a major weak point.

What's the point of all this, you may ask? Well, everyone remembers Dan Kaminsky's ginormous DNS flaw that made the rounds and scared a lot of people. Now, an equally-if-not-worse way of exploiting the design of BGP has surfaced, thanks to Alex Polisov and Tony Kapela at this year's just-passed DefCon conference.

I'm not going to go into the details of the attack - I don't want to steal their thunder - but I'll go over a bit why this is scary and interesting.

First off, BGP really is everywhere, just like DNS. Unlike DNS, however, it's not ubiquitously understood - a lot of network administrators have never even heard of BGP, and very few people have ever actually administered BGP. Therefore a flaw in the design of BGP may not be addressed as quickly as a flaw in DNS. Active attacks against the flaw might not even be noticed by most network engineers.

The other thing that makes this interesting is that it's possibly the sign of a true sea change in the way the Internet works. When the Internet first got off of the ground, all of the nodes were more-or-less trusted, and the protocols were designed accordingly. Nowadays, none of the nodes can trust any of the other nodes. The Internet has grown very quickly, but the core protocols have, by necessity, stayed close to their original designs.

The core protocols are going to have to start changing, perhaps more quickly than we're really comfortable with. The Big One - the transition to IPv6, hasn't happened yet, and it will undoubtedly be the worst shakeup the Internet has undergone since the September That Never Ended. Even after that, though, we're going to have to ferret out all of the older protocols, figure out how to secure them, and then - worst of all - go through the long and arduous process of actually securing them.

As an example, look at DNSSEC - the security extensions for DNS, were first publicized in 1997. Still, after 11 years, practically no one has implemented DNSSEC. Certificate-authenticated email transfer is likewise languishing.

All of these efforts failed because as long as one individual in the system is unsecured, the whole thing breaks down. Changing to a completely secure DNS, SMTP, or BGP infrastructure is going to be like the day Sweden switched to driving on the right. It's going to be expensive, it's going to be painful, and it's going to cause some accidents, but in the end, we'll all be better off for it.
August 29, 2008

Permalink for 'DVLabs__Blogs/2008/08/29/ThreatLinQ__A_Brave_New_World__Legitimate_Script_Obfuscation_'

20:55

ThreatLinQ: A Brave New World: Legitimate Script Obfuscation

» ‎ DVLabs: Blogs

Posted by Marc Eisenbarth

As a filter writer, there is a blurred line between blocking real attacks and Internet annoyances. For example, today's Internet advertisements often use the same obfusction tactics as attackers in order to avoid scrubbing by content filtering systems.

I have been doing some research on Peer-To-Peer (P2P) filters and came across something that illustrates this point very nicely. I came across the following trace that sent to a server that is on one of my IP watch lists:

0000  47 45 54 20 2F 63 67 69 2D 62 69 6E 2F 73 5F 77  GET /cgi-bin/s_w

0010  63 5F 63 6F 72 65 76 33 3F 76 3D 6D 26 74 3D 31  c_corev3?v=m&t=1

0020  20 48 54 54 50 2F 31 2E 31 0D 0A 41 63 63 65 70   HTTP/1.1..Accep

0030  74 3A 20 2A 2F 2A 0D 0A 52 65 66 65 72 65 72 3A  t: */*..Referer:

0040  20 68 74 74 70 3A 2F 2F 67 61 6D 65 73 2E 73 69   http://games.si

0050  6E 61 2E 63 6F 6D 2E 63 6E 2F 69 66 72 61 6D 65  na.com.cn/iframe

0060  2F 32 30 30 38 2D 30 37 2D 30 39 2F 31 31 36 33  /2008-07-09/1163

0070  2E 73 68 74 6D 6C 0D 0A 41 63 63 65 70 74 2D 4C  .shtml..Accept-L

0080  61 6E 67 75 61 67 65 3A 20 7A 68 2D 63 6E 0D 0A  anguage: zh-cn..

0090  55 41 2D 43 50 55 3A 20 78 38 36 0D 0A 41 63 63  UA-CPU: x86..Acc

00A0  65 70 74 2D 45 6E 63 6F 64 69 6E 67 3A 20 67 7A  ept-Encoding: gz

00B0  69 70 2C 20 64 65 66 6C 61 74 65 0D 0A 55 73 65  ip, deflate..Use

00C0  72 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61  r-Agent: Mozilla

00D0  2F 34 2E 30 20 28 63 6F 6D 70 61 74 69 62 6C 65  /4.0 (compatible

00E0  3B 20 4D 53 49 45 20 37 2E 30 3B 20 57 69 6E 64  ; MSIE 7.0; Wind

00F0  6F 77 73 20 4E 54 20 35 2E 31 3B 20 51 51 44 6F  ows NT 5.1; QQDo

0100  77 6E 6C 6F 61 64 20 31 2E 37 3B 20 54 68 65 57  wnload 1.7; TheW

0110  6F 72 6C 64 29 0D 0A 48 6F 73 74 3A 20 77 6F 6F  orld)..Host: woo

0120  63 61 6C 6C 2E 67 61 6D 65 73 2E 73 69 6E 61 2E  call.games.sina.

0130  63 6F 6D 2E 63 6E 0D 0A 43 6F 6E 6E 65 63 74 69  com.cn..Connecti

0140  6F 6E 3A 20 4B 65 65 70 2D 41 6C 69 76 65 0D 0A  on: Keep-Alive..

0150  43 6F 6F 6B 69 65 3A 20 53 49 4E 41 47 4E 3D 30  Cookie: SINAGN=0

0160  7C 31 32 31 37 36 34 34 37 37 34 32 36 35 3B 20  |1217644774265;

0170  73 69 6E 61 52 6F 74 61 74 6F 72 2F 3D 32 33 3B  sinaRotator/=23;

0180  20 53 49 4E 41 47 4C 4F 42 41 4C 3D 31 35 32 2E   SINAGLOBAL=152.

0190  32 33 2E 36 31 2E 31 36 33 2E 33 32 31 30 32 31  23.61.163.321021

01A0  32 31 33 37 36 36 32 39 38 33 31 31 3B 20 76 6A  213766298311; vj

01B0  75 69 64 73 3D 35 62 31 34 66 39 38 33 39 2E 31  uids=5b14f9839.1

01C0  31 62 38 30 34 32 61 37 39 66 2E 30 2E 31 62 30  1b8042a79f.0.1b0

01D0  62 64 61 62 61 32 66 33 66 66 63 3B 20 76 6A 6C  bdaba2f3ffc; vjl

01E0  61 73 74 3D 31 32 31 37 36 34 34 37 37 38 3B 20  ast=1217644778;

01F0  41 70 61 63 68 65 3D 31 35 32 2E 32 33 2E 36 31  Apache=152.23.61

0200  2E 31 36 33 2E 38 36 38 36 31 32 31 37 36 33 30  .163.86861217630

0210  32 33 33 36 37 32 3B 20 53 45 3D 39 43 41 41 36  233672; SE=9CAA6

0220  46 34 33 35 34 30 37 41 42 31 36 32 44 44 37 38  F435407AB162DD78

0230  45 43 37 42 43 45 45 32 37 33 46 37 36 37 37 42  EC7BCEE273F7677B

0240  36 36 44 30 30 35 34 36 36 41 35 41 42 41 32 39  66D005466A5ABA29

0250  39 31 30 42 33 44 34 42 30 35 44 42 32 43 45 33  910B3D4B05DB2CE3

0260  30 46 35 30 37 39 41 44 42 32 34 38 30 30 39 45  0F5079ADB248009E

0270  43 39 43 32 35 30 32 45 33 32 34 46 41 36 46 39  C9C2502E324FA6F9

0280  43 30 34 30 37 42 41 44 34 39 44 32 39 36 46 32  C0407BAD49D296F2

0290  38 39 43 30 36 38 32 42 35 37 38 30 44 42 35 39  89C0682B5780DB59

02A0  43 45 37 45 33 44 43 37 34 30 30 37 33 36 46 35  CE7E3DC7400736F5

02B0  35 45 41 33 37 36 33 31 38 36 34 3B 20 53 43 54  5EA37631864; SCT

02C0  3D 31 31 3B 20 53 41 3D 30 25 37 43 30 25 37 43  =11; SA=0%7C0%7C

02D0  30 25 37 43 30 25 37 43 31 25 37 43 31 25 37 43  0%7C0%7C1%7C1%7C

02E0  31 25 37 43 31 25 37 43 30 25 37 43 31 25 37 43  1%7C1%7C0%7C1%7C

02F0  30 25 37 43 30 25 37 43 31 25 37 43 30 25 37 43  0%7C0%7C1%7C0%7C

0300  30 25 37 43 30 25 37 43 31 25 37 43 30 25 37 43  0%7C0%7C1%7C0%7C

0310  30 25 37 43 30 25 37 43 30 25 37 43 30 25 37 43  0%7C0%7C0%7C0%7C

0320  30 25 37 43 30 25 37 43 30 25 37 43 30 3B 20 50  0%7C0%7C0%7C0; P

0330  53 3D 30 3B 20 53 55 3D 25 45 35 25 41 44 25 39  S=0; SU=%E5%AD%9

0340  39 25 45 39 25 39 44 25 39 36 25 45 34 25 42 38  9%E9%9D%96%E4%B8

0350  25 42 30 3A 32 3A 31 32 37 36 38 33 35 38 32 37  %B0:2:1276835827

0360  3A 66 68 66 79 75 3A 31 32 31 37 36 33 30 32 38  :fhfyu:121763028

0370  34 3A 31 3A 31 39 32 32 2D 30 35 2D 32 36 3A 3B  4:1:1922-05-26:;

0380  20 53 49 4E 41 50 52 4F 3D 66 71 32 6D 66 4D 38   SINAPRO=fq2mfM8

0390  4D 44 25 33 44 37 57 6D 44 78 46 25 32 35 37 25  MD%3D7WmDxF%257%

03A0  32 35 25 32 35 78 32 39 57 39 77 37 25 33 44 52  25%25x29W9w7%3DR

03B0  32 4A 25 32 35 65 78 79 37 4A 25 33 44 32 4D 69  2J%25exy7J%3D2Mi

03C0  52 25 32 36 6C 7A 4D 37 32 77 25 33 44 25 32 35  R%26lzM72w%3D%25

03D0  39 4A 25 32 31 37 6D 77 25 32 35 39 25 32 36 25  9J%217mw%259%26%

03E0  32 36 4D 6D 4A 4D 25 32 31 77 3B 20 55 4E 49 50  26MmJM%21w; UNIP

03F0  52 4F 55 3D 32 3A 25 43 42 25 45 46 25 42 45 25  ROU=2:%CB%EF%BE%

0400  42 38 25 42 37 25 45 31 3A 30 3A 3A 31 3A 3B 20  B8%B7%E1:0::1:;

0410  6E 69 63 6B 3D 66 68 66 79 75 28 31 32 37 36 38  nick=fhfyu(12768

0420  33 35 38 32 37 29 3B 20 61 70 70 6D 61 73 6B 3D  35827); appmask=

0430  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  00000000

0440  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 34  00000004

0450  3B 20 67 65 6E 64 65 72 3D 31 3B 20 53 49 4E 41  ; gender=1; SINA

0460  2D 41 56 41 54 41 52 3D 30 25 37 43 30 25 37 43  -AVATAR=0%7C0%7C

0470  30 25 37 43 30 25 37 43 31 25 37 43 31 25 37 43  0%7C0%7C1%7C1%7C

0480  31 25 37 43 31 25 37 43 30 25 37 43 31 25 37 43  1%7C1%7C0%7C1%7C

0490  30 25 37 43 30 25 37 43 31 25 37 43 30 25 37 43  0%7C0%7C1%7C0%7C

04A0  30 25 37 43 30 25 37 43 31 25 37 43 30 25 37 43  0%7C0%7C1%7C0%7C

04B0  30 25 37 43 30 25 37 43 30 25 37 43 30 25 37 43  0%7C0%7C0%7C0%7C

04C0  30 25 37 43 30 25 37 43 30 25 37 43 30 3B 20 53  0%7C0%7C0%7C0; S

04D0  49 4E 41 50 52 4F 43 3D 31 3B 20 55 4E 49 50 52  INAPROC=1; UNIPR

04E0  4F 54 4D 3D 31 32 31 37 36 33 30 32 38 34 3B 20  OTM=1217630284;

04F0  53 49 4E 41 5F 4E 55 3D 3B 20 53 49 4E 41 5F 4F  SINA_NU=; SINA_O

0500  55 3D 3B 20 53 49 4E 41 5F 55 53 45 52 3D 3B 20  U=; SINA_USER=;

0510  53 4D 53 5F 43 4F 4F 4B 49 45 3D 3B 20 53 49 44  SMS_COOKIE=; SID

0520  3D 3B 20 55 4E 49 50 52 4F 4D 3D 3B 20 67 5F 78  =; UNIPROM=; g_x

0530  5F 64 5F 6A 5F 73 3D 37 64 38 7C 37 7C 31 3B 20  _d_j_s=7d8|7|1;

0540  73 69 6E 61 52 6F 74 61 74 6F 72 2F 3D 32 33 0D  sinaRotator/=23.

0550  0A 0D 0A                                           ...

This seemed strange, so I pulled down the source from the above cgi-bin and found this:

function Bgfhp(){var S_WC_EMBED_CORE=function(){this.Init.apply(this,arg

uments);};S_WC_EMBED_CORE.prototype={bY:false,Init:function(bY,cl){this.

cl=cl;this.bY=bY;this.bX=this.Z();if(this.bX){this.ag();}else S_WC_EMBED

_CORE=null;},Z:function(){var aC=/http://([A-Za-z0-9-.]+)(.sina.com.

cn)//ig;var ci=document.location.href;var bo=ci.indexOf('?');if(bo!=-1)

ci=ci.substr(0,bo);var bp=ci.indexOf('#');if(bp!=-1)ci=ci.substr(0,bp);

if(!aC.test(ci)){return false;}return true;},ag:function(){var ak=new

Util.aO;this.bY=ak.am(this.bY,this.cl.P,true);window.document.woocall_

swf_file.SetVariable("Probe",this.bY);}}; var WCEmbedCore = new S_WC_EMB

ED_CORE('999e69a3b8e9231ea48de6f141d1d3c7fdd567a5',S_WC.EmbedConf);}

Bgfhp();

This looks more like bad programming than anything, so I decided to check out the HTTP Referer, and I was directed to a a Flash application:

a Backdoor perhaps? Let's look at the source code that creates this little gem:

<!--[442,2,9] published at 2007-08-13 11:19:29 from #237 by 1786-->

if(typeof Util=='undefined')Util={};Util.aO=function()

{this.Init.apply(this,arguments);};Util.aO.prototype={Init:function

(){},au:function(v,w){var bs=v.length;var aK=v[bs-1]&0xffffffff;for

(var i=0;i<bs;i++){v[i]=String.fromCharCode(v[i]&0xff,v[i]

>>>8&0xff,v[i]>>>16&0xff,v[i]>>>24&0xff);}if(w){return v.join

('').substring(0,aK);}else{return v.join('');}},bq:function(s,w){var

 ce=s.length;var v=[];for(var i=0;i<ce;i+=4){v[i>>2]=s.charCodeAt

(i)|s.charCodeAt(i+1)<<8|s.charCodeAt(i+2)<<16|s.charCodeAt(i+3)

<<24;}if(w){v[v.length]=ce;}return v;},am:function(cg,at,as){if

(cg==""){return "";}if(as)cg=this.aq(cg);var v=this.bq(cg,false);var

 k=this.bq(at,false);var n=v.length-1;var z=v[n-1],y=v

[0],bh=0x9E3779B9;var bU,e,q=Math.floor(6+52/

(n+1)),cc=q*bh&0xffffffff;while(cc!=0){e=cc>>>2&3;for(var p=n;p>0;p

--){z=v[p-1];bU=(z>>>5^y<<2)+(y>>>3^z<<4)^(cc^y)+(k[p&3^e]^z);y=v

[p]=v[p]-bU&0xffffffff;}z=v[n];bU=(z>>>5^y<<2)+(y>>>3^z<<4)^(cc^y)+

(k[p&3^e]^z);y=v[0]=v[0]-bU&0xffffffff;cc=cc-bh&0xffffffff;}return

this.au(v,true);},aq:function(h){var r="";for(var i=(h.substr(0,2)

=="0x")?2:0;i<h.length;i+=2)r+=String.fromCharCode(parseInt

(h.substr(i,2),16));return r;}};if(typeof Util=='undefined')Util=

{};Util.by=function(){this.Init.apply

(this,arguments);};Util.by.prototype={ar:0,o:"",cb:8,Init:function

(){},bi:function(s){return this.ah(this.aj(this.aL

(s),s.length*this.cb));},aj:function(x,ce){x[ce>>5]|=0x80<<(24-ce%

32);x[((ce+64>>9)<<4)+15]=ce;var w=Array(80);var a=1732584193;var

b=-271733879;var c=-1732584194;var d=271733878;var e=-

1009589776;for(var i=0;i<x.length;i+=16){var ax=a;var ay=b;var

az=c;var aA=d;var aB=e;for(var j=0;j<80;j++){if(j<16)w[j]=x

[i+j];else w[j]=this.bH(w[j-3]^w[j-8]^w[j-14]^w[j-16],1);var

t=this.cf(this.cf(this.bH(a,5),this.aI(j,b,c,d)),this.cf(this.cf

(e,w[j]),this.aJ(j)));e=d;d=c;c=this.bH(b,30);b=a;a=t;}a=this.cf

(a,ax);b=this.cf(b,ay);c=this.cf(c,az);d=this.cf(d,aA);e=this.cf

(e,aB);}return Array(a,b,c,d,e);},aI:function(t,b,c,d){if(t<20)

return(b&c)|((~b)&d);if(t<40)return b^c^d;if(t<60)return(b&c)|(b&d)

|(c&d);return b^c^d;},aJ:function(t){return(t<20)?1518500249:

(t<40)?1859775393:(t<60)?-1894007588:-899497514;},cf:function(x,y)

{var bl=(x&0xFFFF)+(y&0xFFFF);var aw=(x>>16)+(y>>16)+

(bl>>16);return(aw<<16)|(bl&0xFFFF);},bH:function(bm,bg){return

(bm<<bg)|(bm>>>(32-bg));},aL:function(cg){var aX=Array();var av=

(1<<this.cb)-1;for(var i=0;i<cg.length*this.cb;i+=this.cb)aX[i>>5]

|=(cg.charCodeAt(i/this.cb)&av)<<(32-this.cb-i%32);return

aX;},ah:function(bD){var

bj=this.ar?"0123456789ABCDEF":"0123456789abcdef";var cg="";for(var

i=0;i<bD.length*4;i++){cg+=bj.charAt((bD[i>>2]>>((3-i%4)*8+4))&0xF)

+bj.charAt((bD[i>>2]>>((3-i%4)*8))&0xF);}return cg;}};if(typeof

S_WC=='undefined')S_WC={};if(typeof $=='undefined')$=function(id)

{return document.getElementById(id)};if(typeof $C=='undefined')

$C=function(t){return document.createElement(t)};if(typeof

$S=='undefined')$S={};S_WC.EmbedConf={bA:false,cj:

{bZ:'sml_emb_testing',bP:'http://image2.sina.com.cn/woocall/cli/',aS

:'.swf',bz:'woocall_swf_file',bK:'S_WC_EMBED_BOX',bL:400,bJ:300,l:10

,g:true},cd:false,T:'_SP',I:false,D:'_CL',aU:'http://image2.sina.com

.cn/ent/woocall/Theme/',K:36,A:14,f:'_CtrlBtn',C:'_ChatBox',bx:'S_WC

',aQ:14,aW:'_USRTOK',S:6,aV:0,P:'9icn4po62xa2nbcd',bv:0,F:'/cgi-

bin/s_wc_corev3?v=m&t=1'};if(typeof Util=='undefined')Util=

{};Util.bk=(navigator.appName.indexOf("Microsoft",0)!=-1)?

true:false;Util.aD=function(aM,an){var

bd="ABCDEFGHIJKLMNOPQRSTUVWXTZabcdefghiklmnopqrstuvwxyz";var

bf=bd+"0123456789";var bG='';for(var i=0;i<aM;i++){var

bW=Math.floor(Math.random()*bf.length);if(an&&i==0)bG+=bd.substring

(bW,bW+1);else bG+=bf.substring(bW,bW+1);}return

bG;};Util.aG=function(name,value,expires,bn,domain,aE){var

al=name+"="+escape(value)+((expires)?";

expires="+expires.toGMTString():"")+((bn)?"; bn="+bn:"")+

((domain)?"; domain="+domain:"")+((aE)?";

aE":"");document.cookie=al;};Util.ao=function(name){var

bT=document.cookie;var prefix=name+"=";var ca=bT.indexOf(";

"+prefix);if(ca==-1){ca=bT.indexOf(prefix);if(ca!=0)return null;}

else ca+=2;var bE=document.cookie.indexOf(";",ca);if(bE==-1)

bE=bT.length;return unescape(bT.substring

(ca+prefix.length,bE));};function LdCfg(bu){if(typeof

SINA_WOOCALL_CONFIG!='undefined'){if

(SINA_WOOCALL_CONFIG.StandPoint&&SINA_WOOCALL_CONFIG.StandPoint.L&&S

INA_WOOCALL_CONFIG.StandPoint.R){bu.cd=

{L:SINA_WOOCALL_CONFIG.StandPoint.L,M:SINA_WOOCALL_CONFIG.StandPoint

.M?SINA_WOOCALL_CONFIG.StandPoint.M:false,R:SINA_WOOCALL_CONFIG.StandPo

int.R}}if(SINA_WOOCALL_CONFIG.CustomURL)

{bu.aP=SINA_WOOCALL_CONFIG.CustomURL;}if(SINA_WOOCALL_CONFIG.Conn)

{bu.bv=1;}}};function LdBoxCfg(){if(typeof SINA_WOOCALL_CONFIG!

='undefined'){if

(SINA_WOOCALL_CONFIG.EmbedBox&&SINA_WOOCALL_CONFIG.EmbedBox.MyId&&SI

NA_WOOCALL_CONFIG.EmbedBox.MyWidth&&SINA_WOOCALL_CONFIG.EmbedBox.MyH

eight){var B=

{N:SINA_WOOCALL_CONFIG.EmbedBox.MyId,V:SINA_WOOCALL_CONFIG.EmbedBox.

MyWidth,J:SINA_WOOCALL_CONFIG.EmbedBox.MyHeight};return B}else

return false;}return false;};function woocall_swf_file_DoFSCommand

(ai,bC){switch(ai){case 'InitApp':S_WC.EmbedUI.Q(bC);break;}};if

(Util.bk){document.write('<SCRIPT event=FSCommand(ai,bC)

for='+S_WC.EmbedConf.cj.bz+'>');document.write

('woocall_swf_file_DoFSCommand(ai, bC);');document.write

('</SCRIPT>');}S_WC.EmbedUI=function(){this.Init.apply

(this,arguments);};S_WC.EmbedUI.Q=function(bC){var s=$C

('script');s.src='http://'+bC+S_WC.EmbedConf.F;s.type='text/javascri

pt';document.body.appendChild(s);};S_WC.EmbedUI.prototype=

{cl:null,df:null,bR:null,aZ:null,ba:true,Init:function(cl)

{this.cl=cl;if(this.cl.bA)

this.cl.cj.bP=this.cl.cj.bP+this.cl.bA+'/';this.bX=true;this.aZ=this

.cl.bx;this.df=this.ac();this.ba=Util.bk;},H:function(){this.bb

();this.ae();this.af();},aF:function(bK,bL,bJ)

{this.cl.cj.bK=bK;this.cl.cj.bL=bL;this.cl.cj.bJ=bJ;},aH:function

(n,be){if(typeof be=='string'){this.cl.aU=be;}var

ci=this.cl.aU+n+'/';this.cl.aT=

{U:ci+'boxlogo.gif',G:ci+"wc_style_embed.css"};},ap:function(){if(!

this.bR||this.bR.length==0){this.bb();}return this.bR;},af:function

(){var width=this.cl.cj.bL;var

height=this.cl.cj.bJ;this.Y.style.width=width+'px';this.W.style.widt

h=width+'px';this.aY.style.height=(height-this.cl.K-this.cl.A)

+"px";this.aY.style.width=width+'px';this.X.style.width=width+'px';}

,ae:function(){this.aa();var cj=$C('div');var bN=$C('div');var m=$C

('div');var bw=$C('div');var bt=$C

('div');$(this.cl.cj.bK).appendChild

(cj);cj.className=this.aZ+this.cl.C;cj.appendChild

(bN);cj.appendChild(bw);cj.appendChild(bt);bN.className='Hnd';var

bO=document.title;if(bO.length>this.cl.aQ){bO=bO.substr

(0,this.cl.aQ)+'..';}var O='<img align="absmiddle"

src="'+this.cl.aT.U+'" /> '+bO;var aN='<div

class="Title">'+O+'</div>';bN.innerHTML=aN;bt.className='Bottom';bw.

innerHTML=this.ap

();this.X=cj;this.Y=bN;this.aY=bw;this.W=bt;},aa:function(){bV=$C

("link");bV.rel="stylesheet";bV.type="text/css";bV.href=this.cl.aT.G

;var head=document.getElementsByTagName("head")[0];head.appendChild

(bV);},ac:function(){var bM='';if(this.cl.df&&this.bX)

{bM=this.cl.df;}else if(this.cl.aP&&this.bX){var bI=new

Util.by;bM=bI.bi

(this.cl.aP);this.eF=window.location.href;this.eF=this.eF.replace

("&","|");}else

{this.eF=window.location.href;this.eF=this.eF.replace("&","|");if

(this.cl.aV>0){this.eF=this.eF.substr(0,this.cl.aV);}var bI=new

Util.by;bM=bI.bi(this.eF);}return bM;},ad:function(){var

ci=window.location.href;var p=ci.indexOf('/',7);var domain='';if(p!

=-1){domain=ci.substr(0,p);}else domain=ci;return

domain;},ab:function(){var bF=new Date();bF.setTime(bF.getTime()

+365*24*60*60*1000*50);var bQ=Util.ao(this.cl.bx+this.cl.aW);if(!

bQ){bQ=Util.aD(this.cl.S,true);Util.aG

(this.cl.bx+this.cl.aW,bQ,bF,'/');}return bQ;},bc:function(ck){if

(this.cl.cd&&this.bX){ck.push('&position1=');ck.push

(this.cl.cd.L);if(this.cl.cd.M){ck.push('&position=');ck.push

(this.cl.cd.M);}ck.push('&position0=');ck.push

(this.cl.cd.R);}},bb:function(){var ef=this.ab();var ck=Array();var

 domain=this.ad();if(this.cl.cd)

{this.cl.cj.bZ=this.cl.cj.bZ+this.cl.T;}if(this.cl.I)

{this.cl.cj.bZ=this.cl.cj.bZ+this.cl.D;}if(this.ba){ck.push('<object

classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"

codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/

swflash.cab#version=7,0,0,0" width="');ck.push("100%");ck.push('"

 height="');ck.push("100%");ck.push('" id="');ck.push

(this.cl.cj.bz);ck.push('" align="middle"><param

name="allowScriptAccess" value="always" />');ck.push('<param

name="movie" value="');ck.push

(this.cl.cj.bP+this.cl.cj.bZ+this.cl.cj.aS);ck.push('?

ChName=');ck.push(this.df);ck.push('&UsrTok=');ck.push(ef);ck.push

('&Domain=');ck.push(domain);ck.push('&PgURL=');ck.push(escape

(this.eF));ck.push('&isDirect=');ck.push(this.cl.bv);this.bc

(ck);ck.push('" />');ck.push('<param name="quality" value="high"

/><param name="bgcolor" value="#ffffff" />');ck.push('</object>');}

else{ck.push('<embed src="');ck.push

(this.cl.cj.bP+this.cl.cj.bZ+this.cl.cj.aS);ck.push('"

FlashVars="');ck.push('ChName=');ck.push(this.df);ck.push

('&UsrTok=');ck.push(ef);ck.push('&Domain=');ck.push(domain);ck.

push('&PgURL=');ck.push(escape(this.eF));ck.push

('&isDirect=');ck.push(this.cl.bv);this.bc(ck);ck.push('"

quality="high" bgcolor="#ffffff" width="');ck.push("100%");ck.push

('" height="');ck.push("100%");ck.push('" name="');ck.push

(this.cl.cj.bz);ck.push('" align="middle" allowScriptAccess="always"

 swLiveConnect="true" type="application/x-shockwave-flash"

pluginspage="http://www.macromedia.com/go/getflashplayer" />');}

this.bR=ck.join('');}};function S_WC_EMBED_Creese()

{S_WC.EmbedConf.bA='0_2_REV3';LdCfg(S_WC.EmbedConf);var bB=new

S_WC.EmbedUI(S_WC.EmbedConf);bB.aH('Grey2');var bS=LdBoxCfg();if

(bS){bB.aF(bS.N,bS.V,bS.J);bB.H();}};S_WC_EMBED_Creese();

Lots of interesting tricks going on here. This software seems to be a P2P chat program that allows you to chat with people that are currently viewing the same web page as you are. I found it used on the Super Girl TV show website. Seems rather innocent, but until you understand exactly what the above code does, would you use it? Is it merely obfuscation? These are the types of questions that filter writers at DVLabs have to answer on a case-by-case basis, and questions that I'll be spending some time on for the above example. So, back to work!

August 28, 2008
21:40
MindshaRE: The IDA Pro Book
» ‎ DVLabs: Blogs

Posted by Cody Pierce
IDA can be a very intimidating program to use. When starting out, not only are you trying to get comfortable with assembly, but you also must navigate a program with a steep learning curve. IDA's lack of documentation, aside from ida.hlp, compounds this problem leaving you somewhat insecure in your endeavor. Not anymore. A new book as been published by no starch press titled "The IDA Pro Book". Its author, Chris Eagle, is no stranger to the world of reverse engineering and has been a fixture at security conferences for several years. So today we will take a look at this book. If you are strapped for time, and cannot read everything I have to say, I'll summarize this post. Buy this book!

MindshaRE is our weekly look at some simple reverse engineering tips and tricks. The goal is to keep things small and discuss every day aspects of reversing. You can view previous entries here by going through our blog history.

The IDA Pro Book is not the only book on IDA. In fact, another book on using IDA, was released earlier this year. I have looked at both of them, and honestly, there is only one book on IDA Pro. Chris Eagle funnels his knowledge of IDA and reversing into a concise, easily readable, and handy "missing manual" for IDA Pro users old and new. His chapters are well defined, and examples are elaborately detailed. Chris' time as an educator in the field of computer science, security, and reverse engineering really show throughout this book.

Part I of the book starts off by giving the reader a good baseline of tools and idioms as they pertain to reverse engineering. In the first chapter Eagle covers the "Whats, Whys, and Hows" providing a good understanding of what exactly IDA is /doing/ when disassembling a binary. Of particular interest, is the section covering different methods of disassembling a binary such as linear sweep, and recursive descent. It's important to have this understand of the method IDA employs to identify code, data, and primitives.

Chapter two, is necessary for any reverse engineering book, covering commonly used tools outside of IDA Pro. While I understand that mentioning tools such as objdump, strings, PeID, etc are necessary, this chapter is my least favorite. It seems inserted merely for posterity's sake, which isn't a terrible thing.

The last chapter rounds out a good intro, by providing the reader with an understanding of the program. It may seem obvious, but issues such as purchasing, support, and installation are at your fingertips. One paragraph titled "Hex-Rays Stance on Piracy" made me chuckle a bit. Regular IDA users will be familiar with the lengths Hex-Rays has gone to not only protect their product, but publicly decry users of pirated copies in their "Hall of Shame".

From the beginning the reader is exposed to my favorite aspect of this book. It is almost 100% IDA from cover to cover. Other books on IDA cover useful, but misguided, topics such as executable file formats, or assembly and higher level programming languages. Obviously this is required knowledge, but there are plenty of dedicated books in each of these areas. From the gates The IDA Pro Book is non stop IDA, only touching on the aforementioned topics when needed to explain a particular subject. It feels like you are really immersed in the program, learning all of its nuances.

Part II of the book jumps right into the meat and potatoes. Chris gets you started by covering the loading of files, how IDA stores its disassembly, navigation, manipulation, and data types. At over 150 pages this section should be studied and memorized by anyone who uses IDA on a regular bases.

Chapters 4 through 6 get the reader's feet wet in the program's UI. The UI is, in my opinion, the source of frustration for most new users of IDA. Eagle himself states in Chapter 3 "IDA is not your mother's word processor" because, while it may look like a text processor, the UI is in a world of its own.

Of particular interest in these chapters are the sections covering IDA's database creation, common and tertiary windows in the UI, and disassembly navigation. It's nice to see all of the UI elements available to the user described in detail in these chapters. Many of the essential windows aren't as noticeable in IDA at first glance and this provides a good reference when ida.hlp is lacking.

Chapters 7 through 10 round out this essential section of the book. One of the highlights, and must reads, is Chris' 40 page coverage of data types and structures. Everything from creating structures, to how C++ classes look in assembly, is laid out in an easy to understand, example driven, manner that is a delightful read. This could be the premier set of chapters of its kind, and certainly one of the best in the book.

Part III takes us through some of the advanced features IDA provides. Configuration customization, and IDA's FLIRT signatures are covered followed by some of IDA's limitations (Generating EXEs anyone?).

Part IV of the book really shines. Its goal is to familiarize the reader with extending IDA. Of all things IDA can do, I believe its scripting, plugin architecture, loader, and processor modules are what separate it from other disassemblers and truly make it the industry standard.

Chris Eagle has a lot of experience in this field having written many plugins, scripts, and processor modules. This is apparent throughout this part of the book and really helps when covering these complex, and almost undocumented aspects of IDA. While IDA's scripting language and SDK are not perfect, with the knowledge and help this sections provides, a user can apply this to achieve an endless amount of tasks.

While certainly useful, this advanced section may not be for everyone. If you are wanting to just disassemble binaries, and navigate code, you can skip "Extending IDA's Capabilities". But for users wanting to load exotic executable formats, or write a processor module to disassemble a virtual machine this section will be a good resource. I personally got a lot of use out of the loader and processor module chapters. The example driven teaching of these subjects is a welcome detour from the dry documentation, or sparse text files on the web.

Towards the end of the book, in Part V, Chris Eagle shows us how the previous subjects are applied in the real world. Each chapter lightly touches on its respected subject (There are whole books on vulnerability analysis) and provides a good jumping off point for readers interested in that particular application of reverse engineering in IDA Pro. Once again this book stays focused on IDA, and doesn't distract the reader. Although there may be plenty of information on subjects such as vulnerability analysis, and obfuscated code analysis, "Real World Applications" still provides value by delivering useful scripts, and information that can be leverage by IDA.

Finally we end things with the often maligned subject of IDA's built in debugger. Honestly it gets a bad rap, and it may be a deserved one when compared to fully functional debuggers like WinDbg. However the debugger is not IDA's primary function. It is another extension of the program allowing the user to take their static disassembly work into the world of live analysis.

Eagle does a fine job demonstrating the usefulness of the built in debugger and the features it exposes. From scripting breakpoints, and pulling registers, to handling exceptions its all here. Honestly, I may force myself to use it the next time I need a debugger and I'm feeling adventurous.

Chris Eagle delivers a very concise, well laid out book in "The IDA Pro Book". The step by step examples, and much needed detail of all aspects of IDA alone make this book a good choice. Combine that with the little things such as the numbering system in the examples, must have plugins and tools, side bar tidbits of related information, and well formulated descriptions of seemingly awkward tasks, make this book a solid addition to any tech library. I honestly think, like IDA, it will be the industry standard on one of the more intimidating applications in the security, and reverse engineering world.

I know what you may be thinking, "Who is Cody, and why should I care about his wordy review?". To answer that I will leave you with two other opinions of the book.

"I wholeheartedly recommend The IDA Pro Book to all IDA Pro users" - Ilfak Guilfanov
"This is the densest, most accurate, and, by far, the best IDA Pro book ever released" - Pierre Vandevenne

For those that don't know Ilfak is the creator of IDA Pro, and Pierre is the Owner/CEO of DataRescue (Former publishers of IDA). If that's not enough, here is a blog post from Ilfak himself.

[hexblog.com]

Hope you enjoyed this weeks MindshaRE!

-Cody
August 27, 2008
17:26
ThreatLinQ: A tale of two attackers
» ‎ DVLabs: Blogs
Posted by Mike Dausin
After my previous blog post last week about MS-SQL brute force attackers, I asked myself the question "who /are/ these guys?" I mean, There are a lot of different attacks out there, why choose this one? So, today I spent a couple hours trying to answer this question.
Specifically, I decided to take the top 25 attackers from filter 463 'Bad MS-SQL SA Login' portscan them w/OS detection and some other probes and then compare them with the top 25 attackers from our 'PHP File include' filters. So without further delay, Below are the results:
```
Top 25 PHP RFI Attackers           Top 25 Bad 'SA' Login Attackers
```
```
Attacker OS:                       Attacker OS:
```
```
windows:      %32                  Windows:      %88
```
```
Linux:        %68                  Linux:        %0
```
```
Unknown:      %0                   Unknown:      %12
```
```
Open Ports:                        Open Ports:
```
```
21:           %56                  21:           %36
```
```
22:           %48                  22:           %0
```
```
25:           %56                  25:           %28
```
```
53:           %48                  53:           %20
```
```
80:           %68                  80:           %52
```
```
110:          %52                  110:          %28
```
```
143:          %44                  143:          %16
```
```
135 or 445:   %12                  135 or 445:   %60
```
```
1433:         %0                   1433:         %20
```
```
3306:         %36                  3306:         %20
```
So this is somewhat interesting. Pretty much all the 'bad SA login'
attackers were windows machines, while nearly %70 of the PHP file include attackers were Linux machines. Why is this? Well, It's hard to say without more information. But I suspect two things are happening here:

1.) Attackers are using their victims as launching pads for more attacks.
2.) Attackers are not using these machines as general purpose attack platforms. They are using them as attack platforms for more narrow 'classes' of attacks.

If these two points were not true, then you should not see such a strong correlation between the Attacker OS and the Attacked OS. In particular, if the second point were not true, and the attacker was using these hosts as launching pads targeting both Linux and windows machines, then you should start seeing a much more diverse population of attackers as new machines are converted to attack platforms.

So, what do you think? Does the logic follow, or is there something else going on here? If you have any ideas please post them in the comments!
August 22, 2008
21:47
ThreatLinQ: Using Filter Groups - Guilty By Association
» ‎ DVLabs: Blogs

Posted by Marc Eisenbarth
This post shows how the “Filter Group” section of the website can be used to find some very interesting events. Lets start by looking at the “Metasploit Shellcode” group, which is more often that not a very good starting point for finding malicious attackers. Not surprisingly, in analyzing ThreatLinQ data we have noticed that shellcode filters fire in tandem with many severe attacks. This makes sense, as the Metasploit shellcode is borrowed by a majority of exploit tools and proof of concept code circulating on the Internet. So, lets take a look at the “Source IPs” tab and select one of the IP address that has a large number of hits for this ThreatLinQ Filter Group, namely 210.91.205.222 which originates from the Republic of Korea. On 7-16-08 we see a number of filter 3990 “Exploit: Shellcode Payload” hits along with a single hit for filter 3885 “PHP File Include Exploit”. This attacker then proceeded 6 days later to launch a DCOM IsystemActivator Overflow attack. Groupings of severe attacks such as these three strengthen our case that 210.91.205.222 is an active, malicious host and one to keep an eye on in the future.
19:27
Line Noise
» ‎ DVLabs: Blogs

Posted by Cameron Hotchkies
It's that awesome time unscheduled by conventional schedules for the blog that everyone loves to power Fridays with. Line Noise!

First up, Ali found a paper on someone implementing a sublanguage within haskell in order to enforce data flow control, for security reasons. A cool in concept, especially if you're a fan of the functional programming.

Here's a set of new UI concepts. The first one takes a bit to get going, but it's really impressive when it's done. Some seem new-ish, but like they were implemented in 1982. Go see what I mean.

Ali noted improvements to fiber optic materials in order to speed up the net. They're actually talking about slowing down the light to increase speed. This is also the exact opposite of how most Austinites drive, don't ask how that works.

The body of a priest trying to raise money for a chapel for truckers in his highway parish came up with the idea of floating over the ocean hanging from hundreds of helium balloons was finally found three months later. His last contact before his demise was a cell phone call he made to his friends notifying them he was about to crash into the ocean.

Designers at the University of Kitakyushu in Japan have created a life-like robotic red snapper fish. The realistic design is hoped to help the robot blend in while in the wild. Robotic red snapper... very tasty. I'd still take the mystery box.

You probably remember it from TED, now Microsoft has finally released Photosynth. Based off the multitude of pictures taken of me from various conferences over the years, this technology scares the crap out of me. But then, so do the people that would be trying to map pictures of me on Microsoft photosynth.

You may have caught this and thought "Hey reversing iPhone binaries ON the iPhone? does it support batch mode of ida-python scripts?".. or maybe that's just me. Then again, if you did, maybe you'd be a shoe-in for this job (props to Ryan Naraine for finding that one).

Spanish automaker IFR has developed a steering wheel capable of electronically tweaking your vehicle's valve timing, rev limit, ABS, and other characteristics.

Now you're probably thinking "Hey! It's been a month, and that's al you've got?". Well, I went to Black Hat, so our IRC has been very quiet. If you want to read about that, you'll have to check our write-up here.

That's it for now, stay classy blogosphere!
1:32
Where are the Apples of Yesteryear?
» ‎ DVLabs: Blogs

Posted by Rob King

There was a time, not so long ago, where Apple was the plucky upstart. They weren't the second-largest music retailer in the United States. They didn't hold a virtual monopoly on portable music players, and they didn't capture nearly half of the high-end laptop market.

Apple was instead, a geek's company. They were open and friendly, flexible and more than a little quirky. Sure, the fact that large portions of their code are open source is great, and certainly something of which I approve, but they've definitely started playing their cards a bit closer to their chest, at least on security issues.

At this year's just-passed Black Hat, I was very much looking forward to attending two talks discussing security in Apple's products. One was to be a general discussion of Apple's security practices, and was to be presented by several members of Apple's security staff. That would have been, I'm sure, interesting, but I was far more excited about the discussion of an apparent security flaw in Apple's FileVault technology by Charles Edge.

Both talks were unceremoniously yanked from Black Hat by Apple. I don't know what the details of either talk would have been (had I known, I wouldn't have seen the use of attending, now would I?), but I love FileVault, and I'm sad I wasn't able to see the talk.

For the non-Mac users out there, FileVault is Apple's disk encryption technology. In true Apple fashion, it attempts to be easy to use for the vast majority of users, at the expense of some higher-level features for the real power users. Like Time Machine, Apples simple-but-limited built-in backup solution, FileVault aims to be disk encryption that's so easy to use, people actually use it.

FileVault is easy in part because you don't say what you do and don't want to encrypt - you don't get a choice. It's your home directory, your whole home directory, and nothing but your home directory. This is accomplished by the simple expedient of placing your home directory in a disk image and loopback-mounting that disk image when you login.

This was actually cited as one of FileVault's big File Faults - most things in your home directory don't need to be encrypted. That's true, of course. The gigabytes upon gigabytes of photos in my home directory don't need to be encrypted. I'm sure if someone steals my laptop, the photos of my fiancee and I in Japan aren't what they're after. So, spending the CPU power to maintain the encryption on those files is seen as pointless.

I'm going to defend Apple on this one, though. Here's why I like that my whole home directory is encrypted: I don't know where everything interesting is. Well, okay, I do, but most people probably don't. Quick: Where does Safari store its cached images? How about Mail, where does it store your mailboxes? And iChat, where are those remembered chats?

See, if FileVault had made me pick and choose what directories to keep encrypted, chances are I would have forgotten to encrypt Safari's cache, or one of my mailboxes. Or maybe I would have remembered to do those (and known where to look), but some application I download reads a sensitive document and caches somewhere I wasn't expecting. Now my security was just completely compromised. Hooray!

So, I actually very much approve of FileVault's all-or-nothing approach, because I don't want to have to track down where all my applications store all of my potentially-sensitive data. Also, I like the elegance of the approach.

So, yes, I use FileVault. I was therefore eager to see what sort of flaws FileVault suffered from. Some of them are well-known: FileVault doesn't encrypt things other than home directories, for example. Well, I'm not in the habit of storing sensitive information outside of my home directory, so that's not really a flaw for the vast majority of users. Besides, Mac's are multi-user now; you need per-user encryption.

Other flaws are more practical: Apple's Time Machine backup software doesn't really work with FileVault. That is is a legitimate criticism, and I really do hope they fix that in the upcoming Snow Leopard edition of Mac OS X.

The biggest flaws, however, deal with how encryption is actually performed. While the disk image is encrypted using the state-of-the-art Advanced Encryption Standard (AES, also known as Rihndael), it is done using Cypher Block Chaining mode, making it potentially easier to guess the unencrypted contents of the disk. Also, keys are stored in a less-than-perfect manner, using a 3DES (Triple DES) system.

Additionally, there exists a Master Key that can be used to decrypt FileVaults for users who have forgotten their passwords. These master keys end up having an effective key size of only 72 bits in some situations. In other words, its not as hard as some people might think to circumvent FileVault encryption.

Not as hard, but still pretty difficult; it would take some specialized hardware a potentially very long time to crack a FileVault volume.

Additionally, there is some concern that encryption keys are stored insecurely in memory, so if someone grabs my laptop while it's asleep or the contents of memory are otherwise available, they could get a big leg up in bypassing the encryption.

Several weaknesses in FileVault have already been addressed by Apple: when a user migrates to FileVault, the old contents of their home directory are "securely' wiped, by overwriting the files with random data numerous times before deleting them. This is not a perfect solution, but it is worlds better than the old method of simply unlinking the files' directory entries and leaving the data around for any forensic investigator to find.

Another flaw was address when Apple provided the option of encrypting the on-disk swap file. This, of course, has reasonably high performance implications, but it does address the issue. (I'm actually pretty pleased to note that, with 4GB of memory, I rarely, if ever, touch swap. Of course, I run my Mac as a Unix workstation primarily, so I generally don't run anything more memory-demaning than vi.)

(That's mostly a joke, of course - I run iTunes and such, but I rarely have more than 2GB of memory in use at any one time; swap is rarely touched.)

In any case, the encryption implementation weaknesses in FileVault are well documented (see Applebaum's and Weinmann's analysis at the NSA here: [crypto.nsa.org]).

Key stealing and cryptanalysis of the algorithms used are likewise well known and widely published.

All this makes me wonder what the FileVault Black Hat talk could have been about. Was it simply a rehash of the known vulnerabilities? Was it something more esoteric, like remanence issues in RAM (also a well-known flaw, and not just with Apple)?

The problem is that I don't know. No one, save for Apple, Mr. Edge, and whomever they chose to tell knows the details.

The big evil corporation guilty of being notoriously tight-lipped about security vulnerabilities used to be Microsoft. However, Microsoft has become considerably more forthright of late: with their new MAPP initiative ([www.microsoft.com]) and their rather wry sense of humor about vulnerabilities, Microsoft has actually become one of the most open major vendors when it comes to details about security flaws. This is nothing but a good thing.

Apple has the whizbang factor sewn up, especially with Joe Consumer: Apple is just cool, while Microsoft is seen as stodgy at best. But one of the fanboys' rallying cries, of "better security", may be falling by the wayside. Apple can't really claim the moral high ground on security issues anymore. At best, they're on par with the rest of the industry, and at worst, they're falling behind.

I'd love to see a MAPP-like initiative from Apple. They could even come up with a marketing-friendly snazzy name for it, like MAPPLE or something. I'd love to see Apple embrace the security community. I'd love to see more details in Apple's security advisories, and I'd love to see less restrictive NDAs on development tools and software licenses.

In other words, I'd love to see an Apple that's not just cool for Joe User, but also for Joe Researcher. Apple's got great inroads in the security community: at Black Hat I saw an equal number of Macs and non-Macs. If Apple wants to keep those sort of inroads, a little more goodwill to the security community would be much appreciated.
August 21, 2008
21:04
MindshaRE: Fixing Functions
» ‎ DVLabs: Blogs
Posted by Cody Pierce

IDA's function identification has always frustrated me. I could never understand why seemingly undefined functions weren't discovered during analysis. Recently, while attending RECon, I got my answer. While Ilfak, the creator of IDA, was giving a talk he explained why. He always errors on the side of caution. Meaning, unless he is 100% positive about a function he will leave it up to the user to fix. This isn't such a bad philosophy, unless you are dealing with hundred meg binaries. Regardless, its necessary to fix functions in IDA if you want your cross references, graphs, scripts, and various other actions to work. So today we will talk about fixing functions, from undefined functions as a whole, to changing their beginnings and end, and more.

MindshaRE is our weekly look at some simple reverse engineering tips and tricks. The goal is to keep things small and discuss every day aspects of reversing. You can view previous entries here by going through our blog history.

A function in IDA is defined as a block of code that is the destination of a call instruction. IDA uses varying heuristics and cross references to identify these. One of these heuristics is the typical prologue for msvc/intel.
```
.text:238BA1DD     push    ebp
```
```
.text:238BA1DE     mov     ebp, esp
```
If IDA can find the prologue, and it has a cross reference, it will /almost/ always be defined. When IDA defines a function it will set a beginning and end, label all the arguments and local variables, and give it a "sub_" name. Once this function is defined we can use the graph view, or IDC GetFunction* methods. All of this helps when browsing through a binary.

The problem is, IDA can't always define a function. I wish I could tell you why in all cases, but in general it has to do with either not being able to identify a contiguous chunk as code, or IDA cannot find proper references to a function. Either way we need to clean everything up the best we can.

One way to begin this search is via the analysis toolbar. Undefined code will be represented as a red stripe.

Clicking on one of those red bars will bring us to the associated address. You will notice the addresses in this code are red as well.

An alternative way to do this is to hit Alt-U. This will search for the next "not function", meaning code that isn't in a function.

Since we have seen a prologue, and we have identified a return we can be pretty sure this should be defined as a procedure. I say procedure because to do this we move our cursor to the first instruction in the prologue and hit "p". Doing this our function above turns from a raw disassembled dead list to the following.
```
.text:238BA1DD sub_238BA1DD    proc near
```
```
.text:238BA1DD
```
```
.text:238BA1DD var_4C    = qword ptr -4Ch
```
```
.text:238BA1DD var_34    = qword ptr -34h
```
```
.text:238BA1DD var_2C    = dword ptr -2Ch
```
```
.text:238BA1DD var_28    = dword ptr -28h
```
```
.text:238BA1DD var_24    = dword ptr -24h
```
```
.text:238BA1DD var_20    = dword ptr -20h
```
```
.text:238BA1DD var_1C    = dword ptr -1Ch
```
```
.text:238BA1DD var_18    = dword ptr -18h
```
```
.text:238BA1DD var_14    = dword ptr -14h
```
```
.text:238BA1DD var_10    = dword ptr -10h
```
```
.text:238BA1DD var_C     = dword ptr -0Ch
```
```
.text:238BA1DD var_8     = dword ptr -8
```
```
.text:238BA1DD var_4     = dword ptr -4
```
```
.text:238BA1DD arg_0     = dword ptr  8
```
```
.text:238BA1DD arg_4     = dword ptr  0Ch
```
```
.text:238BA1DD arg_8     = dword ptr  10h
```
```
.text:238BA1DD arg_C     = dword ptr  14h
```
```
.text:238BA1DD arg_10    = dword ptr  18h
```
```
.text:238BA1DD
```
```
.text:238BA1DD     push    ebp
```
```
.text:238BA1DE     mov     ebp, esp
```
```
.text:238BA1E0     sub     esp, 34h
```
And its cross reference now shows it is as a function.
```
.data:23932437    db    0
```
```
.data:23932438    dd offset aSplit        ; "split"
```
```
.data:2393243C    dd offset sub_238BA1DD
```
In some cases we might even have to dig a little deeper. In this case IDA didn't even flag it as "not function".
```
.text:238B9FB1 byte_238B9FB1   db 55h, 8Bh, 0ECh
```
```
.text:238B9FB4     dd 5318EC83h, 56085D8Bh, 530C75FFh, 0F55CB7E8h, 85F08BFFh
```
```
.text:238B9FB4     dd 0F5959F6h, 12A84h, 7D8B5700h, 4C88314h, 107D83h, 0FFC4789h
```
```
.text:238B9FB4     dd 10A84h, 0E8458D00h, 5337FF50h, 0F5C0FAE8h, 0CC483FFh
```
```
.text:238B9FB4     dd 840FC085h, 0EFh, 0C1F70E8Bh, 40000000h, 1574C18Bh, 25h
```
```
.text:238B9FB4     dd 1BD8F780h, 800025C0h, 0FF053FFFh, 2300007Fh, 89C085C1h
```
```
.text:238B9FB4     dd 45DBFC45h, 0DC067DFCh
```
```
.text:238BA028     db 5
```
That's because it isn't even discovered as code! Oh well, I happen to know that 0x55 0x8b 0xec is our prologue. Hitting "c" on this will turn it into code.
```
.text:238B9FB1     push    ebp
```
```
.text:238B9FB2     mov     ebp, esp
```
```
.text:238B9FB4     sub     esp, 18h
```
And then we can hit "p" to define it as a function...but it didn't work. Why not? Because when I tried to define those bytes as code it couldn't define all of them. So the function has no return, and has a large chunk of raw bytes in the middle of it. Again this is IDA erring on the side of caution.
```
.text:238BA027                 fadd    ds:dbl_238FD5F0
```
```
.text:238BA027 ; ---------------------------------------------------------------------------
```
```
.text:238BA02D byte_238BA02D   db 0DDh, 5Dh, 0F0h
```
```
.text:238BA030                 dd 0E845DD51h, 241CDD51h, 0B06E8h, 0F85DDD00h, 59EED959h
```
```
.text:238BA030                 dd 0D
```

SecurityFeed.info » DVLabs: Blogs

Feeds

DVLabs: Blogs (10 unread)