I’ve come the conclusion, that the writer’s for main stream technical publications; are just as over-the-top, as any other journalist.

Very recently, some one discovered the Microsoft article, Strong passwords: How to create and use them, published 22 March, 2006. It’s 2 years old. The article as you can imagine is about creating strong passwords. About two-thirds down the page, you encounter this: The “blank password” option.

The author of the article goes on to say at this point, “A blank password (no password at all) on your account is more secure than a weak password such as “1234″.” Whoa, wait-a-minute, what the… Then he/she clarifies that statement, be explaining what he/she means.

What’s so special about a blank password? On a computer with Windows XP or newer installed, an account without a password cannot be accessed remotely by means such as a network or the Internet.

If the default settings have not been altered by the system user.

Under very specific conditions, and somewhat rare, the use of a blank password is just fine.

• You only have one computer or you have several computers but you do not need to access information on one computer from another one
• The computer is physically secure (you trust everyone who has physical access to the computer)

The second bullet is the most difficult condition to meet.

So, this passage of the MS article has been translated into “Blank Passwords Are More Secure” by the technical media. Have you lost your minds? Get real! The average non-technical reader is going to take that as gospel, and switch to using no password at all. Which, I have no doubt that many are doing so or using something like “password1″ or “1234″.

Now here comes my thoughts of the subject:

The sheer lunacy of even suggesting using a blank password for local log-on. That’s the first thing a hacker will try, when sitting in front of a terminal.

Forcing local log-in using a strong password is meant to prevent unauthorized access to the local system; and if the system is configured properly, you’ll be locked out after x number of failed attempts. Which, means reboot and start over. Brute force attacks aren’t effective when the system in configured correctly; and a hacker won’t spend that much time trying to get into the system.

If the system is connected to a network, then Network log-on should be required, and if that is configured properly; not only are you locked out of the system after x number of failed attempts, you are locked out of the network. Until the Network Administrator resets your account and issues you a new password.

There’s been a lot of articles talking about password strength, password security, password cracking of late. None of them, absolutely none of them, with the exception of the MS article, talk about the use of pass phrases of 15 character or greater in length. Why a pass phrase 15 characters or longer? They can not be broken by existing methods. They can be captured by keyloggers.

If your password is 15 characters or longer, Windows stores the constant AAD3B435B51404EEAAD3B435B51404EE as your LM hash, which is equivalent to a null password. And since your password is obviously not null, attempts to crack that hash will fail.

These articles also fail to point out that the hacker must have access, either remotely or locally, to crack a password. If they have access to the system, then they don’t need to crack the password. There are far more reliable (quicker) methods of compromising a system, Social Engineering attacks leading the way.

The rest of the Microsoft article, Strong passwords: How to create and use them, gives very sound advice on creating strong passwords. You should read it, following the advice given on that page will go a long ways to making your online experience a safer one.

Creating strong passwords and keeping them private, is just one piece of the security puzzle; a very critical piece, but still just one piece.

Products:
VMware ACE
VMware Player
VMware Workstation

Details:
Summary
On Windows hosts, if you have configured a VMware host-to-guest shared folder, it is possible for a program running in the guest to gain access to the host’s complete file system and create or modify executable files in sensitive locations.

Relevant Releases
Windows hosted versions of:

• VMware Workstation 6.0.2 and earlier
• VMware Workstation 5.5.4 and earlier
• VMware Player 2.0.2 and earlier
• VMware Player 1.0.4 and earlier
• VMware ACE 2.0.2 and earlier
• VMware ACE 1.0.2 and earlier

Note: The following VMware products are not affected:

• VMware Server is not affected because it does not use shared folders.
• No versions of ESX Server, including ESX Server 3i, are affected by this vulnerability. Because ESX Server is based on a bare-metal hypervisor architecture, not a hosted architecture, it does not include any shared folder abilities.
• VMware Fusion and Linux-hosted VMware products are unaffected.

Problem Description
The following description is from the Core Security Technologies advisory at http://www.coresecurity.com/?action=item&id=2129:
To improve user inter-operation with virtualized systems VMware’s software implements a number of inter-system communication features. The Shared Folder mechanism is one of such feature.

