Tuesday, July 5, 2016

Strategic Recommendations and Bug Bounties


I have so many feelings about bug bounties. First of all, bug bounties turn your penetration testing program into a hilarious cross between sales and marketing. Hiring sales people is fun because you know they are motivated only by money, and have read your sales compensation plan, and spend more time trying to game that plan than actually selling.

And this is what you see with bug bounties - companies spending hours manipulating their plans to try to get their team to perform for them. If you run a bug bounty, and you get no bugs, does that mean your site is secure, or that your incentive plan is bad? Hard to say.

But aside from that hilarity, there was an important point hidden within the Uber page on HackerOne: They are not getting what they would get from a relationship with a security services vendor.

Look,  when you go to the dentist, you get two things:

  1. Cleaner teeth, possibly with fillings and other repair work done
  2. Strategic advice ("please stop chewing ice all day")
Look at the statement I screenshotted above and read it slowly, in a funny British accent. What is the strategic advice you would give out to someone who keeps having to remove lots of various plugins from their WordPress installs, but is security sensitive? Would it be "Please don't install WordPress all day?" 


Monday, May 23, 2016

FINRA and Cyber Security: Starting from Scratch




A Changed Regulatory Environment


Recently regulatory authorities in the financial space are accelerating their efforts to bring rigor to reducing cyber security risk in their space. In particular you are no doubt seeing a lot of action from recently passed cyber security regulations from the SEC (Security Exchange Commission) and FINRA (Financial Industry Regulatory Authority).

According to 2016 FINRA's Regulatory and Examination Priorities Letter, they will start reviewing firms' approaches to security in the following subjects:
  • Cyber security governance and risk management
  • Cyber security risk assessment
  • Technical controls
  • Incident Response
  • Vendor Management
  • Data Loss prevention
  • Staff Training  
In other words, your regulator will shortly be looking at EVERYTHING you do from a cyber security standpoint.

If your firm currently does not have any cyber security strategy in place, this certainly looks overwhelming. At Immunity we work with a variety of organizations at different stages of their security strategies, from companies with decades of mature information security expertise to companies with no experience or security approach who have traditionally outsourced IT entirely.

The first step for a company that finds themselves in a position to comply with the new cyber security regulations is to understand where they currently stand. We can help you do that through penetration and vulnerability testing and assessments and strategic advice. Not every new-fangled security appliance is right for your program - we can help save you money by running real-world testing on the products you are thinking of acquiring.

Strategic Situational Awareness


A penetration test is not the ultimate test, but will allow your firm to identify some of your high-risk vulnerabilities and assess the impact of a potential attack. It will also provide management and give the board of directors an instant wake up call on the consequence of not addressing the cyber security problem and not putting a security strategy in place.

With the results of the security check in hand, we will have a first overview of your security. Now we can slowly but firmly start addressing each of the different subjects of the FINRA recommendation, which we will discuss in the next blog post.

Of course, if you have any questions about how FINRA's focus on information security affects you we can be reached 9-5 EST: +1-786-220-0600


    

Thursday, April 21, 2016

Lessons Learned from Infiltrate Training 2016

Every year I write up a lessons learned blog post that gives some insight into what goes on behind the scenes when producing our security training. Since all of the Infiltrate training happened at the same time this year I'll provide a few lessons from other classes but the majority will from our WebHacking course.

Overview

We fielded four classes this year:
Master Class - Max, Rod, Matias
Click Here for Ring 0 - Facundo, Lurene
Wide Open to Interpretation - Esteban, Enrique
Web Hacking - AlexM, Miguel, David

Hardware matters, a lot

We provide hardware to students for our classes, this year we switched to Lenovo z50s. Despite running the latest XUbuntu their ability to interface with a projector over HDMI was absolute garbage and a horrible headache. Also, they use an AMD processor rather than an Intel one. Some of our Linux kernel master class content relied on Intel specific tricks. We had a surprisingly high number of those laptops die due to bad RAM in the Click Here course.

Lesson: Make sure the lead instructors for any class you teach sign off on hardware changes

Think about distribution

We stopped printing physical copies of the slides for students in 2016 and instead gave each student their own PDFs. In Web Hacking that wasn't hard to do because we've got a scoring server where students have individual accounts and can submit tokens for competition. Other classes had an issue because there wasn't a scoring server concept.

