Maemo 5 as a vulnerability / "hacking" victim
 

Hi all.
First I want to tell you that I'll assist to this Security Conference and I'll go with my N900.
Let's suppose it has a very difficult root password (uncrackable under normal conditions) and the only service available as an open port would be SSH. Bluetooth will be shut down and 3G too.

Would connecting to WiFi in that conference be dangerous? How do you think the attacker could penetrate N900 (without having physical access to it, of course).
Should I let SSH port be open? If I close it, would another service still running be used as an exploitable gate to gain shell access?

As setup, I have latest CSSU with latest Kernel-Power, and latest Busybox (Busybox-Power).

TL;DR :
I wanna know if N900 is vulnerable to attacks as a target, and share experiences about vulnerabilies found in Maemo 5 and how to prevent them.

Hoping I didn't make silly questions that may irritate you (I'm not an expert, for sure, but I'm not a lammo either), I wait for your answers. Thanks a lot, guys.


Ok, let's compile and summarize some nice advices I've got so far:

Re: Maemo 5 as a vulnerability / "hacking" victim
 

well I know SSH requires a password so...

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Turn off SSH if you're not going to use it. Also traffic is being sniffed more than a school girl in Japan. Don't log on to anything, general browsing should be fine as long as nobody does a redirect and exploits you from there.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

how do you "turn off" SSH?

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Alright.
Then, penetration to the shell would not be possible 'in theory' if I don't screw it up on the network side (a.k.a. MITM attacks, redirects and sniffs) and if I turn off SSH.

Any more advices, ideas?

Re: Maemo 5 as a vulnerability / "hacking" victim
 

You don't turn it off, that's right. But you can disable root access.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

What about the SSH switch found in the repos? How does that thing turn SSH off?

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Disable IM status and any mail/calendar/contacts syncing :)

Or make sure they use SSL/....

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Black magic? I really wanna know now, but I don't have it installed and I don't have the sources either.
Something with iptables? Or changed properties in sshd_config? I don't know :/ .-

Re: Maemo 5 as a vulnerability / "hacking" victim
 

/etc/init.d/ssh stop

as root

ps ax | grep sshd

to see if you have ssh running or not

Re: Maemo 5 as a vulnerability / "hacking" victim
 

It simply stops and starts the service, just like you can do manually.

As root. Turn off sshd:
As root. Turn on sshd:

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Use iptables/ip6tables to drop all incoming and outgoing connections over your wifi adapter, only allowing traffic out to your VPN/SSH tunnel server. And use that tunnel for everything.

Otherwise, don't use open wifi, use your 3G internet instead.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

That would be very effective. It would make virtually impossible to penetrate Maemo, and to sniff in/out traffic.
That's a must-do. Thanks!

PS: I didn't want to explain it because it was offtopic, but 3G in my country doesn't work with N900 3g freq spectrum :/

Re: Maemo 5 as a vulnerability / "hacking" victim
 

I don't think disabling sshd would actually change anything, openssh is pretty secure

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Any problems with dropbear ssh implementation?

Re: Maemo 5 as a vulnerability / "hacking" victim
 

I'm intigued by this. The N900 is not just a Linux device but an ARM Linux device with no real java support, which means a virus is a lot less likely than say, for a winxp user. However, access by others on the same network via tcp/ip etc. might be possible, mightn't it?

When normal precautions are taken (no ssh, no non-ssl IM, etc.), is the decive is totally secure?
How vunerable is the N900, when connected to an open wifi network?
Can others access it via a connection protocol?
If so, to which areas/folders?
Can anything be done to improve the operating security of the device, to reduce/prevent access to file system, any ongoing phone calls or sms coversations?

I guess the worst case scenario would be an attack from a malicious N900 user - what steps could be taken before and after, as damage limitation and notification?

Re: Maemo 5 as a vulnerability / "hacking" victim
 

How old is openssh within N900?

There are known exploits for older version of OpenSSH which don't require username/password knowledge.

TSL/SSL may be breached through redirections, especially if the logon page is loaded through basic http without SSL.

Don't use unencrypted login pages.

Basically, since the software running inside N900 is relatively old and therefore very well known to the attackers, you may have additional holes.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Don't accept any new certificates within browser, chat application or mail client.

That may not be enough, comodo has issued certificates without checking identity of servers for such as yahoo, google, etc.

It may be possible that some of these certificates are not revoked (detected) yet.

http://threatpost.com/en_us/blogs/ph...-others-032311

EDIT: Tribute to Comodo: https://bugzilla.mozilla.org/show_bug.cgi?id=647959

Re: Maemo 5 as a vulnerability / "hacking" victim
 

This is a VERY interesting question. In fact, that was more or less what I intend to post but my poor english doesn't help a lot.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Given the fact that the support for N900 was relatively poor when it comes to basic functionality (many unresolved bugs), it is quite reasonable the expect the security aspects were neglected too.

