code

Details on the Storm & Nugache botnets

From Dennis Fisher’s “Storm, Nugache lead dangerous new botnet barrage” (SearchSecurity.com: 19 December 2007):

[Dave Dittrich, a senior security engineer and researcher at the University of Washington in Seattle], 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 C&C 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.

Dittrich and other researchers say that when they analyze the code these malware authors are putting out, what emerges is a picture of a group of skilled, professional software developers learning from their mistakes, improving their code on a weekly basis and making a lot of money in the process.

The way that Storm, Nugache and other similar programs make money for their creators is typically twofold. First and foremost, Storm’s creator controls a massive botnet that he can use to send out spam runs, either for himself or for third parties who pay for the service. Storm-infected PCs have been sending out various spam messages, including pump-and-dump stock scams, pitches for fake medications and highly targeted phishing messages, throughout 2007, and by some estimates were responsible for more than 75% of the spam on the Internet at certain points this year.

Secondly, experts say that Storm’s author has taken to sectioning off his botnet into smaller pieces and then renting those subnets out to other attackers. Estimates of the size of the Storm network have ranged as high as 50 million PCs, but Brandon Enright, a network security analyst at the University of California at San Diego, who wrote a tool called Stormdrain to locate and count infect machines, put the number at closer to 20,000. Dittrich estimates that the size of the Nugache network was roughly equivalent to Enright’s estimates for Storm.

“The Storm network has a team of very smart people behind it. They change it constantly. When the attacks against searching started to be successful, they completely changed how commands are distributed in the network,” said Enright. “If AV adapts, they re-adapt. If attacks by researchers adapt, they re-adapt. If someone tries to DoS their distribution system, they DoS back.”

The other worrisome detail in all of this is that there’s significant evidence that the authors of these various pieces of malware are sharing information and techniques, if not collaborating outright.

“I’m pretty sure that there are tactics being shared between the Nugache and Storm authors,” Dittrich said. “There’s a direct lineage from Sdbot to Rbot to Mytob to Bancos. These guys can just sell the Web front-end to these things and the customers can pick their options and then just hit go.”

Once just a hobby for devious hackers, writing malware is now a profession and its products have helped create a global shadow economy. That infrastructure stretches from the mob-controlled streets of Moscow to the back alleys of Malaysia to the office parks of Silicon Valley. In that regard, Storm, Nugache and the rest are really just the first products off the assembly line, the Model Ts of P2P malware.

Details on the Storm & Nugache botnets Read More »

I for one welcome our new OS overlords: Google Chrome

As some of you may have heard, Google has announced its own web browser, Chrome. It’s releasing the Windows version today, with Mac & Linux versions to follow.

To educate people about the new browser & its goals, they release a 38 pg comic book drawn by the brilliant Scott McCloud. It’s a really good read, but it gets a bit technical at times. However, someone did a “Reader’s Digest” version, which you can read here:

http://technologizer.com/2008/09/01/google-chrome-comic-the-readers-digest-version

I highly encourage you to read it. This browser is doing some very interesting, smart things. And it’s open source, so other browsers can use its code & ideas.

If you want to read the full comic, you can do so here:

http://www.google.com/googlebooks/chrome/

BTW … I don’t think Chrome has the potential of becoming the next big browser; I think instead it has the potential to become the next big operating system. See http://www.techcrunch.com/2008/09/01/meet-chrome-googles-windows-killer/ for more on that.

I for one welcome our new OS overlords: Google Chrome Read More »

Find out a hard drive’s UUID

If you want to add a device like an external hard drive to your /etc/fstab file, it helps if you know the hard drive’s UUID. If you use K/Ubuntu, the following command will display the UUID, along with other useful information.

$ sudo vol_id /dev/sdo1
Password:
ID_FS_USAGE=filesystem
ID_FS_TYPE=ext3
ID_FS_VERSION=1.0
ID_FS_UUID=4857d4bb-5f6b-4f21-af62-830ebae92cff
ID_FS_LABEL=movies
ID_FS_LABEL_SAFE=movies

Find out a hard drive’s UUID Read More »

My new book – Linux Phrasebook – is out!

