comp527

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.

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!

A recent survey by RSA showed that, among other things, half of U.S. IT employees who leave their employer retain access to resources that they shouldn’t have.  Not only that, but over half have knowingly circumvented the corporate security policy because they felt it was needed to accomplish thier job.

The “insider threat” may actually apply to a much broader class of people than we realize.  In this light, it’s suddenly much more reasonable to me that security should always be designed against an insider attack.  Again, this survey is of IT workers who should know better and (chillingly) have the know-how to exploit it.

Perhaps if corporate security policies could be improved, then this wouldn’t happen as much – I see two key areas that they’re failing:

1. Lack of enforcement, probably due to the complexity of enforcement.  If it takes no work to leave someone’s account open, but it takes an hour of cleaning up security records to remove someone from the company, which do you think is more likely to happen?
2. Lack of adherence among enforcers, probably due to bad rules.  If, every time a rule had to be broken, the “enforcers” instead proposed a change to the policy it might tend to create a policy-set that actually reflected the actual company policy.  However – and this I feel is key – careful thought must be given to if a one-time-exception status should be given (and there ought to be a way to do that) or if a general rule change should be made.  Exceptions should not (usually) be rules because that will just add to complexity and decrease the enforceability.

I think that #2 is not done because of the trouble that the IT worker has to go through to propose a rule change, as opposed to the ease of which they can break the rule.  I wonder how many companies have policies that have changed over the years in practice, but remain the same on paper.  I’d bet it’s a lot…

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.