In fact I can bet that SSL attack can be mounted against any of the devices such as 770, N800, N810, N900. Especially if the certificate trust store contains Comodo root certificates (Haven't check that yet!).

Re: Maemo 5 as a vulnerability / "hacking" victim
 

That is an assumption.

Here is the official OpenSSH link:
http://www.openssh.org/security.html

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Using passwords sucks big time. To prevent against a scripted password-guessing bot, just disable password login on your N900 and only use keys.

edit (as root) /etc/ssh/sshd_config:
To use key based authentication: http://www.google.com/search?q=ssh+login+no+password


edit: woowoo post 1,000!

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Thanks a lot, Yoda, I'll lurk more about that.
1K get in my thread? What an honour :D .-

Re: Maemo 5 as a vulnerability / "hacking" victim
 

I've just checked the freemantle repository.
Openssh is version 5.1p1

There are at least 3 published problems with security.

And OpenSSl is 0.9.8n, it also has 3 published issues.

Normally that would not be a severe problem given the use of the device. The herd logic dictates that the probability is low. But since you decided to enter the place where many lions seek food, your chances of getting eaten have risen significantly. :D

Good luck!

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Please list the vulns for us :)

Re: Maemo 5 as a vulnerability / "hacking" victim
 

If is this vuln, it's probably impossible to exploit it in a practical way:

http://www.openssh.org/txt/cbc.adv

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Once again, thank you for allowing me to correct my errors before completely disgracing myself.

Well after carefully reading the reported vulnerabilities (shame on me), it seems neither of the vulnerabilities is applicable to this particular case, or at lease probability is low as stated in:
http://www.openssh.com/txt/cbc.adv

As for openssl: this one may be applicable depending on how the package was built. The rest of them are related to server functionalities.

In any case, the point is that the "secure" is a very relative term that very often degrades over time.

Btw: Can someone check if there is a Comodo root certificate inside keystore within N900?

SSL redirection is still viable threat.
More info on: http://www.thoughtcrime.org/software/sslstrip/
That one actually works on wifi!!! :D:D:D:D

EDIT: Added more details and corrected errors

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Well so far so good:
No Comodo or Honest Achmed within Diablo. (at least not for the built in browser/chat/e-mail)

As for N900, I don't own one so I can not check.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Does our openvpn client have any known vulnerabilities?(let's assume the server is secure) Does HMAC auth apply to client as well as server? Can user/group nobody be set up on client side if server is not *NIX. Would chroot work client side only in the same scenario?

Is there any way to log keystrokes through a browser in N900?

Sandboxing Maemo's browsers?

Just some questions that I'd love to hear your opinion about.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

You may want to check the openvpn page on that topic. But you can not eliminate the server as a factor.

A lot depends on the actual configuration of vpn server. In addition, there may be weaknesses in implementation as well as cryptography.

In brief:
OpenVPN uses TLS/SSL as transport protocol. When SSL session is established, two sides exchange public keys (certificates). By applying both keys to Diffie-Hellman authentication, the shared secret is computed. This shared secret is the symmetric key that is used for the symmetric cipher to transform the plain text to cipher text at the source, and later to transform the cipher text to plain text at the destination.

Please be more specific, because I am not sure if you are referring to the session establishment, or later integrity checks, when data are actualy sent?

By this you mean chroot-ing the openvpn client itself?

The posted exploit does not recover username/passwords from within browser. It basically replaces legitimate login page.

The attacker poses as a default router, by producing massive number of arp messages in order to confuse the victim about default gateways actual ARP address.

The attacker itself is configured to forward any incoming traffic to the legitimate router. The sslstrip is used in-between to replace unencrypted HTML login pages, with ones that can be used to log username/passwords.

Once the username/password is recovered, the information is used to create a legitimate session, so victim firmly belives it is secure, since the SSL is established and locker is visible. :D

Re: Maemo 5 as a vulnerability / "hacking" victim
 

I don't want to neglect that possibility, I just want to look at the topic from Maemo's(the client's) angle. If the server is compromised the client is as well, there is no question about that. The whole idea is what can be done client side to enhance security.

Of course, although my implementation is quite safe from passive attacks due to very low traffic.

I meant kind of meant both, but more of the latter; does HMAC auth protect the client from DoS and portscan by dropping non-authenticated packets before processing?

Yes exactly, to create a chroot jain in case server or another client get compromised. Is it possible client side only assuming server is a win box?

I did get that, very clever actually. But the question was wether or not it's possible to obtain passwords using keylogger for another browsing instance, IM account and whatnot. Lets assume user wanders(via phishing or DNS spoof) to a site that has a keylogger script.

Thx for responding btw:)

Re: Maemo 5 as a vulnerability / "hacking" victim
 

I would not go for static key mode, since in this case the same keys are reused on each connection.

It is better to use SSL based mode, SSL itself enforces the generation of shared secret each time. Thus created secure channel is used to exchange the keying material which is used to dynamically generate shared secrets.

