Infosec'10 metadata (I)

Wops! A long time without writing here... A lot of work and not too much time to write. But I'm going to try to fix it shortly!

Two weeks ago was the Infosec event at London. Our company had a very nice stand and I spent a good time Wednesday talking with some people about what we do and, more specifically, what I do as application tester at Pentura. But I can not stop thinking about security in any moment...

Others companies in the event were giving some CDs with documentation and programs. As I know that sometimes people don't take care about what they copy into the CDs when they make the copies so I took some of them to analyze :) They had been burning in my backpack for two weeks!! But today, when I inserted the first one, it makes my day.

The CD is from (ISC)2 and they call it Green disc. They have a lot of docs I'll analyze some point this week but I discovered something very funny. They are using WS_FTP. How I know it? They left the WS_FTP.LOG files in some of the folders. Take a look:

This file contains the local path of the file (you can get the user name), the remote path of the upload (you get the path) and the IP of the remote server (need I say more?) You can found a lot of WS_FTP.LOG files at Google or, if you got the CD from the (ISC)2, have a quick look to these files ;)

Cheers!!

P.D. Maybe is not a (ISC)2 IP but still funny (and not very secure...), isn't it? :)

Mixed content in different browsers

In security, one of the most old and famous attacks is Man In The Middle attack. With this technique we can read all the packets the user is sending to a server and analyse it. The solution? Use a secure layer to encrypt all the traffic.

This, for web sites, require that the user browser use the HTTPS protocol. This relay in the authenticity of the server certificate and the trust relation between the browser and the certificate authority. It can be broken, but is not the point of this post, maybe for other one :)

If a website mix secure (HTTPS) and insecure (HTTP) content in the same page an attacker sniffing the net will be able to see, for example, our session cookie in clear text. This is a big risk if the attacker has control over the web content we are browsing (using a stored XSS attack) and insert some insecure reference on it to catch our cookie session.

The way the browsers controls this is different in each one, but always insecure. The last version of Internet Explorer can be configured to check if we are loading insecure resources and block them. The result is that we don't see the insecure images if we decide to block. But it's really blocking the resources or only hiding them?

I create a secure web page which load different (mixed) content. Using Wireshark to look the request my browser is doing I can determine that IE8 is currently making the request and, if the user decide to "block" it, only hide it.

 

This can make the user think he is safe when the request (and his cookie sessions) has been sended in clear text.

The other browser I tested is Firefox. When Firefox detect mixed content it load it and show an alert to the user to warn him about it. This is the same insecure process that Internet Explorer, but in this case the webpage is render normally so the user doesn't have the false security feeling when the images are blocked by IE.

I, a huge fan of Firefox and the possibility to expand it using addons, have created a Greasemonkey script to try to prevent this insecure behaviour of Firefox. It's called Mixed Content Protection and can be installed from the userscripts community web page. It requires Greasemonkey to work.

The script is very simple. It works only when we are accessing to HTTPS web pages and search for all the insecure references* in the HTML source code. It executes before the page loads, so it can change "on-the-fly" all these insecure references for the secure ones. If the secure object is not accessible it will not be loaded using a insecure protocol.

Currently it search for:

• All src attributes: img, iframe, object, script, etc.
• The href attribute of link tags for css files
• The insecure value in the param tag to the movie resource.

I think with these references it will cover mostly of the cases but, if you know any other resource can be loaded insecurely, please, feel free to comment me. Also it can fail in some cases, if you detect any issue please let me know :)

* Currently the script only works for the body tag elements, so any insecure reference in the header of the file will be load. It also doesn't work with resources loaded from Javascript or CSS files.

Thanks to Chema Alonso for draw my attention[Spanish blog, sorry] to this web browsers issue.

Will you tell your enemies where you are?

In the current society where everyone has a 3G mobile, a Facebook account, twitter username and more, sometimes we forgot about our privacy.

These days is becoming very popular the Foursquare web site. It's a very simple social game where you can tell your friends where you are. This is a nice way to meet new sites and catch your friends whatever they are. Foursquare also offers badges for different actions to incentive people to use their application. It also send tweets using our Twitter account telling our friends where are we if we configure it. It's funny!

But this can be a very high risk for our privacy. If our twitter account is public anyone can know at any time where we are. This principle is the one behind the Please Rob Me web page. They use a simple search on Twitter, 4sq -@foursquare, which returns all the automatic generate tweets from the Foursquare web site. These tweets are send when we check-in in a place. People telling everyone where they are? Scary... But wait! It's another web page that offers the same service. It is Gowalla and, again, we can know where is the people who is using this web site: gowal.la -@Gowalla

Right now it is more funny than dangerous but the important point behind this web page is that in the actual society the people give away their privacy. Some years ago (not too much, only 2 or 3...) our personal data was the most important thing for ourselves but nowadays we don't really care about it. We publicity everywhere where we are, what are we doing and, sometimes, pictures or videos.

Our recommendation is to keep your data the more private the applications allow you and try to think twice before posting any data (text, image or video) at Internet. Once posted sometimes is difficult to delete it...

Oh, by the way... I have a public twitter account! You can follow me at @p_laguna for all my security related tweets.