From Wikipedia:

Responsible disclosure is a computer security term describing a vulnerability disclosure model. It is like full disclosure, with the addition that all stakeholders agree to allow a period of time for the vulnerability to be patched before publishing the details.

While there is a fair amount of debate over what is considered a reasonable period of time to allow this to happen, or even sometimes what constitutes a vulnerability, most people I know in the industry generally agree that responsible disclosure is a good thing overall.

The responsible disclosure process allows the software and services we rely on every day to get better and more resilient to malicious actors who regularly look to subvert these systems for their own gain. As an employee of Check Point, I see both sides of this debate: as both a receiver of security vulnerability reports from the community and as a discloser of vulnerabilities to other organizations.

I’ve been directly involved with a couple of vulnerability disclosures related to Check Point products. While I can’t get into specifics, overall I believe issues are respond to quickly and appropriately.

To speak to the other side, Check Point does find and disclose vulnerabilities in third party products as part of its ongoing security research. Some recent examples include:

• Issues in Wordpress Core involving privilege escalation, SQL Injection, and page generation – patched in WordPress 4.3.1 and above
• “MaliciousCard” Vulnerabilities in WhatsApp which allowed remote code execution on victim computers
• A privacy issue in iOS versions prior to 9.0 whereby user credentials could be exposed on devices where the end user has logged out of their Apple ID on the device – it should be noted this was disclosed to Apple 8 months prior to the release of iOS 9.

Check Point’s research includes products that compete with Check Point in the marketplace. The latest example is a complete block bypass in Cisco Firepower. You can see a proof of concept video here:

As noted at the beginning of the video, the disclosure of this issue happened back in November 2015 and was remediated by Cisco today (30 March 2016), 134 days after it was initially disclosed. Nothing was disclosed publicly by Check Point until this date. Check Point worked closely with Cisco PSIRT, who was cooperative and professional throughout the entire process.

While there may be some competitive benefit to this research into competitive products, it really speaks more to the fact Check Point wants to see better security for everyone, not just those who happen to be Check Point customers. I think Mahatma Gandhi said it best:

“The best propaganda is not pamphleteering, but for each one of us to try to live the life we would have the world live.”

Check Point is leading the responsible disclosure debate by example here. It’s one of the things that makes me proud to work for Check Point.

I remember when Macro viruses in Microsoft Word were a thing more than a decade ago. They’re definitely back with a vengence, and carrying far more dangerous payload than the Macro viruses of old. A couple recent examples are the Locky Ransomware and PowerSniff.

Microsoft disables Macros by default when you open documents in current versions of Microsoft Office. That said, it makes it very easy to enable them. Sometimes, malware-infested documents include text like this in them:

Despite these very sketchy looking documents, people actually enable macros and before you know it, their system is infected with malware and you have a potential problem on your hands.

Is this really how it plays out? It depends on what other controls you have in your environment.

Check Point and Palo Alto Networks both claim to provide protections for these kinds of threats. However, not all protection is equal. From PowerSniff Malware Used in Macro-based Attacks:

Palo Alto Networks WildFire customers are protected against this threat, as all encountered files have been correctly flagged as malicious. Additionally, all C2 domains currently encountered have also been marked malicious. AutoFocus users can identify this malware using the PowerSniff tag.

Is it really protection? From Palo Alto’s documentation on WildFire with emphasis added by me:

The key benefits of the Palo Alto Networks WildFire feature are that it can discover zero-day malware in web traffic (HTTP/HTTPS), email protocols (SMTP, IMAP, and POP), and FTP traffic and can quickly generate signatures to protect against future infections from the malware it discovers. WildFire will automatically generate a signature based on the malware payload of the sample and tests it for accuracy and safety. Because malware evolves rapidly, the signatures that WildFire generates will address multiple variants of the malware. As WildFire detects new malware, it generates new signatures within 15-30 minutes.

Considering how easy it is to take a malicious file and change it so the file hash is not known, this is not a serious hurdle. More importantly, it means the proverbial Patient Zero who opens the file and enables macros is infected.

