Video Screencast Help
Security Response
Showing posts in English
Mimi Hoang | 02 Nov 2006 08:00:00 GMT | 0 comments

Rootkits are on the rise! We define a rootkit as a component that uses stealth to maintain an undetectable presence on a computer. Above and beyond that, the actions performed by a rootkit are done without end-user consent or knowledge.

Open source offers ready-to-use rootkit applications that are widely available to anybody using the Internet. Even an inexperienced rookie would be able to use a rootkit without having to understand how it works. These hi-tech criminals are money hungry and want to hide their actions and presence on any system they get on. Rootkits are perfect to help them commit fraud and identity theft by granting the attackers unauthorized access to privileged and proprietary information, and launching and hiding other malicious applications on the system. Above all, it leaves the hi-tech criminal with a back door to be able to continue to harm the victimized machine. As well, a large proportion of spyware and adware programs that use rootkits are...

Peter Ferrie | 02 Nov 2006 08:00:00 GMT | 0 comments

We received a virus on Thursday morning that parasitically infects OSX Mach-O format files, without relying on resource forks. It's called OSX/Macarena. If you have read the OSX/Leap paper from this year's Virus Bulletin conference, you will have seen some suggestions about possible infection methods. Those suggestions were all ignored by the virus author in this case. Instead, the virus writer has found a rather unexpected region of memory in which to place the code, along with a way to gain immediate control when an infected file is executed. There is no payload in this virus—it simply replicates. However, it won't replicate very well, because it is restricted to the current directory. On Windows systems it is common to have directories like "Windows" and "Windows\system32" full of executable files; but, files aren't stored like that on OSX systems....

Al Hartmann | 01 Nov 2006 08:00:00 GMT | 0 comments

This Weblog and the blogoshpere in generalhave been abuzz with controversy over Microsoft PatchGuard and issuesdealing with appropriate kernel security instrumentation. This blogentry is the first of a two-part series. It provides an excerpt of adraft posting that proposes an abstract host security metasystem andlaws of host security that attempt to raise the level of discourseabove specific features and implementations. This blog entry willoutline the sensor and effector instrumentation laws and the secondblog entry, covering the security and policy component laws, will bepublished later this week. Symantec posted this draft to openly solicitconstructive comments and helpful suggestions for draft refinements.The intent is to reach industry consensus on an architectural frameworkto guide designers of future host security subsystems and supportinginstrumentation.


Ollie Whitehouse | 01 Nov 2006 08:00:00 GMT | 0 comments

