—-

U.S. regulators are moving to freeze the assets and trading accounts of a Russian accused of hacking into personal online portfolios and manipulating the price of dozens of stocks listed on the Nasdaq Stock Market and New York Stock Exchange.

A New York federal judge on Tuesday sided with the Securities and Exchange Commission and froze the assets of Broco Investments, believed to be a one-trader operation based in St. Petersburg, Russia. The SEC said Broco capitalized by artificially moving prices of more 38 thinly traded securities — enabling Broco to profit from up-or-down price swings.

“These transactions have created the appearance of legitimate trading activity and have artificially affected the prices of at least 38 issuers,” (.pdf)  the Securities and Exchange Commission said in court filing.

The so-called “hack, pump and dump” scheme is among the latest illicit methods of gaming the market though hacking.

An Indian man was sentenced to two years in prison for undertaking a similar scam in 2008. That same year, a Ukrainian hacked into Thomson Financial to get a peek about an upcoming negative earnings report for IMS Health, earning nearly $300,000 for a few minutes’ work.

And in July, a computer programmer working for Goldman Sachs was arrested on charges  he stole proprietary source code for software his employer uses to make sophisticated, high-speed stock and commodities trades.

In the latest case, the affected stocks ranged from Akeena Solar, Magellan Petroleum to Xerium Technologies. The prices fluctuated more than 20 percent in some instances.

Broco would purchase these and other stocks in its own portfolio and immediately place unauthorized buy orders at inflated prices of the same securities in hacked Scottrade accounts, the SEC said.

“Immediately or shortly thereafter, the defendants capitalized on the artificially inflated share prices of the targeted securities by selling the shares previously acquired in their account,” the SEC alleged. “In other instances, the defendants profited by covering short positions previously established in their account while placing unauthorized sell orders through the compromised accounts at substantially lower prices.”

Along the way, victims lost $600,000 in market value the last few months alone, the SEC said. And Broco, believed to be a one-person company run by Valery Maltsev, reaped $255,000 in ill-gotten gains during the same time.

Daily trading volume in Pennsylvania-based financial services company AmeriServe Financial averaged about 11,300 shares in from Dec. 1 to Dec. 20, the SEC said. The next day, volume increased 20 times. At least 200,000 shares were bought and sold through Broco or hacked Scottrade accounts, allowing Broco to leverage the prices for its own profits.

“Broco grossed $141,500 in approximately 15 minutes,” the SEC said.

[via Wired]

The Duo battery chargers for NiMH batteries are safe, but the software that enables the user to monitor the batteries is infected, PC World reported Monday.

The infected software includes a “backdoor” that allows some computer files to be to be remotely controlled, PC World said.

The trouble begins if the consumer downloads Windows software from the Energizer company website If this was not done or if the consumer uses a Macintosh computer, consumer files are safe.

Consumers were advised to uninstall the infected software, reboot the computers and then go to the System32 directory in Windows. There, consumers were advised to delete “arucer.dll,” the file that is the actual backdoor, PC World said.

Energizer has discontinued the software, but you can still buy the DUO at Amazon for about $20.

Most people probably just shrugged their shoulders at the news, but it’s yet another blemish against the company’s security record. This isn’t the first time Facebook has run into security issues, and I’ve grown increasingly concerned that the company might be playing fast and loose with its quality assurance policies because it doesn’t want to sacrifice the rapid iteration it’s famous for.  With this in mind, I reached out to Facebook late last week to ask about their protocol for deploying code and how the bug made it through in the first place. The company responded to some of my questions, and refused to answer others.

At least, Facebook eventually answered some of my questions. At first, the company sent me a vague statement reiterating that they were investigating the issue, and that they “maintain industry-leading quality assurance and security systems, and the reliability of Facebook is our top priority.”

In response, I reminded the Facebook spokesperson that it had just sent thousands of messages to people who weren’t meant to receive them, which would seem to indicate that it is not, in fact, on the bleeding edge of online security. I restated my questions and the company got back to me with this more detailed overview of its QA and code deployment policies, found below. Note that it begins with a general statement Facebook provided, along with more direct answers to my questions (which are in bold).