Lesson: If you're giving out slides just provide students with a pre-loaded USB stick at the beginning of class. I still always recommend each class have a utility web server on the internal network for distributing files during class as needed.


Obvious bugs can have long lives

Despite running the scoring server for years we only this year discovered that the username field for the login page was case sensitive. This rattled us a bit at the beginning of class as we thought we had some kind of wide-spread login problem with the scoring server.

Lesson: Mentally prepare yourself for the reality that your students will find bugs that you missed


Scoring can be helpful

I've written a lot in the past about some of the benefits and drawbacks of including a competitive component in your class. One of the key things we use it for in WebHacking is to get a sense where individual students may be struggling or which exercises need to be tweaked because only a few people have solved them. When I asked other trainers how students in their classes were doing they had a much looser sense of performance where as we had pretty solid data.

Lesson: Create concrete metrics you can obtain throughout the class to determine how students are doing other than self reporting


Scoring can be harmful

Not all students want to participate in the competitive aspect of the class. We make it very clear at the beginning that it is entirely voluntary. But in practice we erred on the side of not going into solutions for some problems because certain students were still competing. This was clearly a disservice on our part as we could have done more to ensure students understood some of the trickier content.

Lesson: Don't let the competitive aspect of the class negatively impact the learning of many students


Students want homework

Our number one request this year was to provide access to exercises outside of class. We've struggled with that a little bit because it meant changing our architecture and providing some kind of support after hours. We still haven't entirely decided how we're going to solve this request.

Lesson: Create your environment to provide remote access from the get-go so students can continue learning after class hours

 

Students expect all solutions

We have a TON of content in our Web Hacking class, right now the class is four days and could easily stretch to five if we went over each and every solution manually. Rather than doing that we're going to be producing solution PDFs that provide in depth discussions and solutions for each exercise. This gives the students the ability to review solutions after class hours and come back in the morning with questions.

Lesson: Any time you create a new exercise or task for students you should write up a complete solution with corresponding documentation explaining how they would figure out each step




Wednesday, March 2, 2016

What's New in Immunity's WebHacking Course

We’ve continued to streamline the course since the last InfiltrateCon based on student feedback. Since Infiltrate 2015 we’ve had the opportunity to give the class twice so these changes have been put to the practical test. As always students are required to solve the exercises without the assistance of automated tools (proxies like burp are allowed but only for their interception/rewrite capabilities). As a result you will be doing coding in JavaScript, Python, MySQL and optionally a tiny bit of PowerShell. If you'd like a refresher on these languages check out our Web Hacking Language Review course on March 22nd, being offered remotely for the first time!

The Introduction to XSS section is now the entire first day. We’ve expanded the content to include exploiting XSS issues via Flash as well as touching on some client-side template injections. We look at practical exploitation scenarios for poorly constructed crossdomain.xml files, permissive Access-Control-Allow-Origin headers and more.

The XXE/XSLT section is now 3-4 hours which is double the amount of time previously allotted. The big new feature is exploiting sighted and out-of-band XXE attacks as well as XSLT injection over an XMLRPC pseudo service. This provides the students an extra level of challenge to adapt to a real world scenario.

We’re allocating an entire day for SQL Injection which will give students more time to complete the final exercise. Thus far we’ve only had one student solve it so it stands as a formidable challenge. Finally the sites for the Web Crypto section have been cleaned up to make a more uniform style and fix some clarity issues, the content takes up the entire last day of the course.

The finalized WebHacking schedule (PDF) for Infiltrate 2016 is:

April 3rd: Introduction to XSS
April 4th: Command Injection, eXternal XML Entities (XXE) and XSLT injection
April 5th: SQL Injection
April 6th: Web Crypto

Monday, January 11, 2016

The Evolution of the Wireless Penetration Test

Years ago a wireless penetration test focused on illustrating the issues with the protocols and implementations in use by the targeted access points. The deliverable would document how an attacker could break into the network due to the use of the ever-so-weak WEP encryption, WPA with a weak pre-shared key (PSK) or insecure distribution of keys. Raise your hand if your 2010 wireless penetration test was made easier by finding the passphrase written on a Post-It note!

Of course, often no encryption was supported or configured at all. There would be screenshot after screenshot of SILICA "breaking into the corporate network in less than 7 minutes" and verbiage that explained how total domination of your corporate wireless network was inevitable. 

Studying the thermodynamics of molten washing machines in the free time that SILICA provided me with.

