Category Archives: Security Research

What the * is wrong with mobile security

Posted on by
1

Long time no post. Sorry about that <insert favorite excuse>.

Anyway, as you can probably imagine, here’s another rant brewing. We have been dealing with a barrage of mobile application security issues lately, and although I had the feeling that there was a lot wrong with the industry back there I haven’t realized it was that bad.

I mean – it’s supposedly almost the same developers, right? Some Java, Objective C, a little JS/Json/GUI/, the concepts are still the same. Oh, was I wrong. When testing some of these applications, and looking at how they are (much easier BTW that with “traditional” software), it almost seems like we are blinded by the fancy little gadget we got sitting on our desk waiting to be tested, and just push out really crappy code with no apparent attention to how it works, how secure it is, or how does it reflect on the security of the rest of the bank/commerce/corporate security.

Forget all the shortcuts that completely bypass any reasonable process and procedure that are implemented through the “regular” (i.e. web, web services, even client-server) interfaces, and the fact that web services are created to support that.

Forget that authentication is almost thrown out the window when you used to have multiple factor authentication on other channels.

Go back to basics. Ummmm, like, SSL? It has been too many times that you see an “application” that is no more than that hybrid thing Apple allowed developers to do – a few HTML pages that get rendered really nicely on an iDevice, some jQuery and CSS tricks, and maybe even bother through churning the end result through PhoneGap to be like the cool kids with the native apps. Problem is – developers go full retard on shiny things like this. The completely forget the fact that the user’s phone is just like a PC, and is going to be connected to so many non-trusted wireless networks that it’s not even funny to think how much data will be exposed through their insecure plaintext calls.

One thing that really helps developers stay in full retard mode is the lack of any security indication on the device that their communications are done completely in the clear. No bright yellow/red/green padlock that indicates an SSL connection, no API checks to verify that some crypto library is in use if any of the “sensitive” (read: contacts, network access, mail, locally saved data, etc…) is accessed by the application. Nothing.

That’s how we got to a point that sensitive data is leisurely sent unencrypted over non-trusted WiFi connections, along with almost everything you can think of from the phone (GPS coordinates, user information, you name it). That’s how we got to a point where useless web services are opened up (again – no requirement for an SSL connection) on financial/corporate/commercial servers to allow logical shortcuts just because the mobile applications needs to be “streamlined”.

We need to put our foot down and say “no more”. We need both the big guys (Apple, Google, Microsoft, RIM) to have a real certification and testing program for their *Stores that actually look at what the application is doing. We need more logic and more process in the way that applications get developed and commissioned. We need developers to get off the “I need to be at the *Store” mentality, and think like they used to in the sense of “we are going to get so pwned if I put this application out like this”. We need product managers and marketing departments to think if they want to be the next Sony™ getting nailed 21 times in a row and still not realizing they are so far behind they need to take everything offline and start getting their stuff together.

We just need to pull our heads out of the sand and smell the napalm. It’s a war out there, and your shiny device doesn’t give a small rodent’s rear-end about your security as long as it looks good.

Rant off, maybe one more post before Vegas. See you all there!

How great perimeter defenses are hurting you

Posted on by
2

I have looked for a good example for a real-world security practice that is misconceived and that also applies to information security. Recently I have had a chance to read an opinion article that talks about physical security measures that are put in to protect small populations (read army bases, gated communities, etc…) and how many of the “traditional” security thinking is actually hurting them.
The example that was cited, talked specifically about building fences around such facilities, and their actual and perceived effect.
The real effect of such a “security” fence is very low. These fences can be easily bypassed with very basic skills and tools.
However, the perceived effect of such fences is incredible. On one hand, the protected population sees that there is a fence that goes around the entire perimeter, and immediately think “cool! we are well protected”. They can SEE the perimeter, and it has an immediate effect on how the area is perceived (especially in gated communities).
On the other hand, a much more worrisome element is how such fences affect the way that the security personnel behave. One would think that security professionals understand that fences are no more than a slight delay for an attacker that looks to break into the protected area. Nevertheless, the article talks about how security personnel are actually putting their guard down when assigned to work in fenced areas. It talks about how the perimeter (again – being highly visible and seemingly intimidating) provides some comfort to the guards, and makes them prone to focus on the gates and openings. Whereas guards that were put in duty to protect non-fenced compounds were much more vigilant in identifying tactical areas that would be used to watch the compound, and to attack it. They have been more active in their movements across the protected area, paying attention not only to the access paths used daily, but to all aspects of the area.

Now think about everything that I have discussed above in information security terms. We have been having firewalls blinding our CIOs, IT personnel and purchasing managers. The ability to market a product that specifically opens access paths into the organization so successfully have actually degraded the security posture of most organizations. Think about it – one of the things that come up very early in a conversation about an organization’s security protections will usually be a firewall.
The more problematic aspect here – much like in the physical fence example, is that firewalls make security personnel put their guards down. They fail to be vigilant in identifying access paths, data patterns, and potential pitfalls in the way that the organization keeps, processes and uses its information.
Don’t get me wrong – I’m not a huge “de-perimeterization” fan, but we do need to take note from this way of thinking about security. Everyone is preaching about “layered security”, but keep putting a lot of focus on the perimeter defenses while leaving the internal layers mostly unprotected.

In summary – when you think about how your organization is protected for security breaches, remember the “fence effect”. Remember how people that live in gated communities have a wrong sense of protection, and how guards stationed at checkpoints and gates are usually focused on the opening rather than the fence around them.

Local PayPal Phishing – and why we need a CERT

