Flash Exploits – New hakin9 Extra is out now!

 
What is in this issue?

• Exploiting Adobe Flash
• Exploiting Adobe Flash
• Adobe’s Security Policies
• Atola’s Technology Showcase
• User Training and Written Security
• Policies in a World of Social Media & BYOD

Why Apple Doesn’t want Flash on its iOS
by Keith DeBus Ever since the advent of the iPhone in June of 2007, Apple’s decision to forego Adobe’s ubiquitous Flash software has raised eyebrows and more than a few hackles. Then, when Apple introduced the now revolutionary iPad in April of 2010, the controversy escalated to a white hot froth in short order. Apple and its CEO and founder, Steve Jobs, has claimed that Flash was a security vulnerability and threatened the convenience and usability of their mobile devices and therefore would be banned from iOS and their mobile devices. In this article, we will look at the long history of the relationship between Apple and Abobe than culminated in this ban, examine closely the claims and counter claims and then attempt to sort out the validity of Apple’s claims against Adobe and its Flash software.
Exploiting Adobe Flash Player
by Swetha Dabbara
The vulnerability exists in Flash Player versions 11.2.202.233 and earlier for Windows, Macintosh and Linux systems, as well as versions 11.1.115.7 and earlier for Android 4.x and versions 11.1.111.8 and earlier for Android versions 3.x and 2.x. The company said the plan to include a Google Play link for Android users at some point today so that they can get the update for their devices. The patch is of highest urgency as there are attacks in the wild against the vulnerability. “Users that have opted-in to participate in the newly introduced silent update feature (currently only available on Windows), will have the update applied automatically on all browsers present on their system,” he continued. “Users of other operating systems and users that have opted-out of ‘silent update’ need to manually install on all browsers.”
User Training and Written Security Policies More Important Than Ever in a World of Social Media & BYOD
by Ken Krauss
Rather than having a standardized list of allowed applications on employee devices known to company security managers, with BYOD the list of allowed applications on computing devices is often non-standardized. Further complicating the issue, company IT staff might not even know which device(s) employees use, and might not now be allowed to connect remotely to employee devices for patch management, virus scans, and other security concerns. It is also much more likely that the BYOD employee will be sharing their devices with others that are even less skillfully trained on computer security than your employees are, such as their children or other family members.
Hard Disk Diagnostics: Opportunities and Solutions
by Dmitry Postrigan
It is not a secret that every data recovery specialist must perform a full diagnosis of a hard disk drive to find the problem or the disk state in general as the very first step in all data recovery cases. Only accuracy and competent approach can guarantee the extraction the maximum amount of a data to avoid further damage to the hard drive. Have you ever considered what it takes to find the exact state of the customer’s drive? Usually, it is a quite complex task that involves a number of tests, guesses, and risks; and it has been like that for many years. I believe it’s time to offer something better. Atola Insight provides the unique, fully-automated in-depth diagnosis of any PATA or SATA hard drive. Just one click, and in a few minutes, you’ll have the full diagnosis report outlining the exact issue.
Security Teams at Adobe
by Adobe
Adobe has a team in place (the Adobe Secure Software Engineering Team – ASSET), which is dedicated to ensuring our products are designed, engineered and validated using security best practices. Brad Arkin, senior director of security for Adobe’s products and services, leads that team. A second team within ASSET (the Product Security Incident Response Team – PSIRT) is responsible for responding to and communicating about security issues. ASSET and PSIRT (as they exist today) were put in place during the integration of Macromedia and Adobe in late 2005 by combining the corresponding security teams from each company, and these teams continue to evolve to best address the threat landscape facing Adobe’s products. All engineering teams at Adobe work very closely and proactively with the Adobe Secure Software Engineering Team (ASSET) during each phase of the Adobe Secure Product Lifecycle (SPLC). In addition, product teams have dedicated security development and testing groups in place. As a result of changes in the threat landscape, we have about seven times as many engineers dedicated to security today compared to 2009.

Password Cracking – Part 9 – Salts continued…

