But let’s not limit our focus to the InfoSec guys. Life coaches (whatever they are) are abusing the subject with exaggerated comparisons and vague slogans. And the business people, oh, believe me, these are the most creative. Telling you how big of a war is out there and how to deal with it like a boss. I kind of secretly desire for a cooking show to refer to The Art of War and debate how to diminish cucumbers’ morale before chopping and throwing them into the salad. All for a better taste of course, because, you know, cucumbers are the enemies.

I don’t find it particularly amusing to be the one breaking the spell but somebody has to do it.

So, The Art of War is a military treaty from 2500 years ago. One other important aspect you have to consider is that the writing and translation process was complicated to say the least. The origins of the text and author are known only to a certain degree of confidence and the writing went through several translation and reinterpretation cycles. It does outline some generic principles which can be applied in various aspects of life, especially if one has the tendency to generalize. Otherwise it talks about:

• Using gongs, drums, banners and flags to raise morale (funny enough, some InfoSec companies take this ad-literam)
• Analyzing weather and terrain conditions. Showing your troops that you packed enough food for the winter. If your rival’s forces are crossing a body of water, don’t meet them in the middle, where you’ll both be bogged down. Instead, wait until half of them have landed and attack while the entire army is divided.
• How spies must be liberally rewarded and their work highly appreciated.

Again, if one is prone to the confirmation bias and willing to look for far-fetched parallels, he can identify in the above 3 bullets awareness, reconnaissance and intelligence.

For this kind of people I’m willing to make a few recommendations of good readings:

• Little Red Ridding Hood outlining the necessity for risk analysis. Red should of known better when walking the woods alone.
• Snow White, which teaches us the need for security assessments. Our heroine could have used one of the dwarfs for QA testing the apple.
• And finally, my favorite, The Three Little Pigs from which we can learn about the security in depth principle and the need for security architecture.

Next time you go into a meeting and talk about the importance of Information Security, use The Three Little Pigs as your support material (on your own risk).

The Art of War is a good book if read properly and understood in the context in which it was written. China, 2500 years ago. And it’s not the only strategy manual from that region and period, another good read is The Seven Military Classics of Ancient China. The only universal principle coming out of these texts is that you must know yourself, your opponents and the context, and adapt your strategies accordingly.

But my question was always: why 10? Why not 11? Or 9. Or whatever else? I guess 10 sounds more important than 11 or 9. It’s the decimal system, 10 fingers, easy to visualize. What would you trust more, a Top 11 or a Top 10? Then the pressure is on the top creator to add, eliminate or combine elements to end up with 10 for a credible list.

Let’s get back to our InfoSec sheep. I prefer simplification and that’s why I started a quest to see if I can end up with a shorter version of the OWASP Top 10.

"The OWASP Top Ten is a powerful awareness document for web application security [...] represents a broad consensus about what the most critical web application security flaws are. [...] Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code." [link]

The OWASP Top 10 is a versatile project and can be used in multiple ways. But as you work with it, you realize that it is a little bit bloated.

Let’s start with A1-Injection: "Injection flaws occur when an application sends untrusted data [...]" This to me sounds very similar to the definition of A3-Cross-Site Scripting (XSS): "XSS flaws occur whenever an application takes untrusted data and sends it [...]". But enough with definitions, rationalizing XSS is JavaScript injection. In my opinion, A1 and A3 are separated by the location of the untrusted data parser, server vs client side. But in terms of mitigation, they’re both addressed on the server side (if you’re security conscious), so why keep them separate, A1 + A3 =  NEW1.

And while we’re at it, isn’t CSRF another form of injection? The attacker injects a command to be executed by the victim in a valid session.

OK, one more and I promise we’ll move on. Otherwise we might end up with Top 1 security vulnerabilities. A10-Unvalidated Redirects and Forwards. The attack mechanism is similar to XSS and CSRF, tricking the victim through phishing. What’s the injection here? Malicious URLs.