Facebook hires the most qualified and highly-skilled engineers we can find – most from industry or from top universities. Upon joining the company, every engineer and engineering manager participates in a six-week intensive ‘boot camp’ training. Our code review process is rigorous, and we phase out changes and test them before they go live for real users to detect any potential issues. During code pushes, our engineering, user support, and operations teams work cross-functionally to monitor the state of the push and to identify any problems early. We also have the capability to quickly push code updates to all of our datacenters worldwide, and to enable or disable critical features of the site if there is a problem.

All of these checks worked together on Wednesday, as designed, to limit the impact of the error and stopped it within minutes. We were able to swiftly disable access to the users who received messages and remove those messages from Facebook, although we were unable to prevent email notifications from being sent to affected users. It is important to recognize that no system is perfect and no company avoids mistakes all of the time. However, we would like to take this opportunity to sincerely apologize to all affected users and ensure them that we are committed to investigating Wednesday’s issue and to learning from it.

What are your protocols for pushing code?

We have staged rollout changes that go through multiple phases before going to end users, so we can proactively detect any problems. As the changes get rolled out to users, a set of support, engineering, and operation leaders are actively engaged to monitor the state of the push. As soon as any issue is identified, we have multiple tools to quickly disable critical features. The combination of these mechanisms dramatically limited the exposure related to Wednesday’s issue.

Are there multiple people reviewing all code that gets pushed?

Yes, we have a rigorous code review process and no code goes live on the site unless it has been reviewed and approved by a skilled engineer.

What changes are you making to ensure that this does not happen again?

We cannot discuss specific improvements, but we take privacy and security very seriously and are continually improving our code standards, processes, and systems to help us build high quality products quickly.

When do you expect to conclude your investigation, because I will certainly be following up for the details about it?

As a general practice, we do not comment on investigations like this.

While interesting, none of this is particularly surprising. And because Facebook isn’t commenting on the outcome of the investigation, we’ll probably never find out what caused the bug (or if company protocol was even followed in this case).  But hey, at least they saythey’re doing the right things.

It’s worth pointing out that Facebook is by no means the only company affected by such issues.  Last year, I wrote a post called the Sorry State of Online Privacy, where I detailed some of the security lapses that had hit Facebook, Twitter, and Google (and of course there’s the recent Google Buzz fiasco). All of these companies would likely claim to have state of the art testing and security measures, yet such problems seem to pop up every few months.  I’m aware that it’s impossible to have a fully secure system, but that doesn’t mean engineering teams should be treating these problems as inevitabilities.  To reiterate what I wrote last year, the word ‘private’ should not mean “this will remain hidden until we accidentally break something”.

[via TechCrunch]

——————————–

Dear Google Apps admin,​

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology.  This includes faster JavaScript processing and new standards like HTML5.  As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 as well as other older browsers that are not supported by their own manufacturers.
We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010.  After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

Starting this week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser.  We will also alert you again closer to March 1 to remind you of this change.

In 2009, the Google Apps team delivered more than 100 improvements to enhance your product experience.  We are aiming to beat that in 2010 and continue to deliver the best and most innovative collaboration products for businesses.

Thank you for your continued support!

Sincerely,

The Google Apps team

Email preferences: You have received this mandatory email service announcement to update you about important changes to your Google Apps product or account.

Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043

——————————————————-

All the companies should follow Google’s lead ! NewsFlash: We as QA hate testing on IE6 ! People there is IE9 in the talks ! GET OVER IE 6 !

In designing Chromium, we’ve been working hard to make the browser as secure as possible. We’ve made strong improvements with the integrated sandboxing and our up-to-date user base. We’re always looking to stay on top of the latest browser security features. We’ve also worked closely with the broader security community to get independent scrutiny and to quickly fix bugs that have been reported.

Some of the most interesting security bugs we’ve fixed have been reported by researchers external to the Chromium project. For example, this same origin policy bypass from Isaac Dawson or this v8 engine bug found by the Mozilla Security Team. Thanks to the collaborative efforts of these people and others, Chromium security is stronger and our users are safer.

Today, we are introducing an experimental new incentive for external researchers to participate. We will be rewarding select interesting and original vulnerabilities reported to us by the security research community. For existing contributors to Chromium security — who would likely continue to contribute regardless — this may be seen as a token of our appreciation. In addition, we are hoping that the introduction of this program will encourage new individuals to participate in Chromium security. The more people involved in scrutinizing Chromium’s code and behavior, the more secure our millions of users will be.