Be warned: this may sound a little odd. Imagine if I told you that some television and radio content is broadcast using IP, over the air. (You'd probably think I’d been working with too much paint thinner over the weekend.) Well, this broadcast method is how a live service in the UK works. It’s called digital audio broadcasting – IP (DAB-IP) and in short, your mobile device just got another network connection.

The UK has just had the “Lobster” (a mobile handset) launched on the Virgin mobile network, which uses DAB-IP for its TV and radio content. DAB is a standard owned by ETSI (the same people who own GSM). With DAB-IP, content is basically being tunneled over IP, over DAB, to your handset. One of the first interesting things I read in relation to this topic was a...

Sarah Gordon | 31 Oct 2006 08:00:00 GMT | 0 comments

This week will find me at the Santa Fe Institute. Wednesday morning kicks off with the Adaptive and Resilient Computing Workshop, and if last year's workshop is any indicator, this one should be very interesting indeed. Meeting with colleagues who work outside the computer security space is extremely informative and helps us to prepare for the many new faces of computing. Although, that only makes sense if you know ahead of time where some technologies are likely to exist and only then can you begin to shape ideas on how you might protect the assets those technologies hold.

For example, let's say that within the next two years, all deep water canals in the state of Florida will be protected against alligator infestation by computerized swimming sharks that work together to form a sort of "canal IDS." We need to make sure the sharks stay up and running to keep those annoying alligators...

Sarah Gordon | 31 Oct 2006 08:00:00 GMT | 0 comments

"People behind the programs" is a topic that has held public interest for many years now. Although, when it comes right down to it, the people behind most of the programs have been the same sort for decades. Yes, it's true that the risk of identity theft is growing. And, it's also true that risks from phishing have increased. And, it is undeniably true that bots are a huge problem, and they weren't twenty years ago.

So, how can I say that the types of people behind most of the programs has not changed in over two decades? Easy. It's true. "But, how can this be?" you ask.

Stay tuned. I'll be writing more about this soon.

Ollie Whitehouse | 30 Oct 2006 08:00:00 GMT | 0 comments

The University of Santa Barbara's software group released the source code for their proof of concept 'Feakk' worm that was developed by Paul Haas in March 2005. The worm uses SMS to send a hyperlink to its target. The targeted user then has to visit the hyperlink and download and acknowledge three sets of prompts in order for the worm to install, at which point it will immediately start to run in the background. It will scan the user's contact list and send a message to each contact (including the recipients' names) and will also scan for new contacts at certain intervals.

Upon installation, the worm checks for a contact with the first name "HACKME." If this isn't found the worm will exit. If it is found, then the worm sends itself to every mobile number it finds in the user's contact list. The author did not write a payload because this was for demonstration purposes only and it should be noted that it can be removed via the "...

Yazan Gable | 27 Oct 2006 07:00:00 GMT | 0 comments

It is pretty much an accepted fact thatvulnerabilities are everywhere these days. They can affect every pieceof software available, whether it is from major vendors (Microsoft,Cisco, etc.) or if it has been written by hobbyist programmers (thosebuilding a Web app, for example). These vulnerabilities can surface onthe public landscape in a wide range of situations; from zero-dayattacks, all the way over to the other side of the spectrum withresponsible disclosure. However, the responsibility does not restsolely on the shoulders of the vulnerability researchers—vendors should(and do, in most cases) have an obligation to be responsible as well.The bottom line is, software vendors should hold some responsibilityfor their customer’s computer security. If a vendor’s software somehowthreatens a user’s security by containing a vulnerability, the vendorshould take responsibility for it and do what they can to protect theuser.

In light of this, I believe that Apple Computer’s...

Zulfikar Ramzan | 26 Oct 2006 07:00:00 GMT | 0 comments

Back in August, I attended the CRYPTO 2006conference in Santa Barbara, where Daniel Bleichenbacher gave aneye-opening talk that highlighted a very common implementation mistakepeople make with the RSA cryptosystem. Since my own background is incryptography I thought I would try to describe not only this commonmistake and its implications, but also some details regarding why thismistake leads to vulnerabilities, in a way that’s hopefully suitablefor a wide audience. For those who don’t recognize the name, Daniel isa well-known and brilliant cryptographer who, among other things, foundcryptographic flaws in SSL v3.0 and also the random number generatorassociated with the Digital Signature Algorithm. Well, he is at itagain!

Before going any further I want to emphasize thatthe flaw Daniel found is not one that is inherent in the RSA algorithmitself; rather, it deals with a specific...

Robert Keith | 25 Oct 2006 07:00:00 GMT | 0 comments

This year has seen a mass influx of reportson remote file-include vulnerabilities. On the same note, it has alsoseen a mass number of invalid vulnerability reports. Thetrend, it seems, is for reporters to grep as much source code aspossible, looking for that special phrase: include($variable). However,the reporters either neglect to read the entire source prior to thatline, or perhaps choose to ignore it. As is often the case for falsereports, within five lines of the include() call is a declaration forthe very variable assumed to be vulnerable.

This naturally makes my job all the more complicated. Our teamprides itself on having the most comprehensive vulnerability databaseavailable. We also want to make sure it’s accurate and doesn’t containinvalid entries. We try to verify all the issues reported to us,usually by inspecting the source code, but it is frustrating to spendtime scrutinizing reports on “issues” that are clearly not vulnerable.This, in turn,...