I had never heard of SDRs until today. But now that I know it, I can understand why some folks are so excited about it. This is almost like a swiss army knife for the radio hackers.
The HackRF can shift between different frequencies as easily as a computer switches between applicationsâ€“It can both read and transmit signals from 100 megaherz to 6 gigaherz, including frequencies as low as the range used by FM radio up to the gigaherz frequencies used by Wifi or experimental wireless protocols for cars communicating in traffic. In between those bookends lies everything from police radio to cellular signals from AT&T; and Verizon to garage door openersâ€“all signals that HackRF can instantaneously intercept or reproduce.
Using Try-Catch block is a very good way to detect run-time exceptions. But one of my code reviewers recently pointed out that over using them can be dangerous. I was pointed out that I should only catch those exceptions which I understand and should correctly handle them once its caught. Catch-all try-blocks may generate less user facing errors, but could hide the more serious issues.
Nothing else describes the danger of this way of ignoring exceptions than this post on android-ssl.org [ More details in this paper ].
To evaluate the real threat of such potential vulnerabilities, we have manually mounted MITM attacks against 100 selected apps from that set. This manual audit has revealed widespread and serious vulnerabilities. We have captured credentials for American Express, Diners Club, Paypal, Facebook, Twitter, Google, Yahoo, Microsoft Live ID, Box, WordPress, IBM Sametime, remote servers, bank accounts and email accounts. We have succesfully manipulated virus signatures downloaded via the automatic update functionality of an anti-virus app to neutralize the protection or even to remove arbitrary apps, including the anti-virus program itself.
To be honest I haven’t see how these apps have implemented this… but based on my java/python background I’d say there is a good chance that either a flag was passed to ignore certificate errors, or a try catch block was implemented to catch+ignore all exceptions (which included valid security exceptions).
One of the first discussions I noticed around TLS/SSL was in a news report last year.
These guys came back again this year with another attack called “CRIME“. A simplified version of how this attack is executed is described here along with the plan on how chrome is going to address is.
The problem that CRIME highlights is that sensitive cookie data and an attacker controlled path is compressed together in the same context. Cookie data makes up most of the red, uncompressed bytes in the diagram. If the path contains some cookie data, then the compressed headers will be shorter because zlib will be able to refer back to the path, rather than have to output all the literal bytes of the cookie. If you arrange things so that you can probe the contents of the cookie incrementally, then (assuming that the cookie is base64), you can extract the cookie byte-by-byte by inducing the browser to make requests.
For example, HTML tags like the following could be used to inject XSS into any page. Most browsers (especially chrome) do protect against this, but it may be possible to get around some of the security measures.
Read this for little more background.
Missing SD card slots in Nexus devices shouldn’t be looked at as a disadvantage. Read this to get the full picture.
Google still supports removable storage in Android, but it is leading by example and providing phones (and now a tablet) with one big block of storage that users can use for anything they like — be it media, documents, or apps. There are a couple of side benefits to this approach as well. The first one is a bit geeky — it allows the device to use ext file systems instead of a mix of ext and FAT. This is faster and safer — both for the data on the device and the way it’s handled, and access to our own personal data. A journalized file system means fewer file errors, and ext preserves file system permissions so random code can’t find your pictures or documents folder.
If you are not blocking chrome updates, you will be automatically patched very soon. No need to wait for the monthly ‘patch tuesday’.
Google has fixed a hole in its Chrome browser that earned a white hat hacker $60,000 at the recent Pwnium 2 hacking contest.
The company released the fix for the vulnerability on Wednesday, around 10 hours after it was revealed at the Pwnium competition at ‘Hack in the Box 2012’ contest in Kuala Lumpur, Malaysia on Tuesday. The hacker â€” who goes by the name of ‘pinkie pie’ â€” found the vulnerability in the browser by combining two separate exploits, and netted a cool $60,000 for his discovery, as well as a free Chromebook.
Zero Day by Mark Russinovich is a brilliant novel about why we should fear an online attack by a rogue non-state-sponsored terrorist before any other forms of spectacular attacks.
I didn’t know that Boing 787 was fully fly by wire, and that medication in hospitals were controlled by networked computers. While attacking that type of software would require specialized knowledge on internals of those systems, it may not be as far fetched as most of us assume it to be.
The fact that zero day exploits are available for sale is also not a secret anymore. There are organizations out there who are willing to pay big bucks for those who prefer money than fame. Why do you think pwn2own doesn’t require exploits to be fully documented anymore ? The proliferation of networked computers is good idea, but our inability to patch them on time is a recipe for disaster.
I’ve worked long enough in IT to know that not all patches are applied immediately to all systems as soon as they are released. There is a long, expensive process to make sure that patches don’t bring down the entire network. And because of this, a lot of organizations patch the most critical systems at the very end (after everything else is patched). And thats for the holes for which patches are available from the software vendor. There are tons of other holes which are still being researched by the vendor, and even more which are not reported to the vendor yet.
Though it may be hard to believe that an attack as big as the one described in this book would go unnoticed by all of the security vendors, its definitely plausible and shouldn’t be ignored.
I highly recommend you to read this book if you are even remotely concerned about how fragile our infrastructure can be. The least you could do is patch your own systems.
Apparently, Iran still being on x.25 was a surprise to some. Aren’t traditional phone networks older that x.25 ? And isn’t that still in service in more parts of the world?
The way I waste my days: Iran`s X.25 NUA Directory: Well , long time ago this directory was a big secret for me ,as I`m sure thi s is the first ever published list of NUA, covering Iran`s X.25…