Such a concept is not new; we’d like to give serious kudos to the folks at Mozilla for their long-running and successful vulnerability reward program.

Any bug filed through the Chromium bug tracker (under the template “Security Bug”) will qualify for consideration. As this is an experimental program, here are some guidelines in the form of questions and answers:

Q) What reward might I get?

A) As per Mozilla, our base reward for eligible bugs is $500. If the panel finds a particular bug particularly severe or particularly clever, we envisage rewards of $1337. The panel may also decide a single report actually constitutes multiple bugs. As a consumer of the Chromium open source project, Google will be sponsoring the rewards.

Q) What bugs are eligible?

A) Any security bug may be considered. We will typically focus on High and Critical impact bugs, but any clever vulnerability at any severity might get a reward. Obviously, your bug won’t be eligible if you worked on the code or review in the area in question.

Q) How do I find out my bug was eligible?

A) You will see a provisional comment to that effect in the bug entry once we have triaged the bug.

Q) What if someone else also found the same bug?

A) Only the first report of a given issue that we were previously unaware of is eligible. In the event of a duplicate submission, the earliest filed bug report in the bug tracker is considered the first report.

Q) What about bugs present in Google Chrome but not the Chromium open source project?

A) Bugs in either build may be eligible. In addition, bugs in plugins that are part of the Chromium project and shipped with Google Chrome by default (e.g. Google Gears) may be eligible. Bugs in third-party plugins and extensions are ineligible.

Q) Will bugs disclosed publicly without giving Chromium developers an opportunity to fix them first still qualify?

A) We encourage responsible disclosure. Note that we believe responsible disclosure is a two-way street; it’s our job to fix serious bugs within a reasonable time frame.

Q) Do I still qualify if I disclose the problem publicly once fixed?

A) Yes, absolutely. We encourage open collaboration. We will also make sure to credit you in the relevant Google Chrome release notes and nominate you for the Google Security “thank you” section.

Q) What about bugs in channels other than Stable?

A) We are interested in bugs in the Stable, Beta and Dev channels. It’s best for everyone to find and fix bugs before they are released to the Stable channel.

Q) What about bugs in third-party components?

A) These bugs may be eligible (e.g. WebKit, libxml, image libraries, compression libraries, etc). Bugs will be ineligible if they are part of the base operating system as opposed to part of the Chromium source tree. In the event of bugs in a component shared with other software, we are happy to take care of responsibly notifying other affected parties.

Q) Who determines whether a given bug is eligible?

A) The panel includes Adam Barth, Chris Evans, Neel Mehta, SkyLined and Michal Zalewski.

Q) Can you keep my identity confidential from the rest of the world?

A) Yes. If selected as the recipient of a reward, and you accept, we will need your contact details in order to pay you. However — at your discretion, we can credit the bug to “anonymous” and leave the bug entry private.

Q) No doubt you wanted to make some legal points?

A) Sure. We encourage participation from everyone. However, we are unable to issue rewards to residents of countries where the US has imposed the highest levels of export restriction (e.g. Cuba, Iran, North Korea, Sudan and Syria). We cannot issue rewards to minors, but would be happy to have an adult represent you. This is not a competition, but rather an ongoing reward program. You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon local law.

We look forward very much to issuing our first reward and featuring it on our releases blog. We’re happy to take questions at security@chromium.org. Alternatively, feel free to leave a comment. We will update this blog post with answers to any popular questions.

Finally, if you’re interested in helping out Chromium security on a more permanent basis, we have open positions.

Posted by Chris Evans, Google Chrome Security

The Reconnect feature is an extension of the site’s Suggestion service, which appears on the right hand side of the page, reminding users to get in touch with contacts possibly needing help on Facebook.

However, there still might be some bugs that have to be ironed out in Facebook’s “Reconnect.” The new tool took reconnecting to a whole new level when it offered users a way to stay in touch with exes, current spouses and deceased Facebook contacts with existing profile pages.