Times have quickly changed. Access points (from an unauthenticated standpoint, anyway) are much more resilient to outside attacks but wireless networks themselves are made up of more than just an access point - and they are still just as vulnerable.

I have spoken with other wireless penetration testers that assume if you can't break into the network via the access point then the network is considered "secure". This reminds me of the flawed logic of relying solely on automated solutions to determine the security posture of a network or application. These misguided penetration testers will declare "if the tool didn't find a way to break in then a human must not be able to break in". 

If you attempt to crack a typical WPA PSK of your target network today then it may be ready to use by the time your grandchildren's grandchildren need access. Attacker always choose the path of least resistance when it is an option and which do you think provides a larger attack surface? A wireless access point that only accepts 802.1x authentication or the corporate laptop that screams at you that it desperately wants to connect to "attwifi" and check for updates?

Today results are obtained in a wireless penetration test by targeting the wireless clients. In a way this has always been true but more so today then ever before. The wireless clients know how to connect to the target network, they have all the necessary keys stored on them, they often leave the safety of trusted network and connect to hostile environments, they have a lot of applications that want to automatically update, backup, phone home, connect, detect, enumerate and act in a way that makes the user's life easier. And an attacker only needs to compromise one corporate client device to gain access to the target network.

In other words, your mobile devices are mobile not just in space, but in security levels - sometimes that security level is "In StarBucks" and sometimes it's "On the corporate WLAN".

When you focus on the attack surface that the typical corporate laptop provides (or your OD that you BY to the BYOD network) it is actually very challenging to deliver "good news" to your client since there is always a laundry list of security vulnerabilities found, we have sadly learned.

After doing so many of these wireless network assessments you might conclude that Mother Nature has hard coded Human DNA to fail at wireless networking (the ultimate backdoor!) but it's not the fault of the client's network engineers or even the security team. The truth is until operating systems and wireless networking solutions learn to cooperate in harmony these exploitable conditions will remain an issue. 

Below I have listed common issues that I see during wireless penetration tests. These are usually the issues that lead to gaining access to the corporate network.

Home, Office and Public network types in Windows does nothing to save you.

Even if you were to select the most restrictive option (Public) it just sets a few firewall rules and turns off some discovery features. Basically it will keep external requests from triggering any response from the laptop but an attacker doesn't need your laptop to interact with an external request. The next section details why.

Corporate Applications and the protocols that they use have no concept of "network types". 

Your mail client, web browser, back up applications and all other applications installed on your corporate laptops will continue to operate regardless of which network you are connected to. They have no loyalties or rules on how to operate on different networks. "Secure" networks and "Public" networks are all the same to the applications. What does this mean from a security standpoint? It means that no matter which network you connect to (your corporate network, home network or open, public network) all of your applications will immediately attempt to do their job to make your life easier. This is why your corporate laptop becomes a playground to an attacker on a network they control. 

The conveniences you extend to your users are also extended to attackers.

An attacker can impersonate any server or service that applications attempt to communicate with. A great example is the auto-configuration proxy script that your corporate laptop wants to download whenever the web browser is spawned. All an attacker needs to do is answer the WPAD request with a malicious proxy server and now every single web request that is made by that corporate laptop will be tunneled through the attacker's proxy server. Passwords, session cookies and all kinds of sensitive data is harvested in this manner. 

Another example is the auto-reconnecting of networking drives. An attacker can impersonate the file server or answer requests for particular file types with malicious versions. This is a great place to inject a CANVAS callback.

Don't forget about those backup routines! Your corporate laptop wants to communicate with a centralized server to determine if it should back itself up.  An attacker can impersonate this server and initiate a backup that your corporate laptop will lovingly and obediently send to the attacker.

There are just so many attack vectors it almost becomes difficult for the attacker to choose which to exploit first. Most likely there is at least one vulnerability that can be leveraged by the attacker to gain remote code execution on the corporate laptop. After which the attacker can pluck the wireless keys off of the machine and voila - he has successfully broken into the wireless network without having to touch a single wireless access point. And as a bonus he also has corporate credentials plucked from the compromised laptop as well as the local administrator password that can be used to gain access to other corporate resources.

Computer-based authentication is not the answer.

