Storm, Nugache lead dangerous new botnet barrage
Storm, Nugache lead dangerous new botnet barrage By Dennis Fisher, Executive Editor 19 Dec 2007 | SearchSecurity.com http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1286808 ,00.html?track=NL-358ad=614777asrc=EM_NLN_2785475uid=1408222 In early 2006, Dave Dittrich, a senior security engineer and researcher at the University of Washington in Seattle, got a sample of a new strain of malware from a colleague, and began monitoring its activity. The Trojan was a bit lazy at first, making just a few outbound connections. But it quickly became obvious that this was no ordinary piece of malware, because each of the connections was to a peer and not a central command and control server. This was strange behavior for PCs that have been compromised by this type of malware. The members of a distributed network like this typically communicate only with one central machine, called the command and control server. It's a top-down structure; the CC server gives the commands and the compromised PCs carry them out. However, this new network didn't seem to have one CC server that was running the show, and the malware itself couldn't really even be classified as a bot as it didn't make its first IRC connection for more than a month. IRC, or Internet Relay Chat, is the preferred method of communication for botnet controllers. But with this network, in lieu of one CC server, there were a number of peers around the network that were sending out commands and serving as download sites for various pieces of the network. So if one of the peers in the network that the attacker is using to issue commands to the rest of the network is shut down, the attacker could simply begin sending orders through another peer. This made the entire network of compromised PCs equal partners and made the prospect of disabling the network incredibly daunting. As troubling as this new development was, more troubling was the fact that the peers sending out the commands changed on the fly and, as Dittrich watched, various members of the network would drop off botnet, only to reappear days or weeks later. So the shape and size of the botnet was changing almost constantly, with entire branches going dark for extended periods of time and peers jumping from one portion of the network to another seemingly on a whim. And, to add to the pile of bad news, the bots were communicating with each other over an encrypted channel, making it all but impossible to listen in on their conversations. Dittrich, one of the top botnet researchers in the world, has been tracking botnets for close to a decade and has seen it all. But this new piece of malware, which came to be known as Nugache, was a game-changer. With no CC server to target, bots capable of sending encrypted packets and the possibility of any peer on the network suddenly becoming the de facto leader of the botnet, Nugache, Dittrich knew, would be virtually impossible to stop. The authors are making these subtle little changes to keep it under the radar, and they're succeeding, said Dittrich. This is the future of malware and it's not a pretty picture. What it is, is a nightmare: a new breed of malicious software developed, tested and sold by professionals and engineered to change on the fly, adapt to its environment and evade traditional defenses. Nugache, and its more famous cousin, the Storm Trojan, are not simply the next step in the evolution of malware. They represent a major step forward in both the quality of software that malware authors are producing and in the sophistication of their tactics. Although they're often referred to as worms, Storm and Nugache are actually Trojans. The Storm creator, for example, sends out millions of spam messages on a semi-regular basis, each containing a link to content on some remote server, normally disguised in a fake pitch for a penny stock, Viagra or relief for victims of a recent natural disaster. When a user clicks on the link, the attacker's server installs the Storm Trojan on the user's PC and it's off and running. Various worms, viruses, bots and Trojans over the years have had one or two of the features that Storm, Nugache, Rbot and other such programs possess, but none has approached the breadth and depth of their feature sets. Rbot, for example, has more than 100 features that users can choose from when compiling the bot. This means that two different bots compiled from an identical source could have nearly identical feature sets, yet look completely different to an antivirus engine. The creators of these Trojans and bots not only have very strong software development and testing skills, but also clearly know how security vendors operate and how to outmaneuver defenses such as antivirus software, IDS and firewalls, experts say. They know that they simply need to alter their code and the messages carrying it in small ways in order to evade signature-based defenses.
Question on export issues
What are the rules these days on crypto exports. Is a review still required? If so, what gets rejected? Just wondering... I have people at work ask me what the rules are and I have not kept up with them. If GnuPG can ship, what gets rejected? Is there some magic cryptotech I am not aware of? (Or is it just theater at this point?) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Fwd: [silk] For years US eavesdroppers could read encrypted messages without the least difficulty
Begin forwarded message: From: Eugen Leitl [EMAIL PROTECTED] Date: December 29, 2007 9:16:49 AM EST To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [silk] For years US eavesdroppers could read encrypted messages without the least difficulty From: Gautam John [EMAIL PROTECTED] Subject: [silk] For years US eavesdroppers could read encrypted messages without the least difficulty To: [EMAIL PROTECTED] Date: Sat, 29 Dec 2007 19:38:28 +0530 Reply-To: [EMAIL PROTECTED] Sat, 29 Dec 2007 04:02:00 By Ludwig De Braeckeleer (OhMyNews) -- For decades, the US National Security Agency (NSA) has been reading effortlessly ultra sensitive messages intercepted from all parts of the world. This extraordinary feat was not the consequence of the work of some genius cyber mathematician. Nor was it the result of the agency dominance in the field of super computers, which allegedly have outpaced their most direct rivals by orders of magnitude. The truth is far simpler and quite troubling. The game was rigged. For half a century, Crypto AG, a Swiss company located in Zug, has sold to more than 100 countries the encryption machines their officials rely upon to exchange their most sensitive economic, diplomatic and military messages. Crypto AG was founded in 1952 by the legendary (Russian born) Swedish cryptographer Boris Hagelin. During World War II, Hagelin sold 140,000 of his machine to the US Army. In the meantime, the Crypto AG has built up long standing cooperative relations with customers in 130 countries, states a prospectus of the company. The home page of the company Web site says, Crypto AG is the preferred top-security partner for civilian and military authorities worldwide. Security is our business and will always remain our business. And for all those years, US eavesdroppers could read these messages without the least difficulty. A decade after the end of WWII, the NSA, also known as No Such Agency, had rigged the Crypto AG machines in various ways according to the targeted countries. It is probably no exaggeration to state that this 20th century version of the Trojan horse is quite likely the greatest sting in modern history. In effect, US intelligence had spies in the government and military command of all these countries working around the clock without ever risking the possibility of being unmasked. An Old and Venerable Company In the aftermath of the Islamic revolution, Iran, quite understandably, would no longer trust encryption equipment provided by companies of NATO countries. The Swiss reputation for secrecy and neutrality lured Iranians to Crypto AG, an old and venerable company. They never imagined for a moment that, attached to the encrypted message, their Crypto machines were transmitting the key allowing the de scri ption of messages they were sending. The scheme was perfect, undetectable to all but those who knew where to look. Crypto AG, of course, denied the allegations as pure invention. In 1994, the company issued a message in the Swiss press, stating that manipulation of Crypto AG equipment is absolutely excluded. On the Wikipedia page of Crypto AG, one can read: Crypto AG rejected these accusations as pure invention, asserting in a press release that in March 1994, the Swiss Federal Prosecutor's Office initiated a wide-ranging preliminary investigation against Crypto AG, which was completed in 1997. The accusations regarding influence by third parties or manipulations, which had been repeatedly raised in the media, proved to be without foundation. However, meetings between a NSA cryptographer and Crypto AG personnel to discuss the design of new machines have been factually established. The story was also confirmed by former employees and is supported by company documents. Boris Hagelin is said to have acted out of idealism. What is certain is that the deal for Crypto AG was quite juicy. In return for rigging their machines, Crypto AG is understood to have been granted export licenses to all entities controlled by the NSA. Early Hints A book published in 1977 by Ronald Clark (The Man Who Broke Purple: The Life of Colonel William F. Friedman) revealed that William F. Friedman, another Russian-born genius in the field of cryptography (he deciphered the Japanese code in World War II) and onetime special assistant to the NSA director, had visited Boris Hagelin in 1957. Friedman and Hagelin met at least on two other occasions. Clark was urged by the NSA not to reveal the existence of these meetings for national security reasons. In 1982, James Bamford confirmed the story in his book on the NSA: The Puzzle Palace. The operation was codenamed the Boris project. In effect, Friedman and Hagelin had reached an agreement that was going to pave the way to cooperation of Crypto AG with the NSA. Despite these very obvious hints, countries such as Iran, Iraq and Libya continued using the Crypto AG machines for encrypting their messages. And so did the Vatican,
Re: 2008: The year of hack the vote?
Jack Lloyd wrote: The only reason this 'must' be true is because an anonymous and secure payment system is a terror which thankfully our federal governments and central banks protect us from. While Amazon and others obviously like being able to build customer profiles of everyone, I don't doubt that they would be perfectly willing to accept an anonymous payment as long as the money is good (and, of course, that the transaction costs are no more than a credit card and/or the order flow is sufficient that it is worth building support for it). in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... which resulted in the x9.59 standard http://www.garlic.com/~lynn/x959.html#x959 in the same timeframe, the EU (in conjunction with eu-dpd) made statements that electronic payments at point-of-sale should be as anonymous as cash. this was interpreted as meaning that names should be removed from payment cards (plastic and magstripe). the contention was that (because of poor authentication) retail outlets could cross-check names on the cards against some other form of ID. the implication that removing names might help promote other integrity measures. in the x9.59 standard, we claimed that the improved integrity allowed meeting the EU-DPD objectives. We also claimed that x9.59 was privacy agnostic i.e. it allowed for privacy. The ALL requirement given to the x9a10 financial standard working group met internet, face-to-face, point-of-sale, electronic commerce. It also met debit, credit, ACH, as well as stored-value cards ... aka the same X9.59 was applicable to *ALL*. In the debit/credit scenario some countries have know your customer mandates associating account numbers with individuals ... which we claimed was outside the x9.59 standard. Supposedly with appropriate regulated access to information, govs can obtain information associating account activity with individuals. However, the very same x9.59 standard also works with stored-value/gift cards ... which doesn't have similar know your customer mandates. http://www.garlic.com/~lynn/subpubkey.html#privacy And in fact, most stored-value/gift cards share a lot of the same exact processing with the debit/credit processing ... the addition of x9.59 could provide for the exactly same level of integrity thruout debit, credit, and stored-value/gift processing. for other drift, in the mid-90s ... there were some of the other payment efforts specifically for the internet which had so much payload and processing bloat that it made it impractical past the toy demo stage http://www.garlic.com/~lynn/subpubkey.html#bloat related recent post on infrastructure provisioning and bloat of toy demos: http://www.garlic.com/~lynn/2007v.html#64 folklore indeed about the same time, there were completely different chip card oriented efforts for point-of-sale. one of the scenarios of some of the chipcard pilot projects in the late 90s and early part of this century was that they managed to increase the vulnerabilities (magstripe vis-a-vis chipcards) http://www.garlic.com/~lynn/subintegrity.html#yescard the common excuse from the period, was that chips cost so much that it wasn't possible to afford integrity that actually improved over magstripe. The other possible observation was that some of the chipcard efforts were so chip myopic ... that they couldn't realize that they were actually making it worse for the overall infrastructure. A big issue for merchants isn't anonymous payments ... it is cost of doing business. This has been in the news quite a bit recently in the form of interchange fees ... recent posts http://www.garlic.com/~lynn/2007v.html#62 folklore indeed the other area is in the liability related to breaches (and/or the costs of countermeasures to breaches). i've mentioned before that we had been called in to consult with small client/server startup that wanted to do payments on their server. They had this technology they called SSL and it is frequently now referred to as electronic commerce http://www.garlic.com/~lynn/subnetwork.html#gateway and then we got dragged into involved with the x9a10 financial standard. as part of attempting to meet the requirement to preserve the integrity of the financial infrastructure for all retail payments ... we did some detailed threat and vulnerability analysis. A big item that came out were infrastructure vulnerabilities ... breaches, skimming, harvesting, evesdropping, ... a whole slew of things. we identified that much of the vulnerability could be attributed to the account number and transaction information has diametrically opposing requirements ... 1) it has to be readily available for large number of different business processes and 2) since the crooks can use the same information for various kinds of essentially replay attacks ... the information has to be kept confidential and never