Meanwhile, Facebook maintains that the option to use Reconnect to stay in touch with dead people was deliberate. The social networking giant maintained in a company blog post that members could use the Reconnect feature to memorialize loved ones whose profiles remained intact by posting remembrances on their Wall.

“We understand how difficult it can be for people to be reminded of those who are no longer with them, which is why it’s important when someone passes away that their friends or family contact Facebook to request that a profile be memorialized,” said Max Kelly, Facebook chief security officer.

Kelly used a personal example of a good friend who was killed in a bicycle accident to illustrate the necessity for memorializing user’s profiles on Facebook.

“As time passes, the sting of losing someone you care about also fades but it never goes away. I still visit my friend’s memorialized profile to remember the good times we had and share them with our mutual friends,” he said.

Kelly said that the profiles of the deceased no longer appear in the Suggestions box once family members decide to memorialize their profile, and also mentioned that the site would remove sensitive information, and prevents users from logging into it in the future, while enabling family and friends to post on the user’s Wall in remembrance.

The blog post elicited numerous comments, some critical, others in praise, of Facebook’s effort to reconnect family and friends with their deceased loved ones.

However, one Facebook user asked an obvious question. “There are 540 comments so far—I’ve not read all of them to see if it has been asked yet, but I don’t understand why everyone isn’t asking this,” said Don Orkoskey. “What if the person isn’t really dead? What if a friend (or non-friend) is playing a sick joke?”

1. Mac OS X – Lord of the Rings and This Day in History

In Mac OS X, there are numerous Easter eggs and the best of them all are the Lord of the Rings timeline and another is the important events on this day calendar.

To access the LOTR egg :

Goto Applications –> Utilities –> Open Terminal. Type in “grep LOTR /usr/share/calendar/calendar.history”  (without the quotes)

To access the This Day in History egg, type in this in Terminal  ”cat /usr/share/calendar/calendar.history”

2. Hall of Tortured Souls – Excel 95

• Create a new worksheet
• Select the 95th Row and then Tab to Column B
• Goto Help –> About
• Hold down Ctrl + Alt + Shift and select “Tech Support“
• The “Hall of Tortured Souls” opens up
• The wall at the end of the hall has the programmer’s names.
• Do a U-turn and type “excelkfa” and then you’ll be able to cross the wall and see their pictures as well

3. Adobe Photoshop Hidden “About” – Red Pill, Cat & Stonehenge

In almost all versions of Photoshop, there is a hidden about screen. Hold down the “Ctrl” key and goto Help –> About Photoshop. The hidden about screen in CS3 and CS4.

There is also a hidden cat in the red pill. Zoomed in and clearer version :

4. The utorrent Tetris

5. The Book of Mozilla

6. The Google Earth Flight Simulator

Google Earth has a built in Flight Simulator which lets you fly either a F-16 or a SR22 (not the SR71) from any airport of your choice. Make sure you have Google Earth 4.2 or newer. In the application, click on the globe and enter Ctrl + Shift + A or Tools –> Flight Simulator (this option came in later versions. In earlier versions, it remained an easter egg).

Google has now provided a guide to using the simulator alongwith the controls. Follow this link.

7. Picasa Teddy Bear

10. Honourable Mentions

Not everybody could make it to the top 10, but some deserve due credit for their ingenuity and their jokes

Excel 97 – Flight Simulator

• Create a new blank document
• Press F5
• Type in X97:L97 and press ENTER
• Press TAB to switch to the cell M97
• Click on the chart wizard button while holding down Control and Shift keys
• Use mouse to fly around – Right button forward/ Left button reverse

Word 97 – Pinball

• Create a new document
• Type “Blue”  - with a capital B
• Select word and choose Font Style as Bold and set the color to Blue
• Type ” ” (space) after word “Blue”
• Go to Help -> About
• Hold down Ctrl + Shift and then left click the Word icon and voila Pinball !
• Use Z for left flipper, M for right flipper, and ESC to exit

Credits in Windows 95 and Windows 98

In Windows 95, right Click on the Desktop.

• Select New… then Folder to create a new folder.
• Name the folder “and now, the moment you’ve all been waiting for”
• Then right Click on the folder and rename it to “we proudly present for your viewing pleasure”.
• For the third time, rename it again to “The Microsoft Windows 95 Product Team!”
• Open the folder and the Windows 95 credits will be displayed

