April 8, 2010
A Federal class action suit filed by Rosen, Bien & Galvin, out of San Francisco alleges that McAfee uses deceptive techniques to “trick” users into handing their credit card information to a third party partner.
After entering the information, previously undisclosed charges charges appear on the user’s credit bill. The suit alleges that when the user attempts to contact the third party to cancel the “service” they receive a recording that states it “does not offer cancellation or subscription services”.
The complaint also states that upon contacting McAfee the users are told that the AV software company cannot do anything about the charge.
Add this one to the “One More Reason McAfee Sucks” category, and file under “Dirt Rat Bastards”.
Class Claims McAfee Pulled A Fast One
April 6, 2010
On March 31 the DEA published a proposal to allow electronic prescriptions for narcotics (Docket No. DEA-218I).
The effective date for this is June 1, 2010 pending congressional review. The RFC section gives insight into how they plan to implement (bold text added by yours truly): Identity proofing, access control, authentication, biometric subsystems and testing of those subsystems, internal audit trails for electronic prescription applications, and third-party auditors and certification organizations.
It looks like there will be a requirement to be “certified” to perform electronic fill of narcotic prescriptions, but is that really enough (think Heartland)?
There are several really interesting tidbits that can be derived from this document that I did not realize:
1. “The responsibility for the proper prescribing and dispensing of controlled substances is upon the prescribing practitioner, but a corresponding responsibility rests with the pharmacist who fills the prescription.” – This makes sense, but also indicates that they will likely follow a path where the responsible parties determine the means by which they accomplish an outline of requirements surrounding security related to narcotics prescription. Ask yourself this: Did HIPAA end internal patient record theft?
2. “[M]ost electronic prescriptions are routed from the electronic prescription or EHR application through intermediaries, at least one of which determines whether the prescription file needs to be converted from one software version to another so that the receiving pharmacy application can correctly import the data. There are generally three to five intermediaries that route prescriptions between practitioners and pharmacies.” – This points to the lack of standards, potential for screw ups and also multiple points of potential abuse.
I am still reviewing the text document (it is long) but I am also preparing and educating myself in this area – I feel some cases coming.
Original Federal Register Text:
FR Doc 2010-6687
March 16, 2010
A recently released survey finds 83% of financial firms use production data for testing. What this means (for the non-developers) is that your customer data is used unmasked and in its full form to test systems that, by the very fact that they should be TEST systems, have an unknown level of security and integrity.
Even though the study was commissioned by a company that works specifically with data protection in test environments (important to call out bias!), I believe the numbers on this one – especially when I go back and research the number of financial institution data breaches that have occurred because “live” customer data sets were in the hands of a third party contractor, or other employee off-site.
I have done development work on health data and I understand full well the challenges of creating meaningful data sets (as well as the enormous expense) for testing purposes. The bottom line comes to this: There is no excuse that justifies exposing personal data in this manner. Period.
In performing penetration tests a common tactic that we use during the “recon” phase is to look for servers that are obviously development systems. We do this because patch levels and security are typically at a minimum on these systems and they are usually the “low hanging fruit”.
So it makes me wonder – just what justification can possibly make these guys think this is OK?
Here are some more stats from the study that should give you pause:
- identity compliance procedures (used by only 56 percent of companies surveyed);
- intrusion detection systems (used by only 47 percent of companies surveyed);
- data loss prevention (DLP) technology (used by only 41 percent of companies surveyed); and
- Social Security number usage (88 percent of those surveyed still use this as a primary identifier)
Remember these findings the next time you read a news release regarding a financial institution data breach and some chuckle-head says that they are quite certain no sensitive data was taken or misused. The very next question to ask is: How would you even know?
March 10, 2010
George Jenkins, the writer for the “I’ve Been Mugged” blog (http://ivebeenmugged.typepad.com) writes about a recent survey release discussing medical identity theft. While this has been going on for a while (I had my first case involving electronic MedID theft 8 years ago) it serves as an excellent proactive warning: THINK about any and all information systems that you give your ID to and QUESTION the flow of information. We are not living in an age where blind trust/acceptance is acceptable.
The study was performed by the Poneman Institute and sponsored by Experian. One of the Privacy analysts with Poneman was quoted (emphasis added):
“The two results that stood out to me were the more than $20,000 average cost to consumers who suffered ID/credit fraud as a result of a medical data breach, as well as the potential for physical harm to those who have their medical records ‘polluted’ due to healthcare fraud,” says Mike Spinney, a senior privacy analyst at Ponemon Institute.
The residual issue of “physical harm’ due to a corruption of medical records gives plenty to ponder – especially given the efforts to aggregate medical records in an electronic environment. Also particularly interesting are the number of people that were aware they had a problem and did not report it. I wonder about the psychology of that.
By the way – George is an excellently informed writer on these types of stories, and his blog is definitely worth a follow.
George Jenkins’ Link:
August 17, 2009
I picked up the following from SC Magazine:
University College Berkeley hit by second data breach in six months
The standout here is the quote:
“…a website hacker may have had access to their social security numbers and birthdates.”
This could simply be sloppy reporting, but if it is true that someone accessed the PII via the Journalism School website then this is a fundamental architecture flaw and probably a rookie information security mistake.
April 3, 2009
IMPORTANT INFORMATION REGARDING: Microsoft PowerPoint Vulnerability
A vulnerability has been discovered in various software versions of
Microsoft PowerPoint. Exploitation of this vulnerability can lead to
code execution at the rights level of the logged in user. No patches or
workarounds have been released.
Microsoft has stated that exploit attempts have been seen in the wild,
on a limited/targeted basis.
Microsoft Office 2000
Microsoft Office 2003 Professional Edition
Microsoft Office 2003 Small Business Edition
Microsoft Office 2003 Standard Edition
Microsoft Office 2003 Student and Teacher Edition
Microsoft Office 2004 for Mac
Microsoft Office XP
Microsoft PowerPoint 2000
Microsoft PowerPoint 2002
Microsoft Powerpoint 2003
As previously stated, successful exploitation limits malicious code
execution to the rights of the logged on user. Steps should be taken to
ensure permissions for various account types are regulated per
Successful exploitation of this vulnerability requires user interaction
with the specially crafted PowerPoint file. Users would therefore have
to to click links in malicious e-mails, or otherwise convinced to visit
websites hosting malicious PowerPoint files. The best defense against
this is educating users on the dangers of accepting files and acting
upon links to websites provided to them via e-mail, IM, or other means
from unknown parties.
Microsoft Security Advisory (969136)
March 4, 2009
Information Week Article
I was sure that the concept of “security through obscurity” had been thoroughly debunked by now, evidently not.
A recent Freedom of Information Act request for a list of .gov domain names was denied by the GSA. You should know this about me: I am all for state secrets – I think that, realistically, a government must have secrets. This is perhaps an argument for another day.
Given the nature of DNS, cached DNS, etc. how long do you think before some of these “hidden” domains show up anyway?
Let’s be clear: I really don’t think this is a huge deal, but it can be a source of mental fun for the rest of us. So here is a “wake up it is hump day” mental exercise for you (This WILL be graded, you WILL need to know this for the test!):
What would be a more effective “security through obscurity model” for the government to use, while still listing the required domains?
I will start the ball on this (and therefore open myself up to immediate criticism!):
- Register the domains as normal, but do not use obviously descriptive names: Instead of “trackingPrivateCitizens.gov” you might use “TPCProject.gov”, you may even consider using a completely sanitized CRC32 version: 13201934.gov (Free Vidoc Razor T-shirt if you can figure that one out).
- Keep an internal, classified document that maps out the “sanitized domains” with their true descriptions.
How would you set out to discover these “hidden” domains?
- We will assume zone transfer is not available (Could be a big assumption).
- Build a database of known domain names.
- What next?
Feel free to post any ideas – or chide me for wasting your time and making you read this cruft!
February 26, 2009
Adobe released a fix for its Flash Player yesterday that mitigates 5 different attack vectors. Some of the flaws could allow a malicious attacker to take over a compromised system merely by enticing a user to a page with a compromised .swf (Flash) file.
Flash player 10.0.12.36 and earlier for:
Windows, Mac OSX, Linux
Adobe Security Bulletin:
Patch for v. 10
Patch for v. 9
Make sure to patch each browser that you have installed. You can do this by visiting the patch link each time for each browser.
February 24, 2009
IMPORTANT INFORMATION REGARDING:Microsoft Excel Vulnerability.
It has been reported that a vulnerability existing in Microsoft Excel
is being exploited in the wild. Exploitation of the vulnerability
involves interaction with Excel spreadsheets specially crafted by
malicious users. Successful exploitation may allow code execution at
the permissions level of the logged in user, whereas unsuccessful
exploitation may result in a DoS condition.
**UPDATE** MS has confirmed the following versions as vulnerable:
Microsoft Office Excel 2000 Service Pack 3
Microsoft Office Excel 2002 Service Pack 3
Microsoft Office Excel 2003 Service Pack 3
Microsoft Office Excel 2007 Service Pack 1
Microsoft Office Excel Viewer 2003
Microsoft Office Excel Viewer 2003 Service Pack 3
Microsoft Office Excel Viewer
Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats Service Pack 1
Microsoft Office 2004 for Mac
Microsoft Office 2008 for Mac
No patches or workarounds have been issued for this vulnerability.
Alternative methods of mitigation can include educating end users on
the hazards of interacting with Excel files (or any files) received
from unknown sources. If Excel files are not a part of day to day
business practices, it may also be possible to block incoming Excel
files at an appropriate firewall and/or mail server. Ensuring user
permissions are set appropriately may also be beneficial. In the event
of successful exploitation, a user with limited permissions will suffer
less impact than accounts working with full administrator priveledges.
Due to the lack of a software fix to this vulnerability, we recommend
alerting end users about the presence of this vulnerability, and taking
any other mitigation steps that are appropriate for your work
environment. We will be keeping a close eye on this situation, and will
send notification once patches/workarounds are available.