Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Security Response
Showing posts tagged with Vulnerabilities & Exploits
Showing posts in English
Ollie Whitehouse | 06 Jul 2006 07:00:00 GMT | 0 comments

HD Moore and the MetaSploit project havegone to town with their toolbox of fuzzers and insight. They haveunleashed a raft of security vulnerabilities on the world, in majorbrowsers across many different platforms, one a day for an entire month(it is now day five of the Month of Browser Bugs as I write this).

WhileI think it's awesome that HD and the project team have made such aconcerted effort to investigate most of the major sub-systems used intoday's browsers (I don't want to detract from their initiative,motivation, or skill) it should be noted they were not the first totake a look at them, thinking that, aside from ActiveX (for a change)they could be fuzzed with high yield results. Similar methods were usedby the illustrious group at Oulu university in 2001,...

David McKinney | 04 Jul 2006 07:00:00 GMT | 0 comments

Cross-site scripting (XSS) is hardly thescourge of the Internet, but at the same time, should it really betrivialized when it affects a widely used service or application?Cross-site scripting (and the broader category of content injectionvulnerabilities) is incredibly prevalent across a wide range ofsoftware, from guestbook programs churned out by weekend warriors, tohousehold names with revenue statements that eclipse the gross nationalproducts of some small countries.

These vulnerabilitiesare so common that most people just wish they would go away. So, if wewant something to go away and we're not willing to expend the time andenergy to develop a real solution, then what alternative do we have? Dowe just pretend that they don't exist? The suggestion is often madethat they aren’t real—nothing to see here—move along.

Some people contend that XSS isn’t a real vulnerability because itcan’t affect security with hosts or end users on its own, or when usedin a product...

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

It has been said that the biggest securityproblem for computers and networks is the user. Every black hat worththeir salt knows that the best way to get information from a targetcomputer or network is to manipulate its user or users. The user setsthe password, knows what’s on the computer, and often knows how toconnect to it from outside of the organization. A little socialengineering by an attacker and then blammo!—the user and theirorganization are compromised.

Simple social engineeringcan go a long way, but the existence of certain vulnerabilities canmake the lives of these social-engineering black hats a whole loteasier. Enter the Microsoft HLINK.DLL Link Memory Corruption Vulnerability,which is a critical flaw in the Microsoft Office Excel application.Using this vulnerability, an attacker could take control of a computerby simply downloading the publicly available exploit and...

Ollie Whitehouse | 23 Jun 2006 07:00:00 GMT | 0 comments

When I look back on it now, MicrosoftOffice is a veritable Petri dish of threat evolution. From attackerslearning how to use intended functionality for malicious purposes,through to exploiting vulnerabilities in the applications themselves,an increased understanding and familiarity with the technology can beseen.

Let me explain. Once upon a time there were macroviruses in Microsoft Office documents that caused havoc. These viruseswere easy to mitigate because Microsoft simply updated Office to promptthe user for further action when opening a document with unsignedmacros. Alternatively, if Office was configured correctly by the user,only signed macros in trusted locations could be executed.

Fast forward four years or so, and we see that Microsoft Office isbeing used a semi-trusted vehicle to exploit buffer overflows in theentire Office suite. Most businesses rely on the transfer of Word,Excel, PowerPoint, Access, Project, or Visio files to exchangeinformation....

Ollie Whitehouse | 16 Jun 2006 07:00:00 GMT | 0 comments

Phreaking ("analog style") emerged in the1960s and was around for over 30 years until it started to die out inthe mid-1990s. In my opinion the term is best described by Wikipedia: "Phreakingis a slang term coined to describe the activity of a subculture ofpeople who study, experiment with, or exploit telephones, the telephonecompany, and systems connected to or composing the Public SwitchedTelephone Network (PSTN) for the purposes of hobby or utility. The term‘phreak’ is a portmanteau of the words ‘phone’ and ‘freak’.”

We'vestarted to see a number of documented cases that point to a resurgencein phreaking, but this time it's not analog networks that are beingexploited; instead, it’s 21st century VoIP networks. I remember when Ifirst started playing with VoIP in 2002, entrenched in the lab with an AsteriskPBX and one...

Liam O Murchu | 07 Jun 2006 07:00:00 GMT | 0 comments

I recently posted a blog that refers to fuzzing techniques—inparticular I spoke about finding file format vulnerabilities usingthese fuzzing techniques. Therefore, it was with no great surprise thatI greeted the announcement of the discovery of nine different fileformat vulnerabilities affecting the Apple QuickTime application.However, what did surprise me was the number of separate file formatsthat were found to be vulnerable.

In this particularannouncement the commonly known .jpg, .bmp, .avi, and .pict fileformats were found to be vulnerable, along with several other formatsthat were disclosed. Given the number of issues discovered, there is nodoubt in my mind that these were all found using file fuzzingtechniques. For a full listing of the issues that Apple has resolvedwith a patched version of QuickTime, please refer to the...

Symantec Security Response | 19 May 2006 07:00:00 GMT | 0 comments

Within the last 24 hours, Security Response has discovered a newattack which exploits a previously undocumented vulnerability inMicrosoft Word. The malicious Microsoft Word document is emailed to thevictim as an attachment, and upon being opened, it installs an embeddedTrojan horse program we are calling Trojan.Mdropper.H.

Thedropper Trojan then installs a backdoor, Backdoor.Ginwui, which binds acommand shell for allowing remote access to the victim machine by theattacker and contacts a remote web server via HTTP. Both the source andthe target of the attack were based in Asia. The Web site thatBackdoor.Ginwui was contacting every minute via HTTP POST commands hasbeen taken down, though the IP addresses were being juggled by theattacker.

Security Response has seen a number of attacks like this of late andit really serves to underscore the new threat landscape we’re dealingwith today. Here’s a few of the signs of the time illustrated by thislatest attack.


John Canavan | 11 May 2006 07:00:00 GMT | 0 comments

With a landmark of six million concurrent online users set last month, Skype’s active user base is growing quickly. With many worms now targeting other IM platforms, it looks to be only a matter of time before Skype becomes targeted as an infection vector. The presence of functionally strong features in the Skype API makes it a prime target for malicious code.

Towards the end of last year, Skype introduced a programming API with the intention of fostering a growing development community. Applications providing useful add-ons to Skype functionality and many hardware interfaces had been springing up over the previous months. Hoping to make development for these programmers less painful, introduce new add-ons to the product, and ultimately increase their market share in the face of the threats from Google Talk and Yahoo IM talk services, the Skype API was launched to capitalize on developer interest.

The Skype API allowed for stand-alone applications to communicate...

Liam O Murchu | 05 May 2006 07:00:00 GMT | 0 comments

History repeats itself. Well, that’s how the saying goes anyway. To see the future we should look to the past.
So what have we seen in the recent past? The whole .wmf debacle at the end of 2005 certainly stands out. Have any lessons been learned from that? I think not, but I guess we will have to wait and see. Of course, the lessons should have been learned a long time before the .wmf exploits were ever circulated.

Why? Well, the .wmf vulnerabilities were more than likely found using some simple file format fuzzing techniques. These vulnerabilities were not the first that could have been found using file fuzzing. Indeed, we have also seen some other prominent examples of bugs in image formats that were probably found using this same technique. For example, we had the .png vulnerability in early 2005. We witnessed the icon vulnerability, also in 2005. What about the .jpeg/GDI vulnerability in 2004? All of these critical vulnerabilities could have been exposed using...