I’m really proud to announce that my 3rd book is now out & available for purchase: Linux Phrasebook. My first book – Don’t Click on the Blue E!: Switching to Firefox – was for general readers (really!) who wanted to learn how to move to and use the fantastic Firefox web browser. I included a lot of great information for more technical users as well, but the focus was your average Joe. My second book – Hacking Knoppix – was for the more advanced user who wanted to take advantage of Knoppix, a version of Linux that runs entirely off of a CD. You don’t need to be super-technical to use and enjoy Hacking Knoppix, but the more technical you are, the more you’ll enjoy the book. Linux Phrasebook is all about the Linux command line, and it’s perfect for both Linux newbies and experienced users. In fact, when I was asked to write the book, I responded, “Write it? I can’t wait to buy it!”

The idea behind Linux Phrasebook is to give practical examples of Linux commands and their myriad options, with examples for everything. Too often a Linux user will look up a command in order to discover how it works, and while the command and its many options will be detailed, something vitally important will be left out: examples. That’s where Linux Phrasebook comes in. I cover a huge number of different commands and their options, and for every single one, I give an example of usage and results that makes it clear how to use it.

Here’s the table of contents; in parentheses I’ve included some (just some) of the commands I cover in each chapter:

  1. Things to Know About Your Command Line
  2. The Basics (ls, cd, mkdir, cp, mv, rm)
  3. Learning About Commands (man, info, whereis, apropos)
  4. Building Blocks (;, &&, |, >, >>)
  5. Viewing Files (cat, less, head, tail)
  6. Printing and Managing Print Jobs (lpr, lpq, lprm)
  7. Ownerships and Permissions (chgrp, chown, chmod)
  8. Archiving and Compression (zip, gzip, bzip2, tar)
  9. Finding Stuff: Easy (grep, locate)
  10. The find command (find)
  11. Your Shell (history, alias, set)
  12. Monitoring System Resources (ps, lsof, free, df, du)
  13. Installing software (rpm, dkpg, apt-get, yum)
  14. Connectivity (ping, traceroute, route, ifconfig, iwconfig)
  15. Working on the Network (ssh, sftp, scp, rsync, wget)
  16. Windows Networking (nmblookup, smbclient, smbmount)

I’m really proud of the whole book, but the chapter on the super-powerful and useful find command is a standout, along with the material on ssh and its descendants sftp and scp. But really, the whole book is great, and I will definitely be keeping a copy on my desk as a reference. If you want to know more about the Linux command line and how to use it, then I know you’ll enjoy and learn from Linux Phrasebook.