VMware’s shared folders allow users to transfer data between a virtualized system (Guest) and the non-virtualized Host system that contains it. This form of data transfer is available to users of the Guest system through read and write access to filesystem folders shared by both Guest and Host systems. To maintain effective isolation between Guest and Host systems, this mechanism should limit access from the Guest only to the Host system’s folders that are selected for sharing with the virtualized guests.

A vulnerability was found in VMware’s shared folders mechanism that grants users of a Guest system read and write access to any portion of the Host’s file system including the system folder and other security-sensitive files. Exploitation of this vulnerability allows attackers to break out of an isolated Guest system to compromise the underlying Host system that controls it.

Solution:
Response
By default, the shared folders feature is disabled in Workstation 6, Player 2, and ACE 2. In order to exploit this vulnerability, the virtual machine must have the shared folders feature manually enabled and at least one folder configured for sharing between the host and guest. Given the requirements of the vulnerability, it cannot be exploited by default in Workstation 6, Player 2, and ACE 2.

Workstation 5, Player 1, and ACE 1 enable the shared folders feature by default, but exploiting this vulnerability still requires at least one folder to be configured as shared between the host and guest. Given the requirements of the vulnerability, it cannot be exploited by default in Workstation 5, Player 1, and ACE 1.

The issue affects all currently supported Windows-hosted versions of VMware Workstation, ACE, and Player. The issue does not affect VMware ESX Server or VMware Desktop Infrastructure products. There have been no reports of this issue occurring in customer environments.
Workaround
Until VMware releases a patch to fix this issue, users of affected Windows-hosted VMware products should disable shared folders.

To disable shared folders in the Global settings:

1. From the VMware product’s menu, choose Edit > Preferences.
2. In the Workspace tab, under Virtual Machines, deselect the checkbox for Enable all shared folders by default.

To disable shared folders for the individual virtual machine settings:

1. From the VMware product’s menu, choose VM > Settings.
2. In the Options tab, select Shared Folders and Disable.

References

• http://www.coresecurity.com/?action=item&id=2129
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1744
• http://www.securityfocus.com/bid/27944
• http://www.vmware.com/security/alerts/

Note: Some links might not be available until 2/25/2008.

Product Versions:
VMware ACE 1.0.x
VMware ACE 2.0.x
VMware Player 1.0.x (Windows Hosts)
VMware Player 2.0.x (Windows Hosts)
VMware Workstation 5.0.x (Windows hosts)
VMware Workstation 5.5.x (Windows hosts)
VMware Workstation 6.0.x (Windows Hosts)

Check your security applications before installing

According to Microsoft certain security applications are blocked from running, knowledge base article, due to “reliability” issues with Vista SP1.

The following security applications are blocked from running, if installed, after install SP1 for Vista:
BitDefender AntiVirus or Internet Security 10
Jiangmin KV Antivirus 10
Trend Micro Internet Security 2008
Zone Alarm Security Suite 7.1.078

If you have any of the above applications installed, see the vendor for a supported version; before installing SP1 for Vista.

Secunia Advisory: SA29029

Some vulnerabilities have been reported in Opera, which can be exploited by malicious people to conduct cross-site scripting attacks, disclose sensitive information, or to bypass certain security restrictions.

1) A security issue is caused due to a design error when handling input to file form fields, which can potentially be exploited to trick a user into uploading arbitrary files.

2) An error within the handling of custom comments in image properties can be exploited to execute arbitrary script code in the wrong security context when comments of a malicious image are displayed.

3) An error in the handling of attribute values when importing XML into a document can be exploited to bypass filters and conduct cross-site scripting attacks if these values are used as document content.

The vulnerabilities are reported in versions prior to 9.26.

Solution:
Update to version 9.26.
http://www.opera.com/download/

Provided and/or discovered by:
The vendor credits:
1) Mozilla
2) Max Leonov
3) Arnaud

Original Advisory:
Opera:
http://www.opera.com/support/search/view/877/
http://www.opera.com/support/search/view/879/
http://www.opera.com/support/search/view/880/

Bugtraq ID: 27812
Class: Design Error
Remote: Yes
Local: No
Published: Feb 15 2008 12:00AM
Updated: Feb 15 2008 11:05PM
Credit: carl hardwick is credited with the discovery of this issue.

Mozilla Firefox is prone to a remote denial-of-service vulnerability because of the way the browser handles IFrames.

Attackers can exploit this issue to make the browser unresponsive and cause denial-of-service conditions.

Firefox 2.0.0.12 is vulnerable; other versions may also be affected.

