Security talk at Reading Geek Night - FlasHack

Hi! Lovely summer, isnt it? :) I'm enjoying carrying out a lot of testing, researching and also a bit of developing.

But I always try to make time for sharing knowledge! I think sharing is the best part of the hacking community (and the Internet), people writing articles, blog posts and also twitts sharing their experience of computer security. And I love doing it when I can, especially as I know the people listening are passionate about the subject.

This is the reason I'm going to speak again at Reading Geek Night next week. I'll be doing a talk about how to decompile, modify, analyze and abuse Flash applications.

If you are interested in finding out how you can have some fun with Flash files and you can excuse my English and bad jokes, you are more than welcome to join me at another Reading Geek Night!

See you :)

XCampo

I'm very pleased to present you with a (more or less) usable version of XCampo!

What is XCampo? I decided to write this when I was coming back from the RootedCon conference in Madrid and it is intended to help me (and anyone who wants to use it) to generate better screenshots and demos for the report generation (and presentation) process.

Sometimes, when people generate security reports and they want to represent the risk of a XSS vulnerability they insert a simple script that shows an alert box with the name of the website or with text. This illustrates the possibility to execute anything we want and security people understand this....but do non technical people?

Using this PHP code you will get a nice page with some options to generate dynamically different payloads to your demos:

• Fake login: Generates a fake login form page to force the user to insert his login details.
• hax0r defacement: Try to generate an over-everything black layer with a text and an audio file.
• Form redirection: Redirect any form in the website to a specified URL.
• Password manager: Try to steal the login details stored in the browser when accessing to a specified webpage
• Cookie stealing: Perform a cookie steal sending the details to the URL we want.

As you can see this provides a good range of options to generate more "dangerous" demos in the presentation of the results.

Security challenges for the summer

Hello! The summer is here and the holidays are near!

Planning something to do? Too much free time as you don't have to do any exams in September? Looking for something to learn? Me too! :)

Each summer I plan something to learn, something to investigate... basically something to help me enjoy my free time! This summer I'm going to focus on:

• Firefox addons development (Check this Hackbar Google Code website)
• HTML5

I'll also try to keep my mind fit by playing online challenges games. If you want to practice and learn about security you can check the following websites:

• The Bright Shadows
• Try2Hack
• Hack This Site

Enjoy and keep out of direct sunlight ;)

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? :)

Pentura is Delicious!!!

Well... maybe I did the easy joke, but I couldn't resists!!!

I had never use any kind of bookmarks, even local ones. I try to remember the links or at least the keywords of the article or post to be able to localize it later using Bing or Google. But today I change something in my life... well, at least in my working life :P I'm starting to use bookmarks!

I added a small box in the right of the blog showing the RSS of the new delicious account I created for Pentura to store all these links about security I consider interesting around the web. Some of them will be in Spanish (I'm sorry...) but you can easily translate them using online translators :)

I also added my personal twitter account, where you can follow my public timeline with funny security jokes, thoughts about how stupid can be sometimes the bugs I found and maybe personal stuff between friends around the world. Again I'll try to keep it in English, but sometimes replies goes in Spanish.

Bye!

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.

Hello World!

Hello, my name is Pedro Laguna and I'm security consultant at Pentura Ltd. I'm going to write the first post in this new blog about our security consultancy work in Pentura. This is going to be a place to write down all these small tricks that we use to break the security in some scenarios, post about our tools and scripts or a place to contribute with a better understood about all the security terms.

The most common way to start a blog (more specifically a computer related blog) is posting a "Hello World" post. This is some kind of joke about the first program that anyone learn to do in any coding language. You can check a list with more than 200 examples of Hello World programs in the Wikibooks page.

In our case, as we are a security-related blog, we have to do it in a security way. More specific using Javascript to generate an alert to show the message "Hello World!".

Click here to generate "Hello World!" the alert

Now is time for a bit of technical explanation... If someone can insert Javascript in our pages like we already do, is a vulnerability because he or she can get our cookie session, per example. So, is blogspot in risk? No, and we are going to explain why.

For access to the cookie information using Javascript we need to call to the document.cookie object. This object only has privileges to access to the current domain cookies (it's a browser security measure). Blogger platform only stores cookies in the blogger.com domain and we can only access to blogspot.com domain cookies. You can check it clicking in the following link:

Click here to show blogspot.com cookies

As you can see no session cookie was showed, so... we are safe!!! But only for now, cookie sessions, XSS vulnerabilities and all these web security stuff has a lot to explain and we will be showing you here :)