In Windows 98, go to C:\Windows\Application Data\Microsoft\WELCOME

• Create a Shortcut for the file Weldata.exe by right clicking on the file and selecting “Create Shortcut”
• Right click on the shortcut and select “Properties”
• Add the following at the end of the target  : “You_are_a_real_rascal”
• Now in the “Run” combobox select “Minimized”
• Click OK and double click the shortcut

NASA reported 1,120 security incidents that have resulted in the installation of malicious software on its systems and unauthorized access to sensitive information in fiscal years 2007 and 2008, according to a report issued Thursday by the Government Accountability Office. And, the GAO reports, National Aeronautics and Space Administration systems remain vulnerable despite the establishment of a security operation center last year to deter such incidents.

“The control vulnerabilities and program shortfalls, which GAO identified, collectively increase the risk of unauthorized access to NASA’s sensitive information, as well as inadvertent or deliberate disruption of its system operations and services,” wrote Gregory Wilshusen, GAO’s information security issues director, in a report cosigned by GAO Chief Technologist Nabajyoti Barkakati. “They make it possible for intruders, as well as government and contractor employees, to bypass or disable computer access controls and undertake a wide variety of inappropriate or malicious acts. As a result, increased and unnecessary risk exists that sensitive information is subject to unauthorized disclosure, modification, and destruction and that mission operations could be disrupted.”

GAO cited a NASA report that said the number of malicious code attacks – 839 – was the highest experienced by any of the federal agencies, which accounted for more than one-quarter of the total number of malicious code attacks directed at federal agencies in 2007 and 2008. GAO cited an official at the U.S.-CERT as saying NASA’s high profile makes the agency an attractive target for hackers seeking recognition, or for nation-state sponsored cyber spying.

Reacting to GAO’s findings, House Science and Technology Committee Chairman Bart Gordon, D.-Tenn., sees NASA’s IT vulnerability woes as being emblematic of the cybersecurity problems federal agencies face, despite the passage of a dozen major IT security laws in as many years, the increased attention given by the Clinton and Bush administrations on cybersecurity and $7 billions in annual spending to safeguard IT systems. “Regulation and legislation alone will not suffice,” Gordon said in a statement. “Agencies and departments must follow through with corrective actions to mitigate identified vulnerabilities. GAO has performed an invaluable service to NASA by identifying weaknesses and recommending needed improvements.”

Congressional investigators offered a number of security incidents to illustrate NASA’s IT system vulnerabilities, including some this year in which the space agency reported unauthorized access to sensitive data. According to GAO:

One center reported the theft of a laptop containing data subject to International Traffic in Arms Regulations. Stolen data included roughly 3,000 files of unencrypted International Traffic in Arms Regulations data with information for Hypersonic Wind Tunnel testing for the X-51 scramjet project and possibly personally identifiable information. Another center reported the theft of a laptop containing thermal models, review documentation, test plans, test reports, and requirements documents pertaining to NASA’s Lunar Reconnaissance Orbiter and James Webb Space Telescope projects. The incident report does not indicate whether this lost data was unencrypted or encrypted or how the incident was resolved.

“Significantly,” GAO said, “these were not isolated incidents, since NASA reported 209 incidents of unauthorized access to U.S.-CERT during fiscal years 2007 and 2008.”

Here’s another intrusion, according to the GAO report:

One center was alerted by the NASA SOC (security operations center) in February 2009 about traffic associated with a Seneka Rootkit Bot. In this case, NASA found that 82 NASA devices had been communicating with a malicious server since January 2009. A review of the data revealed that most of these devices were communicating with a server in the Ukraine. By March 2009, three centers were also infected with the bot attack.

And another:

In October 2007, a total of 86 incidents related to the Zonebac Trojan were reported by NASA centers. This particular form of malware is capable of disabling security software and downloading and running other malicious software at the whim of the attacker. U.S.-CERT reported in January 2008 on NASA’s ongoing problems with Zonebac and other malware infestations and recommended that the agency employ consistent patching and user education practices to prevent such infections from occurring.

“These attacks can result in damage to applications, data, or operating systems; disclosure of sensitive information; propagation of malware; use of affected systems as bots; an unavailability of systems and services; and a waste of time, money, and labor,” GAO said.