So…

A1 + A3 + A8 + A10 = NEW1 – Injections of all kinds

Moving on to other categories. Now, talking about A2-Broken Authentication and Session Management, isn’t authentication part of the bigger concept, authentication and authorization? If so, A4-Insecure Direct Object References deals with flawed authorization and would fall under the same umbrella.

But wait a minute, isn’t A7-Missing Function Level Access Control dealing with access control aka authorization? The definition says:

Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget.

Let’s leave the part that is managed via configuration out of the question for a second (it will be incorporated in the next category). The rest of the problem is at the code level generated by the developer who doesn’t introduce proper checks and thus allows a malicious user to execute functions without authorization.

We have our second category:

A2 + A4 + A7 = NEW2 – Flawed authentication and authorization

What’s left? Ah, yes, the all mighty configuration issues. Let’s start with A5-Security Misconfiguration. If I had a penny for each vulnerability I’ve seen which was classified as A5, I wouldn’t probably write this article. What I’ve noticed is the tendency that most pentesters have to drop vulnerabilities that they think can’t be classified otherwise in this category. Sometimes it’s because issues are complex and there’s no other category for them, other times it’s just easy to drop them somewhere and forget about it, even though the vulnerabilities can easily fit in one of the other 9.

About A6-Sensitive Data Exposure, this is mainly related to infrastructure configuration. The main point here is related to the protection of data in transit and at rest. While developers can introduce vulnerabilities by using weak (if at all) cryptographic functions, this can be enforced by other security controls and with proper management of the development life-cycle. The focus has been lately on using old or poorly configured SSL versions and not encrypting data at rest. To me, A6 is just a different set of configuration issues.

Last but not least, A9-Using Components with Known Vulnerabilities. This is a no brainer, if you configure your systems properly and have a good change management process, you would you introduce or continue using old components, right? Depending on weather this is an infrastructure problem or using old vulnerable libraries in the code, the responsibility can be shared between SecOps and DevOps.

Thus we have our bronze medalist:

A5 + A6 + A9 = NEW3 – Configuration Vulnerabilities

Without further ado, I give you my heavily revised and compressed OWASP Top 3 Web Application Vulnerabilities

• NEW1 – Injections of all kinds
• NEW2 – Flawed authentication and authorization
• NEW3 – Configuration Vulnerabilities

Is it usable? It depends. On a higher and less technical level it makes things easier to explain. It might be useful to map the identified vulnerabilities on this top in order to identify the developers security training needs.

If you managed to read this far, you should know that I use the OWASP Top 10 on a daily basis in more than one way, I find it very practical and I prefer it over other web vulnerability classifications like CWE/SANS Top 25 due to its simplicity. There are certain cases where others are better, it all depends on how you plan to use them and the maturity of the organization where you try to implement.

It looks something like this:

https://{cloud_storage_provider}/?secret_token={some_unique_token}

All the security of this model relies in the randomness and length of the secret token. But essentially the data is exposed to everyone. Google (Drive) is doing it, Microsoft (OneDrive) is doing it.

Now the really silly part comes in. Because the URL is quite lengthy, a decision was made to use URL shorteners (goo.gl, bit.ly, etc.) to distribute the above mentioned links. Which essentially means that the entropy of secret link is now reduced to just a few characters (around 6 usually).

Martin Georgiev and Vitaly Shmatikov from Cornell Tech did an interesting research on these shortener services to see how much data they can gather, the results were impressive/scary. They were able to trace back Google Maps searches back to individuals and get access to confidential data.

In order to install the tools that are making Kali what it is, I had to install the metapackages. For me, the easiest option was to install all of them (kali-linux-all).

It sounds simple:

# apt-get install kali-linux-all

but it was failing constantly

Failed to fetch http://http.kali.org/kali/pool/main/##whatever_package## Size mismatch

A little bit of research and trying to download the actual package from the host machine made me realize that the proxy was blocking access to the packages.