Zonealarm have included a “ZoneAlarm Spy Blocker toolbar” in its latest update. However, this Toolbar is in fact the /Ask.com search engine toolbar and is being installed deceptively

read more | digg story

I am in complete agreement on this with Derek.  Malwareteks will no longer recommend, or offer ZoneAlarm for download and resale.

Firefox 2.0.0.11 fixed a bug introduced by the 2.0.0.10 update in the <canvas> feature that affected some web pages and extensions.

What’s New in Firefox 2.0.0.11
Release Date: November 30, 2007
Stability Update: This release corrects a compatibility issue with some websites and extensions discovered in Firefox 2.0.0.10.
Earlier Changes: For information about previous changes, please see the Firefox 2.0.0.10 Release Notes.
Firefox 2 Features: For an overview, please see Firefox 2 Features.

Press Release

‘Bot Roast II’ Nets 8 Individuals

Second Phase of Ongoing Cyber Investigation Reveals More Than $20 Million in Economic Loss and More Than One Million Victimized Computers. Public Urged To Take Precaution.

The FBI today announced the results of the second phase of its continuing investigation into a growing and serious problem involving criminal use of botnets. Since Operation ‘Bot Roast’ was announced last June, eight individuals have been indicted, pled guilty, or been sentenced for crimes related to botnet activity. Additionally, 13 search warrants were served in the U.S. and by overseas law enforcement partners in connection with this operation. This ongoing investigative effort has thus far uncovered more than $20 million in economic loss and more than one million victim computers.

FBI Director Robert S. Mueller, III said, “Today, botnets are the weapon of choice of cyber criminals. They seek to conceal their criminal activities by using third party computers as vehicles for their crimes. In Bot Roast II, we see the diverse and complex nature of crimes that are being committed through the use of botnets. Despite this enormous challenge, we will continue to be aggressive in finding those responsible for attempting to exploit unknowing Internet users.”

A botnet is a collection of compromised computers under the remote command and control of a criminal “botherder.” A botherder can gain control of these computers by unleashing malicious software such as viruses, worms, or trojan horses. By executing a simple task such as opening an attachment, clicking on an advertisement, or providing personal information to a phishing site (a fraudulent site that mimics a legitimate site), an individual computer user has unintentionally allowed unauthorized access. Bot operators will then typically use these compromised computers as vehicles to facilitate other actions such as commit identity theft, launch denial of service attacks, and install keystroke loggers.

FBI offices participating in Bot Roast II included Cincinnati, Detroit, Jacksonville, Los Angeles, Philadelphia, Sacramento, and Washington, D.C. As happens most often with complex cyber investigations, there was valuable intelligence sharing amongst law enforcement agencies that led to the success of Bot Roast II. Exchange of information between the U.S. Secret Service, the New Zealand Police, and the FBI led to the initiation and enhancement of additional botnet investigations. In one example, authorities in New Zealand, working in collaboration with the FBI Philadelphia Office, conducted a search this week at the residence of an individual who goes by the cyber ID of AKILL. AKILL is believed to be the ringleader of an elite international botnet coding group that is responsible for infecting more than one million computers.

The individuals identified as part of Bot Roast II are as follows:

1. Ryan Brett Goldstein, 21, of Ambler, Pennsylvania, was indicted on 11/01/07 by a federal grand jury in the Eastern District of Pennsylvania for botnet related activity which caused a distributed denial of service (DDoS) attack at a major Philadelphia area university. In the midst of this investigation the FBI was able to neutralize a vast portion of the criminal botnet by disrupting the botnet’s ability to communicate with other botnets. In doing so, it reduced the risk for infected computers to facilitate further criminal activity. This investigation continues as more individuals are being sought.

2. Adam Sweaney, 27, of Tacoma, Washington, pled guilty on September 24, 2007 in U.S. District Court, District of Columbia, to a one count felony violation for conspiracy fraud and related activity in connection with computers. He conspired with others to send tens of thousands of email messages during a one-year period. In addition, Sweaney surreptitiously gained control of hundreds of thousands of bot controlled computers. Sweaney would then lease the capabilities of the compromised computers to others who launched spam and DDoS attacks.

3. Robert Matthew Bentley of Panama City, Florida, was indicted on 11/27/07 by a federal grand jury in the Northern District of Florida for his involvement in botnet related activity involving coding and adware schemes. This investigation is being conducted by the U.S. Secret Service.

