01-14-2010 12:10
Targeted attacks on Google, Yahoo, Adobe and other companies
2010-01-14
On Tuesday, 13th of January, Google announced that their security experts detected targeted attacks on Google's employees. The attackers successfully gained access to sensitive data about certain users of the Gmail service provided by Google. The attacks were carried out in second half of December last year and, according to a report by iDefense, attackers used malicious PDF documents to exploit client machines. The malicious PDF documents were sent as e-mail attachments.
Exploitation of vulnerabilities in the Adobe Reader and Acrobat applications became very common in last couple of years due to a high number of identified vulnerabilities in these products. Infigo's security researcher Bojan Ždrnja published several analysis of malicious PDF documents on SANS' Internet Storm Center website; the analysis can be seen at the following URLs: http://isc.sans.org/diary.html?storyid=7867 and http://isc.sans.org/diary.html?storyid=7984. It is assumed that similar malicious PDF documents were used in published attacks.
Google also announced that they detected attacks on over 30 other companies and that the attackers, which are suspected to come from China, managed to gain access to sensitive intellectual property such as application source code. INFIGO IS is urging customers to install the latest available patches for the Adobe Reader and Acrobat applications and to disable JavaScript in these applications as well.
Vesti ::
infigo
Povezani zapisi:
08-31-2010 1:17
 Posted by Adam Mein, Google Security Team