I decided to check if Tor traffic is allowed. Luckily it was. So I installed it

# apt-get install tor

started it

# tor &

and used torify to pass all the traffic through Tor

# torify apt-get install kali-linux-all

A few more minutes (6+ GB) and I had my fully featured Kali installation.

Their approach was to use https just for the login sequence and plain text communication for everything else. And it was not like they didn’t understand the underplaying problem of sending session cookies over an unencrypted channel, it was just that they thought https is too much for the servers to deal with.

Doing some research back then, I found a paper from the 90s stating that the performance impact was between 10 and 20%. And that only because of the hardware (mainly) CPU available at that time. With the advancement in computational power that should have decreased over time.

And indeed, as of 2010, Gmail switched to using HTTPS for everything by default. Their calculation shows that SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Of course there were some tweaks, but no rocket science involved.

1%, 2%, 10KB. Nothing. I remember somebody saying that 640KB ought to be enough for anyone Maybe he knew something. As you can see in the link, Bill Gates didn’t actually say that.

5 more years have passed since then, hardware is more capable, cheaper, so there’s no excuse not to use https.

I’ve seen poor implementations where all http traffic was passed over a secure channel, but not the .js files. Needless to say, a MitM attack can easily modify the .js on the fly and run code in the victim’s browser.

As a closing note, use https for everything, don’t invoke the performance issues, there’s no reason in the current era not to do so.

A form of identity theft in which a malicious attacker impersonates a legitimate user. This is done by creating a copy of the original account.

An attacker would most likely:

• create an account under the same name as the victim using a public email address (Gmail, Yahoo, etc.)
• copy all the pictures from the victim’s account and add them under the cloned one
• duplicate posts from the victim’s accounts
• get the list of favorite artists, songs, movies and replicate them under the cloned accounts
• get a list of all the friends

To make things easier, there are scripts available to do this with just a few clicks. One of them is FBPwn. It was written as a social engineering tool but we can safely assume that a sophisticated attacker will have better scripts and is probably able to duplicate posts in almost real time from the victim’s account.

The next step is to start adding as friends all the friends of the victim. In addition, the attacker may choose to block the victim and close relatives from viewing the cloned account and avoid detection.

What are the motives behind this?

To find the real motivation we need to differentiate between a private and a business person (which is a private person outside working hours but the attacker is mainly interested in the information that is related to his work).

For a private person, the main reasons behind account cloning are:

• Profit – ask favors, money or other stuff from the victim’s friends
• Revenge – which is another form of profit; the attacker will post on behalf of the victim compromising information or disclose (distorted) confidential information or extract information based on the trust relationship that he now has with the victim’s friends
• Fun – trolling is almost a sport and some people find the energy and resources to make fun of others

For a business person, the attacker’s reasons are more or less the same, but the stake is much higher:

• Profit – impersonating a legitimate user, the attacker can get access to confidential information from co-workers and spread distorted information for confusion; he can also try to social engineer his way to internal systems and credentials
• Revenge – a disgruntled employee can perform this sort of attack as a payback
• Discredit – a company may hire attackers to discredit their competition

This type of cloning can easily be extended over any social media platform like Twitter, LinkedIn, etc.

A motivated attacker will always find a way to duplicate in a credible manner a social media account given enough resources.

So, what can we do to prevent this?

Well, on one side, there is nothing preventing other people creating cloned accounts. However there are some preventive measures that one can take to limit the impact of a cloned account.

• Don’t accept people you don’t know as friends (you wouldn’t do that in the real life, so why do it in the virtual world?)
• Periodically review your friends list and delete the persons that don’t have a valid reason to be there
• Ask your friends not to accept a separate invitation to connect from you (the possible cloned account) without getting in contact with you offline
• To help your friends, announce them when you receive invitations from cloned accounts
• Divide your friends in interest groups (family, close friends, co-workers, etc.) and post information to the relevant groups
• Block cloned accounts by the email address used to register: https://www.facebook.com/help/115913751826993/
• Report cloned accounts: https://www.facebook.com/help/207209825981040/
• Limit the access to your data only to your friends (I’ll have a separate post to discuss the security settings of Facebook)