You can read about and buy the book at Amazon (http://www.amazon.com/gp/product/0672328380/) for $10.19. If you have any questions or comments, don’t hesitate to contact me at scott at granneman dot com.

My new book – Linux Phrasebook – is out! Read More »

A technical look at the Morris Worm of 1988

From Donn Seeley’s “The Internet Worm of 1988: A Tour of the Worm“:

November 3, 1988 is already coming to be known as Black Thursday. System administrators around the country came to work on that day and discovered that their networks of computers were laboring under a huge load. If they were able to log in and generate a system status listing, they saw what appeared to be dozens or hundreds of “shell” (command interpreter) processes. If they tried to kill the processes, they found that new processes appeared faster than they could kill them. Rebooting the computer seemed to have no effect within minutes after starting up again, the machine was overloaded by these mysterious processes.

… The worm had taken advantage of lapses in security on systems that were running 4.2 or 4.3 BSD UNIX or derivatives like SunOS. These lapses allowed it to connect to machines across a network, bypass their login authentication, copy itself and then proceed to attack still more machines. The massive system load was generated by multitudes of worms trying to propagate the epidemic. …

The worm consists of a 99-line bootstrap program written in the C language, plus a large relocatable object file that comes in VAX and Sun-3 flavors. …

The activities of the worm break down into the categories of attack and defense. Attack consists of locating hosts (and accounts) to penetrate, then exploiting security holes on remote systems to pass across a copy of the worm and run it. The worm obtains host addresses by examining the system tables /etc/hosts.equiv and /.rhosts, user files like .forward and. rhosts, dynamic routing information produced by the netstat program, and finally randomly generated host addresses on local networks. It ranks these by order of preference, trying a file like /etc/hosts.equiv first because it contains names of local machines that are likely to permit unauthenticated connections. Penetration of a remote system can be accomplished in any of three ways. The worm can take advantage of a bug in the finger server that allows it to download code in place of a finger request and trick the server into executing it. The worm can use a “trap door” in the sendmail SMTP mail service, exercising a bug in the debugging code that allows it to execute a command interpreter and download code across a mail connection. If the worm can penetrate a local account by guessing its password, it can use the rexec and rsh remote command interpreter services to attack hosts that share that account. In each case the worm arranges to get a remote command interpreter which it can use to copy over, compile and execute the 99-line bootstrap. The bootstrap sets up its own network connection with the local worm and copies over the other files it needs, and using these pieces a remote worm is built and the infection procedure starts over again. …

When studying a tricky program like this, it’s just as important to establish what the program does not do as what it does do. The worm does not delete a system’s files: it only removes files that it created in the process of bootstrapping. The program does not attempt to incapacitate a system by deleting important files, or indeed any files. It does not remove log files or otherwise interfere with normal operation other than by consuming system resources. The worm does not modify existing files: it is not a virus. The worm propagates by copying itself and compiling itself on each system; it does not modify other programs to do its work for it. Due to its method of infection, it can’t count on sufficient privileges to be able to modify programs. The worm does not install trojan horses: its method of attack is strictly active, it never waits for a user to trip over a trap. Part of the reason for this is that the worm can’t afford to waste time waiting for trojan horses-it must reproduce before it is discovered. Finally, the worm does not record or transmit decrypted passwords: except for its own static list of favorite passwords, the worm does not propagate cracked passwords on to new worms nor does it transmit them back to some home base. This is not to say that the accounts that the worm penetrated are secure merely because the worm did not tell anyone what their passwords were, of course-if the worm can guess an account’s password, certainly others can too. The worm does not try to capture superuser privileges: while it does try to break into accounts, it doesn’t depend on having particular privileges to propagate, and never makes special use of such privileges if it somehow gets them. The worm does not propagate over uucp or X.25 or DECNET or BITNET: it specifically requires TCP/IP. The worm does not infect System V systems unless they have been modified to use Berkeley network programs like sendmail, fingerd and rexec.

A technical look at the Morris Worm of 1988 Read More »

Computer commands as incantations

From Julian Dibbell’s “A Rape in Cyberspace: How an Evil Clown, a Haitian Trickster Spirit, Two Wizards, and a Cast of Dozens Turned a Database Into a Society“:

After all, anyone the least bit familiar with the workings of the new era’s definitive technology, the computer, knows that it operates on a principle impracticably difficult to distinguish from the pre-Enlightenment principle of the magic word: the commands you type into a computer are a kind of speech that doesn’t so much communicate as make things happen, directly and ineluctably, the same way pulling a trigger does. They are incantations, in other words, and anyone at all attuned to the technosocial megatrends of the moment — from the growing dependence of economies on the global flow of intensely fetishized words and numbers to the burgeoning ability of bioengineers to speak the spells written in the four-letter text of DNA — knows that the logic of the incantation is rapidly permeating the fabric of our lives.

Computer commands as incantations Read More »

When to use XML

From W3C’s “Architecture of the World Wide Web, Volume One“:

XML defines textual data formats that are naturally suited to describing data objects which are hierarchical and processed in a chosen sequence. It is widely, but not universally, applicable for data formats; an audio or video format, for example, is unlikely to be well suited to expression in XML. Design constraints that would suggest the use of XML include:

1. Requirement for a hierarchical structure.
2. Need for a wide range of tools on a variety of platforms.
3. Need for data that can outlive the applications that currently process it.
4. Ability to support internationalization in a self-describing way that makes confusion over coding options unlikely.
5. Early detection of encoding errors with no requirement to “work around” such errors.
6. A high proportion of human-readable textual content.
7. Potential composition of the data format with other XML-encoded formats.
8. Desire for data easily parsed by both humans and machines.
9. Desire for vocabularies that can be invented in a distributed manner and combined flexibly.

When to use XML Read More »

John the Ripper makes password cracking easy

From Federico Biancuzzi’s “John the Ripper 1.7, by Solar Designer“:

John the Ripper 1.7 also improves on the use of MMX on x86 and starts to use AltiVec on PowerPC processors when cracking DES-based hashes (that is, both Unix crypt(3) and Windows LM hashes). To my knowledge, John 1.7 (or rather, one of the development snapshots leading to this release) is the first program to cross the 1 million Unix crypts per second (c/s) boundary on a general-purpose CPU. Currently, John 1.7 achieves up to 1.6M c/s raw performance (that is, with no matching salts) on a PowerPC G5 at 2.7 GHz (or 1.1M c/s on a 1.8 GHz) and touches 1M c/s on the fastest AMD CPUs currently available. Intel P4s reach up to 800k c/s. (A non-public development version making use of SSE also reaches 1M c/s on an Intel P4 at 3.4 and 3.6 GHz. I intend to include that code into a post-1.7 version.)

John the Ripper makes password cracking easy Read More »

Google on the Google File System (& Linux)

From Sanjay Ghemawat, Howard Gobioff, & Shun-Tak Leung’s “The Google File System“:

We have designed and implemented the Google File Sys- tem, a scalable distributed file system for large distributed data-intensive applications. It provides fault tolerance while running on inexpensive commodity hardware, and it delivers high aggregate performance to a large number of clients. …

The file system has successfully met our storage needs. It is widely deployed within Google as the storage platform for the generation and processing of data used by our ser- vice as well as research and development efforts that require large data sets. The largest cluster to date provides hun- dreds of terabytes of storage across thousands of disks on over a thousand machines, and it is concurrently accessed by hundreds of clients. …

We have seen problems caused by application bugs, operating system bugs, human errors, and the failures of disks, memory, connectors, networking, and power sup- plies. Therefore, constant monitoring, error detection, fault tolerance, and automatic recovery must be integral to the system.

Second, files are huge by traditional standards. Multi-GB files are common. Each file typically contains many applica- tion objects such as web documents. When we are regularly working with fast growing data sets of many TBs comprising billions of objects, it is unwieldy to manage billions of ap- proximately KB-sized files even when the file system could support it. As a result, design assumptions and parameters such as I/O operation and blocksizes have to be revisited.

Third, most files are mutated by appending new data rather than overwriting existing data. Random writes within a file are practically non-existent. Once written, the files are only read, and often only sequentially. …

Multiple GFS clusters are currently deployed for different purposes. The largest ones have over 1000 storage nodes, over 300 TB of diskstorage, and are heavily accessed by hundreds of clients on distinct machines on a continuous basis. …

Despite occasional problems, the availability of Linux code has helped us time and again to explore and understand system behavior. When appropriate, we improve the kernel and share the changes with the open source community.

Google on the Google File System (& Linux) Read More »

The original description of Ajax

From Jesse James Garrett’s “Ajax: A New Approach to Web Applications“:

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

  • standards-based presentation using XHTML and CSS;
  • dynamic display and interaction using the Document Object Model;
  • data interchange and manipulation using XML and XSLT;
  • asynchronous data retrieval using XMLHttpRequest;
  • and JavaScript binding everything together.

The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing — retrieving data, crunching numbers, talking to various legacy systems — and then returns an HTML page to the client. It’s a model adapted from the Web’s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn’t necessarily make it good for software applications. …

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.

Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something. …

Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.

The original description of Ajax Read More »

The mystery of the Voynich mss

From John Baez:

A page from the Voynich mssThe Voynich manuscript is by far the most mysterious of all texts. It is seven by ten inches in size, and about 200 pages long. It is made of soft, light-brown vellum. It is written in a flowing cursive script in alphabet that has never been seen elsewhere. Nobody knows what it means. During World War II some of the top military code-breakers in America tried to decipher it, but failed. A professor at the University of Pennsylvania seems to have gone insane trying to figure it out. Though the manuscript was found in Italy, statistical analyses show the text is completely different in character from any European language.

The mystery of the Voynich mss Read More »