Archive for the ‘privacy’ Category
Responsible disclosure for Jailbroken iPhones
It has been talked of how a jailborken iPhone has been hacked here and here
But although the problem was publicly advertised so has the manner of using it to hack such iPhones.
The guy from the Netherlands published the source code he used. Was this a good choice?
Since the first incident, several malicious programs have appeared which take advantage of the default root password.
Two of them can be found: here (worm – “harmless yet annoying prank”) and here (a “truly malicious iPhone malware” which extracts personal data)
Jailbroken IPhone Security
Here is a remainder that if you want to escape Apple’s security, you’d better know what you’re doing and enforce your own.
A hacker from Netherlands used port scanning to find jailbroken iPhones running SSH and who’s users were careless enough to leave the default root password after jailbreaking their phones. His initial demands for fixing a hacked iPhone were 5 euros and has now published the solution for undoing what he did.
Personal opinion: Those who got their iPhones hacked should have at least said thank you for uncovering how insecure their phones were instead of accepting his apologizes for what he has done.
Can hacking cable modems get you in jail?
Ryan Harris, an expert on cable modem hacking who has been selling unlocked cable modems through a small company, is facing criminal charges of wire fraud and computer fraud.
In his defence he claims that: “arresting every firearms dealer, because handguns can be used to commit murder.”
Read more here
A/N: If the fact that one of his programs is called “Coax Thief” puts him in a bad light than a note for all those hacking: Make sure you name all of your software things like “Safe Program Thingy” or “Well Behaved Program”. More importantly, don’t you dare use user or socket messages like: “It’s hacked” or “Hack in place” nor variable or function names with similar connotations!
Smartphone Security
As if worrying about security on your computer wasn’t enough, your smartphone is increasingly becoming a significant target.
Besides the standard virus and worm attacks via email attachments, one recent attack used the phone’s bluetooth capabilities to spread between other nearby bluetooth-enabled devices.
Research indicates that a significant amount of the problem is that, while many users know to be careful on their home computer, many people feel their phone is more immune to security threats. Not so. The article’s suggestion – “treat your smartphone like a computer, not a telephone.”
Unfortunately, there are many people who don’t treat their home computer security properly, much less their smartphone security. People need to continue to be educated about internet security. If you’re going to fall for a phishing attack on your home computer, you’re probably going to fall for anything on your smartphone. Awareness is key.
News article: http://www.cnn.com/2009/TECH/10/25/smartphone.security/index.html
How safe is wireless access???
A recent bug in Times Warner cable modem had caused the wireless admin site exposed to a potential hacker. About 65,000 users are affected by this. More details can be found here
The most amazing part of this is that the administrative portion was guarded off by JavaScript code. A simple toggling of JavaScript option exposed this vulnerability.
I admire David Chen for reporting this issue to the concerned authorities. His ethics would go a long way.
A question which always seems to pop off is ” How secure is wireless access?”. Ever since the first draft of 802.11 specifications, people have been able to exploit wireless networks easily.
A classic paper which uncovered the lame security aspects was “Intercepting Mobile Communications: The Insecurity of 802.11″ (link) . This paper showed some very simple tricks to attack wireless medium. It was an eye opener to the 802.11 committee who formed the very basis of the protocol.
In my opinion, we require a new framework to test these vulnerabilities. Even if the protocol is safe, there is some implementation problem. If the implementation is right, there is an issue with hardware and this chain keeps going on…
Another Phishing attack, Hotmail accounts hacked
It seems that there has been a major Phishing attack on Hotmail accounts ( more than 10,000 accounts affected).
Furthermore, the passwords of users were posted online.
Beware, Be secure and avoid unwanted mails.
Read more of the news here.
Crack your neighbor’s password
Most of us would take for granted that the * marked field was enough to avoid onlookers reveal our passwords.
Well, Think again. Your next door neighbor could learn your password without even coming close to you. A recent research work gets hold of passwords through keyboard clicks. They do this by simply decoding the electromagnetic radiations emitted by keyboards.
Hard to believe. Take a look at the video posted here along-with other comments.
This paper received the outstanding student paper award at the recent USENIX forum.
(Thinking point??) How would we transition from all the legacy password systems to any new authentication system?
Secret Sharing
Reposting this from Nikita Borisov’s blog (a crypto/security professor at Illinois Urbana-Champaign). It’s closely related to the number guessing commitments we described in class today. Can anybody crack the secret?
I decided to perform a small experiment in my Applied Cryptography course. We were discussing additive secret sharing. The basic idea is that, given a secret number
, you pick a random share
and set the second share
. Neither share by itself contains any information about the secret.
I asked the students to each pick a number between 0 and 99 (i.e., in
). I treated the first student’s number as the secret s. The rest of the students had to treat their number as a first share,
, and compute
based on it. I asked the students to report back the result of the subtraction. Note that none of the students revealed their secret share
, so the response should not reveal any information about the secret. Here are the results:
42 82 85 10 25 49 85 43 63 21 87 63 25 1 70 Can you guess what the secret number
was?
In case my description was confusing, imagine that the class had four students, Alice, Bob, Carol, and David. Each student picked a random number:
- Alice: 61
- Bob: 34
- Carol: 54
- David: 59
We will use Alice’s number as
= 61. Then Bob will pick his share as
= 61-34 = 27. Carol will take her own number as
= 54, but use the same (Alice’s)
, to produce 61-54 = 7. David will do the same thing, obtaining 2. So the report for the table above would be 27, 7, 2. In theory, knowing all these three numbers, you still have no information about Alice’s secret. In practice, you should be able to guess it from the results of the in-class experiment.
WPA goes the way of WEP?
Researchers Martin Beck and Eric Tews appear to have found a way to break part of the WPA encryption scheme, reports ITworld. They are able to convince the 802.11a/b/g router to send them lots of data, which they then analyze using a “mathematical breakthrough.” Afterwards, they are able to decrypt traffic from the router to the client, but not from the client to the router.
Beck and Tew’s work will be presented at the PacSec conference starting November 12. Until then, it appears that there has been little independent review, so the full scope of this vulnerability remains unknown.
Here’s hoping is more fluke than fact.
(Found via Slashdot.)
An update was posted to Slashdot and ars technica. The exploit is not as large as was initially reported. As Slashdot says,
ARP packets and similarly short packets can be decoded. Longer packets are likely still safe, and TKIP hasn’t been cracked. Don’t believe the hype, but the exploit is still notable.
(Hat tip to fortunaMajor.)
Hack-a-Vote retrospective
OK, so there’s a lot of people talking about our Hack-a-Vote (HaV) project. We should probably be among them! So let’s talk about what we learned from HaV, now that it’s over.
I’d like to start by saying that the number one thing that I learned was that the system as a whole needs to be audited, not just the source code. The source is hugely important, don’t get me wrong, but if all you look at is the source, all you can talk about is the source. You can’t validate a SYSTEM without looking at every part of that system.
Second, adding crypto can make a system less secure. Not just fail to add security, but actually increase possible attacks. If you use crypto, you had better know why you’re using it, how it works, and that you’re using it properly.
Third, a system must be tested in “real world” scenarios. I know our group’s specific attack didn’t appear during any of the testing modes, only when the HaV program thought it was in a real election. Testing must be done, at least in a final stage, as a whole, complete system that can be operated exactly as you will operate in a “live” situation. Again – you can only validate what you actually audit.
Finally, if you know something about the expected audit process, you can play on the psychology of the auditor, and make things appear as expected so that they aren’t scrutinized properly. After all, if you can trick the audit team into not looking at your attacked code, then it doesn’t matter how obvious the attack is in that code, you’ve passed the audit.
This is, of course, a bunch of broad generalizations – I’ve learned a lot more about Java security in particular etc. etc., but I think this is the “bullet point list” that will be embedded in my long-term memory well beyond when this class is over.
So: what did you feel were the most important points of the HaV project? And if you want to discuss a specific attack, feel free to bring it up, don’t feel constrained by my “overview only” tone.