Posted on by
6

This just came in the mail: (twice – at two different mailboxes – I must be a high value target for these guys)

A classic phishing email, with the only exception that it seems highly targeted at the Israeli market! (yeah – I know, I sound a little excited, but this is the first one I ever got…). Obviously, I am not the new owner of a BROWN denim jeans (eeewww!), so as I am very interested in who may want my PayPal details, a bit of digging brought this up:

 

  1. The phishing site (the one led to by the obvious “CANCEL TRANSACTION” link) is hosted on al3abnt.com.
  2. al3abnt.com is obviously not related to PayPal, and in a very unusual turn of events it is actually registered to a person, or at least something that may lead closer to a person than most phishing sites (that use whois anonymizing).
  3. The Whois registration (see below) also leads to a website on anasblog.me. This seems a personal blog from a local village called Salfit in Israel (I knew it reminded me of something… been around there a couple of times :-) ).

    4.  

  4. The blog (see screenshot below) seems pretty anti-Israeli (note the “we are with the third intifada” button on the top-left corner) – thus explaining the interest in local Israeli PayPal accounts.

  5. Obviously – there’s no-one to send the notification to… no CERT would handle this, and the police is almost comical in the way they reacted to calls of this nature…

I’m guessing that a CERT would have done the following:

  1. Publish a warning notification on the offending site, and the email template.
  2. Coordinate with ISP the takedown of the offending site and law-enforcement work to apprehend the scammer (A phone number is listed on the whois information – feel free to try it out :-) ).

Be safe out there!

The curious case of Dropbox security

Posted on by
4

The Dropbox logoAfter the disclosure of the host_id authentication issues that plagued the popular Dropbox service last week, a new issue came up with the fact that Dropbox can detect whether the files you are trying to upload to their cloud already exist there, and “save you the bandwidth” of uploading it if they already have a copy in hand.

So – the Dropbox client probably checks for the hash of the file being uploaded against a list of hashes of existing files that are already stored on the cloud. It may also be that the files stored online are encrypted. So… what’s the big deal?

One has to remember that when using a service such as Dropbox (and I’m an avid user myself), you clearly do not have full control over the material you upload, and the online encryption is only a fraction of the protection you may be seeking. There is no key management visible to the user. There is no way that each client you use has its own key, nor they share keys, and if they do, Dropbox is managing your keys. This also gives them the ability to decrypt your data at any given time. Subsequently, it also gives them the ability to provide you with the file of another user if you tried to upload it yourself (hence saving you the bandwidth) – for example, when you may want to access it from a client which does not have the synched copy of your account (or through the web interface). They just decrypt the other user’s file, and serve it back to you. After all – you have the same one back on your home/work/whatever PC (remember that you showed “proof” by providing the hash before).

Which brings us back to reality – what are we really exposed to here in terms of risk?

  1. Dropbox has the ability to access the contents of my files.
  2. If I can come up with a hash of a file that I know someone else has, and that file may be confidential in some way, I can potentially claim to upload the same file, and then download the real one (as I don’t really have the original) from another client or through the web interface.

Clearly, the media attention to point 1 is important – but still not really interesting as people should have had a clue when they send their files to the “cloud”.

However, point 2 makes a more interesting argument… It would be interesting to see when the first “hack” will come along which will start “uploading” files (by hacking the client protocol – hint: start here, here, and here) just based on hashes, and then downloading them as if from another client to see what you get (if they were “cached” already on the Dropbox cloud). Now that would be an interesting little experiment…

Happy hacking!

SCADA, control systems and security – not necessarily enemies

Posted on by
1

Insights from the NISA International SCADA Security Forum conference (NISA stands for National Information Security Authority, which is a division of the Israeli Security Agency).

We all know that SCADA has been considered a security nightmare for a long time. Admittedly, I only have a short experience with such systems and control systems in general (just short of two years), but the topic is fascinating. The main challenges in securing control systems from my point of view is the ability to “connect” with the domain experts and understand the systems and processes properly.
Unfortunately, we, as a security community are far from it (at least based on what I have seen in the past couple of days in the conference). The rush to force traditional IT solutions and ways of thinking onto control systems just do not work. From “learning” firewalls that monitor the industrial control protocols, to systems that are designed to ADD complexity to the threat modeling by layering network and Internet related threats to SIEM mechanisms and add the “scada” data to it. These are all solutions that are Bound to fail as they do not understand the actual needs and operational state of mind of control systems engineering.

If we take a new and unbiased look at what kind of data and processes are involved in such systems, we (as in the security community) would be thrilled to learn that there are a lot of untapped intelligence resources that would substantially help us in building a more appropriate and relevant detection and alerting mechanisms. Trying to force an IT solution on these would be an exercise in fitting a square peg into a round hole, and as exciting as that may be we all know what would be the outcome of it.

To sum things up – just as you would not pretend to know the environment of a financial or a commercial customer when approaching the task of securing it, control systems pose an ever more distinct challenge. Open up, keep the critical thinking and most of all LISTEN. You’ll find out that long before you can start pushing the “cyber” agenda, you have much to work with just with the basic data and processes already at hand, and that there is a lot of value that a security practitioner can bring to such an organization.

P.S. I’m specifically refraining from addressing any product or vendor as I do not think it’s fair to “out” them (however big or small they may be) as these have obviously been rushed to the market in an attempt to get an initial foothold in the industry. Nevertheless, I do encourage such vendors to do some more homework, and work WITH the industry rather than just try to capitalize on their existing expertise in IT and “cyber”.