4. Alexander Dmitriyevich Paskalov, 38, multiple U.S. addresses, was sentenced on 10/12/2007 in U.S. District Court, Northern District of Florida, and received 42 months in prison for his participation in a significant and complex phishing scheme that targeted a major financial institution in the Midwest and resulted in multi-million dollar losses.

5. Azizbek Takhirovich Mamadjanov, 21, residing in Florida, was sentenced in June 2007 in U.S. District Court, Northern District of Florida, to 24 months in prison for his part in the same Midwest bank phishing scheme as Paskalov. Paskalov established a bogus company and then opened accounts in the names of the bogus company. The phishing scheme in which Paskolov and Mamadjanov participated targeted other businesses and electronically transferred substantial sums of money into their bogus business accounts. Immigrations Customs Enforcement, Florida Department of Law Enforcement, and the Panama City Beach Police Department were active partners in this investigation.

6. John Schiefer, 26, of Los Angeles, California, agreed to plead guilty on 11/8/2007 in U.S. District Court in the Central District of California, to a four felony count criminal information. A well-known member of the botnet underground, Schiefer used malicious software to intercept Internet communications, steal usernames and passwords, and defraud legitimate businesses. Schiefer transferred compromised communications and usernames and passwords and also used them to fraudulently purchase goods for himself. This case was the first time in the U.S. that someone has been charged under the federal wiretap statute for conduct related to botnets.

7. Gregory King, 21, of Fairfield, California, was indicted on 9/27/2007 by a federal grand jury in the Central District of California on four counts of transmission of code to cause damage to a protected computer. King allegedly conducted DDoS attacks against various companies including a web based company designed to combat phishing and malware.

8. Jason Michael Downey, 24, of Dry Ridge, Kentucky, was sentenced on 10/23/2007 in U.S. District Court, Eastern District of Michigan, to 12 months in prison followed by probation, restitution, and community service for operating a large botnet that conducted numerous DDoS attacks that resulted in substantial damages. Downey operated Internet Relay Chat (IRC) network Rizon. Downey stated that most of the attacks he committed were on other IRC networks or on the people that operated them. Downey’s targets of DDoS often resided on shared servers which contained other customer’s data. As a result of DDoS to his target, innocent customers residing on the same physical server also fell victim to his attacks. One victim confirmed financial damages of $19,500 as a result of the DDoS attacks.

FBI Assistant Director James E. Finch, Cyber Division, said, “The public is reminded once again that they can play a part in thwarting botnet activity. Practicing strong computer security habits such as updating anti-virus software, installing a firewall, using strong passwords, and employing good e-mail and web security practices are as basic as putting locks on your doors and windows. Without employing these safeguards, botnets, along with criminal and possibly terrorist activities, will continue to flourish.”

It should be noted that the FBI does not contact the public online with requests for personal information. Computer users are urged to be wary of fraud schemes that request this type of information, especially via unsolicited emails. To report fraudulent activity or financial scams, contact either the local police or your local FBI field office as well as file an online complaint with the FBI’s Internet Crime Complaint Center (IC3) at www.ic3.gov.

For more information on botnets and tips for cyber crime prevention, the public is encouraged to visit the following online resources:

• www.fbi.gov

• www.onguardonline.gov

• www.lookstoogoodtobetrue.com

• www.uscert.gov

• www.ic3.gov

Firefox 2.0.0.10 has been released to fix multiple vulnerabilities in the popular open source web browser.

What’s New in Firefox 2.0.0.10
Release Date: November 26, 2007
Security Update: The following security issues were fixed.
MFSA 2007-39 Referer-spoofing via window.location race condition
MFSA 2007-38 Memory corruption vulnerabilities (rv:1.8.1.10)
MFSA 2007-37 jar: URI scheme XSS hazard

Earlier Changes: For information about previous changes, please see the Firefox 2.0.0.9 Release Notes.
Firefox 2 Features: For an overview, please see Firefox 2 Features.

Secunia Advisory: SA27725 Mozilla Firefox Multiple Vulnerabilities

Firefox users should immediately upgrade to 2.0.0.10.

FixIEDef can now be found on it’s very own web page at the MalwareTeks main site: http://www.malwareteks.com/FixIEDef.php

This is the official web page for FixIEDef, and this page may not be mirrored.