The good people at Applidium decided to do a little reseach about Siri, the voice recognition technology behind Apple’s new iPhone 4S. Using tcpdump, they discovered that the technology is sending requests over to an apple server located here, at http://126.96.36.199.
They had a desire to look more into the protocol, so they make their own certificate and added it to their iPhone 4GS. Once that was done, they were seeing every time the iPhone sent a request, the request was being sent to their server and not the official iPhone server. From the information displayed in cleartext, they were able to view the protocol, and all fields associated with it.
So what was learned by this? Apple is very thorough with their technologies. The iPhone sends your voice directly to the server for interpretation, and then the voice commands are sent back to the phone, along with a confidence score for every transcribed word. I can’t even speculate the value of this, but I’m sure there is some reason.
For the full article, and to download their tools for making your very own Siri server, visit their blog here:
Rainbow tables are a very interesting method for hackers to ‘crack’ passwords. Instead of relying on CPU power to crack passwords, the rainbow table method favors storage ability over computational power. I’ll give an example.
Let’s say you’re password is ILoveCyberSelfDefense
For the sake of convenience, let’s say the algorithm used to encrypt the password is MD5. The attacker retrieves the MD5 version of the password, which is:
This isn’t useable yet to the attacker, so they will need to do one of two things. They can either make the computer attempt a brute-force attack on the password, or they can check for an entry on a MD5 rainbow table. The user would input the above MD5 hash in the search. If there is a result, it will pop up almost instantly. Otherwise, the user is out of luck and could try a bruteforce attempt.
So what is the catch? A computer still has to manually generate every entry in the rainbow table list, and that takes time and a TON of storage space. So like everything else in this business, it’s a trade off. Do we want to save a ton of time, or do we want to get the answer instantly, but have a hard drive or two with stored passwords?
Only a few weeks ago, someone posted on this blog about the top devices that pose serious security risks to companies. On that list was Apple’s iPad, and at first I cried bloody murder. Apple’s application store provides a unique level of security in the device’s market that the android market has yet to provide.
I thought it was ridiculous that some security blog would consider the iPad to be a major security risk (unrooted) just because of the number of corporations that used such devices. Of course, I was wrong.
Above is a video of how to bypass the passcode lock of an iPad 2 using a very simplistic ‘hack’. You only need to bring up the screen asking for the passcode, hold the lock button down until the power off screen is brought up, close the screen, and hit cancel.
Granted, this method only allows you access to the application that was previously open when the device was ‘locked’. So this could either do no damage to the user if the user had the home screen open, or it could do horrendous damage to the user and company if the email client was open.
Apple will certainly get around to patching this security risk, but how many users won’t update to it? How many devices could be bricked because of the update? How many other security flaws aren’t we seeing?
It’s no surprise to see a return of the infamous stuxnet virus. With the source code being so readily available, it was only a matter of time.
This time the virus isn’t designed to really ‘attack’ anything, but rather gather information for a future attack. In the original stuxnet attack, stolen certificates were taken from both Siemens and Realtec. This time, the certificate was stolen from Symantec.
Once again, the attacking body is unknown, and the intentions are unknown. Only time will tell what this virus has done. The threat is still very new.
Air Dancers, more informally known as “Wacky Wavy Inflatable Arm-Flailing Tubemen” have recently infected our campus. Perhaps we should take a look at the assets and weaknesses of these air dancers from a security standpoint.
Their assets include:
- Attracting customers
- Attracting attention
- Substitute scarecrow
However, not everyone loves the air dancers as you and I. Their Potential Adversaries, Threats, and Weaknesses include:
- Heavy Rain
- Power outages
- Very heavy wind
- Overhead electrical lines
- Vehicles and lawnmowers
- Holes in plastic
- Blower motor failure
- Unstable ground leading to falling over
Possible defenses include:
- Placing the air dancer on a platform so rain will go underneath the dancer, and the dancer will have stable ground and will not fall over.
- Turn it off when hurricane force winds come to Rochester.
- Don’t place under electrical wires/trees.
Here is the risk map:
Here is an interesting topic that I originally found posed this week on RIT’s Reddit; the idea of offline anonymous file sharing.
I figured since we talked this week about how when we find removable media, flash drives, CDs, etc. we should avoid putting them in our machines. The concept here is to do the exact opposite. Here we have a video of a German blogger putting flash drives into the walls and cracks of New York City.
While this is extremely unsafe from a security standpoint, you have to admit the idea is cool. If there were ever a way to ensure only ‘safe’ files could be put on the drive, I would be VERY interested in trying it out.
Here is a link to the original blog post:
The evolution of the conflicker problem has been extremely interesting.
For those not familiar with the infection, it is a very large botnet that has its origins in using an exploit in the Microsoft Windows operating system. While the exploit was patched long before, many users and organizations chose not to run the patch. It spread through other means as well, including using shared resources on networks, and spreading via removable media.
More commonly, especially in enterprise networking and computing it spread because of user’s weak passwords. Conficker became known as a widespread threat because of its ability to spread across a network because of old practices, like setting local administration passwords to 5-6 character passwords, which could be hard to guess as a user, but easy to guess as a computer.
While the virus hasn’t mutated in a very long time, it will be interesting to see what the creators of the worm have in mind for its use. With a couple of million computers infected, the botnet still has a large presence, even if it hasn’t yet been utilized yet.
With Graphics Processing Units (GPUs) becoming faster and more reasonably priced, it’s becoming important to understand what password entropy is and how it is calculated.
Password entropy is defined as a password’s randomness, in regards to how difficult it would be to crack. We calculate password entropy by first looking at the pool of characters a password is made from. For example, the password thisisapassword would have a possible pool of 26 characters from the English alphabet. Changing the password to ThisIsAPassword would increase your pool to 52 characters. I made a table below to outline the rest.
||Pool of Characters Possible
|Lower & Upper Case
|Alphanumeric & Upper Case
|Common ASCII Characters
|Diceware Words List
|English Dictionary Words
Entropy is calculated by using the formula log2(x), where x is the pool of characters used in the password. So a password using lowercase characters would be represented as log2(26) ≈ 4.7 bits of entropy per character. So our previous example of thisisapassword would have an entropy value of ~70 bits (4.7 * 15 characters), assuming a brute-force algorithm. However, there is also another way of looking at that password. We could also think of it as log2(7776)*4 ≈ 51.69 bits of entropy, which makes it a much easier password to guess – it would only take 15 days instead of 19 millennia!
On a final mathematical note, to calculate out the number of possible combinations using your calculated entropy value you would use 2^x, x being the number of bits of entropy. While a password with 40-50 bits of entropy may be semi-safe now, it is only a matter of time until GPUs become more powerful, and password cracking takes less time!
I’ve always enjoyed this particular XKCD comic, because of its simplicity. I’ve never heard it debated in a practical setting. The strategy it describes seems very strong, and I’d like to know if I’m missing something.
This comic is assuming a standard stupid brute-force algorithm. That would mean for this example password, each letter has a 1 in 26 chance of being correct. In terms of entropy, we can describe this as log2(26). Because we are talking about a password that is 25 characters long, we should be able to represent this as log2(26)*25, which would mean a total of 117.5 bits of entropy.
If we assume an english word to be a ‘character’, and we assume there are 171,476 words in the english language, then we can calculate entropy based on an entire english word (no capital letters, no spaces, nothing but letters). Every random word would then have an entropy value of log2(171476) or ~17.39 bits per random word. With 4 words, that would mean 17.39 *4, or ~69.55 bits of entropy, which would still take way too long to guess.
So I still have no idea how the comic’s author came to the conclusion of 44 bits of entropy, so I’m obviously missing something, but does anyone have anything voiding this as a possible strategy for password generation? I would be very interested to hear it.
Viruses have evolved rapidly, and have distanced themselves far from their origins of opening a computer’s CD tray to use as a cup holder. In the past years, viruses have evolved from a medium to tell jokes, to a monetary venture, and are moving dangerously close to the arena of war. The best example of using a virus as a weapon is still Stuxnet.
For those who are not familiar, I would strongly recommend you watch the short clip at the top of this post. It was a revolutionary virus because of its legitimacy. It had 2 proper security clearances from both Realtek and JMicron. The code was very targeted, and the virus would only install itself on machines that met its requirements. It was found on both Windows based machines, and Siemens based controllers in multiple countries. The code spread using many zero-days as well as commonly known vulnerabilities that are structurally similar to conflicker’s distribution method. Yet this behemoth only attacked Iranian nuclear facilities.
Stuxnet invites a new era of virus complexity, as well as a powerful weapon. The virus’s source is freely available, to dissect and modify. Surely megaviruses like Stuxnet will provide a new challenge to current and upcoming security professionals.