It’s a Trap!! Infected Microsoft Word Files Exploiting Unpatched Vulnerability

April 11, 2017

itsatrap.jpegA new virus is ‘in the wild’ that exploits a ‘zero-day’ vulnerability to infect or, worst case, wipe computers. The only known mitigation is to not download or view the infected files.  One may also view the files using ‘Protected View’, which has been reported to work in this case. Opening the file outside of Protected View will infect the system, however.

Note: Disabling ‘Macros’ does not protect against this exploit. The exploit bypasses most system protections, including the tools built into Windows 10.

The infected word document arrives via email.  Once opened, it downloads malicious code from a remote site, and installs various malware payloads. The virus actually opens a ‘decoy’ Word document in an attempt to cover its behavior.

A patch is expected today, but patches are useless if they are not applied. The patch will likely be issued only for Windows 7,8,10.  Older Windows versions will likely still be vulnerable.

At a Glance:

Threat Level:     HIGH
Delivery Method:     Email
Infection Vector:     MS Word Document:  .doc, .docx, .rtf
Infection Type:     Various malware libraries
Vulnerable:     All Windows Versions. All Office versions.

Actions:

1- Communicate and Educate: Make sure ALL users are aware

2- Until patch is applied:  Utilize Protected View to view documents

You (or IT support) may also change registry files to automatically open documents in Protected View.

3- Pay attention to patch cycle. MicroSoft’s standard patch day is today. Make sure patches are applied and operational.

Outside Links:

Ars Technica


‘Shellshock’ In Plain English: Latest Security Vulnerability is a Big One

September 25, 2014

Many network administrators and information security folks are feeling the effects of the ‘Shellshock’ bug, this morning.  The bug has been confirmed as ‘worm-able’, and proof-of-concept code is already bouncing around.
(source: Errata)

In many ways, Shellshock is worse than Heartbleed.  Here is a quick, plain English breakdown of the vulnerability:

What Shellshock Is:

It’s an attack that does not require the attacker to ‘authenticate’ to the system or server being attacked.  In other words- the attacker does not have to have a username/password, or break passwords.

What the attacker can do:

Everything up to full control of the compromised device/system/server.

What Shellshock affects:

Linux, Mac OS/X or any device that uses a ‘Bash’ Linux command-line (most internet connected devices).

If you read that it only affects Linux systems/servers- don’t breathe a sigh of relief just yet!  Most of the ‘Internet-of-things’ devices (Cameras, refrigerators, TVs, etc.) use a form of Linux, and are potentially vulnerable.  In addition, if you are running ‘SOHO (Small Office/Home Office)’ wireless access points, managed switches, and routers, or if you are using a store-bought Firewall/Cable modem then you may be vulnerable.

If you rely on IT support, and they tell you that there is ‘No problem- we don’t allow shell or terminal access to the outside world’, then you need to point out to them that is not the entire attack vector:  Any process, or program that IS accessible, that sends commands to the shell, is potentially vulnerable.  It is not always obvious which programs or services do this, behind the scenes.

So what can be done?

Review and Confirm: Check your systems, servers, and devices to see if they are, in fact, potentially vulnerable.

Patch:  A number of the primary Linux shell versions had patches available within hours.

Keep an eye out for firmware updates for your internet devices: Internet connected TVs, Wifi access points, SOHO-class firewalls, Network storage devices, internet connect cameras, etc.

Kill Non-essentials: Consider turning off, or disconnecting, non-essential ‘internet-of-things’ devices until a patch is available for them.

BE ALERT FOR PHISHING SCAMS:  So-called ‘spear phishers’, and scammers of every ilk, like to use these well-publicized security issues to trick people into downloading malicious programs.  Always deal with a known security site, or directly with the manufacturer.

USEFUL READING:

Patch NOW (the Register)

Shellshock bug (the Mirror)

TECHNICAL: CVE-2014-6271 (NIST.gov)

TECHNICAL: OSS Write-up


Making Sense of “Heartbleed”: Information Security Catastrophe/Nightmare

April 11, 2014

The term “Internet Security Nightmare” has been used.  This is not an exaggeration, and not an example of hyperbole; Heartbleed is a security catastrophe that cuts a wide swathe across the internet.