Check Point takes this a step further. In addition to blocking a file that is known to be bad by a signature/file hash and emulating the file to see if it’s bad, the file is actually held while it is emulated. If the file is determined to be malicious, the file is not delivered to the end user, and appropriate indicators are delivered to ThreatCloud so others can benefit.

While the file is being emulated, Check Point can also provide a reconstructed file to the end user that contains no macros. This is what Check Point calls Threat Extraction. In fact, I experienced this today when I received an email from a customer containing a Word Document. The email contained the following warning:

1
2
3
4
5
________________________________________
This email's attachments were cleaned of potential threats by Check Point Gateway.
Agenda Draft2.pdf : files(s) were successfully converted to PDF 
Click here if the original attachments are required (justification needed). 
________________________________________

Instead of being delivered the original Word document, I was delivered a PDF that had the basic content of the file rendered in a harmless form. No option to enable macros at all.

What if it turns out the file was genuine and I actually need the original? There’s a link so I can download it, after confirming I trust the source. If the file actually was infected and Check Point’s Threat Emulation detected that, I would not be able to download it.

Sure, Threat Emulation could consider the file clean and it turns out not to be, but the chance of that is pretty low. Even so, you’ve added additional hurdles to prevent Patient Zero from getting infected in the first place. And, in case it happens, it’s now a lot easier to track down who Patient Zero is.

Microsoft Office documents aren’t going anywhere, and neither are macro viruses. Make sure whatever solutions you deploy to protect against these threats have the ability to immediately block threats inline, even if there is no signature for the threat. Controls should be deployable inline and on managed endpoints for maximum protection.

Disclaimer: As noted above, my employer Check Point Software Technologies has a dog in this hunt with their SandBlast Zero-Day Protection offering. These thoughts, however, are my own.

​In the information security business, we are always trying to stay one step ahead of the threats out there. Sometimes, the threats come from our own misconfigurations or lack of security controls, other times it comes from pushing the boundaries of what is acceptable in a given protocol allowed through a security control, eliciting a specific reaction which allows a hacker to obtain their objective (namely, getting a foothold in your environment).

The HTTP Evader test suite demonstrates techniques that can be used to bypass detection by various inline security tools. Specifically it uses HTTP in unique ways to obfuscate malicious code so it can not be detected by a security gateway. The “malicious” code, in this case, is the EICAR virus, which any antivirus or antimalware scanner will detect. With a more malicious payload, these same techniques could easily result in a malware-infected endpoint.

HTTP Evader should not be confused with the well-known Evader tool originally released by Stonesoft. Since it seems to have disappeared from the Internet, I made a copy of it available. Both tools operates on similar principles, though the focus of the Stonesoft/McAfee tool is far broader than HTTP traffic. Perhaps the reason one tool was confused for the other stems from the fact that both tools were used to demonstrate bypasses in Palo Alto Networks gear (as well as others).

The Stonesoft tool uses techniques noted by the SANS Institute in a whitepaper called Beating the IPS. At the time this video was produced, Palo Alto Networks was vulnerable to these issues. As of Version 549 of their Application and Threat Content, a full three years after the SANS Institute paper was published, these issues are finally fixed.

The HTTP Evader tool is shown below. The video was posted in December 2015 and, to my knowledge, Palo Alto Networks gear is still vulnerable to the issues demonstrated:

If you’re a Check Point customer? You’re covered. Refer to the following SK articles for more details:

