Maemo 5 as a vulnerability / "hacking" victim - Page 4 - maemo.org

Active Topics

Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 1 day, 8 hrs ago
TLS 1.2 for N9 is ready (28)
to MeeGo / Harmattan by smartblu9 - 1 day, 9 hrs ago
Maemo repository (3)
to Community by torsen - 2 days, 1 hr ago
Error after installing Leste on sdcard (11)
to Maemo 7 / Leste by Maemish - 2 days, 23 hrs ago
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 4 days, 5 hrs ago
more...

Page 4 of 5

« First

< Prev

Next >

Thread Tools

	fasza2	2011-06-15 , 22:34
	Posts: 187 \| Thanked: 96 times \| Joined on Sep 2010 @ London, UK	#31

Originally Posted by momcilo

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

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.

Originally Posted by momcilo

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

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

Originally Posted by momcilo

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?

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?

Originally Posted by momcilo

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

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?

Originally Posted by momcilo

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.

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

Quote & Reply |

The Following User Says Thank You to fasza2 For This Useful Post:
momcilo

momcilo	2011-06-16 , 07:04
Posts: 673 \| Thanked: 856 times \| Joined on Mar 2006	#32

Originally Posted by fasza2

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?

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.

Originally Posted by fasza2

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?

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.

__________________
http://gpl-violations.org/faq/violation-faq.html

Last edited by momcilo; 2011-06-16 at 11:51.

Quote & Reply |

The Following 2 Users Say Thank You to momcilo For This Useful Post:
Estel, fasza2

	fasza2	2011-06-16 , 13:51
	Posts: 187 \| Thanked: 96 times \| Joined on Sep 2010 @ London, UK	#33

Originally Posted by momcilo

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

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.

Originally Posted by momcilo

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.

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

Originally Posted by momcilo

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

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

Originally Posted by momcilo

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.

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.

Originally Posted by momcilo

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

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.

Quote & Reply |

The Following 2 Users Say Thank You to fasza2 For This Useful Post:
Estel, momcilo

momcilo	2011-06-16 , 14:28
Posts: 673 \| Thanked: 856 times \| Joined on Mar 2006	#34

Originally Posted by fasza2

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'

Here is the quote from openvpn manual:

In static-key encryption mode, the HMAC key is included in the key file generated by --genkey. In TLS mode, the HMAC key is dynamically
generated and shared between peers via the TLS control channel. If OpenVPN receives a packet with a bad HMAC it will drop the packet.
HMAC usually adds 16 or 20 bytes per packet. Set alg=none to disable authentication.

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.

__________________
http://gpl-violations.org/faq/violation-faq.html

Quote & Reply |

The Following User Says Thank You to momcilo For This Useful Post:
fasza2

sr00t	2011-06-16 , 15:16
Posts: 135 \| Thanked: 75 times \| Joined on Apr 2011 @ Buenos Aires, Argentina	#35

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

Originally Posted by fasza2

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.
.

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.

Quote & Reply |

momcilo	2011-06-16 , 18:21
Posts: 673 \| Thanked: 856 times \| Joined on Mar 2006	#36

Originally Posted by sr00t

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.

Gecko = Mozilla Engine

__________________
http://gpl-violations.org/faq/violation-faq.html

Quote & Reply |

sr00t	2011-06-16 , 19:07
Posts: 135 \| Thanked: 75 times \| Joined on Apr 2011 @ Buenos Aires, Argentina	#37

Originally Posted by momcilo

Gecko = Mozilla Engine

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.

Quote & Reply |

The Following User Says Thank You to sr00t For This Useful Post:
momcilo

momcilo	2011-06-16 , 19:22
Posts: 673 \| Thanked: 856 times \| Joined on Mar 2006	#38

Originally Posted by sr00t

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.

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

__________________
http://gpl-violations.org/faq/violation-faq.html

Quote & Reply |

The Following 2 Users Say Thank You to momcilo For This Useful Post:
fasza2, sr00t

sr00t	2011-06-16 , 19:41
Posts: 135 \| Thanked: 75 times \| Joined on Apr 2011 @ Buenos Aires, Argentina	#39

Originally Posted by momcilo

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

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

Quote & Reply |

	fasza2	2011-06-16 , 21:05
	Posts: 187 \| Thanked: 96 times \| Joined on Sep 2010 @ London, UK	#40

Originally Posted by momcilo

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

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:

Originally Posted by momcilo

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 fact, I'm not really sure what the static key mode is. Is it the non-PKI one?

Originally Posted by momcilo

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.

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.

Originally Posted by momcilo

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

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.