0

I have an old embedded Linux based device, it's from a project I did about 10 years ago. The device has no built in UI, keyboard or anything like that only a small web server to control it.

Iv'e since forgotten the password on the unit, and the company that originally made it disappeared over 5 years ago now.

Anyway, I thought I'd try to get into it, and see if I could bring it back to life, maybe re-purpose it for some other task (It's GSM comms equipment if anyone's interested) but I need to reset the password on it.

Iv'e managed to get a "reset password" screen up, but it insists on trying to validate some stuff with an external server on the internet, that is no longer online, or even in existence.

It's makes a https request to the server, and putting a packet trace on the request using wire shark, shows it attempting to contact the server, and failing.

So... I thought, I wonder if I can put my own server online, see what it does.

I spun up an Apache2 instance, enabled SSL on it, created a self signed cert for it, then set up my DNS, so that it was redirected to my server, rather than the one it was looking for.

This all works great except for one thing.

If I observer the packet trace, the embedded device refuses to talk to my server because it doesn't trust the certificate CA.

If I could get my server to issue a self signed certificate, but pretend to be another CA (Say equifax, verisign, or something like that) I think I may be able to get the device to validate, and let me reset the admin password.

Does anyone know if it's possible to do this with a self signed certificate?

Improve this question
2
  • it's the client that is choosing to trust the cert or not. It will never trust a self-signed cert when it thinks it's supposed to be connecting back home. It's possible the unit may trust certs from a free CA (so you could get a free cert from a real CA), but that would be your only hope if you can't hack into it to install more trusted root certs.
    – Adrien
    Commented Mar 21, 2017 at 2:13
  • Alas, I think that's going to be my only option, to actually hack into the darn thing. I don't want to scrap it because it's quite a powerful little device, if I can get another OS on it such as OpenWRT then it'll make an amazing little micro server. It's designed for secure GSM operation however, inside a mobile phone network, so it's Nebs Rated for one so is physically strengthened and it's secure OS/Trusted computing for two which means it's designed to keep nation states out :-) I like a challenge though ...
    – shawty
    Commented Mar 21, 2017 at 11:41

1 Answer 1

Reset to default
0

Probably.

If the self-signed cert is being rejected, good for that device to resist the attack. You'll need a cert that is recognized by one of the certificate authorities that the device trusts.

One option may be to adjust what certificate authorities the device trusts. However, I'm guessing that isn't a desirable option. (If you could just remove the hard drive and adjust which authorities are trusted, presumably you could also just adjust the password.)

However, if the device is really as old as you say, it may be that it relies on hashing algorithms like MD5 which are known to be broken.

Note: I'm not going to provide you instructions on how to perform an MD5 collision. I'm simply saying that such a device may be vulnerable to such an attack.

Improve this answer
3
  • Yea I suspected it might be something like that. No hard drive in it, it's a sealed unit with everything burned into permanent flash memory. MD5 collision I can do if need be ;-) don't think it'll be useful though, I can't change the trusted CA list either. I was kinda hoping I might somehow be able to fake a trusted CA name using my self signed cert but I don't think that's gonna happen either. I'll leave the question open for a few days and see if anyone else chimes in with any ideas.
    – shawty
    Commented Mar 20, 2017 at 1:01
  • " I was kinda hoping I might somehow be able to fake a trusted CA name using my self signed cert" - well, the whole point of the encryption signature in the SSL certificate is to prevent that. So the ways to avoid that is to simply not use HTTPS, or to find a flaw in HTTPS. HTTPS is likely pretty solid except that it uses SSL/TLS, which again is likely pretty solid except that they rely on the crypto algorithm, so you need to find a flaw in the crypto algorithm. (Or use another approach to take over the machine.)
    – TOOGAM
    Commented Mar 20, 2017 at 2:02
  • True, HTTPS wouldn't be much use if it could be easily broken I suppose :-) Iv'e got another approach (or two) I'm trying (I'm not going to document them however, for obvious reasons) tks anyway.
    – shawty
    Commented Mar 20, 2017 at 12:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .