Don't squid me, bro.
Don't squid me, bro.
Selling fear:
The Vivos network, which offers partial ownerships similar to a timeshare in underground shelter communities, is one of several ventures touting escape from a surface-level calamity.Radius Engineering in Terrell, Texas, has built underground shelters for more than three decades, and business has never been better, says Walton McCarthy, company president.
The company sells fiberglass shelters that can accommodate 10 to 2,000 adults to live underground for one to five years with power, food, water and filtered air, McCarthy says.
The shelters range from $400,000 to a $41 million facility Radius built and installed underground that is suitable for 750 people, McCarthy says. He declined to disclose the client or location of the shelter.
"We've doubled sales every year for five years," he says.Other shelter manufacturers include Hardened Structures of Colorado and Utah Shelter Systems, which also report increased sales.
[...]
The Vivos website features a clock counting down to Dec. 21, 2012, the date when the ancient Mayan "Long Count" calendar marks the end of a 5,126-year era, at which time some people expect an unknown apocalypse.
Vicino, whose terravivos.com website lists 11 global catastrophes ranging from nuclear war to solar flares to comets, bristles at the notion he's profiting from people's fears.
"You don't think of the person who sells you a fire extinguisher as taking advantage of your fear," he says. "The fact that you may never use that fire extinguisher doesn't make it a waste or bad.
"We're not creating the fear; the fear is already out there. We're creating a solution.
Yip Harburg commented on the subject about half a century ago, and the Chad Mitchell Trio recited it. It's at about 0:40 on the recording, though the rest is worth listening to as well.
Hammacher Schlemmer is selling a shelter,
worthy of Kubla Khan's Xanadu dome;
Plushy and swanky, with posh hanky panky
that affluent Yankees can really call home.
Hammacher Schlemmer is selling a shelter,
a push-button palace, fluorescent repose;
Electric devices for facing a crisis
with frozen fruit ices and cinema shows.
Hammacher Schlemmer is selling a shelter
all chromium kitchens and rubber-tiled dorms;
With waterproof portals to echo the chortles
of weatherproof mortals in hydrogen storms.
What a great come-to-glory emporium!
To enjoy a deluxe moratorium,
Where nuclear heat can beguile the elite
in a creme-de-la-creme crematorium.
Hacking ATMs to spit out money, demonstrated at the Black Hat conference:
The two systems he hacked on stage were made by Triton and Tranax. The Tranax hack was conducted using an authentication bypass vulnerability that Jack found in the system's remote monitoring feature, which can be accessed over the Internet or dial-up, depending on how the owner configured the machine.Tranax's remote monitoring system is turned on by default, but Jack said the company has since begun advising customers to protect themselves from the attack by disabling the remote system.
To conduct the remote hack, an attacker would need to know an ATM's Internet IP address or phone number. Jack said he believes about 95 percent of retail ATMs are on dial-up; a hacker could war dial for ATMs connected to telephone modems, and identify them by the cash machine's proprietary protocol.
The Triton attack was made possible by a security flaw that allowed unauthorized programs to execute on the system. The company distributed a patch last November so that only digitally signed code can run on them.
Both the Triton and Tranax ATMs run on Windows CE.
Using a remote attack tool, dubbed Dillinger, Jack was able to exploit the authentication bypass vulnerability in Tranax's remote monitoring feature and upload software or overwrite the entire firmware on the system. With that capability, he installed a malicious program he wrote, called Scrooge.
EDITED TO ADD (7/30): Another two articles.
"Who controls the off switch?" by Ross Anderson and Shailendra Fuloria.
Abstract: We're about to acquire a significant new cybervulnerability. The world's energy utilities are starting to install hundreds of millions of 'smart meters' which contain a remote off switch. Its main purpose is to ensure that customers who default on their payments can be switched remotely to a prepay tariff; secondary purposes include supporting interruptible tariffs and implementing rolling power cuts at times of supply shortage.The off switch creates information security problems of a kind, and on a scale, that the energy companies have not had to face before. From the viewpoint of a cyber attacker -- whether a hostile government agency, a terrorist organisation or even a militant environmental group -- the ideal attack on a target country is to interrupt its citizens' electricity supply. This is the cyber equivalent of a nuclear strike; when electricity stops, then pretty soon everything else does too. Until now, the only plausible ways to do that involved attacks on critical generation, transmission and distribution assets, which are increasingly well defended.
Smart meters change the game. The combination of commands that will cause meters to interrupt the supply, of applets and software upgrades that run in the meters, and of cryptographic keys that are used to authenticate these commands and software changes, create a new strategic vulnerability, which we discuss in this paper.
The two have another paper on the economics of smart meters. Blog post here.
The DNSSEC root key has been divided among seven people:
Part of ICANN's security scheme is the Domain Name System Security, a security protocol that ensures Web sites are registered and "signed" (this is the security measure built into the Web that ensures when you go to a URL you arrive at a real site and not an identical pirate site). Most major servers are a part of DNSSEC, as it's known, and during a major international attack, the system might sever connections between important servers to contain the damage.A minimum of five of the seven keyholders -- one each from Britain, the U.S., Burkina Faso, Trinidad and Tobago, Canada, China, and the Czech Republic -- would have to converge at a U.S. base with their keys to restart the system and connect everything once again.
That's a secret sharing scheme they're using, most likely Shamir's Secret Sharing.
We know the names of some of them.
Paul Kane -- who lives in the Bradford-on-Avon area -- has been chosen to look after one of seven keys, which will 'restart the world wide web' in the event of a catastrophic event.
Dan Kaminsky is another.
I don't know how they picked those countries.
Okay, this is just weird:
Mark S. Price, a specialist in public security, and his privately held company, Paradise Lost Antiterrorism Network of America (www.plan-a.us), have recently applied to the United States Patent and Trademark Office for a Utility Patent on their Suicide Bomb Deterrent, a security device designed, manufactured and distributed by PLAN-A. This device has been designed to warn and deter potential fanatical religious suicide bomb-wielding terrorists from otherwise detonating an explosive charge within close proximity of said device, to the intended end of successfully accomplishing its namesake purpose of Suicide Bomb Deterrent and the protecting and preserving of all life and property otherwise in mortal and destructive danger.
Reading the partial patent application on their minimal website, it appears to be a packet of pork product, combined with a big sign saying something like: "Warning. If you blow up a bomb right here, you'll get pork stuff all over you before you die -- which might be suboptimal from a religious point of view."
This appears to not be a joke.
It's a service:
The mechanism used involves captured network traffic, which is uploaded to the WPA Cracker service and subjected to an intensive brute force cracking effort. As advertised on the site, what would be a five-day task on a dual-core PC is reduced to a job of about twenty minutes on average. For the more ?premium? price of $35, you can get the job done in about half the time. Because it is a dictionary attack using a predefined 135-million-word list, there is no guarantee that you will crack the WPA key, but such an extensive dictionary attack should be sufficient for any but the most specialized penetration testing purposes.[...]
It gets even better. If you try the standard 135-million-word dictionary and do not crack the WPA encryption on your target network, there is an extended dictionary that contains an additional 284 million words. In short, serious brute force wireless network encryption cracking has become a retail commodity.
FAQ here.
In related news, there might be a man-in-the-middle attack possible against the WPA2 protocol. Man-in-the-middle attacks are potentially serious, but it depends on the details -- and they're not available yet.
Dozens of wallpaper apps being sold for Google Android devices have been found to be gathering personal information and sending it back to the apps' developers.......
The White House is seeking to add language to a list of items the FBI can demand without a judge's approval.......
A second Lower Merion (Pennsylvania) High School student has filed a lawsuit against the school district, its board of directors, the superintendent and two school employees alleging a civil rights violation for the misuse of a laptop computer theft tracking program.......
The UK Information Commissioner's Office (ICO) has examined some of the data Google collected while gathering information from unsecured Wi-Fi networks for its Street View feature and concluded that Google did not collect "meaningful personal details.......
According to Verizon's Data Breach Investigation Report from the Verizon Business RISK Team, 70 percent of breaches were committed by outsiders.......
Slovenian police have arrested a 23-year-old man in connection with the Mariposa botnet.......
A presentation at the Black Hat Conference in Las Vegas described the activity of a group of Russian cyber criminals involved in a counterfeit check scheme.......
Apple issued updates for Safari 4 and 5 just one day before a scheduled presentation on one of the flaws at the Black Hat conference.......
The man who wrote a web crawler that collected data of more than 100 million Facebook users says he did it as part of his work on a security tool.......
The personal information of as many as 230,000 New Zealanders, including a handful of celebrities, has been compromised following the theft of information from the database of a popular pizza chain.......
A lawsuit filed in federal court on Tuesday, July 27, 2010 alleges that a number of popular websites violated federal law by using Adobe Flash storage to recreate cookies that users had deleted.......
Category: Widely Deployed Software
Affected:
Category: Widely Deployed Software
Affected:
Category: Widely Deployed Software
Affected:
CVEs: CVE: CVE-2010-2703, CVE-2010-2704
Platform: Cross Platform
CVEs: CVE: CVE-2009-4896
Platform: Cross Platform
CVEs: CVE: CVE-2010-1214
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: CVE-2010-0654, CVE-2010-1205, CVE-2010-1207,CVE-2010-1210, CVE-2010-1211, CVE-2010-1212, CVE-2010-1213,CVE-2010-1215, CVE-2010-2751, CVE-2010-2752, CVE-2010-2753,CVE-2010-2754
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: CVE-2010-2528
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: CVE-2008-3279
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: CVE-2010-1965
Platform: Cross Platform
CVEs: CVE: CVE-2009-4404
Platform: Cross Platform
CVEs: CVE: CVE-2010-1870
Platform: Cross Platform
CVEs: CVE: CVE-2010-2529
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: CVE-2010-2755
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: CVE-2010-1452
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: CVE-2010-0126, CVE-2010-0133, CVE-2010-0134,CVE-2010-0135, CVE-2010-0131, CVE-2010-1524, CVE-2010-1525
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Cross Platform
CVEs: CVE: CVE-2010-2531, CVE-2010-2484
Platform: Cross Platform
CVEs: CVE: CVE-2010-1871
Platform: Cross Platform
CVEs: CVE: CVE-2010-090010.2.0.4, and
Platform: Cross Platform
CVEs: CVE: Not Available
Platform: Linux
CVEs: CVE: CVE-2010-2524
Platform: Linux
CVEs: CVE: CVE-2010-2237, CVE-2010-2238, CVE-2010-2239,CVE-2010-2242
Platform: Linux
CVEs: CVE: CVE-2010-1794
Platform: Mac Os
CVEs: CVE: Not Available
Platform: Other Microsoft Products
CVEs: CVE: Not Available
Platform: Other Microsoft Products
CVEs: CVE: Not Available
Platform: Other Microsoft Products
CVEs: CVE: CVE-2010-2374
Platform: Solaris
CVEs: CVE: Not Available
Platform: Third Party Windows Apps
CVEs: CVE: Not Available
Platform: Third Party Windows Apps
CVEs: CVE: Not Available15.0.0.357 is affected.
Platform: Third Party Windows Apps
CVEs: CVE: CVE-2010-1966
Platform: Third Party Windows Apps
CVEs: CVE: CVE-2010-1967, CVE-2010-1968
Platform: Third Party Windows Apps
CVEs: CVE: Not Available
Platform: Unix
CVEs: CVE: CVE-2009-4050
Platform: Web Application
CVEs: CVE: Not Available
Platform: Web Application
CVEs: CVE: Not Available
Platform: Web Application
CVEs: CVE: Not Available
Platform: Web Application
CVEs: CVE: Not Available
Platform: Web Application
CVEs: CVE: Not Available
Platform: Web Application
CVEs: CVE: Not Available
Platform: Web Application
CVEs: CVE: Not Available
Platform: Web Application
CVEs: CVE: Not Available
Platform: Web Application
CVEs: CVE: Not Available
Platform: Web Application
CVEs: CVE: CVE-2009-4038
Platform: Web Application - Cross Site Scripting
CVEs: CVE: CVE-2009-4039
Platform: Web Application - Cross Site Scripting
CVEs: CVE: Not Available
Platform: Web Application - Cross Site Scripting
CVEs: CVE: CVE-2010-1969
Platform: Web Application - Cross Site Scripting
CVEs: CVE: Not Available
Platform: Web Application - Cross Site Scripting
CVEs: CVE: Not Available
Platform: Web Application - Cross Site Scripting
CVEs: CVE: Not Available
Platform: Web Application - Cross Site Scripting
CVEs: CVE: CVE-2009-4464
Platform: Web Application - Cross Site Scripting
CVEs: CVE: CVE-2010-2854
Platform: Web Application - Cross Site Scripting
CVEs: CVE: CVE-2009-4037, CVE-2009-4045
Platform: Web Application - SQL Injection
CVEs: CVE: Not Available
Platform: Web Application - SQL Injection
CVEs: CVE: Not Available
Platform: Web Application - SQL Injection
CVEs: CVE: Not Available
Platform: Web Application - SQL Injection
CVEs: CVE: Not Available
Platform: Web Application - SQL Injection
CVEs: CVE: Not Available
Platform: Web Application - SQL Injection
A new JavaScript engine, HTML5, tabs on top, and a new add-on framework are not the only improvements that users can expect in Firefox 4. At Black Hat on Wednesday, a trio of security representatives from Mozilla detailed how the company plans to push the browser to be more secure for users while nudging developers toward safer coding practices.
One of the biggest fixes that's been implemented in the Firefox 4 beta (Windows | Mac | Linux) repairs a hole that affects all browsers, a decade-old vulnerability that was mentioned in the documentation for CSS2. The exploit is a CSS sniffing history attack, where malicious code can gain access to your browser history by manipulating link appearance and style. What made the bug so difficult to repair is that the simplest solution, to prevent all link style manipulation, would be like throwing the baby out with the bathwater, said Firefox's director of development, Jonathan Nightingale. Changing an already-visited link's colors is one the most-used features of the Web, and it would be catastrophic to prevent that.
Mozilla's David Baron figured out how to solve the problem with a three-pronged approach that focuses on the user instead of the Web site. His solution limits what aspect of links can be tweaked to color, then "lies" through JavaScript so that although the page queries the link and reports back what it would look like if it was unvisited, the one that Mozilla's engine draws is the correct one, whether it's been visited or not. This solution also limits the amount of computation that the rendering engine needs to do, said Nightingale, which allows the focus to remain on the content and reduces the overall "heavy lifting" required to render it properly. "By limiting the link, there's fewer options for [link exploits that look like] dancing bananas."
Nightingale added that Wednesday's release of Safari 5.0.1 has incorporated the fix.
Another type of bug addressed in the Firefox 4 beta is an XSS primary scripting exploit. [...]
Other changes in Firefox 4 promise to be less technical. Firefox's approach to browser updates is changing, and sounds like in some cases it will more closely resemble Google Chrome's automatic updates. "There are updates that we want you to know about, and that you'll have a choice to install or not, but there's also updates that we just want to get our security patches out," said Nightingale. Those silent updates will be rolled out first to Windows users because Windows experience the most security risks, he said, but Mac and Linux users will eventually see them, too.
CNET Download Blog
A researcher released software at the Black Hat conference on Thursday designed to let people test whether their calls on mobile phones can be eavesdropped on.
The public availability of the software, dubbed Airprobe, means that anyone with the right hardware can snoop on other peoples' calls, unless the target telecommunications provider has deployed a patch that was standardized about two years ago by the GSMA, the trade association representing GSM (Global System for Mobile Communications) providers, including AT&T and T-Mobile in the United States.
For more on this story, read Can your calls be intercepted? This tool can tell on CNET News.
A "publicity stunt?" Major threat? Or easily contained?
Executives at AirTight are defending their description of a little-known "vulnerability" in the 802.11 standard in the face of criticism following their demonstration of a Wi-Fi exploit at the Black Hat security conference. One WLAN vendor called the claim a "publicity stunt."
Others are saying the attack, which can only be mounted by an internal authorized WLAN user, is so limited in scope that it would be easier for an attacker to just use the unattended computer in a neighbor's cubicle or even bribe a fellow employee to access data.
"What those limitations really mean is that 'YES' there are much easier ways to get the data," says Jennifer Jabbusch, chief information security officer, Carolina Advanced Digital, a Cary, N.C. IT services company. "In a scenario like this, that data is most likely (more than 99.9% likely) to be [already] unencrypted on the wire. In addition to that, the close physical proximity [required] would mean an attacker could also just as easily walk over to the victim's machine and load a tool to collect data while they're at lunch or getting a soda in the break room. The wireless attack is 'going around your butt to get to your elbow,' as we say in the South."
She analyzed the AirTight exploit previously in her SecurityUncorked blog.
WLAN vendor Aruba Networks issued its own analysis, by Robbie Gill of the company's engineering department, which concluded, "The attack scenario described by AirTight is well known and old news ? it was, in short, a publicity stunt."
Yesterday's detailed demonstration at Black Hat Arsenal, a demo area associated with the Black Hat info security conference, confirmed nearly all of the details that Jabbusch and others had been expecting. [See: "Wi-Fi WPA2 vulnerability FAQ".] It did little to convince observers that the exploit constituted a serious threat to enterprise wireless LAN security.
Dell is apparently eager to compete with Best Buy and Walmart for the title of most despised retailer in the country. A few months back, a tech support rep got in trouble for turning on a woman's webcam without her permission. Then, last month, the company got nabbed knowingly shipping faulty PCs. And, just this week, the Texas-based manufacturer was caught shipping motherboards infected with malware. Now, a woman from California is alleging that a support technician for Dell stole nude photos of her from her PC and posted them online, and then charged $800 worth of computer gear to her credit card for another woman in Tennessee.
This is not a cut-and-dry case of a misbehaving tech rep, though. This drama has actually been going on for almost a year, and only now is Tara Fitzgerald coming forward with her accusations. Try and follow the sequence of events, and make sense of Fitzgerald's often questionable judgment.
Did Dell tech support display woman's naked pics?
Fitzgerald wanted to send some pictures of herself to her boyfriend, but she couldn't find them on her Dell computer.
Her urgent need to find these pictures drove her, quite naturally, to call Dell tech support. Her call was answered, she said, by a gentleman in Mumbai, India, named Riyaz Shaikh.
Shaikh, who, by the time you finish this tale, might not turn out to be a gentleman, after all, offered to remotely access her computer so that he could find the pictures for her. Fitzgerald said she watched him as he located her snapshots.
It was another fine day in the helpful history of tech support. However, this success was ruined somewhat, when Fitzgerald allegedly received an e-mail from an unidentified source telling her that her pictures were now freely available for anyone to see on the Web. They were on a site called "bitchtara." [...]
News10 contacted Dell, it received the following reply: "We investigated the issue, which involved a technical representative at one of Dell's vendors. We contacted the vendor about the allegation and can confirm that the representative no longer handles Dell calls. We've been in contact with Ms. Fitzgerald regarding this issue and continue to investigate her claims to best assist in a resolution."
The largest U.S. websites are installing new and intrusive consumer-tracking technologies on the computers of people visiting their sites?in some cases, more than 100 tracking tools at a time?a Wall Street Journal investigation has found.
The tracking files represent the leading edge of a lightly regulated, emerging industry of data-gatherers who are in effect establishing a new business model for the Internet: one based on intensive surveillance of people to sell data about, and predictions of, their interests and activities, in real time.
The Journal's study shows the extent to which Web users are in effect exchanging personal data for the broad access to information and services that is a defining feature of the Internet.
In an effort to quantify the reach and sophistication of the tracking industry, the Journal examined the 50 most popular websites in the U.S. to measure the quantity and capabilities of the "cookies," "beacons" and other trackers installed on a visitor's computer by each site. Together, the 50 sites account for roughly 40% of U.S. page-views.
The 50 sites installed a total of 3,180 tracking files on a test computer used to conduct the study. Only one site, the encyclopedia Wikipedia.org, installed none. Twelve sites, including IAC/InterActive Corp.'s Dictionary.com, Comcast Corp.'s Comcast.net and Microsoft Corp.'s MSN.com, installed more than 100 tracking tools apiece in the course of the Journal's test.
The Journal also surveyed its own site, WSJ.com, which doesn't rank among the top 50 by visitors. WSJ.com installed 60 tracking files, slightly below the 64 average for the top 50 sites.
If you use IE, enable "InPrivate Filtering"
Use Hosts file to block ads. Use Adblock Plus for FF or use AdBlock IE for IE
The latest independent survey of 1,000 workers from business ISP Star UK has found that 72% of British workers spend their lunch hour online and performing activities like shopping, banking, catching up with the latest sport or chatting to their friends on email or Facebook.
The research was conducted after Star noticed that the network bandwidth usage for business Internet traffic in their data centres was consistently peaking between 12:00 ? 14:00hrs, which is normally when British workers should be enjoying their lunch breaks.
The most popular lunchtime habits for 63% of people are checking their personal email accounts, engaging in online shopping and banking (62%), and 31% catch up with friends on social networking sites like Facebook ? unsurprisingly this trend was higher ( 40%) for younger workers between the ages of 16 to 34 years.
Farmville is arguably the biggest social game the world has seen. Well, maybe that's a bit much, but it is a popular game. It so popular in fact, that many people will play it at work. However, doing so might get you into trouble with the IT police.
According to a security report by Cisco, employees are breaking company policies by playing social networking games, and, by doing so, could be opening up networks to outside attacks.
Cisco's 2010 Midyear Report found that 7-percent of those who admitted to using Facebook at work also fessed up to spending an average of 68 minutes each day playing 'FarmVille.'
FarmVille isn't the only game Facebookers play, as they are also sucked up into playing 'Mafia Wars' (5-percent for 52 minutes each day) and 'Cafe World' (4-percent for 36 minutes each day).
Guard Dog, Inc. today announces a significant advance in its mission to protect consumers with a truly complete level of security against threats of identity theft through a recent partnership with Javacool Software LLC (JCS). In keeping with the company?s commitment to provide the best protection and solutions against online identity theft threats JCS?s popular software, SpywareBlaster, will be provided to all Guard Dog members to help protect them online.
?It has always been our primary objective to provide both current and future members of our identity theft protection service with the most comprehensive protection,? states Guard Dog Inc. Chief Executive Officer James Watson. ?This partnership is one of many clear strategic moves towards Guard Dog achieving that objective. This is a never-ending process of building layers of protection and it is critical to include online partners in that process. SpywareBlaster is a proven anti-spyware, anti-malware system and when combined with Guard Dog?s unique, full-featured pro-active approach; the combination provides serious protection against identity theft.?
There are many key features that make SpywareBlaster a perfect fit for the Guard Dog product line. SpywareBlaster works alongside any existing security software on a PC to help provide a strong ?layered defense? against spyware, malware and other threats. It also prevents the installation of ActiveX-based spyware and other dangerous programs, blocks spying and tracking via cookies, and restricts the actions of potentially unwanted Web sites. Unlike many other security tools, the performance-friendly SpywareBlaster software does not remain running in the background to slow down your PC.
?We are extremely pleased to announce our cooperative agreement with Guard Dog ID,? said a Javacool company spokesperson. ?Over the years we have been approached by numerous companies that wanted to enter into a partnership program. The only one that was clearly in the best interests of our customers and our SpywareBlaster product was Guard Dog. We have been in talks with Guard Dog over the last three months and have a good understanding of their product and how SpywareBlaster fits into the equation. We are very excited to be a part of it.?
With more than 60 million free downloads since the company?s launch in 2002, having this agreement with Javacool furthers the distance between Guard Dog ID and its competitors. The company now truly offers a full suite of comprehensive identity theft protection, including key protection against online threats.
Amendments to Telemarketing Sales Rule Prohibiting Debt Relief Companies From Collecting Advance Fees Will Take Effect in October 2010
Starting on October 27, 2010, for-profit companies that sell debt relief services over the telephone may no longer charge a fee before they settle or reduce a customer?s credit card or other unsecured debt.
?At the FTC we strive every day to make sure America?s middle class families get straight deals for their dollars,? Chairman Jon Leibowitz said. ?This rule will stop companies who offer consumers false promises of reducing credit card debts by half or more in exchange for large, up-front fees. Too many of these companies pick the last dollar out of consumers? pockets ? and far from leaving them better off, push them deeper into debt, even bankruptcy.?
Three other Telemarketing Sales Rule provisions to take effect on September 27, 2010, will:
require debt relief companies to make specific disclosures to consumers;
prohibit them from making misrepresentations; an
extend the Telemarketing Sales Rule to cover calls consumers make to these firms in response to debt relief advertising.
The FTC yesterday published a list of companies that used unfair, deceptive, false or misleading claims about consumer privacy that caused ?substantial consumer injury,? and the names on it will surprise you. Sure, many of the companies are mortgage scammers and spam phishers. But lots of them are household and blue-chip brands such as Twitter, TJ Maxx (TJX), Microsoft (MSFT) and Dave & Busters.
The list proves that advertisers cannot be trusted to regulate themselves when it comes to tracking and targeting consumers on the web or on mobile devices. There are currently few rules controlling how advertisers can use personal information gathered from consumers electronically, and if self regulation worked the FTC would not have brought action against these companies for privacy abuses (see pages 7 and 8):
- Dave & Buster?s
- LifeLock
- ValueClick
- CVS Caremark
- The TJX Cos. (TJ Maxx)
- Reed Elsevier
- DSW
- BJ?s Wholesale Club, Inc.
- Nationwide Mortgage Group
- Petco Animal Supplies
- Guess?
- Microsoft Corp.
- Lexis Nexis
In addition, the FTC has brought:
? 15 actions charging website operators with collecting information from children without parents? consent, as well as 15 spyware cases and dozens of actions challenging illegal spam, ?
Mobile app developer Jackeey Wu defended himself against claims of producing Android spyware apps today while also underscoring some of the risks of Google's mobile OS. He noted that some of the permissions his Wallpapers allegedly requested, such as for the web browser history and SMS message records, aren't in the actual app. As requesting private information automatically flags the app in Android Market before the install, it's virtually impossible to collect such information in secret, Wu said.
What few permissions Wu needs, such as basic phone access, are to help make features such as favorites work properly as a user changes devices. There's no connection to user data, he said.
Lookout, the research team that had first made the accusations, has since scaled back its claims and in an update said there wasn't any evidence of rogue behavior.
Commtouch today announced that it has signed a definitive Asset Purchase Agreement to acquire the assets, products, licenses, and operations of the Command antivirus division of Authentium, Inc., a Florida-based company.
Command antivirus -- which also includes technology to protect against spyware, Trojan downloaders, and other threats -- is strongly synergetic with the rest of Commtouch's product portfolio. With the addition of antivirus technology as a new, third product line, Commtouch will be offering a comprehensive set of solutions for inbound and outbound messaging and Web security to its customers, which are networking and security vendors and service providers.
The Command antivirus division currently provides its technology to a notable number of leading service providers and vendors, including Google, McAfee, and Microsoft. Certified by Checkmark, West Coast Labs, and a winner of multiple Virus Bulletin awards, Authentium's Command antivirus technology boasts a small footprint and a highly efficient event-processing system.
Commtouch is expected to pay $4.6 million in cash and an additional "earnout" contingent upon the achievement of certain revenue milestones through December 31, 2011, which may bring the total amount to approximately $8 million.
The acquisition is expected to be accretive starting the first quarter post-closing, and should contribute positively to Commtouch's non-GAAP top and bottom line in 2011.
When Web pages are infected with malicious code, the current security practice is to block the entire page and warn users not to go there. But what if the infected page is on a legitimate site that needs that page up in order to do business?
In a presentation here Wednesday, a Black Hat speaker proposed a new technology that strips out malware from infected Web pages, effectively allowing sites to continue to serve Web content even after a page has been infected.
The new "mod_antimalware" Web server module, which is outlined in a white paper at Black Hat, is designed to recognize malware by its behavior on a website, says Neil Daswani, CTO of upstart security vendor Dasient and co-author of the paper.
"When a PC gets infected with malware, you don't tell the user to stop using it," Daswani says. "But that's basically what happens to Web pages that get infected -- the whole page is blocked, and your site may even be blacklisted, all because one element on one page is infected."
Mod_antimalware monitors Websites for malicious behavior, such as redirecting users to other sites or attempting to download Trojan horses, Daswani explains. It then identifies the code that instigated the malicious behavior and strips it off the page, allowing the rest of the Web content to continue being served safely.
Government to persevere with browser despite high-profile vulnerabilities and advice from France and Germany
The government has ruled out scrapping the use of Internet Explorer 6 on department computers, saying it will persevere with the bullet-riddled browser despite its high-profile vulnerabilities.
Responding to an online petition with more than 6,000 signatures urging government departments to upgrade away from IE6, the government said such a move would be "a very large operation" potentially at "significant potential cost to the taxpayer".
"It is therefore more cost-effective in many cases to continue to use IE6 and rely on other measures, such as firewalls and malware-scanning software, to further protect public sector internet users," reads the statement.
The petition, set up by Dan Frydman, director of Inigo Media, launched the day after Google announced it would be phasing out support for the Microsoft browser after the company's corporate network was broken into by Chinese hackers using a vulnerability in IE6. The (pre-election) cabinet office signalled its intention to stick with IE6 in January this year, despite governments in both France and Germany advising people to stop using it.
Frydman responded to today's government decision on his blog, expressing disappointment that the possibility of an upgrade across any department was ruled out so off-handedly. "What I was looking for was a recommendation to upgrade away from IE6," he says. "A recommendation isn't hard, it's cheap and easy and isn't an admission of guilt. It puts the onus on the government departments to modernise, to innovate and to take care of [on] their own.
Well, you are putting your organization or department at RISK.
Millions have downloaded 'suspicious' wallpaper apps, says mobile security firm
Between one and four million users of Android phones have downloaded wallpaper apps that swipe personal data from the phone and transmit it to a Chinese-owned server, a mobile security firm said today.
According to San Francisco-based Lookout, a large number of free wallpaper apps in the Android Market scrape the phone number; the user-specific subscriber identifier, also know as the IMSI (International Mobile Subscriber Identity); the phone's SIM card's serial number; and the currently-entered voicemail number from the phone.
That information is then transmitted to a server that Internet records show is registered to a resident of Shenzhen, a city in China's Guangdong province, just north of Hong Kong.
Over 80 wallpaper apps created by a pair of developers -- "callmejack" and "IceskYsl@1sters!" -- include code that accesses users' personal data, said Kevin Mahaffey, chief technology officer and a co-founder of Lookout.
"All that is sent to a Chinese server in clear text," said Mahaffey in an interview prior to Black Hat, where he and CEO John Hering presented findings of what the company called the "App Genome Project," an attempt to analyze the code of some 300,000 applications available in the Android Market and Apple's iPhone App Store.
In a Friday entry on Lookout's blog, Mahaffrey published pieces of the data-scraping code found in the wallpaper apps, as well as an example of the HTML request made to the Chinese server by those programs.
Barracuda Networks is out this week with new research attempting to quantify how much malicious activity occurs on Twitter. Barracuda defines the Twitter "crime rate" as the percentage of accounts created per month that are eventually suspended by the company.
Barracuda presented its research here at the BSides event, down the Strip from the Black Hat security conference.
In total, Barracuda looked at more than 25 million accounts and found that the crime rate for the first half of 2010 is only 1.67 percent. Barracuda saw the crime rate on Twitter fluctuate from month to month, peaking in October 2009 when the rate checked in at 12 percent.
David Maynor, a research scientist at Barracuda Networks, told InternetNews.com that Twitter has not published a rigid set of guidelines specifying why accounts are deleted, though spammers and phishers are likely candidates for deletion.
While some Twitter accounts may have been set up by those with malicious intent, others may have been compromised by third-party applications, a situation Twitter is trying to address by moving to the OAuth. Maynor said that OAuth can be helpful, but won't necessarily make much of a difference to the Twitter crime rate.
"OAuth is the first step toward building a more secure infrastructure," Maynor said. [...]
Compared to other forms of online communications, Twitter's crime rate ranks somewhere in the middle.
"The crime rate on Twitter is more than it is on Facebook but less than it is on e-mail," Judge said.
According to a newly released report by Barracuda Labs, based on a two-month study reviewing more than 25,000 trending topics and 5.5 million search results, Google remains the most popular search engine used by malicious attackers, relying on poisoned keywords.
The company, which also sampled Yahoo Search, Bing, and Twitter, contributes Google?s leading position to the fact that Google remains the market share leader in online search, and consequently the most targeted search engine.
Key highlights of the study:
- Overall, Google takes the crown for malware distribution ? turning up more than twice the amount of malware as Bing, Twitter and Yahoo! combined when searches on popular trending topics were performed. Google presents at 69 percent; Yahoo! at 18 percent; Bing at 12 percent; and Twitter at one percent.
- The average amount of time for a trending topic to appear on one of the major search engines after appearing on Twitter varies tremendously: 1.2 days for Google, 4.3 days for Bing, and 4.8 days for Yahoo!
- Over half of the malware found was between the hours of 4:00 a.m. and 10:00 a.m. GMT. The top 10 terms used by malware distributors include the name of a NFL player, three actresses, a Playboy Playmate and a college student who faked his way into Harvard.
Interestingly, based on the data gathered, the most popular topic of choice for cybercriminals were spyware related searches, followed by entertainment news, with hosting sites, P2P and proxies related searches showing a significant growth. What?s worth highlighting while interpreting the data, is that it?s only valid for a specific period of time. How come? [...]
From Graham Cluley's Blog at Sophos:
Yesterday my colleague Pablo Teijeira, who is based in our Madrid office, logged into Facebook as normal and was confronted with a rather unusual message in place of the usual reminder of whose birthday it was today:
Rather than "Hoy es cumple de" ("Today is the birthday of") the Spanish language version of Facebook was saying "f*ck you bitches". Charming.
Pablo dropped me a line, wondering if I knew if Facebook had been hacked or if there was some other sinister explanation.
Well, the good news is that it wasn't malware and it was more done as a prank than with malicious intent. Facebook has relied upon volunteers to translate its site, and if enough people vote for an incorrect translation it can automatically replace the legitimate wording.
It's all very well harnessing the power of the net to get your website translated, but maybe Facebook should put a few more checks in place before the system is abused again in future - perhaps with more malicious intentions.
By the way, the Turkish translation version of Facebook was also abused in a similar way [...]
A security expert found a way to catch the talks at Black Hat for free, thanks to bugs in the video streaming service used by the security conference.
Michael Coates, the head of Web security for Mozilla, said he discovered several problems while trying to sign up for the US$395 service. As he went through the sign-up procedure, he was "quickly sidetracked by a few oddities in the design," he wrote in a blog post describing the incident.
He poked around a bit more and discovered that he could register an account without providing anything more than an e-mail address, and then use that account on a test login page to access the videos for free.
"Now, to be fair, Black Hat didn't operate this video service themselves," Coates wrote. "But its still a bit ironic that the largest hacking conference in the world has this security hole in their video streaming service."
Black Hat's video streaming was provided by Inxpo this year.
Quicktime Player (version 7.6.6) allows movie files to trigger download of files, and cybercriminals are using this to download malware from malicious websites.
Trend Micro Threat Research Engineer Benson Sy encountered two .MOV files (001 Dvdrip Salt.mov, salt dvdrpi [btjunkie][xtrancex].mov) that both used the recent movie, Salt of Angelina Jolie. It looks suspicious enough because of its relatively small size compared to regular movie files.
When the movie files are loaded to Quicktime player, it doesn?t show any live action scenes but leads users to download malware pretending to be either an update codec or another player installation. It is still under investigation whether the malware is using vulnerability or a known functionality to download the malware.
# cutter 192.168.2.55 3400
What do you think of your antivirus company, the one that didn't notice Sony's rootkit as it infected half a million computers? And this isn't one of those lightning-fast internet worms; this one has been spreading since mid-2004. Because it spread through infected CDs, not through internet connections, they didn't notice? This is exactly the kind of thing we're paying those companies to detect -- especially because the rootkit was phoning home.
But much worse than not detecting it before Russinovich's discovery was the deafening silence that followed. When a new piece of malware is found, security companies fall over themselves to clean our computers and inoculate our networks. Not in this case.
Forget the outdated hacker image of a spotty anarchic teenager holed up in his bedroom defacing the Web sites of global organisations, today's hackers are not only older but more determined than ever to claim your cash and identity.
...ran a heroin distribution ring that was violent and tightly knit, making it difficult for informers to penetrate it, federal authorities say.
The gang also had a secret weapon: It cultivated a police officer to dig into a law enforcement database to figure out which of its customers might be undercover informers...
"This case personifies exactly the effectiveness of the system," the chief said. "We had intelligence that somebody was running people's names involved in narcotics cases without a legitimate reason, and we ran those names and found out who it was, and took the appropriate action."
Mokwa said officers use REJIS on a daily basis, and tightening security would be burdensome. "You have to rely upon the integrity of officers to use the system properly," he said. "To change it, you would have to restrict their access."
Michael Lynn, the hacker who hit the headlines in July for exposing a Cisco router flaw is now employed by arch-rival Juniper, according to the vendor. Juniper declined to reveal what role Lynn is occupying.
The security researcher was dramatically sued by Cisco earlier in the year after he discovered a Cisco router IOS flaw and defied the networking giant and then-employer ISS to publicise the flaw at a hacking convention in Las Vegas.
Lynn was widely regarded as a hero by many in the internet community in the wake of the scandal but many doubted if he could again find gainful employment as a security researcher.
For its part, Cisco was widely castigated for its heavy-handed tactics in stopping Lynn from further publicising his findings, with some commentators suggesting that the internet could be at threat if similar whistle-blowers are discouraged to come clean on flaws.
Mitsuru, one of our support engineers in Japan, actually did some excellent research recently into exactly what our behavior is for auditing audit policy and I wanted to share that with you.
In Windows, we've always had auditing for changes to security policy. Audit policy has always been one aspect of that policy.
However, it's not so clear how to audit changes to audit policy. The reason is, because the change itself might affect whether or not the audit is generated. Usually in Windows, we generate audit after the operation that we are auditing, is performed. When we generate audit, we always check audit policy to see if we need to generate an event.
So what would happen if you turned off the setting "audit changes to audit policy"? Well, if we implemented it in the way we generally implement audit policy, nothing would happen- no event. As described above, if we checked audit policy after we disabled audit policy, then the effective policy would say "don't generate audit".
But consider the case where a malicious audit or system administrator wants to cover their tracks. One thing such a person might do, to not leave as much of a trace, is to disable audit policy before they do the bad thing, and re-enable it afterwards. If we implemented audit normally, then there would be no trace of this.
To avoid this undesirable case, we changed around the instrumentation a little so that we always generate audit for certain audit policy change events. This means that you might not get EXACTLY what you intended, but it also ensures that you can always find the significant events when someone disables audit policy.
Anyway, to sum up, the following events are always audited when audit policy is disabled regardless of the "Audit Policy Change" subcategory setting in Windows Vista+:
4715 The audit policy (SACL) on an object was changed.
4719 System audit policy was changed.
4906 The CrashOnAuditFail value has changed.
4908 Special Groups Logon table modified.
4912 Per User Audit Policy was changed.
The following events are only audited when success auditing is enabled for the "Audit Policy Change" subcategory:
4902 The Per-user audit policy table was created.
4904 An attempt was made to register a security event source.
4905 An attempt was made to unregister a security event source.
4907 Auditing settings on object were changed.
Special thanks to Mitsuru for documenting this.
Hi Everyone,
Sas sent me an email complaining that I am not posting as often as I should- sorry about that. I am working on a different project now but I am still in close touch with the auditing team and I'll try to do better.
Anyway a question that I hear regularly is, "how do I find all the NTLM authentications on my network"?
Other than running a network trace, the best way I have found (ok invented :-) to do this is to look at the logon events in the audit log.
One of the changes we made to the logon events in Windows Vista (and therefore subsequent releases of Windows) was to include the NTLM protocol level in the logon events, if the NTLM auth package was used.
Now, with the new EventLog ecosystem, it's easy to generate some XPath to find just these events.
Here's the query:
|
*[System [Provider [@Name='Microsoft-Windows-Security-Auditing'] and Task = 12544 and (band(Keywords,9007199254740992)) and (EventID=4624) ] and EventData [Data [@Name='LmPackageName'] != '-' ]
] |
To use this in Event Viewer:
The event view will now be filtered and you'll only see NTLM logon events. Additionally, each filtered event will contain a "Detailed Authentication Information" section containing the protocol level (e.g. LM, NTLM, NTLM V2) in the "Package Name" field, and the session key length, if one was negotiated.
|
Detailed Authentication Information: |
UPDATE 2010-06-06 (EricF) - Fixed Vista+ architecture image; link was broken on migration to new blog platform
I get questions from time to time, such as my recent offline question from Steve, about what performance impact auditing has on the system as a whole.
To answer this you need to understand a couple of things:
I have uploaded graphics of the Windows XP/Windows Server 2003 auditing architecture, and the Windows Vista/WS08/Windows 7 architecture, to make this process more clear:
Windows Vista+ Auditing Architecture
So now back to the original question- what is the impact of auditing on performance?
At low auditing loads, auditing generally has no discernable impact on perf. If you were hardcode with a profiler and iterated an auditable activity a million times I am sure you'd be able to measure it, but for reasonable audit policies you won't notice a significant difference.
At high auditing loads, auditing has a significant performance impact. This is more true of pre-Vista multiprocessor systems than of systems with the new eventlog system.
For example, a multi-processor domain controller (say a 32-processor box) running Windows Server 2003, might run into problems under extreme load. Why is that? Because ultimately the limiting factor on event rate is how fast you can write the events to disk. Pre-Vista eventlog has a single thread writing events to disk. So even though you might have 32 threads servicing authentication requests (an auditable activity), each of them is queueing to a single audit queue which is ultimately despooling to eventlog via RPC on a single thread, and eventlog is only writing to the security log with a single thread. What we observe in practice in this case is that a single processor on the system goes to 85-100% utilization, and the other processors drop to a very low utilization as the authentication threads are blocked waiting for the audit function call to return. This call won't return until the queue is not full, and the queue is waiting on RPC which is waiting on eventlog... so eventlog governs the rate.
In Windows Server 2003, we added a particular optimization only for the security event log, which batches events in the RPC call to eventlog. This means that you can get more event throughput in the security log than in other logs on the system. It didn't eliminate the bottleneck, but it pushed back the limit, so WS03 on typical hardware should be able to log several thousand events per second to the security event log. Previous versions were only able to log about 1000 events per second.
Note that the change in performance characteristics occurs all at once. So the impact tends to be trivial until the queues fill, at which point the impact is severe. It does not scale linearly, there's a discrete behavior change. What this means realistically is that if you ever encounter a performance problem with auditing, then you probably just need to turn it down a little and you won't have a problem any more.
In Vista and subsequent releases, audit queues events via ETW. ETW was designed for high-performance kernel tracing, and in the auditing team we tested it to over 10,000 (10.000 for you folks in Germany :-) events per second before we decided that we had hit our scale targets. We never tested exactly how high it would go, but we were satisfied that the eventlog service was no longer a bottleneck in realistic scenarios.
There are some edge cases where you might run into performance problems by trying to audit too much in a critical path. For instance, it is a really really bad idea to put SACLs on your entire registry. If you monitor registry activity with a tool like Process Monitor, you will notice that when a system is not idle, there are often hundreds or thousands of registry accesses per second. If you impose an auditing tax on each of those activities you will notice a degradation in performance. Not to mention that the resultant mountain of events is probably not very valuable. Of course you can tune SACLs as I have mentioned before, but I doubt that it's useful to take the time to tune SACLs for the entire registry.
One last point is that the eventlog is writing the events somewhere. Wherever it is writing events, it is consuming disk I/Os and competing with anything else writing to the same volume. If you have a disk performance problem on that disk, it can result in an auditing performance problem, as everything else will back up if the eventlog can't write events to disk fast enough. So one thing you can do is ensure that the disk where your log is placed has enough I/Os.
In summary audit has very minimal impact unless you do a whole lot of it, in which case it can have severe impact on your system. The change happens suddenly, not gradually, so you can do a lot of auditing with no problem. If you run into a problem, turn it down just a little (or little by little) and at some point the behavior will change such that you won't have any significant perf impact anymore.
I've written twice (here and here) about the relationship between the "old" event IDs (5xx-6xx) in WS03 and earlier versions of Windows, and between the "new" security event IDs (4xxx-5xxx) in Vista and beyond.
In short, EventID(WS03) + 4096 = EventID(WS08) for almost all security events in WS03.
The exceptions are the logon events. The logon success events (540, 528) were collapsed into a single event 4624 (=528 + 4096). The logon failure events (529-537, 539) were collapsed into a single event 4625 (=529+4096).
Other than that, there are cases where old events were deprecated (IPsec IIRC), and there are cases where new events were added (DS Change). These are all new instrumentation and there is no ?mapping? possible- e.g. the new DS Change audit events are complementary to the old DS Access events; they record something different than the old events so you can?t say that the old event xxx = the new event yyy because they aren?t equivalent. The old event means one thing and the new event means another thing; they represent different points of instrumentation in the OS, not just formatting changes in the event representation in the log.
Of course I explained earlier why we renumbered the events, and (in the same place) why the difference is "+4096" instead of something more human-friendly like "+1000". The bottom line is that the event schema is different, so by changing the event IDs (and not re-using any), we force existing automation to be updated rather than just misinterpreting events when the automation doesn't know the version of Windows that produced the event. We realized it would be painful but it is nowhere near as painful as if every event consumer had to be aware of, and have special casing for, pre-Vista events and post-Vista events with the same IDs but different schema.
So if you happen to know the pre-Vista security events, then you can quickly translate your existing knowledge to Vista by adding 4000, adding 100, and subtracting 4. You can do this in your head.
However if you're trying to implement some automation, you should avoid trying to make a chart with "<Vista" and ">=Vista" columns of event ID numbers, because this will likely result in mis-parsing one set of events, and because you'll find it frustrating that there is not a 1:1 mapping (and in some cases no mapping at all).
Eric
I've written before on noise reduction in the Windows security event log. I've also written to describe how object access auditing works. But, I still get questions on how to reduce noise from object access events. The other day I got that question, specific to Directory Service objects, on an internal discussion list so I thought I'd clean up the answer a bit and share it with the world. In general the same is true for any type of object, although there are a few more knobs to control for DS objects.
Object access audit is generated when the system access control list (SACL) on the object matches the access that was performed on ALL of the following conditions:
The specific auditing algorithm is discussed here.
So the way to reduce the number of audit events (566 on Windows Server 2003, 4662 on Windows Server 2008, or one of the new DS Change events on Windows Server 2008) is to cause one or more of those conditions to fail, except in the specific cases that you care about.
The SACL which will generate the most audit events is "Everyone:Success & Failure:All accesses" on the domain head with OI,CI (object inherit & container inherit flags) for all object types. This SACL matches all of the above conditions in all cases. (Incidentally I think that this is pretty close to the default SACL- with the exception of failures- for Windows 2000 Active Directory installations, and SACLs are not updated when DCs are upgraded from version to version. Windows Server 2003 has much more conservative SACLs for new installations of AD.)
To reduce noise, I offer the following suggestions, addressing each of the above conditions:
I get the question fairly often, how to use the logon events in the audit log to track how long a user was using their computer and when they logged off.
As I have written about previously, this method of user activity tracking is unreliable. It works in trivial cases (e.g. single machine where the user doesn't have physical access to the power switch or power cord), and it works most of the time in simple cases where there is good network connectivy and the user is not trying to evade detection. If the user has physical access to the machine-- for example, can pull out the network or power cables or push the reset button-- and if the user is actively trying to evade time tracking, then the only reliable solution is to surreptitiously put a video camera (subject to local laws) in a place that can monitor the user's presence in front of the keyboard (yes I am aware of research done to track sound of keyboard clicks, etc.).
There is no way to instrument the OS to account for someone who just backs away from the keyboard and walks away. The screen saver, if configured, will come on after a configurable delay since the last keypress or mouse movement. Yes, if you know the SS delay then you could just work that into your calculations. However the workstation does not lock until the screen saver is dismissed (some of you might have noticed that when you bump the mouse to dismiss the screensaver, sometimes you see your desktop for a fraction of a second- that?s because your machine isn?t locked while the screen saver is being displayed). And the events don't tell you whether the workstation was locked or auto-locked so you don't really know whether to add in the screen saver delay factor. Plus, prior to Windows Vista, there is no workstation lock event at all, only an unlock event, which is constructed in a way which makes it difficult to correlate with the original logon event.
So the bottom line is, I don't advocate or recommend this method for tracking the time a user spends at the keyboard. If I were hypothetically called as an expert witness, I would testify that such a method is unreliable and trivially circumvented. You have been warned, I've beaten that dead horse enough I guess.
Given that you are disregarding all my contrary advice, how are you going to accomplish this?
First, we need a general algorithm.
Use time (for a given logon session) = Logoff time - logon time
Now, what about the cases where the user powers off the machine, or it bluescreens, or a token leak prevents the logoff event from being generated, etc.? We can use the BEGIN_LOGOFF event to handle token leak cases. We can use the shutdown event in cases where the user does not log off. And in case of crashes, the only event we can use is the startup event. Note that each of these introduces increasing levels of uncertainty.
Logoff time = (logoff time | begin_logoff time | shutdown time | startup time)
This is good, but what about the time the workstation was locked?
Workstation lock time = unlock time - lock time
Total workstation lock time (for a given logon session) = SUM(workstation lock time)
How about remote desktop & terminal server sessions, and fast user switching? You can connect and disconnect from logon sessions, during which time the user technically isn't using the computer.
Session idle time = session connect time - session disconnect time
Total session idle time (for a given logon session) = SUM(session idle time)
How about times when the machine was idle? We can estimate that by looking at the time the screen saver was in place and adding the screen saver timeout.
Console idle time = (screen saver dismiss time - screen saver invoke time + screen saver delay)
Total console idle time = SUM(console idle time)
Putting all of this together and modifying our original formula, we get:
Use time (for a given logon session) =
Logoff time - logon time
- SUM(workstation lock time)
- SUM(session idle time)
- SUM(console idle time)
When we expand it, it is not quite so pretty:
Use time (for a given logon session) =
( (logoff time | begin_logoff time | shutdown time | startup time) - logon time )
- SUM(unlock time - lock time)
- SUM(session connect time - session disconnect time)
- SUM(screen saver dismiss time - screen saver invoke time + screen saver delay)
You have to be very careful that you only look at events that are properly contained chronologically between two other appropriate events, to avoid accidentally pairing the wrong logon and logoff events, or pairing a lock workstation event from one logon session with a different logon session. The best correlation field is the Logon ID field, the next best are timestamp and user name. At various times you need to examine all of these fields.
Now, which event IDs correspond to all of these real-world events?
They are all found in the Security event log. The pre-Vista events (ID=5xx) all have event source=Security. The Vista/WS08 events (ID=4xxx) all have event source=Microsoft-Windows-Security-Auditing.
512 / 4608 STARTUP
513 / 4609 SHUTDOWN
528 / 4624 LOGON
538 / 4634 LOGOFF
551 / 4647 BEGIN_LOGOFF
N/A / 4778 SESSION_RECONNECTED
N/A / 4779 SESSION_DISCONNECTED
N/A / 4800 WORKSTATION_LOCKED
* / 4801 WORKSTATION_UNLOCKED
N/A / 4802 SCREENSAVER_INVOKED
N/A / 4803 SCREENSAVER_DISMISSED
* prior to Windows Vista, there was no event for locking the workstation. Unlocking the workstation generated a pair of events, a logon event and a logoff event (528/538) with logon type 7. These events had the same user name as the "original" logon session and were completely enclosed chronologically by the logon/logoff events for the "real" logon session, but did not contain the Logon ID of the original logon session or other unambiguous correlator. This makes correlation of these events difficult.
All of these events are generated in the Logon/Logoff audit policy category, although on Windows Vista and Windows Server 2008 they are scattered among the various subcategories in this audit policy category. The audit event spreadsheet that Ned wrote has all the policy subcategory mappings as well as the event descriptions.
Sorry that this is more of a do-it-yourself than a solution-in-a-box, but this is pretty difficult to script and so far I haven't worked on a project that required this.
Eric
I get a lot of questions about how ACS event retention works. So here you go, I'm blogging it so I can just answer with a link :-)
There are two DWORD registry values which affect backlog transmission. Both are on the collector machine under HKLM\System\CurrentControlSet\Services\AdtServer\Parameters.
EventRetentionPeriod, if present, is expressed in hours (I forget the default). It takes precedence over MaximumEventAge, which is in days (default=1). Both of these values control the backlog of events that will be sent from agents to the collector on agent connect, but as mentioned, EventRetentionPeriod wins any conflict. MaximumEventAge used to control database retention in early beta builds but does not anymore, since the database moved to a partitioning mechanism. You might encounter MaximumEventAge if you are migrating from ACS beta to Operations Manager 2007 ACS.
Grooming is now governed entirely by the grooming algorithm. The grooming algorithm is simple: partitions will be deleted by the next grooming job as soon as they are eligible for deletion.
Eligible for deletion means:
Think of (partitionDuration * numPartitions) as the retention period before data is groomed from the database.
Note that dtPartition[<partitionId>].LastCreationTime defaults to 12:00am 1/1/2000 (collector local time). After successful execution of the close partition script, this field?s value is set to max(dtEvent_<partitionId>.CreationTime) for the partition in question. There is an implication here that if you update status to 2 without updating LastCreationTime, then the partition is immediately eligible for grooming assuming your clock is accurate.
The partition switch offset (time of day to switch partitions) value in dtConfig has no effect on grooming, other than that grooming will not occur during a partition switch.
Grooming runs at startup and immediately after checkpointing. The default checkpoint interval is 198 seconds but this interval can be configured by the DWORD registry value CheckPointInterval on the collector, in the same location as the other registry values. A successful checkpoint logs an event in the database, event ID 0 with a source of ?_acs? (you might have seen these on an ?idle? ACS and wondered how they got there?)
We got several reports recently of a bug in ACS that certain DS Access events, primarily for dnsNode and dnsZone objects, don't properly get looked up.
Some background: the event log in Windows prefers to log invariants such as message IDs, parameter message IDs, SIDs (security IDs which represent users and groups, etc.), and GUIDs (globally unique IDs which represent objects in Active Directory), rather than the actual names of the objects. At view time the viewing application is expected to look up the name associated with the invariant and display it to the user.
The reasons that Windows does this are (1) that it enables localization, so that English speakers can see "Administrator" and French speakers can see "Administrateur", and (2) that it provides rename safefy- many objects are rename-able, such as domain accounts and other AD objects.
Anyway in ACS we had to solve the problem of how to store mountains of log data in a database, make it queryable in meaningful ways, preserve original format, present to users in a recognizable/understandable format, etc.
The way we chose to solve our several problems was to take strings that contained an invariant and append the translated name or string.
For example:
%{e0fa1e8c-9b45-11d0-afdd-00c04fd930c9}
would be translated to:
%{e0fa1e8c-9b45-11d0-afdd-00c04fd930c9}=?dnsNode?
and
%%7685
becomes:
%%7685=?Write Property?
As I mentioned, though, we ran into a problem recently. Some of our customers were monitoring AD objects with ACS and noticed that ACS was not translating the GUIDs for certain objects. When they manually looked up the GUIDs they noticed that they were for AD-integrated DNS objects.
After investigation, we found that AD was logging certain audit events for the objects, before all the attributes of the objects had been populated- DNS was populating the objects in multiple operations per object and each operation causes a separate event. So ACS, which operates as close to real-time as we could get, was actually noticing the first event and asking AD "what's this?" before DNS had finished updating AD with things like the object's name. The difference in time was literally only milliseconds.
Anyway I didn't really feel it was an ACS bug and wanted to file a bug against Windows DNS Server. However the Operations Manager team has prototyped a configurable behavior for the ACS agent that lets it wait a very short time (configurable number of ms) and retry, when it fails to look up an AD object because the object doesn't exist. This might be released as a public patch and/or in a future Service Pack.
I thought you might appreciate stories of the kinds of weirdness we run into.
A judge in New Zealand declined to convict the admitted (guilty plea) botherder of a million-bot botnet, citing the negative consequences a conviction would have on the young man's future prospects. See the story here.
Well duh. The whole theory of crime and punishment is that if you do something bad, you get punished, and punishment is something that is unpleasant, so you try to avoid it, hopefully by not doing the crime. See? One would hope that a judge would understand this concept.
I could understand if the judge said "this is just a stupid kid, he doesn't deserve to do 20 years", and gave the kid probation, community service and a big fine. I don't know if New Zealand has such options, or if the judge has latitude in sentencing. There is probably more to the story than is being told. But you don't take over a million computers that don't belong to you, personally making tens of thousands of dollars, and not realize that you're doing something wrong. Unless you're a sociopath. And in either case, you either need punishment (for doing something you know is wrong) or separation from society for the protection of society while you get treatment (if you are a sociopath). So whatever the case, the judge got it wrong, and as a result is practically encouraging future behavior of the same sort.
If you haven't used wevtutil.exe to script event log tasks in Windows Vista or Windows Server 2008, you're missing out. The new tool makes getting events out of the log pretty easy, but the main thing is that it doesn't suffer from any of the drawbacks around getting field delimiting correct.
The tool's command to query events from a log is "qe", and takes a log name as a parameter.
If you want to specify a query expression, then you can use XPath with the /q switch. The easiest way to do this is to use Event Viewer to build a filter for just the events that you want, and then copy just the XPath expression out of the XML tab of the filter dialog in Event Viewer. Be careful to copy only the filter expression and not the XML that surrounds it.
Finally, the default output format of wevtutil is XML. However it dumps each event as XML, but does not include a root element- in other words it's not well-formed XML by default. To include a root element you need to include the /e switch and a root element name.
I put this all together in a batch file, with an example XPath filter that just gathers interactive logon events (event ID=4624, logon type=2). You can save this as a .cmd file and run it as an administrator on Vista or WS08 and it will pull up a list of your interactive logons in Internet Explorer (or your default XML handler application if you've changed the registration). It has to run as admin because it accesses the security event log.
If you're really good (better than me, which is not hard) you could write an XSL style sheet and put this into a report format.
Good luck!
@echo off REM (C) 2008 Microsoft Corporation REM All Rights Reserved REM The next command is all one line and has no carriage returns REM The only spaces in the XPath are around the AND keywords
set outputfile=%temp%\interactive-logon-events.xml
if "%1" NEQ "" set outputfile=%1
wevtutil qe Security /q:"*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and Task=12544 and (EventID=4624)] and EventData[Data[@Name='LogonType']='2']]" /e:Events > %outputfile%
start %outputfile%
set outputfile=
I often talk about Ned, who is the current subject matter expert in Microsoft product support for the auditing feature in the US (Fadi is your guy in the Middle East and we have a couple of guys in Europe). Well, Ned has a blog and I thought I'd point you guys there. His recent posts on auditing include a description of how to deploy the special groups logon auditing feature with group policy.
Fadi, Ned and Brian of the auditing team have documented all the auditing events by audit policy category and subcategory for your reference.
Check it out in the Knowledge Base.
Even better, they documented all the events in spreadsheet format, and that's propagating to the Microsoft Download Center. I'll publish the link when it's online.
2008-04-17 UPDATE: Brian just sent me the link: here is the spreadsheet.
2010-04-01 UPDATE: Here is the link to the updated spreadsheet for Windows 7 and Windows Server 2008 R2.
There's one topic that I know is on everyone's mind- no, not American Idol- it's "What's new in Auditing in Windows Server 2008?"
Well, funny that you brought that up. My friend Jesper Johanssen just wrote a new book, the Windows Server 2008 Security Resource Kit, and he invited me to write a chapter about auditing for it, which I did. So you, dear reader, are getting information straight from the horse's mouth, so to speak.
Anyway I think the book hits store shelves on March the 10th. A number of distinguished individuals contributed to the book: Susan Bradley, Darren Canavor, Kurt Dillard, Roger Grimes, Brian Komar, Alun Jones and others.
I'd also like to send out special props to my auditing posse: Raghu (who was the primary developer for auditing for Vista & WS08) and Ned (who is the resident guru for auditing in Microsoft Customer Support Services), both of whom made significant contributions. Raghu introduces the new "special group logon tracking" feature, and Ned contributed a spreadsheet mapping all the events (360-ish) to the policy category and subcategory and giving other key information about each event; this is included on the CD bundled with the book, along with an XML file defining the schema for all the events and event messages. Ned's also working on getting a version of the spreadsheet available for download from the Microsoft download site.
In other news, the Windows Server 2008 Security Guide is also out, and yes, yours truly contributed in small part to the auditing guidance in there too, although I seem to have been overlooked in the credits (in all fairness my work delta from the Vista Security Guide was really small so maybe it did not meet their "credits bar").
Anyway, download the security guide and buy a copy of the book. Buy more than one copy of the book, and give copies to your friends and loved ones. Nothing says "Happy Anniversary, Honey" quite like a book or white paper about computer security. OK, so maybe I should stick to computer security and stay away from relationship advice. Flowers work well in my experience.
I've decided to start dumping my knowledge of ACS for posterity's sake. My first installment is here, and it's an excerpt from an external email I put together which describes how event transformation works on ACS.
Transformation is performed on the agent (using instructions provided at connect time by the collector) and on the collector. Transformation instructions are all stored on the collector in a file called EventSchema.xml which is in the AdtServer directory (%windir%\system32\security\adtserver). This file is pointed to in the collector?s registry and is read during startup of the collector service; failure to successfully read and parse this file at startup is a fatal error for the collector (the debug log will complain about parsing).
The collector reads EventSchema.xml and builds in-memory binary tables of event transformation instructions and event string types by OS version/event log/event source.
The collector (as explained elsewhere) also reads AcsConfig.xml to get its persistent state and configuration for all known agents, to know what logs/sources to collect for each agent/agent group, etc. This is all read into in-memory state for each agent.
At connect time, the agent sends version information- what the OS and agent version and service pack are, etc. The collector first looks in its in-memory agent state to see what configuration applies to the agent. Then it looks in its transformation tables and extracts the appropriate version-specific transformation instructions for the events that the collector is configured to collect from that agent. Then it packages these instructions and sends them to the agent.
The agent starts reading events, transforming them according to its instructions from the collector, and sending the transformed events to the collector. The collector finishes the transformation, services real-time subscriptions and loads the events into the database as appropriate.
If the agent encounters an event that is it configured to send (by log/source) but does not have transformation instructions for, then it simply builds a copy the event string for string and sends the copy of the event to the collector as an ?unschematized? event. The collector will handle this event without problems but will not extract non-header user fields (no primary/client/target user fields) and will not add string type information.
I?ll take Windows Server 2003 (build 3790), Event Log: Security, Event Source: Security, Event ID: 644 as an example.
Here?s the WS03 schema for 644 (excerpt from %systemroot%\system32\security\adtserver\EventSchema.xml in the path ?Schema\Log[@Name=?Security?\Source[@Name=?Security?]\Version[@MinBuild=?3790?]\Event[@SourceId=?644?]?).
<Event SourceId="644" SourceName="SE_AUDITID_ACCOUNT_AUTO_LOCKED">
<Call Name="AppendString" Param1="1" Param2="0" />
<Call Name="AppendString" Param1="3" Param2="0" />
<Call Name="AppendString" Param1="2" Param2="0" />
<Call Name="AppendString" Param1="4" Param2="0" />
<Call Name="AppendString" Param1="5" Param2="0" />
<Call Name="AppendString" Param1="6" Param2="0" />
<Call Name="AppendSidFromNames" Param1="4" Param2="5" />
<Call Name="AppendNamesFromSid" Param1="3" Param2="0" />
<Param TypeName="typeUserDn" />
<Param TypeName="typeComputerName" />
<Param TypeName="typeTargetSid" />
<Param TypeName="typeClientUser" />
<Param TypeName="typeClientDomain" />
<Param TypeName="typeClientLogonId" />
<Param TypeName="typeClientSid" />
<Param TypeName="typeTargetUser" />
<Param TypeName="typeTargetDomain" />
</Event>
The instructions are all applied in order. ?Call? instructions are executed agent-side; ?Param? instructions are executed server-side.
These instructions can be translated as:
· Take string 1 from the original event and make it string 1 in the new event. It is of type ?typeUserDn?.
· Take string 3 from the original event and make it string 2 in the new event. It is of type ?typeComputerName?. Note that we are doing reordering here by appending original string #3 before original string #2. Nifty, eh?
· Take string 2 from the original event and make it string 3 in the new event. It is of type ?typeTargetSid?.
· Take string 4 from the original event and make it string 4 in the new event. It is of type ?typeClientUser?.
· Take string 5 from the original event and make it string 5 in the new event. It is of type ?typeClientDomain?.
· Take string 6 from the original event and make it string 6 in the new event. It is of type ?typeClientLogonId?.
· Take string 4 from the original event and treat is as a user name, and take string 5 from the original event and treat it as a domain name, look up the associated SID and make it string 7 in the new event. The new string is of type ?typeClientSid?.
· Take string 3 from the new event, treat it as a SID, look up the user/domain name associated with it and append the user name as string 8 to the new event and the domain name as string 9 to the new event. String 8 is of type ?typeTargetUser? and String 9 is of type ?typeTargetDomain?.
See the reordering? Now here is an instance of the event with the original event data. If you?re not familiar with the XML, it?s the XML output of Crimson, the new eventlog service introduced in Vista/WS08, but this is a WS03 [pre-Crimson] machine; we're looking at a saved event log (evt) file.
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Security" />
<EventID Qualifiers="0">644</EventID>
<Level>0</Level>
<Task>7</Task>
<Keywords>0xa0000000000000</Keywords>
<TimeCreated SystemTime="2007-12-17T15:50:14.000Z" />
<EventRecordID>28003981</EventRecordID>
<Channel>C:\Users\ericf\AppData\Local\Temp\SERVER34_SecEvts.evt</Channel>
<Computer>SERVER34</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data>user09</Data> // String 1 ? user name
<Data>SERVER34</Data> // String 2 ? looks like a machine name, confirmed by string 4
<Data>%{S-1-5-21-5998314728-109421381-169156293-611111}</Data> // String 3 ? definitely a SID
<Data>SERVER34$</Data> // String 4 ? definitely an account name (machine account)
<Data>CONTOSO</Data> // String 5 ? looks like a domain name
<Data>(0x0,0x3E7)</Data> // String 6 ? definitely a logon ID
<Data>-</Data> // String 7 ? empty null string at the end of the event (ignored by ACS)
</EventData>
When the event arrives at the collector, type information is applied, and then the user fields (typePrimary*, typeClient*, typeTarget*) are extracted from the string data section and the strings that are left are re-numbered starting at 1 (no reordering occurs).
Here?s a chart of what the event looks like at the various points in the system. The changes at each step are shown in red.
|
Original Event in Event Log |
Client-Side Transformation at Agent |
Server-Side Normalization (WMI/SQL output) | |||
|
Field |
Content Description (implicit) |
Field |
Content Description (implicit) |
Field |
Content Description (explicit) |
|
|
|
Client User |
|
Client User |
typeClientUser |
|
|
|
Client Domain |
|
Client Domain |
typeClientDomain |
|
|
|
Client Sid |
|
Client Sid |
typeClientSid |
|
|
|
Client Login Id |
|
Client Login Id |
typeClientLogonId |
|
|
|
Target User |
|
Target User |
typeTargetUser |
|
|
|
Target Domain |
|
Target Domain |
typeTargetDomain |
|
|
|
Target Sid |
|
Target Sid |
typeTargetSid |
|
String01 |
typeUserDn |
String01 |
typeUserDn |
String01 |
typeUserDn |
|
String02 |
typeTargetSid |
String02 |
typeComputerName |
String02 |
typeComputerName |
|
String03 |
typeComputerName |
String03 |
typeTargetSid |
String03 |
|
|
String04 |
typeClientUser |
String04 |
typeClientUser |
String04 |
|
|
String05 |
typeClientDomain |
String05 |
typeClientDomain |
String05 |
|
|
String06 |
typeClientLogonId |
String06 |
typeClientLogonId |
String06 |
|
|
String07 |
|
String07 |
typeClientSid |
String07 |
|
|
String08 |
|
String08 |
typeTargetUser |
String08 |
|
|
String09 |
|
String09 |
typeTargetDomain |
String09 |
|
To finish off a description of transformation, there are 7 transformation functions, each of which can optionally take 2 integers as parameters. Note that there is no ?destination event? field specifier; all references are only to the original event. That?s because when constructing the destination event, any data added to the event is always appended- it is constructed from beginning to end- so the implicit destination field is ?at the end of the event as it is now?.
|
Function |
Parameter 1 |
Parameter 2 |
Description |
|
AppendString |
Reference to a string parameter in the source event in the event log |
Unused |
Appends the referenced string to the event which will be sent to the collector |
|
AppendStringFromTable |
Reference to a constant string in the statically defined <Strings> table (1-based) in the relevant Source\Version element in EventSchema.xml |
Unused |
Appends the referenced constant string to the event which will be sent to the collector |
|
AppendProcessNameFromPid |
Reference to a string parameter in the source event in the event log (source string is expected to be a numeric process ID) |
Unused |
Looks up the process image path name for the referenced PID and appends it to the event which will be sent to the collector |
|
AppendTimeFromDatetime |
Unused |
Unused |
Not Implemented/No Action |
|
AppendSidFromNames |
Reference to a string parameter in the source event in the event log (source string is expected to be a user name) |
Reference to a string parameter in the source event in the event log (source string is expected to be a domain name) |
Looks up the SID for the account represented by the specified user and domain names, and appends the SID to the event which will be sent to the collector |
|
AppendNamesFromSid |
Reference to a string parameter in the source event in the event log (source string is expected to be a security ID) |
Unused |
Looks up the user name and domain name for the account represented by the specified SID, and appends the user name and the domain name as separate strings to the event which will be sent to the collector |
|
AppendNumber |
Unused |
Unused |
Not Implemented/No Action |
Out of range params cause the transformation instruction to be ignored and skipped. Non-integer params or other XML formatting/malformation problem (including non-UTF8 formatting) cause an EventSchema.xml parsing error at collector startup which in turn causes collector startup failure.
So that?s ACS transformation in a nutshell. I hope this helps you guys understand ACS functionality a little better.
Shortly I will finish my write-up on AcsConfig.xml but that is a simple file and not too hard to figure out if you are into experimentation.
Here are some cool things that you can try with the event schema file if you are adventurous:
1. Drop fields. We have modified eventschema.xml successfully to cause it not to collect certain fields (e.g. logon GUIDs) of certain events:
<Call Name="AppendString" Param1="1" Param2="0" />
<Call Name="AppendString" Param1="2" Param2="0" />
<Call Name="AppendString" Param1="3" Param2="0" />
// try deleting a line here
// or, to preserve ordering of subsequent strings
// try replacing ?AppendString? with ?AppendStringFromTable (param1=1)?
<Call Name="AppendString" Param1="4" Param2="0" />
<Call Name="AppendString" Param1="5" Param2="0" />
<Call Name="AppendString" Param1="6" Param2="0" />
2. Add an event source. Some caveats are:
· You must have a unique, well-formed GUID for the new source
· You have to get events of the new source into the log (try ?AuthzReportSecurityEvent? from MSDN)
· You have to modify AcsConfig.xml to tell the agent(s) to collect the new source
NB I have used the C/C++ comment syntax throughout this post but note that ACS does not support either C/C++ nor XML style comments in the XML config files it uses
Today I encountered something new in the logon event- I thought that was old hat and I knew all there was to know about that but I guess I was wrong.
The logon event (528/540 prior to Windows Vista, 4624 in Vista and Windows Server 2008) has a field called a Logon Type. This is a code that is passed into the logon API that tells the authentication system in Windows which policy to check the logon against. Windows has separate policy checks for network logons, interactive logons, etc., so that you can allow users to access a system in some ways but not in others.
The logon type code is, in C/C++ parlance, an enumerated value- it's an ordered list of numeric values, each with an associated name, and these are defined in a publicly available file in the source code (ntsecapi.h). In the source code, the values are always referenced by name.
Today on one of the internal aliases someone actually found a logon event with a logon type of 0- I have never personally seen one of these before and 0 is not defined in the SECURITY_LOGON_TYPE enumeration, so I would have assumed that it was a bug- but it turns out that we are aware of this case and use it occasionally for system logons.
So there you are.
Well there has been a lot happening on my old project, ACS (Audit Collection Services, a feature of SystemCenter Operations Manager 2007).
Two more of our partners, Enterprise Certified and NetPro, have released compliance solutions on top of ACS.
Another of our partners with ACS-based compliance solutions, SecureVantage, has started a new blog where ACS is a frequent topic.
Anyway I'm pleased to see that ACS is becoming a successful platform and I'm happy to answer ACS questions! To you ISV's out there, Joseph and I welcome your questions as well (if we aren't already talking to you). Let us know who you are so we can stay in touch with you!
OK here's something I just remembered today. I may be the last person who remembers this so it's important that I record this somewhere.
In the RTM bits of Windows NT 4.0, for the German language release only, someone snuck in a string resource into the auditing message file. I'm guessing that it was one of our localization engineers, but I don't know- I was over in the support side of things at the time. I stumbled across the message one day while looking at source code.
Here's Björn's momentous message: "Björn grüßt den rest der welt". Basically Björn says hi to everyone. He's a friendly guy.
This is string resource zero in the message table resource- it's not a code resource, it's properly formed and it's not used by the code anywhere. You would not know it exists unless you slog through source code (like me) or use a hex editor or string dumper to analyze binaries AND happen to be so bored that you pull out an NT 4.0 RTM German CD and examine msaudite.dll. NT4 RTM CD's are pretty rare, btw, because we replaced them with slipstream SP1 CD's very shortly after release.
If I remember correctly somebody else came along in a later service pack and changed Björn's name to their own (maybe it was Ulli? I can't remember and I'm too lazy to find the source- it requires a lot of effort to dig that far back). I do remember that shortly thereafter there was a huge Easter Egg crackdown here at Microsoft probably brought to a head by the Excel 97 Flight Simulator. Björn's message of goodwill to mankind was erased forever.
I did a search using the Officially Santioned Search Engine and the other one too; evidently the internet has forgotten Björn's message. But I still remember, Björn.
Anyway I thought you might like this bit of arcana. If you are bored, have a hex editor and a German NT4 CD, knock yourself out...
I got the question last week, why there are so many logon failure events on Windows XP when it is not domain joined.
The short answer is, by design. (Yes, bad design.)
The longer answer is that the shell team is working around the fact that there is no "tell me if this user account has a blank password" API.
When in a workgroup (not domain joined), Windows XP displays a welcome screen that has little pictures (called "tiles") for each user who is permitted to log on to the computer.
The shell team wanted the experience that when you click on a tile, that you will immediately be logged on if your password is blank (we have good data that a large percentage of home users have blank passwords). They only want you to be prompted for a password if you actually have a password. Fair enough, and it also helps with accessibility for people for whom typing is challenging.
The XP Welcome Screen, when it is initialized each time it is to be displayed, attempts to log on each user for which a tile will be displayed, using a blank password. Users with non-blank passwords will cause failures in this case (other users will cause logon success events followed by logoff success events). [2007-11-21 correction]
The Welcome Screen uses the result of these logon attempts to decide whether to display a password box when you select a user's tile. If the user has a blank password, they will be logged on instead of being prompted for a password.
Why are they logging on the account? Well it turns out to be the easiest way to tell if your password is blank. We don't have a "is your password blank" API- that would be a security disaster- and we would prefer that the shell team not go mucking about in the SAM, retrieving hashes and computing the blank password hash for each account so that it could compare them.
I asked for this behavior to be changed prior to XP's release. Specifically I asked that the blank password check be moved from Welcome screen initialization to tile selection- this would still cause logon failures but many fewer of them. I was declined. I asked for fixes to it in SP1 and SP2 and was declined. At this point we will not be revisiting this "feature"; the Welcome Screen was redesigned to eliminate this problem.
The shell team who designed the Welcome Screen did not feel that auditing was a common scenario for workgroup machines, and I didn't (and still don't) have any business case to dispute that.
So a long time ago, back in my days of providing technical support for Windows NT 4.0, I published "Security Event Descriptions". This article was the "schema" so to speak, for the Windows NT 4.0 security event log events.
Technically Windows events are not schematized until Windows Vista; or put another way the schema is implicit based on the instrumentation in the code- since the event is raised by some function in the code, the "schema" could be interpreted as the parameter order in the call to that function.
Anyway security monitoring types love that article, but I hate it. It's just better than nothing. It doesn't state which events map to which audit policy categories. It does tell you whether the event is a succss or failure event but it doesn't alert you to the cases where the same event is used for success and failure (e.g. event 560).
When Windows 2000 came around and we added two new audit policy categories (DS Access and Account Logon [which was a huge naming blunder]), I wrote an article for the Windows 2000 security events. However it was so large I broke it into two articles.
I didn't write an article for Windows Server 2003. At first I didn't think it was necessary because we propagated all the WS03 events to the Technet Events & Errors Message Center web site. I wrote custom content for the top 30 or so events by volume of searches
(On a side note, did you ever wonder what happens when you click the "More Information" link at the bottom of the Event Viewer event description? We send the event source, event ID, OS version and so forth to the Technet E&E site and display the content that is returned. We count the number of hits for each OS Version/Source/Event ID combination and then our writing teams pester the component owners to populate that content.)
Anyway, I was making excu^h^h er, explaining why I didn't write the KB articles for Windows Server 2003 security events. So I thought the E&E message center would be all that anyone needed. It didn't strike me as that important that you had to have seen the event (or at least know it exists) before you could use the site. However since then I have received a large number of requests for the event definitions, mainly from people who were creating security event management solutions.
So here's what I have for you, courtesy of Ned, one of the audit log posse here at Microsoft. If you want a complete list of WS03 security events, then I suggest you look at chapter 4 of the Windows Server 2003 Security Guide. This documents the event IDs of all the security events on Windows Server 2003. Plus, it groups them by policy category, in case you ever wanted to know what you are in for if you enable one of the categories for audit. If you want the layout of the event (what data is in the description field, and in what order) then just look for that specific event on the Technet E&E site or click the link in the bottom of the event description in Event Viewer.
I've already described how the Vista and Windows Server 2008 (and subsequent releases) event systems are self-documenting, so I won't go into that further here.
One last tip: If you own Microsoft System Center Operations Manager 2007, then you can search for a file called EventSchema.xml on the media. It is an XML document that describes one possible normalization all the security events from Windows 2000 forward, and the semantic content of the normalized events.
2007-10-31 UPDATE: There is also an event-id-to-audit-policy-category map here.
A German court has ruled that a government web site may not retain IP addresses and other personally identifiable information (PII) in their logs for any longer than the user is actually using the site.
The judges pointed out that in many cases it was simple to map an IP address to an identity with the help of 3rd parties, and declared that logging IP addresses was a "violation of the right to informational self-determination."
OK whatever.
Germany does not seem to be of one mind regarding logging. On the one hand their draconian privacy laws (how's that for an oxymoron?) are pretty much in opposition to any meaningful user activity logging. On the other hand, their law enforcement folks at least seem to know the value of logs, even if they are a little draconian in the other direction. Finally the article above notes that even the Bundestag, the lower house of the German Parliament, doesn't comply with with the privacy laws that body created- the web site logs and retains PII.
Attention Germany: the privacy horse has left the barn. Technology has far outpaced the capability of an individual to control where his or her information flows. Expecting to both receive service from an online provider, and to remain "private" (whatever that means) from the provider, is unreasonable- and in fact denying the provider the right to log prevents the provider from systematically improving service to you. Logging is a best practice for administrative activity, including maintenance-related activities, marketing & service planning, and security-related activities such as forensics. Everything generates logs nowadays. It would probably be better to write laws restricting what can be done with logs rather than to outlaw logging. In this manner you could mitigate abuses such as those by the ambulance chasers but still provide organizations of all sorts, including the government itself, the information they need to do their jobs.
As I wrote about earlier, TorrentSpy, a file-sharing search engine, was ordered by a U.S. magistrate to enable logging on its servers and to subsequently make those logs available to the MPAA, the plaintiff in an illegal file-sharing lawsuit against TorrentSpy. They have lost their appeals and as a result have decided to block US IP addresses from their web servers (which will effectively ensure that no information interesting to the MPAA will reach their logs). This ruling also puts copyright law squarely at odds with privacy rights, as pointed out by the Electronic Frontier Foundation. The whole case seems to hinge on the fact that the judge interpreted the fact that information such as IP addresses temporarily reside in a computer's RAM as meaning that information is "stored" by the computer and therefore discoverable; many computer experts reject that argument. More analysis of the implications of the ruling are found here.
Researchers in the state of Ohio in the United States have discovered that by analyzing the logs produced (by law) from e-voting machines used in certain counties, they can determine the vote(s) each voter made. Further, the logs, by law, must be produced on demand, as part of our open elections process.
I haven't read the in-depth reports and analysis. It appears to me that the manufacturers of the voting machine anticipated the risk of vote correlation with voters and tried to mitigate it by separating the vote log from the voter log. However they mitigated this very poorly as (1) only one voter can apparently use the machine at a time and (2) every thing the machine does is logged and (3) every log entry is timestamped. So simply separating the "Voter X logged on" records into one log, and the "Vote cast for candidate Y" records into another log seems to be a pretty naive solution.
I normally try to stay away from politics and commentary on my blog, because I don't want to alienate anyone. But this is not a political issue. Here in the United States we have problems with elections. It doesn't matter which party you are in, there are things to be unhappy about. The machines we have built to make elections easier seem to have made things much harder- from the "hanging chads" we had in the 2000 elections to the current pain we're having with voting machine certification.
The audit trail problem with voting machines is daunting. How do you simultaneously accomplish the goals of (1) allowing only authorized individuals to vote (2) exactly once per election, regardless of location (4) the votes cannot be tampered with after being cast (or at least tampering is evident), (5) the votes can be tallied quickly (in a matter of only a few hours, (6) all of these steps can be accomplished in such a way that even if he voter wishes it, the vote cannot be correlated with the voter, and (5) a recount can reproduce all the same results with these same election characteristics (maybe we can relax the time window) without the voters physically being present.
Punch card and optical scan systems opt for auditing the voter before handing them the ballot, and the ballots themselves are the audit trail of the votes (and are not numerically linked with the voter). These systems would seem to be pretty foolproof but there are systemic problems with both: the hanging chads and butterfly ballot problems were with punch card systems, and optical scan systems in general have a fairly high error rate, and all of these problems are largely due to users who fail to follow instructions which are critical to accurate operation of the machines which tally the votes.
Coupled with the fact that many e-voting systems are getting poor reviews from security researchers, I would be much more comfortable as a voter slowing down on e-voting until we work out the kinks.
http://arstechnica.com/news.ars/post/20070811-iphone-bill-is-surprisingly-xbox-huge-lol.html
Fortunately for customers they strip out all the interesting details that would make it useful to, well, anyone.
From time to time I hear this, and it usually turns out not to be the case.
I'll begin with a little background.
First, The eventlog service does not have (and never did have) any public or private API to delete individual events- there is a log clear API but nothing else. The eventlog team thought about implementing selective delete for Vista (there were some internal groups asking for it) but a lot of us security types yelled at them and nothing came of it. Logs are logs, not databases- if you want selective delete, export the events you want to a database and have at it.
Second, there is no getting around the 10 Immutable Laws of Security, particularly law #6 (a computer is only as secure as the administrator is trustworthy) and law #2 (if a bad guy can alter the operating system on your computer, it's not your computer anymore).
What this means is that, no matter if we implemented the most advanced, coolest, 1337est event-signing/real-time-exporting/writing-to-optical-media-and-a-line-printer-too event system, IT DOESN'T MATTER IF THE ATTACKER IS THE ADMINISTRATOR- all we do is reduce the window of time that that person has to do his dirty work. Now I will admit there is value in those features, but if such an evil person were to use his powers of debugging to open the services.exe process (where eventlog lives) and inject a thread which alters the eventlog data structures in memory in real time, prior to commit to disk, then none of that stuff would help us. As a matter of fact such tools exist, they are not theoretical. I haven't seen the Vista versions yet but there's no technical reason why such a tool could not be built for Vista.
However, the cases I've seen of apparent gaps in event logs have a much more mundane explanation: the "Retain X days" event retention policy. This is an evil setting; if people truly understood it they wouldn't use it. Prepare to truly understand it.
<puts on lab coat>
Imagine you have a finite space S to store resources of type R. You get a constant incoming stream of R's, and put each of them into S. Now imagine that S is full and a new R arrives. You have two choices:
1. Throw the new R away.
2. Remove one or more of the old R's from S (enough so that the new R can fit into S) and put the new R into S.
When selecting which old R's to discard, the generally accepted best practice is that you should throw away the oldest R first- in other words freshness is a priority. Of course if you wanted to optimize for space you could just pick the smallest old R equal to or larger than the new R, but that would cause ordering problems if you wanted to maintain sequential access. You could even pick one or more old R's at random but that would be too arbitrary for most structured purposes like logging.
Now imagine that you had an additional constraint: you can throw away old R's, but only if they're more than X days old.
Now your choices are:
1. Throw the new R away, or
2. Throw away one or more of the old R's, if and only if there are enough R's that are older than X.
If there are no R's older than X, you may not discard any old R's and since you have a fixed size buffer S and there is no room for the new R, you MUST choose option 1- throw away the new R. You have no other choices.
This is the situation with event log. "Retain X days" actually CAUSES event loss (as does "Overwrite as needed"). However, Overwrite as needed causes predictable event loss (oldest events gone). Retain X days causes unpredictable event loss (if the log is full and there are no events older than X days, then NEW events are thrown away until there are some events older than X days).
Detecting gaps in your log
Can we detect if someone has deleted events out of your log?
At the end of the day, the event log is an ordered list of data structures (called event records), with each having a pointer to the next. There is also a unique, monotonically increasing sequence number associated with each event record.
A clever attacker will have disabled the instrumentation that causes the event to be raised; eventlog will never have been involved so there will be no gap (but no event).
A less clever or less resourceful attacker who deletes an event from the log, probably will not go fix up the sequence numbers for the rest of the log (in fact the attacker might not even fix up the pointers, causing the eventlog service to crash or hang).
We can use this priciple to our advantage. By examining each event and looking at its sequence number, we can look for gaps in the stream and, although we can never be sure that there was no tampering, we can often tell when there was tampering.
Here's a VBScript that demonstrates this concept. I don't provide VBScript support; you're on your own on this one.