I promised that once we learned more about password cracking we would come back to salts.
If you remember, I mentioned that one of the ways salts made passwords harder to crack was by making them longer. As you’ve learned, every additional character exponentially increases the amount of possible character combinations. Once the hacker finds out what the salt is, this is no longer the case. The attacker can edit any dictionary or brute force password cracker code to add the salt to the current word before running it through the hash function. The attacker can now run normal password lists and brute force attacks as if the salt wasn’t even there. This can also applied on a larger scale. If the attacker found out that the salt was the user’s username, he could easily automate a password cracker by editing the code to attach the user’s username to the password. So as you can see, it is important to create good salts and store them as securely as possible.
Random Salts vs. Unique Salts
So which is better, having random generated salts, or unique salts like your username or email address?It depends on how you store it. If it is in the same database as your username and password hash, then it doesn’t matter if it’s random or unique, because it’s being stored either way. Once the hacker gets access to the database and dumps the username/password database, to figure out what the salt is, allhe would need to try attaching every stored value (username, email, name, etc..) to a possible password until he cracked the password. He would then know what the salt was for every other user. The attacker could also just choose to try and crack the password hash as is, and if successful he would see the salt and password in plaintext. The attacker would then compare the plaintext with the database values under that user and see where it matches up, finding the salt. This would probably take much longer or wouldn’t work depending on how long the salt and password combination is.
This would be a different situation if the salt was stored in a different server because if the attacker had access to one database, he might not have access to the other. In this case, using a random salt would make sense because the attacker would still be able to guess a unique salt like a username, but not a random hash stored elsewhere.
For even greater security, in addition to using a salt that is stored in the database, you could add to it in the actual source code of the register/login script. This way, the attacker would need to have access to both the database and the source code to be able to get the salt.

Password Cracking – Part 8 – Rainbow Tables

What are Rainbow Tables?
Rainbow tables are lookup tables that contain almost every possible combination of passwords in a given character set. It is simply a completed brute force attack that you can reuse as many times as you wish without having to regenerate all those possible password combinations. This can reduce password cracking time by up to 99%! Of course, to generate a rainbow table it can take longer that it would take to crack one password, but afterwards you will be able to crack others in a few minutes compared to hours. Now that you have a basic idea of what rainbow tables are, let’s look at exactly how they work.
If you recall, I said that rainbow tables store most of the possible hashes in a given character set. This is true, but not in the way you might think. Depending on the character set and length of the password, a rainbow table can get extremely large. Below is an example of tables from the RainbowCrack Project:











If the rainbow stored every hash for every plaintext word in a given character set, it would use more memory then you have or can imagine. Instead, rainbow tables use a time-memory trade off technique, known as chains.
To understand these chains, you must first understand the “reduction function”. As you’ve learned, hash functions map plaintext words to hashes, well, the reduction function maps hashes to plaintexts. You might be thinking, didn’t you say that you couldn’t reverse a hash function and get the plaintext from it? True, the reduction function doesn’t inverse the hash function acquiring the original text. No, instead it gets another plaintext from the hash. For example, if we have a set of plaintexts that are made up of 7 numbers [0-9], using the md5() function a possible hash could be MD5(1234567) -> fcea920f7412b5da7be0cf42b8c93759. In this case the reduction function could be as simple as taking the first seven numbers from the hash to generate a new plaintext. So once the reduction function was applied to the hash, it would result in the new plaintext, “9274125”. And that’s what the reduction function does, generates a new plaintext from a given hash.
These chains that make up rainbow tables are made up many combinations of the one way hash function combined with the reduction function, making a chain. For example, if we were to continue the chain from the first example, it would look like this:
Md5(1234567) -> fcea920f7412b5da7be0cf42b8c93759 ->
Reduction(fcea920f7412b5da7be0cf42b8c93759) -> 9274124 ->
—————————————————————————————–
Md5(9274124) -> ed7db1cf7fc4fbd0169f00c37a0165ab ->
Reduction(ed7db1cf7fc4fbd0169f00c37a0165ab) -> 7174016 ->
—————————————————————————————–
The above chain would keep repeating until you or the rainbow table maker decides to stop it, usually after millions of hashes are created. Now here’s how rainbow tables save memory. Instead of storing every one of these hashes, the rainbow table only stores the first plaintext and the last hash in that chain. Then millions of more chains are created, each representing millions of password hashes. If a table was made up of the above chain, then it would be made up of its first plain and final hash looking something like this: 1234567 -> ed7db1cf7fc4fbd0169f00c37a0165ab.
Once enough tables have been generated (millions), you will want to actually use the final rainbow table to crack a password hash by checking to see if it is inside any of the generated chains. Here is the algorithm:

• Check to see if the hash matches any of the final hashes. If so, break out of the loop
  because you have found the chain that contains its plaintext.
