Client-side Security

I was planning to start this topic for some time now and here I am making the first steps towards explaining what client-side security is and why it is important. I suspect that there will be a follow up post in the near future. There is definitely a lot of ground work that needs to be laid out for this topic.

"So, what is client-side security?" Well, it is related to JavaScript and Browser security, which is a hot topic today, but in general, simply put, client-side security is all about the security of the client. I hope that wasn't a surprise for you. As I said many times throughout other publications at GNUCITIZEN, the client and the server are in very delicate situation. Here is a quote from a previous GNUCITIZEN article about The Next Super Worm.

Clients and servers are in symbiosis. The security of the server depends on the security of the client and vice versa

The role of the client can be taken by anything. A client is your browser but also your machine as part of a Windows domain. A client is also your Skype and your Wifi card that is associated with an access point. Every piece of software often is a client. Please do not assume that clients and servers are only terms used to describe the state between machines in a network. The role of the client is taken by the thing that sits on one of the sides of the communication spectrum. We define clients and servers based on the way we look at them. Very often servers are clients too as we established that earlier in this post.

The reason why client-side security is interesting today is because it is often ignored by security professionals and in general companies that pay these security professionals to test for vulnerabilities. Here is a typical example; When we need to perform a wifi test, very often we look at things such as available networks, encryption on these networks, network segmentation between them and also signal range. These points definitely cover many things about the security aspects of a wifi network but for sure this is not all. What is left are things such as rouge access points, preferred network list probes and ad-hoc networks. These characteristics of the premises that is tested could be provided as part of the report but very often no solution is specified simply because it is harder to control hundreds of machines compared to controlling only a few.

This is exactly what client-side security problems are. Here is an example how the preferred network list probe requests available exclusively in Windows are a problem for your organization. So let's say that you are supporting encryption (WPA) with 802.1x authentication. It sounds great and moderately secure. However, if any of the clients of that network has other networks in their preferred network list that are not encrypted, attackers can setup a rouge access point, pretending to be one of them, and wait for that client to associate. Once the connection is established and the DHCP server transmits the client IP down the line, the attacker has a network access to that machine. From that point on the attacker will attack this client, which is not as well secured as your corporate infrastructure, and plant a program that will allow the attacker to sneak into your protected WPA enabled network. That of course can be accomplished in many different ways one of which is to wait for a software update from one of the many installed software components like Skype, Firefox and Google Desktop, and replace that update with your own. In an environment where the attacker controls the network, that can be accomplished quite easily.

The reason why I use Wifi problems here in order to describe client-side security is because I want to escape from the Web2.0 cliché for a moment. Similar attacks can be applied to many other things. Just because you have a firewall and well configured intrusion detection system, it does not mean that you are secure. It means that attackers cannot attack your network directly and this is it. However, as we saw earlier in this post, there are many, many other ways a similar goal can be accomplished.

It is said that the security of a system is as strong as its weakest link. The users, the client, these are the weakest links of any system. They are the low-hanging fruit and aldo the targets attackers will go after. Not your network! Their security problems are defined by the term client-side security because often they are seen as clients.

Archived Comments

Carl

It might sound a little bit glib, but as far as our development practices go, we ALWAYS consider the client to be compromised, and factor that into how our systems respond to every request from a client. Authentication, smauthentication. Our systems don't even trust the 'authenticated' client, for many of the reasons you listed above. This does make for some interesting problems - how do you design and implement a security system that introduces low overheads without compromising security? Of course, HOW we solved that problem isn't quite ready for publication just yet.

pdp

Carl, this is very interesting. Of course I am really looking forward to hear how exactly you solved that problem in way that users are still allowed to perform their activities without the overall security of the network being compromised. IMHO, there is no single golden solution for client-size problems, mainly because there are different aspects to be considered. Client-side security problems of Wifi networks are completely different from those found in Web technologies, for example.

dpd

useless discussions........ it's all relative, u can't never be invulnerable. it's all for money. Security experts...bah... if a person had the capabilities he can break in every (virtual) place... if we consider the physical brute force....we're dead...so ... the point is that security and security experts are totally useless in extreem conditions guys... so this discussions are valid for the 98% of the humanity...but if we count the 2%... this is my point of view...maybe too sadddd ... but for me is reality.. bye

Teller

Clinet-Side security is underestimated. IMO, there is no real Client-side security unless you use a strong encryption or a well permission mechanism. Client must be designed to be secured just like the server. There are alot of vectors which one can exploit local security, since we own the client and have full access. Vendors should start writing low-level code, put delicate code in read only sections, they should also use encryption and permission mechanism. So there will be more authentication windows, and performance issues, so what? If we look at the big picture, this is for the best.

pdp

true, but ... keep in mind that business still needs to make money. you cannot abandon everything and start from scratch. the world does not work this way. we need to find a compromisable way of introducing security while keeping the efficiency and usability intact.

Carl

I'd sort of forgotten that I'd replied earlier, but here is some more information about how we ensure that the information being served, stored, and manipulated, is as safe as possible. Assumptions: 1 - The client is compromised 2 - The network is compromised 3 - The server may be compromised (If the server is compromised, then all security is out the window, as the attackers can read straight from RAM, or poke around pretty much anywhere). There are a couple of last-ditch measures that can be put in place, but all they will do is cause the system to halt - since it has identified itself as being compromised. As we are only considering the user's experience for this discussion, we need to find a way to ensure that the client is assured that they are interacting with OUR service, and not a MITM. There are a handful of techniques that we have developed that can give the client a high confidence level that they are interacting with the legitimate service. While they can be spoofed in appearance, their functionality can't. I know that this is something that many people say can't be done, but those people are artificially limiting the scope of their imagination. This is a real world problem that had existed and been solved in other fields of speciality for some time. Some of these solutions can be modified to fit InfoSec. Secondly, we need to ensure that an absolute minimum of sensitive data is sent by the client across the network (considering sniffing and replay attacks). We assume that someone can sniff, and has sniffed, the connection and is able to try a replay attack. In this instance it isn't so much the security of the client, but how the server responds to falsified connections. The goal is to neutralise any and all replay / false connection attempts. Intelligent data design, compartmentalisation, and management will limit the amount of sensitive data exposure that is possible. The other component is to ensure that client-supplied data is extremely volatile - once the legitimate client has used that data, it can't be re-used. Now, this is just scratching the surface of what we have done. We know that it is impossible to be completely secure, but we can make it hard enough. As the solutions evolve, we can keep one or two steps ahead of those trying to break them, so it isn't a one-shot one-off solution - it does require continual improvement. Now for the best part - the base theory can be implemented in many different languages and on most platforms (we always develop for a cross platform solution), and it can be a simple wrapper that encapsulates existing apps - enhancing the security (though it isn't as effective as a ground-up solution). The same underlying problems affect online voting and online finance and it was through considering these challenges that we started to develop our solutions (and then spent the last few years breaking and refining them). For more info, you can always email me.