Microsoft released a record number of 13 bulletins for 34 vulnerabilities on Patch Tuesday–and the first critical update for Windows 7–as well as fixes for zero-day flaws involving Server Message Block (SMB) and Internet Information Services (IIS).

The most severe of the three SMB flaws, which were first reported last month, could allow an attacker to take control of a computer remotely by sending a specially crafted SMB packet to a computer running the Server service. Exploit code for one of the SMB holes has been posted to the Web, Microsoft said.

Windows 7 is affected by two critical patches intended to mend vulnerabilities that could allow remote code execution if a malicious Web page were viewed, one part of a cumulative security update for Internet Explorer and the other in .Net Framework and Silverlight.

The official release date for Windows 7 is October 22, but the new operating system has been available to some large businesses with volume licenses since the summer. The code was finalized in July.

Other critical patches in the security bulletin for October fix a vulnerability in Windows Media Runtime that could be exploited if a user opened a malicious media file or received malicious streaming content from a Web site or application, and if a specially crafted ASF (Advanced Systems Format) file is played using Windows Media Player 6.4.

Among the critical updates: a cumulative security update of ActiveX Kill Bits that is being exploited and that affects ActiveX controls compiled using Active Template Library (ATL); and another patch resolving several vulnerabilities in ATL ActiveX Controls that could allow remote code execution if a user loaded a malicious component or control. ActiveX and ATLs were the subject of an emergency patch Microsoft released in July.

The final critical bulletin fixes a hole in Windows GDI+ (Graphics Device Interface) that could allow an attacker to take control of a computer if the user viewed a malicious image file using affected software or browsed a malicious Web page.

“Microsoft has repeatedly had to fix problems related to the Graphics Device Interface in Windows, and vulnerabilities in the component have been exploited broadly in the past. We can expect that security researchers will be looking to reverse-engineer today’s patches, which may very well lead to exploits being created,” said Dave Marcus, director of security research and communications at McAfee Labs.

Nine of the vulnerabilities were previously disclosed, which meant that attackers had time to come up with so-called “zero-day” exploits before the patches were available, Marcus noted.

The most alarming vulnerability in the mix is the SMB flaw, which was introduced by the patch for a different vulnerability, according to Josh Phillips, virus researcher at Kaspersky Lab.

Andrew Storms, director of security operations at nCircle, said the bug that is likely to have the biggest impact will be the critical one that affects Windows Media Runtime and involves a speech codec bug that has limited exploits in the wild. “This is a typical file-parsing issue and similar to vulnerabilities that have allowed attackers to create drive-by attacks that infect unsuspecting video viewers,” he said.

Meanwhile, the critical SMB vulnerability is relatively difficult to exploit given default firewall conditions, but the IIS bugs are easy to exploit, Storms added.

“The sheer volume of the bulletins and patches is extreme,” said Jason Miller, senior data team leader for Shavlik Technologies. “This is really going to affect administrators. It’s going to be very challenging because of the time and research that’s going to be needed” to patch systems.

Also released were five bulletins rated “important” to fix vulnerabilities in IIS, for which exploit code has been publicly released and for which there have been limited attacks, along with Windows CryptoAPI, Windows Indexing Service, Windows Kernel, and Local Security Authority Subsystem Service.

The update for Windows CryptoAPI relates to flaws in the way domain names are verified on the Internet, which could allow attackers to impersonate a site and steal information from unsuspecting Web surfers. The holes were revealed by researchers Dan Kaminsky and Moxie Marlinspike at Defcon in August.

Affected software includes Windows 7; Windows 2000; Windows XP; Windows Vista; Server 2003 and 2008; Office XP, 2003, and 2007; Microsoft Office System; SQL Server 2000 and 2005; Silverlight; Visual Studio .Net 2003; Visual Studio 2005 and 2008; Visual FoxPro 8.0 and 9.0; Microsoft Report Viewer 2005 and 2008; Forefront Client Security 1.0; and Office software including Visio, Project, Word Viewer, and Works.

The installation also removes the Win/FakeScanti Trojan, which displays fake malware warnings and then asks computer users to pay for fake antivirus software.