Open Source Laptop Tracking Service

Adeona. Looks good.

Schneier on Security: Open Source Laptop Tracking Service

Schneier segnala questo strumento molto molto carino, alla faccia di altri blasonati strumenti a pagamento.

Adeona has three main properties:

• Private: Adeona uses state-of-the-art cryptographic mechanisms to ensure that the owner is the only party that can use the system to reveal the locations visited by a device.
• Reliable: Adeona uses a community-based remote storage facility, ensuring retrievability of recent location updates.
• Open source and free: Adeona’s software is licensed under GPLv2. While your locations are secret, the tracking system’s design is not.

Testing in corso

With the iPhone quickly becoming the market leader in mobile devices, the need for law enforcement personnel to perform forensic analysis of these devices is beginning to surface. Unlike most other smart phones, the iPhone incorporates desktop-like features in an easy-to-use mobile package

[Via Webcast: iPhone Forensics Demonstration]

Come promesso ai ragazzi del corso di forensics posto le informazioni per un pò di mela evidence acquisition

Last week, Adobe released a security bulletin concerning updates that should be deployed as a part o …(more)…

Qui il riferimento originale

This is not good. Researchers from INSERT found a vulnerability in the Gmail engine that could allow spammers to forward mail through Google, thereby bypassing blacklists and being accepted by whitelists. It works by using the same forwarding features that allow users, myself included, to forward their email through Gmail. The worst part of this is that it also bypasses Gmails 500 recipient limit for any email, though that part should be easy to fix. I hope.

INSERT has been courteous enough to omit a fair amount of the details of the vulnerability, but I think there’s enough general information in the notification that spammers will be able to figure it out soon if Google doesn’t act even faster than the bad guys. Given Google’s track record and the sneaking suspicion that Google was given advance warning of the vulnerability, I’m hoping Gmail can be made secure fairly quickly.

I’ll be interested to see what we hear on this over the next couple of weeks on the Full Disclosure/No Disclosure argument. Did INSERT give Google some warning or did they post this as soon as it was written up? How did Google react? Did Google take the Micorosoft stance of quietly taking the research and fixing the hole before anyone notices? Or did they take the Apple/Cisco approach and threaten to sue INSERT into non-existance? I’m hoping for the former.

Just goes to show you, even the best built, least offensive features in software can be subverted if you put enough brain power into solving the problem.

[Via - http://feeds.feedburner.com/~r/Security-Bloggers-Network/~3/287848056/]

The WordPress Photo Gallery module suffers from a remote SQL injection vulnerability.

[Via - http://packetstormsecurity.org/filedesc/wpgallery-sql.txt.html]

The Oracle Application Server Portal 10G suffers from an authentication bypass vulnerability. Details are provided.

[Via - http://packetstormsecurity.org/filedesc/oracleasp-bypass.txt.html]

[Via - http://www.milw0rm.com/exploits/5587]

David Ross had a good blog post a few weeks back about how IE8.0 is no longer vulnerable to the US-ASCII encoding attack. For those of you who don’t know what I’m talking about you can find an example of it on the charsets page. Looks like both of the browser manufacturers are stepping up their game a little for the next version of the browsers to hit the market.

On a side note, and something I’ve been meaning to post for a while now, I’ve found a discrepancy between IE and Firefox that I think is worth noting. Most of the time this isn’t an issue but most web-pages decode Unicode inputs, so the fact that Firefox automatically encodes every GET parameter with Unicode is not a big deal. However, if the page doesn’t do any conversions, but rather echos the data back exactly as it was seen Firefox isn’t vulnerable. However, Internet Explorer is - because it doesn’t convert " into %22 for instance.

It’s a subtle difference, and only effects certain websites, but it was big enough of an issue that I had to switch testing methods because Firefox wasn’t giving me the results I was expecting - even though I could see the vulnerability using a proxy. I don’t know what percentage of pages do this, but it will lead to a lot of false negatives in scanners that are looking for XSS injection, if they follow the RFC. Net result for me? Firefox = less good for testing and IE = less secure.

Meanwhile, not that anyone cares, but it turns out that blogging is going to make me die an unfortunate and unglamorous early death. And I always thought it was because it was going to be due to an explosion. You people totally owe me. I expect payment in the afterlife.

[Via - http://ha.ckers.org/blog/20080407/ie80-us-ascii-and-other-stuff/]