Have you ever tried to export a private key from your corporate laptop? Most network administrators are under the impression that you can't export private keys from the corporate laptop. They probably think this because even they, being the administrators, can't export the certificate after they install it the first time because they selected the please-under-no-circumstances-let-any-user-including-administrators-export-this-private-key box. But the tiny grey-out "export" option is no match for someone who knows what they are doing. You only need to hook one function to trick the Windows API into letting you export non-exportable private keys. This means that under the circumstance where an attacker gains access to one (read: any) corporate laptop and steals the certificate used to establish trust that they can connect any machine they want to the wireless network. So in short - by bypassing that grey-out "export" option you also bypass 802.1x authentication.

Captive portals do not solve any security issues.

Captive portals are more for device management and to keep random people from sucking bandwidth unnecessarily; they provide very little security.  I have yet to see a captive portal whose authentication can't be bypassed with MAC address cloning (clone the MAC address of someone that has successfully authenticated and you're done). It is very common to see that your client is forcing contractors, consultants and maybe even board members to use the guest wireless network which is most likely open to the public but has a captive portal in place. This means all of their traffic is vulnerable to eavesdropping and tampering. Why they consider that consultant and contractor traffic is any less important than an employees is a mystery to me. After all they are hired to work on internal resources or they are trusted with or have access to sensitive data and when they transmit this data it is just as easy to capture as data on a Starbucks wireless network.

In conclusion a wireless penetration test will always result in successful compromise of the wireless network if efforts are made to assess the wireless clients. And you can guarantee that a real-world attacker knows that the corporate laptop is the weakest link to gain access to the corporate network.

I'm just a happy corporate laptop. You can't expect me not to connect my corporate drives on strange networks!

Corporate laptops are really like playful puppies that trust everyone and want to make your life easier and more enjoyable. They go retrieve your newspaper as soon as you wake up (by leaving the safety of home and entering into the hostile world to do so), they lick any surface that may or may not have something edible and/or delicious (because they are hungry, have weird taste buds and are eternally optimistic), they will play fetch with any tennis ball thrown by any person (even the creepy guy that hangs out at the park all the time and who knows where that tennis ball as been?). Even though you have trained your dog well he is still vulnerable and he may never learn who to trust and how to change his behavior to better protect himself.

Tuesday, December 29, 2015

Wide Open to Interpretation: Java

Duke has gotten a lot more hard-core lately - I'm worried he's a Trump supporter.

We do private classes sometimes, and the most requested class by far is the Java class, which we are also giving at INFILTRATE 2016. But just because something is "Java" doesn't make it easy. I did a re-read of the whole Wide Open: Java class today. In many slides we suggest using "mature frameworks", but of course, in the last section of the talk there is a note about the bugs in so-called "mature frameworks".

Here's the thing about maturity: It makes you more complex. That line makes me feel like I'm writing an entry on my dating blog, but the reality is that when I learned Java, a class was a class and XXE was not a thing. Ah, the good ol' days, when "Beans" were a brand new, hip technology and you were probably using Solaris.

Your modern Enterprise web application runs in a very different way, and is audited in a very different way, and is being attacked by much more modern adversaries, some of which we've hired to do commercial services for you, and of course, teach you this class.

We knew you liked templates so we put an expressive templating system into your templates!
To sum up, "Mature Frameworks" are one small step from being "Legacy Frameworks", which are widely known to not be up to security standards. What this class does is go through modern Java, and how it's built today, from the standpoint of Immunity's professional auditing team. This is the exact same class we make our new consultants take, and it's excellent, and you can sign up today while there are still spots.




Monday, December 28, 2015

Wide Open to Interpretation: PHP

We're teaching a 2 day class at INFILTRATE this year on PHP and another one on Java. Both of them are linked, but in fact cover very different concepts. My main point is this: Just because you don't use PHP at your company doesn't mean you don't use PHP-like technologies. The deserialization issues PHP had last year, Java has this year. Getting ahead in software security means cross-training where possible.

It's also true that auditing PHP apps never goes out of style. Everyone uses PHP apps, just as everyone eats fries, no matter how vegan.

So what are you going to learn if you come to INFILTRATE and take the class? Here are some slides.

We've of course cut our sample target code down to show basic concepts but each is pulled from an impactful vulnerability.

PHP bugs can be deceptively simple at first.

One hint is that the researcher was wrong is that we include them in our slides. :)

In any case - you should sign up for the class before it fills up, as it invariably does RIGHT BEFORE EVERYONE WANTS TO SIGN UP. But we cannot add more seats last minute. So a little prep-time is all I'm asking for this year. :)