Today, I acquired a copy of a report on anakata’s alleged hacking of Logica. You, too, can find a copy of it in PDF form here.
There’s a number of interesting things in this report, and I figured I would take the time to disassemble them and give a little bit of analysis on each.

The first interesting thing, which starts on the bottom of page 36, is the vast number of IPs from which the attackers came from. Out of curiosity, I did a little investigation on the boxes involved in the attacks, the jumpboxes, if you will.
Now, one of these is pretty interesting.
124.248.187.225 and 27.109.118.33 are located in Cambodia. This implies that, if it WAS anakata, he presumably just compromised wireless routers in his area and used those to launch the attacks, or else was too lazy to protect himself.
93.186.170.54 belongs to a VPS company.
The others, bar one, are all residential ranges. I took a look at them, and nothing particularly struck my fancy about them, however, they did possess dreamboxes and/or some rather esoteric webservers, so my guess would be either default credentials or really, really bad code led to their compromises.
Now, what grabs my attention is 202.120.189.223, and here is why:
This was a z/OS mainframe belonging to Tongji University in China, one of the most respected universities in the country (although it is now offline). So, this brings the total number of hacked mainframes up to 3.

I’m just speculating here, but I would imagine that owing to the difficulty in transferring and working with files from UNIX to z/OS (even with Unix System Services and FTP), that Chinese mainframe probably existed as both storage for the tools used in the Logica hack, and as a development environment. I’m frankly very curious as to how, exactly, these mainframes were so easily broken into, but I have some suspicions.
RACF, which is one of two competing “user management systems” for z/OS (the other being ACF2), has a number of interesting… quirks, including a limit on password length (8 characters), and the fact that the superuser account shipped by default cannot be completely removed; trying to attempt so may seem successful, but will result in it being quietly restored later. I have a few other theories, including the possibility of credential reuse and easily enumerated accounts (RACF conveniently tells you if a username doesn’t exist on the system), but unfortunately most of these aren’t concrete. Additionally, the main methods of egress seem to have been FTP and SSH, with little to no login failures reported, in which case it is worth assuming that the credentials may have been gathered from elsewhere, ie a compromised webserver.
Anyway, as I said, this is just conjecture, and not solid facts.

Another interesting thing that is worth pointing out is the nature of the majority of the backdoor tools. Take a look at the following code:

#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
setuid(0);
setgid(0);
setgroups(0, NULL);
execl("/bin/sh", "sh", NULL);
}

That’s incredibly, incredibly simple C. I’m not a C programmer, and even I could write that. But there’s a wonderful elegance about it. Why waste time with a tremendously technical backdoor tool when the simplest thing, a setuid wrapper for a shell, works just as well?
That said, there are also far more technical and clever tools deployed, including one written in Z/arch HLasm. Dabbling in C, assembly, and other languages seems rather adventurous, so, with the warning that it’s just speculation, I’d imagine that this was a group of people familiar with mainframe development, not just one developer.
The other tools, go.rx and kurwa, are interesting, too. Based on the strings shown from them, they’re probably rexx scripts (rexx is the equivalent of Perl on UNIX). If the giant /* REXX */ didn’t inform you. What is interesting is that they are apparently exploiting a previously unknown privilege escalation vulnerability, as well as adding yet another language to the list used.
There are also less technical backdoors, for example, changing SSH keys to ensure access later, and altering inetd.conf to accomplish the same thing.

So, now that we’ve taken a look at this, I’d like to comment on what seems, to me, to be paradoxical and/or stupid.
There are only two mainframes, yet a fairly bewildering range of techniques was deployed, with tools written in at least three different programming languages. This right here is terrible opsec, and a terrible waste. Adding multiple backdoors is risky, because you can’t gain MORE access; once you’ve got a backdoor in place you’ve got a backdoor, but you’re leaving more things around that a curious system administrator might stumble upon. As well as that, the more varied the tools and techniques, the more obvious it’s a large and diverse group. It would have been wiser to agree on a list of public tools and simple code that could have been easily ported to z/OS. It just seems weird that everyone was deploying their own toolkit; if these were made specifically for this attack, that’s quite an amount of time to spend.

Still, it’s a fascinating story. Mainframe security doesn’t get nearly enough coverage, and IBM’s z/OS has survived through a lack of scrutiny; security through obscurity.