If you are not aware of the recently discovered Heartbleed flaw: An extremely critical security flaw has been identified in a cryptographic software component that affects an estimated two-thirds of Web servers, as well as many devices and programs that rely on the software component.  The flaw has been nicknamed “Heartbleed” because of the methodology used to exploit it.  The flaw allows an attacker to retrieve active contents in memory, including private security keys, unencrypted information, and usernames and passwords.

The Heartbleed flaw affects a software module that is in use by everything from routers and web servers, to some phones and devices.

Here are some steps you should take now to give yourself a fighting chance against this flaw:

1) Examine your own practice first:  Are you using hosted email, providing client portals, file upload services, or other web- or internet- enabled services for your clients?  If the services offer SSL, or access using encryption then you need to check with your hosting provider or IT company to confirm that they have patched, or otherwise mitigated the issue.

2) Change your passwords AFTER you have confirmed the service has been fixed: This flaw is being actively exploited.  If you change your password BEFORE the service is fixed, then you are still at risk.  Confirm first, change after.

3) Be aware of “password re-use”:  This flaw has existed for 2 years, and has only now come to light.  Some companies have gone back to review logs, and have found active attacks against this flaw from before March.  If you use the same password in multiple locations, then it is time to change all your passwords.  Recommended reading:   Because One Thing Leads to Another: Data Breach and Password Re-Use

I have included a simple chart below, as an example of high profile services to review (source: Mashable):

Social Networks

Was it affected? Is there a patch? Do you need to change your password? What did they say?
Facebook Unclear Yes Yes “We added protections for Facebook’s implementation of OpenSSL before this issue was publicly disclosed. We haven’t detected any signs of suspicious account activity, but we encourage people to … set up a unique password.”
LinkedIn No No No “We didn’t use the offending implementation of OpenSSL in http://www.linkedin.com or http://www.slideshare.net. As a result, HeartBleed does not present a risk to these web properties.”
Tumblr Yes Yes Yes “We have no evidence of any breach and, like most networks, our team took immediate action to fix the issue.”
Twitter Unclear Unclear Unclear Twitter wrote that OpenSSL “is widely used across the internet and at Twitter. We were able to determine that [our] servers were not affected by this vulnerability. We are continuing to monitor the situation.”Twitter has not yet responded to Mashable‘s request for comment.

Other Companies

Was it affected? Is there a patch? Do you need to change your password? What did they say?
Apple Unclear Unclear Unclear Apple has not yet responded to a request for comment.
Amazon No No No “Amazon.com is not affected.”
Google Yes Yes Yes “We have assessed the SSL vulnerability and applied patches to key Google services.” Search, Gmail, YouTube, Wallet, Play, Apps and App Engine were affected; Google Chrome and Chrome OS were not.*Google said users do not need to change their passwords, but because of the previous vulnerability, better safe than sorry.
Microsoft No No No Microsoft services were not running OpenSSL, according to LastPass.
Yahoo Yes Yes Yes “As soon as we became aware of the issue, we began working to fix it… and we are working to implement the fix across the rest of our sites right now.” Yahoo Homepage, Yahoo Search, Yahoo Mail, Yahoo Finance, Yahoo Sports, Yahoo Food, Yahoo Tech, Flickr and Tumblr were patched. More patches to come, Yahoo says.

Email

Was it affected? Is there a patch? Do you need to change your password? What did they say?
AOL No No No AOL told Mashable it was not running the vulnerable version of the software.
Gmail Yes Yes Yes “We have assessed the SSL vulnerability and applied patches to key Google services.”*Google said users do not need to change their passwords, but because of the previous vulnerability, better safe than sorry.
Hotmail / Outlook No No No Microsoft services were not running OpenSSL, according to LastPass.
Yahoo Mail Yes Yes Yes “As soon as we became aware of the issue, we began working to fix it… and we are working to implement the fix across the rest of our sites right now.”

Stores and Commerce

Was it affected? Is there a patch? Do you need to change your password? What did they say?
Amazon No No No “Amazon.com is not affected.”
Amazon Web Services(for website operators) Yes Yes Yes Most services were unaffected or Amazon was already able to apply mitigations (see advisory note here). Elastic Load Balancing, Amazon EC2, Amazon Linux AMI, Red Hat Enterprise Linux, Ubuntu, AWS OpsWorks, AWS Elastic Beanstalk and Amazon CloudFront were patched.
eBay Unclear Unclear Unclear “The vast majority of our services were not impacted and our users can continue to shop securely on our marketplace.”
GoDaddy Yes Yes Yes “We’ve been updating GoDaddy services that use the affected OpenSSL version.” Full Statement
PayPal No No No “Your PayPal account details were not exposed in the past and remain secure.” Full Statement
Target No No No “[We] launched a comprehensive review of all external facing aspects of Target.com… and do not currently believe that any external-facing aspects of our sites are impacted by the OpenSSL vulnerability.”