Until I’ve seen this guy and his awesome presentation.

You feel like taking the tools and start practicing on your front door after seeing this. Or on your neighbors door, depending on your preferences and where you want to spend the night. You have to admit that Mr. Towne has a special gift and is a true showman.

Nevertheless, this is a perfect example of what hacking was originally supposed to mean, understanding (and exploiting) what happens inside a black box from a technical perspective. And even though it’s not related to InfoSec, it’s the perfect example for to describe hacking to non-technical people.

Doing some more research about Schuyler Towne, I found out that he initiated a Kickstarter project to create custom lockpicks designed by a competitive lockpicker to bring “Open Locksport” to market. Awesome.

The only problem is that he failed to deliver the tools, and according to Wikipedia It was later revealed that Towne had been using the Kickstarter funds for his own purposes. These expenditures have included things such as travel and living expenses, car insurance and repairs, computer hardware and other undisclosed expenses. Towne also used the funds to take his family on a holiday and purchase a TV. A number of supporters have subsequently taken over the Kickstarter projects with initial picks out for delivery. However, as of 2014, the majority of orders have still not been filled.

Isn’t that funny? He’s now paying back from his salary and speaking fees. He looks like the kind of lunatic you wouldn’t land your money to but nevertheless a very funny and awesome lunatic.

# ifconfig en0 ether xx:xx:xx:xx:xx:xx

For iOS versions >5 you have to resort to nvram:

# nvram wifiaddr=xx:xx:xx:xx:xx:xx

and then reboot the device.

Prerequisite: jailbroken device, terminal access (local or SSH) and sudo.

Go to Account Policies, then click on Password Policy.

The options, explained:

• History – how many passwords will Windows store (you won’t be able to reuse these passwords)
• Complexity requirements – if enabled, the Windows complexity requirement states that passwords should be at least 6 characters long, must not contain the username, have at least 3 different character types ([a-z][A-Z][0-9][special characters])
• Minimum length – this overrides the previous length setting
• Store passwords using reversible encryption – self explanatory; note that if the key used for encryption is lost, the password can be retreived
• Maximum age – how long (in days) until the user is forced to change the password
• Minimum age – very interesting option! If left to 0 you can change the password as many times as you like in one day. The problem is in conjunction with History. If, for example, History is set to 5, a user can change 6 passwords in one day and reuse the original password.

More information on: http://windows.microsoft.com/en-au/windows-vista/change-password-policy-settings

###

OWASP (The Open Web Application Security Project) are acum deschisa o organizatie locala si in Romania. Suntem in cautare de noi membri cu care sa alcatuim o echipa puternica de oameni implicati in securitate informatica. Scopul nostru principal este sa formam o comunitate locala in care sa putem gasi si oferi suport pentru proiectele fiecaruia si sa putem invata si progresa in acest domeniu in care activam sau pentru care avem o pasiune speciala.

Ce este OWASP: O comunitate globala care aduce vizibilitate si conduce evolutia catre siguranta si securitatea softwareului.

Ce isi propune organizatia in Romania:

– sa initieze intalniri periodice intre membri

– sa aduca la intalnirile periodice oameni implicati in OWASP la nivel global

– sa contribuie la proiectele OWASP

– sa propuna si sa dezvolte proiecte proprii in cadrul OWASP

– sa organizeze o conferinta de securitate in Romania

Activitatea OWASP nu este una comerciala sau profit. Mediul de afaceri este insa binevenit si incurajat sa sustina proiectele OWASP.

Cum poti deveni un membru activ al acestei comunitati? Intra pe pagina OWASP Romania, acceseaza grupul nostru de pe LinkedIn, aboneaza-te la lista de mail si intra in contact cu ceilalti membri.