Quite a few security companies and organizations produce vulnerability databases, cataloguing bugs and reporting trends across the industry based on the data they compile. There is value in this exercise; specifically, getting a look at examples across a range of companies and industries gives us information about the most common types of threats, as well as how they are distributed.
Unfortunately, the data behind these reports is commonly inaccurate or outdated to some degree. The truth is that maintaining an accurate and reliable database of this type of information is a significant challenge. We most recently saw this reality play out last week after the appearance of the IBM X-Force® 2010 Mid-Year Trend and Risk Report. We questioned a number of surprising findings concerning Google’s vulnerability rate and response record, and after discussions with IBM, we discovered a number of errors that had important implications for the report’s conclusions. IBM worked together with us and promptly issued a correction to address the inaccuracies.
Google maintains a Product Security Response Team that prioritizes bug reports and coordinates their handling across relevant engineering groups. Unsurprisingly, particular attention is paid to high-risk and critical vulnerabilities. For this reason, we were confused by a claim that 33% of critical and high-risk bugs uncovered in our services in the first half of 2010 were left unpatched. We learned after investigating that the 33% figure referred to a single unpatched vulnerability out of a total of three — and importantly, the one item that was considered unpatched was only mistakenly considered a security vulnerability due to a terminology mix-up. As a result, the true unpatched rate for these high-risk bugs is 0 out of 2, or 0%.
How do these types of errors occur? Maintainers of vulnerability databases have a number of factors working against them:
Vendors disclose their vulnerabilities in inconsistent formats, using different severity classifications. This makes the process of measuring the number of total vulnerabilities assigned to a given vendor much more difficult.Assessing the severity, scope, and nature of a bug sometimes requires intimate knowledge of a product or technology, and this can lead to errors and misinterpretation.Keeping the fix status updated for thousands of entries is no small task, and we’ve consistently seen long-fixed errors marked as unfixed in a number of databases.Not all compilers of vulnerability databases perform their own independent verification of bugs they find reported from other sources. As a result, errors in one source can be replicated to others.To make these databases more useful for the industry and less likely to spread misinformation, we feel there must be more frequent collaboration between vendors and compilers. As a first step, database compilers should reach out to vendors they plan to cover in order to devise a sustainable solution for both parties that will allow for a more consistent flow of information. Another big improvement would be increased transparency on the part of the compilers — for example, the inclusion of more hard data, the methodology behind the data gathering, and caveat language acknowledging the limitations of the presented data. We hope to see these common research practices employed more broadly to increase the quality and usefulness of vulnerability trend reports.
Feedproxy Security
08-27-2010 15:22
FTP brute password guessing attacks are a fairly regular occurrence at the moment. The fact that these are occurring with regularity means that they are still working, so If you have an internet facing FTP server then there are a few things that you might consider doing to help weather the storm.
Watch your logs!
It is surprising when you work on an incident to see how long an event goes unnoticed. Sometimes months, even though the logs are full of events such as:
09:19:44 211.45.113.143 [2]USER Administrator 331 0
09:19:46 211.45.113.143 [2]PASS - 530 1326
09:19:46 211.45.113.143 [2]USER Administrator 331 0
09:19:46 211.45.113.143 [2]PASS - 530 1326
09:19:46 211.45.113.143 [2]USER Administrator 331 0
09:19:47 211.45.113.143 [2]PASS - 530 1326
09:19:47 211.45.113.143 [2]USER Administrator 331 0
09:19:47 211.45.113.143 [2]PASS - 530 1326
09:19:47 211.45.113.143 [2]USER Administrator 331 0
09:19:48 211.45.113.143 [2]PASS - 530 1326
09:19:48 211.45.113.143 [2]USER Administrator 331 0
09:19:48 211.45.113.143 [2]PASS - 530 1326
It is quite clear what is going on here. a user typing a password multiple times per second? not likely. The log shows very clearly what is going on someone is guessing passwords. In this case it was a Microsoft FTP server which was being attacked, so there is likely to be an administrator account on the system and eventually this attack result in access.
Many people don't have their logging enabled. Make sure it is switched on and watched regularly, this is something junior can do on his own.
Rename Administrator
On windows systems I like renaming the administrator account and then setting up a new user called Administrator, but without any privileges or access on the system. I set the password to something very long and then watch the logs. Even if they eventually manage to guess the password the account is not worth anything. It is a simple thing to do, but can be very effective. The FTP brute password attack above won't work and you may pick something else up as well. Simple but effective.
Remove Anonymous Access
Should you remove Anonymous access? I guess the answer depends on why there is an FTP server in the first place. Anonymous access is usually abused. When placing a FTP honeypot on the network the first files start getting uploaded, usually within the hour. So unless you really need it, remove it.
Restrict Access to FTP
In many organisations the actual use of FTP is fairly limited. There is no need for the whole internet to access the FTP serverthere may be a finite number of locations. Restrict access to FTP to these locations only, either through firewall rules, or on the FTP server itself (or even both). This will limit the opportunity for abuse of your FTP server.
The above are a few simple ways to reduce the risk of losing your FTP server to someone else. If you have some nifty tricks that will help protect an FTP service, write a comment or use the contact form.
Cheers
Mark H
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC
08-25-2010 21:42
Pedro Bueno (pbueno /%%/ isc. sans. org) Twitter: http://twitter.com/besecure
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC
08-20-2010 22:10
31 posts left…
There are quite a few different methods of performing MITM attacks, but one in particular kinda struck my fancy early on when I was thinking about airpwn. In the case of airpwn and similar exploits the attacker may be able to listen to the packets being transmitted but they aren’t able to block them, so instead it comes down to a game of beating packets to their source and origin. I don’t know what the prevalence of use of any sort of MITM is, but in this case there are a few things you could do to detect.
Anyway, if you receive double the DNS replies, or double ACK responses for instance, that could indicate that someone is trying to beat another packet back, which is why you’ll end up with two. Of course, figuring out which one is real isn’t straight forward (the bad guy may have just been slow, so it’s the first one that’s real). And there may be other things the bad guy can do like immediately forward a RST packet to the server you’re trying to connect to to quash the double ACK, so this may have some limits of utility.
Perhaps someone could think of another ingenious way to use that information or think of other clever methods of detection based on something similar for the other classes of MITM (like acting as a proxy, or re-routing traffic, etc…). I’m sure someone somewhere has already thought about and posted about this concept, but I wasn’t able to find anything in a cursory search. Maybe it’s new, maybe not, but I still thought it was interesting, even if limited.
ha.ckers
| |
|
|
|