Banks and Brokerages

Was it affected? Is there a patch? Do you need to change your password? What did they say?
Bank of America No No No “We’re currently taking precautions and steps to protect customer data from this threat and have no reason to believe any customer data has been compromised in the past.”
Chase No No No “These sites don’t use the encryption software that is vulnerable to the Heartbleed bug.”
E*Trade No No No E*Trade is still investigating.
Fidelity No No No “We have multiple layers of security in place to protect our customer sites and services.”
PNC No No No “We have tested our online and mobile banking systems and confirmed that they are not vulnerable to the Heartbleed bug.”
Schwab No No No “Efforts to date have not detected this vulnerability on Schwab.com or any of our online channels.”
Scottrade No No No “Scottrade does not use the affected version of OpenSSL on any of our client-facing platforms.”
TD Ameritrade No No No TD Ameritrade “doesn’t use the versions of openSSL that were vulnerable.”
TD Bank No No No “We’re currently taking precautions and steps to protect customer data from this threat and have no reason to believe any customer data has been compromised in the past.”
U.S. Bank No No No “We do not use OpenSSL for customer-facing, Internet banking channels, so U.S. Bank customer data is NOT at risk.”
Wells Fargo No No No No reason provided.

Government and Taxes

Was it affected? Is there a patch? Do you need to change your password? What did they say?
1040.com No No No “We’re not vulnerable to the Heartbleed bug, as we do not use OpenSSL.”
FileYour Taxes.com No No No “We continuously patch our servers to keep them updated. However, the version we use was not affected by the issue, so no action was taken.”
H&R Block Unclear No Unclear “We are reviewing our systems and currently have found no risk to client data from this issue.”
Healthcare .gov Unclear Unclear Unclear Healthcare.gov has not yet responded to a request for comment.
Intuit (TurboTax) Yes Yes Yes Turbotax “has examined its systems and has secured TurboTax to protect against the “Heartbleed” bug.” Full Statement
IRS Unclear Unclear Unclear “The IRS continues to accept tax returns as normal … and systems continue operating and are not affected by this bug. We are not aware of any security vulnerabilities related to this situation.”

Other

Was it affected? Is there a patch? Do you need to change your password? What did they say?
Dropbox Yes Yes Yes On Twitter: “We’ve patched all of our user-facing services & will continue to work to make sure your stuff is always safe.”
Evernote No No No “Evernote’s service, Evernote apps, and Evernote websites … all use non-OpenSSL implementations of SSL/TLS to encrypt network communications.”Full Statement
LastPass Yes Yes Yes “Though LastPass employs OpenSSL, we have multiple layers of encryption to protect our users and never have access to those encryption keys.”
Netflix Unclear Unclear Unclear “Like many companies, we took immediate action to assess the vulnerability and address it. We are not aware of any customer impact.”
OKCupid Yes Yes Yes “We, like most of the Internet, were stunned that such a serious bug has existed for so long and was so widespread.”
SoundCloud Yes Yes Yes “We will be signing out everyone from their SoundCloud accounts … and when you sign back in, the fixes we’ve already put in place will take effect.”
Spark Networks (JDate, Christian Mingle) No No No Sites do not use OpenSSL.
Wunderlist Yes Yes YesYes “You’ll have to simply log back into Wunderlist. We also strongly recommend that you reset your password for Wunderlist.”Full Statement

Because One Thing Leads to Another: Data Breach and Password Re-Use

June 27, 2012

Dropping Your Breaches…

After the data breach of LinkedIn two weeks ago (6.5 million passwords leaked, a five million dollar lawsuit on the way), I have asked a simple question of some of my clients that I know are LinkedIn users: “Have you changed ALL your passwords yet?”.

The question has been met with confusion (“What data breach?”) and, in most cases, with indifference (“I don’t see what benefit having access to MY LinkedIN would provide a hacker.”). When I mention the phrase “password re-use”, I receive an almost universal response of “huh?”.