• If the hash doesn’t match any of the final hashes in the tables, use the reduction function on
  it to reduce it into another plaintext, and then hash the new plaintext.
• Go back to step 1.

Now that you know which chain contains the plaintext, you can start with the original plaintext of that chain and start hashing and reducing it until you come to the password hash you are trying to crack and its secret plain text. There you have it! The quickest and simplest explanation of rainbow tables that you will ever find!
When should I use a rainbow table?
If there are rainbow tables available for the type of password hash(es) you have, then use it! Chances are it’ll work. If you have to download the tables, then while that’s going on, trying a dictionary attack won’t hurt.
If the passwords are salted, then you probably will not want to use rainbow tables because you will need to create a new rainbow table for every password. Why? Well, if you recall, when you salt a password, you add a random or unique string to it and then run it through the hashing function. So if the password was “password” and the script attached the user’s username to it, the final password would be MD5(“username”+”password”). Since everyone has a different username, the word “password” will never look the same once hashed.

Password Cracking – Part 7 – Hybrid

What is a hybrid attack?
A hybrid attack is a mixture of both a dictionary and brute force attack. That means that like a dictionary attack, you would provide a wordlist of passwords and a brute-force attack would be applied to each possible password in that list.
A hybrid attack is like the beginning of an MMORPG where you choose your character design. Your figure stays the same but you have the choice to change your clothes, hair and color until you have the look you want, a badass Schwarzeneggar or a medieval hooker.
On my first day as a freshman in high school, I was given a username and password for the school’s computer network. Everyone’s password was set to the first initial of their first name, their last name and birth date. So if my name was Bob Sagat and I was born on May 22, 2010, my password would be “bsagat052210”. This wasn’t a great way to distribute passwords, but we did have to change it after we first logged in. Can you see why a hybrid would be an effective attack in this case? What I could have easily down was get a list of every freshman student in the school and apply a brute force attack to the end of each name. The rule would look something like this:
(first initial of first name)(last name)([0-9] [0-9] [0-9] [0-9] [0-9] [0-9]) In this case, a hybrid attack would have enabled me to crack every single student’s password within a few minutes.
When should I use a hybrid attack?
Use a hybrid attack whenever you have an idea of how a password is formatted. For example, if you dump a database of password hashes from a website, and after trying a dictionary attack against it you are left with many uncracked passwords, then take a look at the password requirements for that website. Many websites require a password to be made a certain way. For example it may require a password to have at least two numbers and a special character. Knowing how people like to make things as easy as possible for themselves, you can safely guess that many people used exactly two numbers and one special character. Armed with this knowledge you can go back to your dictionary file and apply a brute force attack to it (making it a hybrid attack), trying the following combinations:
([0-9] | SC) ([0-9] | SC) ([0-9] | SC) (password) or
(password) ([0-9] | SC) ([0-9] | SC) ([0-9] | SC) Where SC = Special Character (ex. !,@,#,$) and (| = or).

Password Cracking – Part 6 – Brute Force

What is a brute force attack?
A brute force attack is a password attack where every possible combination in a range of characters is generated and used against the password hash.
For those visual learners, a brute force attack is presented pretty well with a Rubik’s Cube. The brute force attack would be the act of your hand turning the cubes in every possible direction to create different combinations until finally the Rubik’s Cube is solved and you have matching colors, the password.
When selecting a range of characters to use for a brute force attack, you have a few options. Below are the ones available in the popular cracking program, Brutus.

• Numerical – Use any numbers from 0-9
• Lowercase Alpha – The lowercase alphabet
• Uppercase Alpha – The uppercase alphabet
• Mixed Alpha – Both lowercase and uppercase
• Alphanumeric – The lowercase and uppercase alphabet plus digits 0-9
• Full Keyspace – Everything above including all the special characters on your keyboard.
• Custom Range – If you have an idea of the characters included in the password(s) you can create
  a custom list of characters to use.

Each range option yields a different amount of possible password combinations. Let’s look at how many combinations there are for a password of 0-6 characters in length.

• Numerical – 1,111,110 Passwords
• Lowercase Alpha – 321,272,406 Passwords
• Uppercase Alpha – 321,272,406 Passwords (obviously the same because it’s the same amount of
  characters)
• Mixed Alpha – 20,158,268,676 Passwords
• Alphanumeric – 57,731,386,986 Passwords
• Full Keyspace – 697,287,735,690 Passwords

For a six character password, we are hitting over 697 Billion combinations for the full keyspace! And by just adding one more character to the password making it 0-7, the number of combinations jumps to 65,545,047,154,955, that’s over 65 Trillion! As you can see, it makes a big difference having an idea of what types of characters are being used in the password(s) and how long it is.
Calculating Number of Combinations
You now have an idea of how the number of combinations can grow with the addition of a new character or an extra character in the password, but how are these numbers calculated? Simple.
If you are doing a Numerical attack on a 6 character long password, that means there are 10 possible different characters (0-9) that you can use. So the equation to calculate the number of different combinations is:

# of different possible characters^{password length} So the expression for our example would be:

10⁶ Which, once calculated, comes out to 1,000,000 combinations?
Wait! Didn’t I state that there are 1,111,110 possible combinations for the same character set before? Yes, but it was for passwords that consisted of 0 to 6 characters long, not just 6. If you don’t get what I mean, look at it this way. When I’m looking for all the possible combinations of a password that is of length 0 to 6, I need to account for the combinations of all the 6 character length combinations, 5 character combinations, 4 character combinations and so on. If you were doing it out, this is what it would look like:

10⁶ + 10⁵ + 10⁴ + 10³ + 10² + 10¹ = 1111110 This would get pretty tedious if you had to do it manually for long numbers, so here’s a simple C script I put together that does it out for you:
#include
#include main(){
int n = 10; // number of possible characters
int a = 6; // length of the password
unsigned long long int x = 0; // this will hold the answer, its set to unsigned long long int so that the variable x can
// hold the largest possible number
while (a >= 1){ // keep going until a is 1
x+= pow(n,a); //take n to the power of a and add it to x
a--; //subtract 1 from a
} //do it again until a is lower than 1
printf("The number of possible combinations is %lld.\n",x); //finally print the answer
}
Backwards Brute Force Attack
A backwards Brute Force attack is a brute force attack against usernames. So instead of using the brute force attack to create and try a bunch of password combinations, you will be most likely be using one password and using the brute force attack to generate all possible usernames in a range of characters, trying that password(s) against it.
When should you use a Brute Force attack?
Only use a brute force attack when a Dictionary and all other options fail. A brute force attack takes a lot of resources and a lot of time to perform. Depending on how big the password is, the range of characters being used and the resources available, a brute force attack can take years to fully complete as you’ll see later on.

