I’m presently contemplating a project to build a small DC/storage outbuilding down the side of my garage, basically to relocate all the random servers and such which are currently located in my study to somewhere else, ideally with proper climate control.

Now of course I don’t want the inconvenience of actually having to go out there to yutz with things when I need to so I went digging around on eBait for an IP KVM, turned up a “Prima IP-16 Uniclass” for $140, seemed like a reasonable price, unfortunately it’s one of the ones that uses an oddball cable that feeds PS2/USB and VGA via an HD15 connector. But I digress.

When I got it home, I started poking around if of course. First thing I wanted to do was to upload my own SSL certs to it, via the vendor-supplied web interface you can upload SOME certs but not others, one of the ones you can’t upload is the SSL cert for the web server, no biggie, let’s make that happen.

First things first, these guys have a non-password-protected root console available on Serial port 1, w00t! What an awesome start, fire up realterm, connect to port, determine that we’re talking 115200-8-n-1, reboot box. Surprise surprise it’s running Linux (on some flavour of Intel XScale processor);

Prima IP-16 Bootloader

Prima IP-16 Bootloader

Having a sniff around we find that we’ve got one linux user, and that’s root, not sure what the default password is, but since it’s just crypt’d I could feed it to cudahashcat, or since I’ve got a root shell I could just change it…

Prima IP-16 Password Reset

Prima IP-16 Password Reset

Let’s have a look at inittab;

/> cat /etc/inittab
#slog:unknown:/bin/syslogd -n
#klog:unknown:/bin/klogd -n

Hmm, we’ve an inetd but it’s disabled, I wonder what runs out of that?

/> cat /etc/inetd.conf
discard dgram udp wait root /bin/discard
discard stream tcp nowait root /bin/discard
telnet stream tcp nowait root /sbin/telnetd
ftp stream tcp nowait root /bin/ftpd -l

Woo, telnet and ftp, just what I always wanted, let’s run it up and see if she works

/> /bin/inetd&

Sure enough, now we can telnet over and login using the root password we set;

Prima IP-16 Telnet Access

Prima IP-16 Telnet Access

Now that we have a fully functional terminal we can actually use “vi” so let’s make that inetd change stick;

/> cat /etc/inittab
#slog:unknown:/bin/syslogd -n
#klog:unknown:/bin/klogd -n
/> reboot

Next step, find the certificates, a bit more nosing around turned up /etc/config/certs;

/> cd /etc/config/certs
/etc/config/certs> ls
dh1024.pem        dserverkey.pem    server.crt        webserverkey.pem
dh512.pem         ldapcert.crt      serverkey.pem
droot.crt         ldapkey.pem       webroot.crt
dserver.crt       root.crt          webserver.crt

OK, so here are all the certs, not just the ones the web UI will let us update, I reckon that “webserver.crt” and “webserverkey.pem” are probably what we’re looking for, so we can just drop in our own certs and we’re golden, right? Not quite so fast there, there’s a problem;

/etc/config/certs> cat webserverkey.pem
Proc-Type: 4,<b>ENCRYPTED</b>
DEK-Info: DES-EDE3-CBC,D0C717240CAC789F

That’s a fly in the ointment, the private key is encrypted, probably with some hard-coded password. Time for some reverse engineering, by the wonders of FTP we download /bin/webs and feed it to our old friend IDA, have a sniff around in the “Strings” sub-view to find ourselves a starting point;

Prima IP-16 webs IDA - Strings

Prima IP-16 webs IDA - Strings

A bit of digging around leads to;

Prima IP-16 webs Code

Prima IP-16 webs Code

Oh, look “dserverpass” that sounds suspiciously like a really un-creative private key password, let’s grab the keys from the KVM and see what we can see;

$ openssl rsa -in webserverkey.pem -out webserver.key
Enter pass phrase for webserverkey.pem: <i>dserverpass</i>
writing RSA key

Awesome, so the password is, in fact “dserverpass”, so let’s go encrypt our private key with that password;

$ openssl rsa -in privkey.pem -out webserverkey.pem -des3
writing RSA key
Enter PEM pass phrase: <i>dserverpass</i>
Verifying - Enter PEM pass phrase: <i>dserverpass</i>

FTP the cert and key up, reboot the device and no webserver…

/> cat /var/log/webs.log
SSL: Unable to set certificate file &lt;/etc/config/certs/webserver.crt&gt;

Bugger… The cert which was there to begin with used a 1024-bit RSA key, maybe it doesn’t like 2048-bit keys…

$ openssl req -newkey rsa:1024 -keyout -nodes test.key -x509 -days 365 -out test.crt
Generating a 1024 bit RSA private key
writing new private key to 'test.key'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

$ openssl pkey -in test.key -out test.pem -des3
Enter PEM pass phrase: *dserverpass*
Verifying - Enter PEM pass phrase: *dserverpass*

Upload, rename, reboot, et. viola, it’s presenting our new cert… That’s rather a kick in the teeth.

At least we got our own cert into it, but I’d prefer something a bit more than 1024-bit…

Not sure whether it’s a limitation to how they’ve compiled the openssl libs for it, or if it’s a limitation of their implementation, I’ll have to do some digging and figure out which it is, if it’s a limitation in their code it might be possible to patch it (and fix the crappy hard-coded key passphrase while I’m at it…) if it’s a limitation in the libs it may well have to go in the “too hard” basket, because I don’t particularly fancy building a cross-compile toolchain for an unknown platform, time will tell.

In the meantime I’ll leave it as is and disable inetd again.