Single Point of Failure

Password re-use is seemingly an ingrained response to the presence of a password: You have hundreds of password protected resources, so it is natural that you would re-use the same password across multiple (or all) of those resources. This is the problem.

From the point of view of a hacker the world looks a little wider:

1- Breach LinkedIN passwords

2- Now leverage the email addresses, username conventions, etc. to test the password on:

Workplace accounts – Obvious information on LinkedIN. This could include work email systems, vpn access, extranets, etc.

Gmail and other webmail accounts – Possibly contains password/access information to online banking, work, other accounts

Mobileme and other “Cloud” services – Dropbox, anyone?

Online Banking – A pretty obvious target.

You can see how the seemingly “insignificant” breach can lead to much bigger issues.

In the case of the LinkedIN breach, the information obtained was posted for download by anyone that wanted to take a whack at them. Consider the scenario of an opposing party downloading your breached information and leveraging it for further access.

We know that information security is a balance between usability of information and systems, and security of those same areas. So how does one maintain separate use passwords but still easily access needed resources?

So Now What?

Fortunately there are some solutions. I have listed the top ones below:

Password Safe  (also known as PWSafe) – Windows, iPad, iPhone, Mac, Linux: This is actually my favorite. Syncing among the devices is supported by iCloud (of course then you need to make sure that Apple iCloud isn’t breached) so that a change on one device is rolled out to all the others. Password Safe is free for Linux and Windows (it’s always a nice thing to do to donate to the open-source team that keeps it going and evolving, though). The PWSafe version is $3.99 for Mac and $1.99 for iPad/iPhone.

LastPass  – Windows, Linux, Mac, iPhone, iPad, Android, PocketPC:  LastPass is perhaps the most “feature rich” password management systems out there, and even offers password management for common web-based forms. There is a free and premium version. The premium version runs $1 per month.

KeePass  – Windows, Mac, Linux, iPhone, PocketPC, Android: KeePass uses very strong encryption (SHA-256). It interested me for a couple reasons: Multiple user support and it keeps the password encrypted even in RAM memory. The only reason I don’t use this one is that I don’t find synching to be as transparent, and I was already in the habit of using Password Safe (since it’s creation by Bruce Schneier). KeePass is free for the desktop versions (I recommend donations to the open-source team that keeps it running).

So the question becomes: “How would you and your firm like to be at the center of a multi-million dollar lawsuit that could have been prevented by a series of easy to use software that costs nothing to use?”.

Coming next week: Information security breaches for law firms are on the rise. How vulnerable are you, and what easy steps can you and your firm take to defend yourself?


Stripping Anonymity From the Internet

January 13, 2011
Stripping anonymity is like peeling an informational onion. It is about tying together otherwise benign pieces of information that, in the aggregate, allow you to identify, uncover, and infer the existence of other pieces of information. 

Pieces of information across the internet can be pulled in from so-called “Dark web” sources (sounds sexy, right? It actually just refers to information that is contained in databases that are not indexed by search engines), public records, search engine indexed information, metadata information contained in posted documents (photos, PDF docs, various graphics formats, etc.), online newsgroups, social media sites to name a few.

Using these pieces of information to uncover locations, associations, activities, behaviors and motives is entirely possible (and, in fact, is done every day in active investigative work), but not in every case. As you may imagine, it is easy for the thread to get broken and for a logical disconnect to occur. The trick is to combine inductive and deductive reasoning with the real information you find, and then to develop theories about other possibly available pieces of information and test those theories.

At a certain point any investigation, electronic or otherwise, will likely require “boots on the ground” to verify assumptions.

For your reading pleasure I’ve provided a link to a popular story back in 2006 about the accidental release of “anonymous” search results by AOL and the subsequent work done by a NY Times reporter in using aggregated information about search queries to strip anonymity.

http://select.nytimes.com/gst/abstract.html?res=F10612FC345B0C7A8CDDA10894DE404482

Wikipedia entry on the same incident:

http://en.wikipedia.org/wiki/AOL_search_data_scandal

DEA Proposes Allowing Electronic Prescriptions for Narcotics

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


Financial Institutions Using Live Data Sets in Test Environments

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?

Sources:

http://money.cnn.com/news/newsfeeds/articles/globenewswire/185342.htm

http://cpwr.client.shareholder.com/releasedetail.cfm?ReleaseID=448389