Access Your Facebook Account with 3 Passwords

Did you know that you can login to your Facebook account using 3 different passwords? Seems interesting isn’t it? Yep! Unlike any other online account which has only one password to access, Facebook lets you log in using 3 different variants of your password.

Only a few Facebook users are aware of this fact but, for many others this might seem a bit surprising. Facebook accepts the following forms of your password:

 

1. Your Original Password

Let me explain this to you with the following example. Assume that your default Facebook password that you created during the sign-up process is:

2. Password with the Case Toggled

In the above password the letters ‘F’ and ‘P’ are in uppercase and the remaining are in the lowercase. If you TOGGLE the case where all the UPPERCASE characters are converted into the lowercase and vice versa, your default password “myFacebookPass” would become:

Now if you log in using the above toggled password, your Facebook will accept it and welcomes you! This is the first variation of your default password which is accepted by Facebook.

 

3. Password with the First Letter Capitalized

If the first character of your password is in the lowercase, you may just change that first letter to UPPERCASE and Facebook will again accept it and let you in. As in case of the above example where your default password is “myFacebookPass”, if you just change the first letter to UPPERCASE your password would be “MyFacebookPass” and this should work fine as well:

Please note that this option will work for Mobile users only!

 

Why 3 Passwords?

Now, you all know that Facebook can be accessed using 3 different passwords. But you may be curious to know the actual reason behind it.

Well, this is definitely not because Facebook has a bug or a serious vulnerability. In fact this is just an option provided by Facebook itself to make the sign-in process easier for the users. Here’s how:

The most common reason for the authentic logins to be rejected is when the CAPS LOCK is ON. This is where the first variation comes in handy. That means, when the CAPS LOCK is ON the case gets reversed (toggled) for your password but Facebook will accept this as well.

In case of mobile, users it is a common for the first letter of the password to get capitalized which often leads to the login failure. So, in order to tackle this issue, Facebook will also accept the password where only the first letter is capitalized.

Thus if the CAPS LOCK is accidentally enabled, the toggled password feature would still let you log in to your account!