• Check Point Response to Stonesoft IPS Evasion Techniques published on June 14, 2011
• Check Point Response to HTTP Evader (http://noxxi.de/research)

Keep in mind that both Evader tools merely demonstrate known techniques to evade detection by modern security tools. Surely new evasion techniques will be developed, which will hopefully cause security vendors to react and update their products accordingly. I think it’s safe to say Check Point will be at least one step ahead of Palo Alto Networks in keeping up with new developments in this area.

Disclaimer: My employer Check Point Software Technologies may or may not have differing views on this topic. These thoughts are my own.

Edited to add a link to the Stonesoft Evader tool on 5 March 2016.

While there are definitely bigger issues at play in the case of Apple vs. The FBI, issues that have been discussed ad-infinitum, there’s actually something a bit more innocuous to look at, and it was discussed on my favorite podcast, No Agenda, hosted by Adam Curry and John C. Dvorak.

Recall that the actual court order is asking for Apple to make it possible on a specific device to allow the PIN code to be brute-forced in an automated fashion without introducing unnecessarily delays and without wiping the device after 10 missed guesses. This is because the PIN code unlocks the encryption key for the device, which would allow the FBI to access the device.

To explain how this works, I’ll quote from Apple’s iOS Security Guide for iOS 9:

The passcode is entangled with the device’s UID, so brute-force attempts must be performed on the device under attack. A large iteration count is used to make each attempt slower. The iteration count is calibrated so that one attempt takes approximately 80 milliseconds. This means it would take more than 5½ years to try all combinations of a six-character alphanumeric passcode with lowercase letters and numbers.

The stronger the user passcode is, the stronger the encryption key becomes. Touch ID can be used to enhance this equation by enabling the user to establish a much stronger passcode than would otherwise be practical. This increases the effective amount of entropy protecting the encryption keys used for Data Protection, without adversely affecting the user experience of unlocking an iOS device multiple times throughout the day.

To further discourage brute-force passcode attacks, there are escalating time delays after the entry of an invalid passcode at the Lock screen. If Settings > Touch ID & Passcode > Erase Data is turned on, the device will automatically wipe after 10 consecutive incorrect attempts to enter the passcode. This setting is also available as an administrative policy through mobile device management (MDM) and Exchange ActiveSync, and can be set to a lower threshold.

It’s tricky to provide very high security for devices while at the same time maintain usability. This is a classic case of balancing convenience and security and Apple should be lauded for their efforts here. With all of these limitations Apple puts in place, including the end user enabling the “Erase Data after 10 failed passcode attempts” option, even a 4-digit PIN can provide a reasonable balance between usability and security.

That said, I generally agree with Adam Curry’s assessment in that a 4-digit PIN code isn’t really that secure. This is because end users generally pick PIN codes that are easy to guess if you know even a little bit about the person in question. Given the passwords people choose, this should be no surprise.

Even with a 4-digit PIN and the “Erase Data after 10 failed passcode attempts” option turned off, the ever-escalating passcode lockout provides some level of protection. Same with limiting passcode entry to the touch screen. Without those limitations in place, it would be trivial to brute code a 4-digit PIN code (about 15 minutes) or even a 6-digit PIN code (about a day).

Which is, of course, why the FBI wants the ability to remove those protections. And why, if you care even a little bit about the security of the data on your mobile device, that you should use a longer, more complex passcode on your device. Given that even without those restrictions, it takes roughly 80 milliseconds to check each PIN/passcode attempt, it doesn’t have to even be that long or that complex to keep the passcode from being guessed in your lifetime.

Disclaimer: My employer Check Point Software Technologies might have differing views on this topic. These thoughts are my own.

I will admit, I’ve never been a huge fan of Mobile Device Management (MDM). Given the way this whole kerfuffle between the FBI and Apple is playing out, anyone who cares about their personal digital privacy should think twice before subjecting their personally-purchased devices to MDM.

One of many things an MDM solution can do is control the PIN code on the device. Namely, it can control that one exists, force a specific length of PIN, and even reset a PIN. This fact entered the public discourse around the San Bernardino shooter’s iPhone that the FBI is trying to get Apple to assist them in unlocking.

If San Bernardino County (who owned the phone the shooter used) installed MDM on the target device, the whole public debate around this would not be happening. I don’t know of any company who would deny a request to reset or disable the PIN, particularly if it were backed by a court order. Unlike what the FBI is asking Apple to do now, it would not be burdensome to carry out, either.

This places an extra burden on employers who manage employee devices through MDM. Specifically, do you have a process to handle law enforcement requests like this? Are your employees aware of this policy and have they consented? Also, MDM doesn’t do a whole lot to protect corporate data or detect the presence of malicious software on mobile devices.

As an individual, this doesn’t make me feel all that safe about trusting my phone to MDM, at least not without understand precisely what features and functionality will be under MDM control.

Disclaimer: My employer Check Point Software Technologies might have differing views on this topic. These thoughts are my own.