Yes you may do that, in addition you can isolate clients within VPN.

The possible intrusion vector may be the built-in browser. I don't know which version of Gecko is used, but I am pretty sure the there were severe problems with firefox pre-3.6 versions.

Closed-source Flash might also be interesting for poking around.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

You must have misunderstood me on this one, let me call openvpn.net to help explain what I meant:

'Hardening OpenVPN Security

One of the often-repeated maxims of network security is that one should never place so much trust in a single security component that its failure causes a catastrophic security breach. OpenVPN provides several mechanisms to add additional security layers to hedge against such an outcome.
tls-auth

The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:

* DoS attacks or port flooding on the OpenVPN UDP port.
* Port scanning to determine which server UDP ports are in a listening state.
* Buffer overflow vulnerabilities in the SSL/TLS implementation.
* SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).

Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key:

openvpn --genkey --secret ta.key'

To my current understanding this option uses a SHA1 hash of secret ta.key file and the packet data to verify that packet comes from source and that it hasn't been tempered with and places this hash in the packet header. I think it also gets encrypted with the cypher of your choice, but that I can't tell for sure.

That is indeed correct, and I wouldn't have it any other way;)

Thanks, the latter is done via the client-to-client option;)

That I am also worried about and we are not likely to recive any security updates for MicroB, unless in CSSU. I don't even know wether MicroB is open. It would be a good thing if some of our 'seasoned' members looked into this.

Probably the weakest link as there is no way we can apply updates to that.

Please note that I am no way an expert in either networking nor security, I just have a genuine interest in these areas. I just started reading up on both very recently. I have some knowledge of ITC from my past, but I wasn't very interested until I actually joined this community. So that being said any positive criticism is hugely welcome.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Here is the quote from openvpn manual:

In short, this is used for static keys when used with UDP. For dynamic (TLS based) you do not need it.

My guess is that the shared secret is used to feed IV of hash function (MD5, SHA1, SHA224, SHA256, SHA384, SHA512), although I would have to inspect source code to see what is actually going on.

In case of SHA1 20 bytes * 8 bits, gives you 160 bits.

Instead of putting SHA1 to the outer package, I would prefer to keep it together with plain-source, than encrypt everything together. That would provide more security.

Any poking around with the cipher text, would cause inner SHA1 hash to fail.

The drawback to this approach is the need to decrypt each packet, than calculate SHA1 to detect the "faulty" packet.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Wow. This is getting very interesting. Thanks good Sirs.


Nokia didn't specify about MicroB property but I'm pretty sure MicroB is closed-source as a property of Nokia.

Maybe here's an answer to the sandboxing idea (again, maybe):
http://browser.garage.maemo.org/docs/build_howto.html

White paper of MicroB showing internal architecture:
http://browser.garage.maemo.org/docs/browser_paper.html

Lemme know it this helped you.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Gecko = Mozilla Engine

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Yeah I know that part, but as being a 'fork' of Firefox it has a lot of source tweaks that appear to be closed. I didn't see microb source code available anywhere. Even if it's based in the same engine, the rest of it's a part of Maemo's closed source parts.
That sucks big time.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

I don't know about the facts at the moment. But consider this: they wanted to use gecko in order to have a device with good and stable browser.

Developing such piece of software requires years and huge resources. The complexity of that effort is significantly higher than a sum of all source code created by Nokia for 4 devices so far.

So they have resorted to using existing product based on MPL licence which is far less restrictive to source closing. They may have done some patches, but the scale of changes is negligible compared to original Gecko.

In addition, the company culture dictates rapid releases of new devices, so I can bet they did not spend too much time patching security issues.

By following this logic you can expect "Mozilla Engine" to suffer majority of problems identified within original Gecko engine.

Sure they can continue to merge with the original project, but this did not happen too often for any of the devices. Once the support has stopped, no new updates have appeared and it is reasanoble to expect that some exploits will work in MicroB

Re: Maemo 5 as a vulnerability / "hacking" victim
 

Oh I didn't understood where you were going. I totally agree with you. Thanks.

Re: Maemo 5 as a vulnerability / "hacking" victim
 

You got me confused now:) I had to check my .conf file; but
I think tls-auth /etc/openvpn/ta.key 1 stands for the dynamic one.
So the preshared ta.key file is needed probably for this very reason:

In fact, I'm not really sure what the static key mode is. Is it the non-PKI one?

Now I'm not sure how exacly they implemented this; if hash is encryped seperate from data or together. But I know if an attacker changes a single bit in the packet the hash will fail.

The whole idea is that the server has to be able to be extract the hash from the packet in order to filter out dodgy UDP packets to save the cypher and the TCP/IP stack from further processing. Sort of not letting your 'pipe' get 'clogged'. Thankfully, this is just the first line of defence. That being said as long as the hash can be extracted from the packet it would be possible to encrypt them together, but I'll try to read up on this later.

PS: MD5 is not recomended due to vulnerabilities and some other problems.