Blog – WhiteHat Security

syndicated content powered by FeedBurner

FeedBurner makes it easy to receive content updates in My Yahoo!, Newsgator, Bloglines, and other news readers.

Learn more about syndication and FeedBurner...

Current Feed Content

“Just because something works doesn’t mean it can’t be improved.” ~ Black Panther: Princess Shuri

Posted:Wed, 07 Mar 2018 23:13:54 +0000

I watched Black Panther this weekend, and outside of being gob-smacked by a brilliant script, soundtrack, sets, cinematography, I fell in love with Princess Shuri. Yes, the time is right for a 16-year old R&D Scientist with a message I want to send to every engineering department in the world. Especially with International Women’s Day this week.

This, in a nutshell, is why we need gender diversity in technology, especially security. We’re all used to characters like James Bond’s Q churning out new toys, new explosive pens, new car guns. But who goes back and fixes things that aren’t broken?

Now, I don’t want to be dragged into a #NotAllEngineers discussion, but in the 18 years I’ve been in security technology, I’ve seen a definite trend toward innovation being directed into the idea of “What is disruptive technology?” and “What’s the next Big Thing?” when there’s so very much work to do with improving and fixing what already exists. This is why we need diversity in engineering – to have teams say “Sure, that’s a nice interface. But we can make it better. We can make it talk to other things. We can make three things that didn’t used to interact have an integrated control system, and make it easier, and make it user-proof.”

Additionally, women in non-engineering but still technical roles, including product management, technical support, and even product marketing, have a lot to add to the big picture of What’s Next and What is Needed in the security industry. This is diversity of another kind; if only one group is doing the engineering, while others with great ideas feel they must sit on the sidelines and watch, how can improvement and new innovation really come to be? We need a regular influx of different thinkers from different backgrounds (and genders), who can build on existing ideas, as well as create new possibilities we never dreamed about.

According to the Society of Human Resources Management, employee referrals accounted for over 30 percent of all hires in 2016. Employees usually recommend people who are similar to them in race and gender, so it requires strategic efforts to recruit those who don’t already have identities that match up with those of current employees. We are not talking about excluding great candidates, but making sure every group has an equal shot; especially women.

Specifically, it’s important to do the following:

1. Evaluate Current Talent and Seek Out Diverse Candidates
Often when gender diversity is lacking at the leadership level, many women in STEM are overlooked. In addition, even if the diversity of thought is one of the goals of the company, hiring efforts can’t come at the expense of hiring those who belong to under-represented groups who add substantial value – and who deserve to work in technology, just as much as anyone else.

A practical tip: Have your HR department remove names when first circulating resumes.

2. Look Beyond “Culture Fit”
In technology companies, “culture fit” has a tendency to perpetuate the status quo, and in many cases, perpetuate the gender status quo. Beer pong competitions and happy hours might appeal to some, but certainly not everyone. Instead, look for people who can add to the culture by introducing people with different backgrounds and interests. This comes from hiring diverse candidates. Sometimes your idea of a Cultural Fit means Hire More of the Same – and it takes all kinds of cultures to make a planet and organization.

A practical tip: Ditch the “first date” assumptions about potential employees, and just be as up front as possible. Try to break down to the basic needs, which in security tend to be Communication, written and verbal, and process evaluation. Technology can be taught – communication can’t, really.

3. Train Technology Teams How to Interview Candidates Objectively
There is widespread consensus that hiring is important for scaling success, but many tech companies spend very little time and effort in actually training employees to make objective hiring decisions. This matters greatly, because like it or not, we all have unconscious biases about the world around us. We won’t necessarily rid ourselves of those biases, but with training and experience, we can minimize the impact of that bias in hiring new talent.

A Practical tip: I loved this blog I saw on LinkedIn, and this one from the Harvard Business Review.

Shout out to #WomenInTech on #IWD2018. And keep being you, Shuri, and all the other rebellious R&D leads who are doing the right thing even when it argues with authority. It’s the clever “troublemakers” in security and development that are motivated to make things better, not just make things new, who will move us forward as an industry.

The post “Just because something works doesn’t mean it can’t be improved.” ~ Black Panther: Princess Shuri appeared first on WhiteHat Security.
WhiteHat Security’s Most Popular Whitepapers of 2017

Posted:Thu, 01 Mar 2018 16:17:43 +0000
In 2017, we made a concerted effort to provide more helpful resources to the application security space, and we’re thrilled that these assets were of value to so many people and organizations, across a multitude of industries.

Here’s a rundown of some of our most popular whitepapers of 2017:
1. Ironclad APIs: An Approach to Application Security Testing
  I’m sure the term “API Economy” is becoming familiar to you by now. After all, APIs change how the world interacts. Everything from sharing a photo, to online shopping, to hailing a cab, is done through APIs. And this technical innovation is happening faster every single day. WhiteHat Security’s “Ironclad APIs” whitepaper gives step-by-step best testing practices from authentication to authorization, from Source Code Analysis to Business Logic Testing. APIs are here to stay and there are security issues that need to be addressed when these APIs are being implemented. When security is implemented into your development organization, developers can then run security tools, such as WhiteHat Scout and Sentinel Source against these newly created APIs. This ensures that testing is performed on any web application component. Download the full paper here.
2. 2017 Application Security Statistics Report: The Case for DevSecOps
  
  2017 marked the 12^th year of our AppSec Stats Report, and for the first time it provided substantial metrics around DevSecOps. The 60-page security report covers DAST, SAST and Mobile App Security Testing, as well as how all three can work together seamlessly. It also provides key best practices on how to get started on a successful AppSec journey.
  In addition, in the section of this report titled, “Case Study: Making the Case for DevSecOps”, we’ve profiled a WhiteHat customer that implemented a program for creating “Security Heroes” in the development organization, putting the training and infrastructure in place necessary to support secure coding in Rugged DevOps. The results were impressive: critical vulnerabilities in applications in development and in production were resolved in a fraction of the time that it takes organizations that haven’t engaged DevOps teams in security efforts. Download it here.
1. Getting the Board Onboard with Application Security: Best Practice Guide
  
  One of the patterns we saw across the industry, was that more and more CISOs were at a loss for where to start an AppSec program, much less sell it to the board of directors. While many board members understand the concepts and terms used in Network Security or Perimeter Security, Application Security, as a concept and discipline, is not quite firmly defined. This paper gives Security Executives and Advisors the right information to educate their peers, colleagues, and executives about initiating a successful application security program, including, making application security visible to executives, as well as security and development organizations; provides guidance for building and managing application security processes; how to measure and manage application security risks and processes; and assure compliance of applications with security regulations for privacy, data protection and information security. Read the full paper here. (There is also a great webinar on the subject)
2. Design Secure Software from the First Line of Code
  
  Latency, bottlenecks and security teams finding vulnerabilities after a product has been coded and released have been consistent problems for developers. After all, developers have their own tools and processes that they use, and adding additional security is often seen as a huge burden. They need security to work seamlessly with their individual process, and from within their unique environment. The developers who understand the importance of application security either wrongly assume that the AppSec team will take care of it, or they are not aware of how to fix the flaws themselves.
  
  This paper helps the reader understand how to shift security further left in the SDLC, how to empower developers to write secure software, and an unmatched way to develop secure applications in the age of DevOps and Continuous Integration/Continuous Delivery (CI/CD). Read the full whitepaper here.
3. The Art of Application Security: Getting Started with DevSecOps
  
  We wrote this paper to shine some truth on the subject of DevSecOps. It’s often a seductive term throughout many industries, sometimes thrown around ad nauseam without sufficient explanation of what it demands. What you will find in this paper, is a “blueprint” or best practices for application security, and substantial evidence of the value of development and security working together to build and protect those applications. We highlight steps to take to get started, as well as describe a customer who successfully implemented security throughout the SDLC. Read on, here.
The post WhiteHat Security’s Most Popular Whitepapers of 2017 appeared first on WhiteHat Security.
Cyber Attackers: A perfect 10! Olympic Committee: Failed to qualify.

Posted:Tue, 13 Feb 2018 19:51:35 +0000

The Olympics are meant to be a celebration of the human spirit. A spectacle of national pride. A living, breathing example of the limits of the mind and the body. Through the Olympics, we get to experience the thrill of victory, and the agony of defeat. Wait. I’ve started to sound like a 1970s sportscaster. That’s no good, especially since we obviously no longer live in the 1970s.

What do I mean by that? Well, it’s obvious we no longer live in the 1970s because the extent of hacking in the 1970s were some whistles on phones that stole long distance. Today, though, we’re in the midst of a cybercrime epidemic, and not even the Olympics are immune.

You might not have noticed it, but during the 2018 Olympics Opening Ceremonies in Pyeongchang, South Korea last Friday night, a “destroyer” cyberattack targeted and took out the Pyeongchang 2018 website and other services, including the ability for spectators to print out their event tickets. This bit of malware was impressive in that it COULD HAVE completely destroyed the machines it infected, but didn’t. It left open the possibility for organizers to fix the issue, which they had done by Sunday.

There are all sorts of detailed descriptions of the hack on the web (for example, Cisco’s Talos group has a great write-up) so I won’t waste your time on that here. Instead, I’ll just say that no one is immune to cyber attacks in today’s world. Large or small, famous or not, you and your company are a target. You should be constantly thinking about how to stay one step ahead of the hackers so that you and your customers can continue to lead a safe digital life.

By the way, I found this quote, from the International Olympic Committee spokesperson Mark Adams, ironic: “We are not going to comment on the issue. It is one we are dealing with. We are making sure our systems are secure and they are secure.” (source: Reuters) Are you sure about that, Mr. Adams?

The post Cyber Attackers: A perfect 10! Olympic Committee: Failed to qualify. appeared first on WhiteHat Security.
You ARE the weakest link!

Posted:Tue, 06 Feb 2018 14:39:22 +0000

Does anyone else remember that AWESOME TV game show that aired in the US in the early 2000s? It had that delightful British woman who would gaze at the contestants with only slightly disguised contempt, and then send the least intellectually capable off with a dismissive nod and a wonderfully throaty: “You ARE the weakest link!” That was a great show. But I’m not sure it really taught us anything. Because in today’s scary cyber security climate, it turns out that all of us – the humans – are “the weakest link.”

We’re obviously the weakest link when it comes to writing software. As an old developer, I used to say that software isn’t buggy – people are. We code this stuff. We are the ones who make it buggy. We are the ones who don’t know the security holes and don’t plug them before we send this stuff to production. So, we can’t blame the software. We have to blame ourselves. Because we are the weakest link.

With software bugs, at least there are tools that can help protect us. Technologies like WhiteHat Security’s Sentinel Source scan source code for security vulnerabilities before it goes into production. If we make a mistake and send a vulnerability to production, WhiteHat’s Sentinel Dynamic can find it, and help you mitigate and remediate. We can at least protect, to a certain extent, the damage caused by the human weakest link.

But what about the things no automated tool can possibly find? Those things that even the most incredibly talented WhiteHat hackers can’t protect against?

What about the people who talk too much, too loudly, and share way too much information? What about THOSE weakest links?

Last week, I encountered two really bad weak links. Both of them in Delta SkyClubs – one in Tampa, and one in Atlanta.

The guy in Tampa gave me so much information about his email address, company, and the domain to which he was trying to connect that I could have taken over his account – if I were a lesser person, of course. He was on the phone with his help desk, lamenting the fact that he couldn’t log into his corporate email. He shared with the entire SkyClub his email address, his logon id, the domain to which he was connecting, and his company name. He also shared with us the fact that he had no problem connecting before he tethered his laptop to the physical network the day before. Oh, he also mentioned that they use Office 365 for their shared documents.

He gave me so much information that I could have taken over his account, dug into his documents, and found enough information to bring his company to its knees (the name of which I know, thanks to his vocal immodulation disorder).

But, of course, I didn’t. Because I’m one of the WhiteHat hackers.

The second incident was in Atlanta. And, frankly, this guy was a hacker’s dream. Not only did he share with me the full names of 10 contract physicians at a Columbus, Ohio area hospital that was recently taken over by a healthcare management company (he told me that name, too!), but he also used the full name of the person on the other end of the phone no fewer than five times.

He also shared with me (and everyone else in earshot) his plans for taking over the next hospital. I know where it is, and how his company is planning to take it over.

But the best part?? He got up to go to the men’s room… AND LEFT HIS COMPUTER UNLOCKED! Yes, I did take a picture. But I won’t share it. I just did it to prove to myself that even the most ethical of hackers have access to things they should not have access to.

Look – we’re all people. We all make mistakes. But the results of those mistakes are easier to control with automation on the software side. And even on the people side, we can do proactive control through high-quality eLearning to help them recognize when they are engaging in behaviors that put your company at risk..

That said, there will always be people who act like the idiots in the SkyClubs. People who don’t recognize when they’re sharing so much information that bad people are plotting their downfall.

Are YOU the weakest link?

With WhiteHat Security, you just might be… the STRONGEST link.

The post You ARE the weakest link! appeared first on WhiteHat Security.
Software Composition Analysis: Identify Risk in Open Source Components

Posted:Thu, 01 Feb 2018 17:53:32 +0000

An estimated 90 percent of your code is from open source and third-party libraries. How are you verifying that you have the latest version?

In order to fully understand your application vulnerabilities and the overall security posture of your web and mobile applications, you need in-depth visibility into the third-party components that you are using. Software Composition Analysis (SCA) allows you to identify third-party and open source components that have been integrated into all your applications. It informs you about the licenses for each of them an identifies out-of-date libraries that should be upgraded or patched. Software Composition Analysis tells you if any open source frameworks have open CVEs that must be addressed.

When Open Source Goes Wrong

In March of 2017, it was reported that certain versions of the Apache Struts 2 Framework were vulnerable to Remote Code Execution attacks. If you were using a vulnerable version of the Apache Struts 2, the recommended remediation was to upgrade to Apache Struts 2.3.32 or 2.5.10.1. The issue was a Remote Code Execution bug in the Jakarta Multipart parser of Apache Struts 2 that could allow an attacker to execute malicious commands on the server when uploading files based on the parser.

Using Software Composition Analysis, you can easily know which applications are using a particular library – either directly or transitively.

Here are a few items to look for when searching for an SCA solution:

You Must Fix Vulnerabilities, Not Just Find them

Typically, Software Composition Analysis is only considered a testing tool, flagging security problems at relevant times. However, this is missing the boat. The ultimate goal is not to just simply find the vulnerabilities. We must fix them! Fixing vulnerabilities must be part of your plan for addressing risk in open source code.

Integrated in SAST (Static Application Security Testing)

Flexibility is also an important feature, depending on your needs. Solutions that show an SCA dashboard with CVEs, versions, and license details but also creates vulnerabilities out of these CVEs that can be integrated with ALM and Bug Tracking, is your best bet.

Ensure Your Tool Understands Your Dependencies Well

Understanding dependencies can be a challenge that might seem easy until you look under the hood. If you have an SCA solution, you may rely on its ability to detect the libraries you’re using. If it happens to miss a library, it can therefore miss vulnerabilities.

SCA Should Give Security Teams Visibility into Development

Given the speed of development and the adoption rate of DevOps release automation platforms, security teams will never be able to keep up and keep that code secure. Therefore, the SCA solution you choose needs to be designed to give security teams visibility into development environments.

Choose a Solution or Service that Can Grow with Your Company

Whether in our personal or professional lives, we’ve all seen and experienced the continuously faster pace of software development. This won’t change as many organizations are either in the middle of their digital transformation journey, or looking to increase productivity and speed going forward. Maintaining security is crucial.

Obviously, the solution or service you choose should fit the needs you have now, but keep in mind that it’s just as important to choose technology that will help you get where you want to be the future.

Given that most code is open source, and that applications are a popular attack surface, coupled with more attackers targeting vulnerabilities in open source code, SCA is an integral part of application security and secure DevOps. It’s not a “check-the-box” requirement.

Want to know more? Our Principal Product Manager, Sandeep Potdar offers a free webinar, Software Composition Analysis, the Linchpin of Modern Software Development. He will walk you through the importance of SCA, why it’s essential for secure DevOps, and how SCA helps you manage open source vulnerabilities, including issues with compliance.

The post Software Composition Analysis: Identify Risk in Open Source Components appeared first on WhiteHat Security.
The Meltdown Over Spectre

Posted:Sat, 06 Jan 2018 01:33:10 +0000
Do you know to whom you owe a first debt here at the start of 2018? I do.

I’d like everyone to pause, and in their minds and hearts say thank you to the hundreds of engineers at various hardware, software, and security vendors who spent their holidays working on OS patches, browser patches, cloud roll-outs and distribution of patches for Meltdown and Spectre. (The Q&A section at the bottom of their summary page is excellent.) Thank you to Intel and ARM for their responsible disclosure, great communication, and clear timelines. Kudos to Graz University of Tech and Google and others for finding them.

What do these two threats mean to you, though? What can you do?

At work: Contact your IT team, or if you are on the IT team, get the OS updates pushed out as quickly as possible. Prioritizing this action is important, in an all-hands-on-deck way. This round of patches are critical not to delay, including firmware updates.

Some extra information from the cloud:
- AWS and Azure are patched at the hypervisor level, which means VMs which are currently in operation there should be ok.
- Google cloud platform is patched at OS level, so people with VMs there will need to patch their VMs.
- In general, when using Infrastructure-as-a-Service (IaaS), you will need to update the operating systems of any virtual machines and container base images that you manage.
Do NOT go looking for patches randomly from “helpful” patch sites on the Internet; only use the official patches that arrive via the usual auto notifications of your system, or reach out directly to the vendor website. In general, never trust emails saying, “We scanned your system and found ___.”

It’s possible to use JavaScript to steal stuff from browsers using this bug if your OS is out of date. Therefore, in addition to installing OS updates as they roll out, please prioritize updating your organization’s browser clients. Firefox, Edge, IE and Chrome all have patches available.

The vast majority of applications do not allow user execution-level access on the server. In some rare cases, some apps might intentionally give users the ability to execute commands and rely on sandboxing or containerization to keep them from doing harm. In these rare cases, this bug could allow them to break out or escalate their privilege. There have also not been reported instances of either vulnerability accessing either device storage or databases behind web or mobile applications at this time. However, I do think it is important to be aware of any XSS vulns (which could be used to access saved passwords from the browser’s memory) and Remote Code Executions, because if attackers can run commands on the server, they might be able to chain together an app-level attack using these exploits.

If you have an application-level vulnerability in your DevOps queue from DAST or SAST regarding the insecure storage of logins or passwords, this is an excellent time to prioritize those tickets to prevent that portion of memory from being read by another application using this threat. While Meltdown and Spectre are not vulnerabilities which can be detected via Dynamic or Static Application Security Testing, these are hygiene-type precautions which can help prevent the spread of a successful attack from the server into applications.

General Tip: Remember when building your applications – the least privilege you allow, the more stingy you are with complete data records shared via client or API operation, the fewer opportunities for abuse will exist later. And naturally, we would hope that you do not use the same root login/pw combination on a server as you do on the applications hosted therein. But it never hurts to check, especially in smaller IT organizations where one person fulfills many functions.

Finally, and I’m sure your IT department already says this, but allow me to help reinforce it: If you have an IT-distributed patch system in your organization, let them do their jobs. Just ask in a friendly way when the patches will be available/pushed.

The post The Meltdown Over Spectre appeared first on WhiteHat Security.
Nation State Activity – The continuing story for 2018

Posted:Thu, 04 Jan 2018 15:21:36 +0000
Well, I called it at the end of 2016. 2017 was a slurry of accusations as well as actual proof found of Russian meddling in U.S. politics via both state infrastructure systems and with regards to online propaganda on social media.

Even more specifically, I also correctly called the meddling of the Russian propaganda machine into the E.U. nation state social media and other avenues – France saw it, although narrowly avoided falling prey to it. German political parties, lacking the open enmity and polarization created in the U.S., seemed to have promised not to hack one another for dirt. The Twitterbots pushing messages of anti-immigration and anti-EU sentiment found little resonance in Germany. Kudos to them.

Cleverly, the Russian attackers seem to have gone more after systems of voter registration/authentication rather than trying to alter the votes themselves. (Why do a big hack when you can do an equally-useful little hack of annoyance and demographic skew?)

Additionally, we now all know there are tens of thousands of false troll personalities active on Facebook and Twitter and other social media, including LinkedIn, who fall upon anti-GOP sentiment with a flurry of personal attacks and harassment. This, I fear, will be the new normal until the social media platform giants learn how to winnow trolls from truth, and refuse the advertising dollars from non-US businesses.

Let’s talk China, though. Although Obama got the government to promise not to meddle with U.S. commercial interests by also committing that the U.S. would not meddle with Chinese commerce, there has appeared a wrench in the works. Or rather, a Twitter hammer from the oval office. One speculates that if that Twitter account attacks U.S. businesses directly, China will start to feel that the gloves are off if too many jabs attack them?

In tech, I think cyberwarfare is in full swing. We have two cyber events which have me bemused, the first being the creation of U.S. Cyber Command to defend Department of Defense (DoD) networks, which is still under the National Security Agency (NSA) though we’re not sure for how long. In August 2017, the DoD communicated it would initiate the process to elevate U.S. Cyber Command to Unified Combatant Command, which is commonly perceived that the U.S. is announcing to the world that it’s ready to attack. Whether this escalation of cyber arms is a good idea or not will be unveiled through 2018.

2017 also saw attacks coming in against websites directly for high-profile cases, rather than just via network traffic and payloads. 2016 introduced major Samas.A ransomware hitting healthcare and in 2017 Abuse of Functionality attacks like WannaCry and Petya have been spreading, and we’ll see more of these types of proliferating attacks as hackers are finding that perimeters are secure, but websites are still not coded with security and safety in mind.

Tied to this, the security skills shortage surveys are now actually calling out Application Security as a separate and important discipline. And everyone is talking about Education again – and realizing that they need to train and educate their own employees instead of just trying to hire an expert.

2017 saw more security vendors starting to play ball together, which makes me happy. API security and API functionality are no longer topics to make IT Security people blush and go get more drinks at the party. Sharing security meta data via APIs between technology will be key to making multiple technologies function as a unified machine to secure the digital ecosystem. Tools developers, aka the folks who can script connections between applications, or between services and platforms and security devices, are the unsung heroes of the world and I hope that in 2018 they’re training more of them at the Universities. Let’s face it – APIs are the backbones of the IoT, so let’s keep a healthy backbone out there.

Further, I find additional hope in the New York Dept. of Finance Cyber Security regulations, because they called out application security as a line item. There still seems to be a gap in the current legislation when it comes to understanding that an asset is more than a box, but also includes the programs and applications on that box – but there are cases where progress is being made. GDPR is coming, and I predict there will be a flood of interesting and high-profile cases made against U.S. companies who have played fast and loose with customer data in the past – including and especially their marketing departments. Google Analytics has already updated this page on the topic of compliance, and SalesForce ran multiple sessions on the topic at Dreamforce.

All said, in 2018 I expect the following to happen:
- Continued nation-state activity….
- It will be revealed that the U.S. has been a more aggressive cyberwarfare participant on the world stage
- With the incorporation of GDPR, there will be a flood of interesting and high-profile cases made against U.S. companies who have played fast and loose with customer data in the past
The post Nation State Activity – The continuing story for 2018 appeared first on WhiteHat Security.
ROBOT: For When the Metal Ones Decide to Come for You

Posted:Wed, 13 Dec 2017 22:55:49 +0000

Clever Name, Derivative Attack

Dust off your Old Glory Insurance policy, ROBOT attack is now a real thing that can happen to you. Researchers Hanno Böck, Juraj Somorovsky, and Craig Young have a new attack to tell you about, and they have named it Return of Bleichenbacher’s Oracle Threat (ROBOT). To sum it up in one sentence, their whitepaper says “We didn’t go for the full solution to this problem, and it came back.”

Their main finding is that a specific padding oracle attack from ’98 can still be used against modern TLS stacks. Transport Layer Security (TLS) is supposed to provide you with confidence that messages you send back and forth with a server are secure. Only the real server should be able to read your messages, and only they should be able to sign messages back to you so you know they are from the real server not some hacker in between you. The researchers proved that this classic attack works by forging Facebook’s signature.

To make this work, the attack has to open many thousands (possibly millions) of connections to the server with different cryptographic payloads, and monitoring how the server responds. There are more efficient ways to exploit this, but the researchers stuck to the original plan of attack. So, in the coming weeks and months, we can probably expect someone to build a faster ROBOT.

It’s clear that the researchers are trying to emphasize the similarities to the original research done by Bleichenbacher in ’98. In their whitepaper, they make a compelling case that complicated mitigations are not an effective long-term strategy to fix a basic flaw. In this case, the basic flaw is using RSA key exchanges to facilitate encryption. In their words: “In our opinion this shows that it is a bad strategy to counter cryptographic attacks with workarounds. The PKCS #1 v1.5 encoding should have been deprecated after the discovery of Bleichenbacher’s attack.”

Is this a Big Deal?

Being vulnerable to this attack is a sliding scale. It could take a few thousand connections to decrypt a captured message, or millions, or be impractical to pull off at all. If you are vulnerable to this in a way that an attack is practical, then a sophisticated attacker could use it to do real harm. In my opinion, you almost certainly have vulnerabilities that are more easily exploited and can be used to do more widespread harm. Please fix this if you have it, but don’t forget about your boring old SQL Injection and XSS!

ROBOT is something you should pay attention to, and look for patches to your TLS library. Better yet, consider dropping all support for RSA key exchange based encryption, if possible.

I would still call this attack a big deal because it has the potential to educate on an overall issue of wallpapering over security weaknesses to close specific vulnerabilities. This basic problem comes up every day for us at WhiteHat, as we keep overcoming blacklists and workarounds to exploit the underlying vulnerabilities. We try to always coach the full solution, and it’s great to see hard evidence to support it.

This attack also demonstrates once again that for TLS to remain secure, we need to keep marching forward, removing support for old cipher modes and adding new ones.

What is WhiteHat Doing?

We consider ROBOT worth reporting, and we’re currently working on detection that won’t DoS your server for our DAST and Mobile customers. We’ll put an update in the Sentinel portal when we have more information.

In most cases, people will be vulnerable to ROBOT because of specific issues with your TLS stack. If it’s in your code and you have Sentinel Source, we’ll automatically report those once the CVE’s publish.

The post ROBOT: For When the Metal Ones Decide to Come for You appeared first on WhiteHat Security.
Security Predictions 2018

Posted:Tue, 12 Dec 2017 14:06:56 +0000

2018 is right around the corner, and with the changing of the calendar people naturally gravitate to looking ahead and thinking about everything that will happen in 2018. Security is no different and we often are asked, what’s going to happen in 2018?

Last year on December 13th, 2016, I posted up my prediction. Here’s a little quote that I think summed it all up. “Nothing will change. Companies will continue to get breached because of simple vulnerabilities.” Unfortunately, my prediction was correct, but that’s no surprise. I could have made that prediction every year for the past decade and I would have been correct. In 2017, we saw some of the biggest breaches to date. The Equifax breach, which affected hundreds of millions of Americans, contained some of the most sensitive information we have. In 2018, we’ll continue to see breaches occur at a massive scale. So why is that?

Put simply, organizations on the whole still aren’t investing enough time and energy into security; certainly, not as much as they need to. The web application layer is the single highest point of entry when it comes to breaches, yet we continue to focus more on firewalls and antivirus software. In addition, to keep up with consumer demand, we also want to release code as fast as we can. The faster we release code, the faster we release vulnerabilities as well, which means attackers have ample opportunities to pull off a big breach.

But there is light on the horizon! My prediction (besides the bleak, “we’ll continue to get breached” one) is that more and more companies will start adopting the DevSecOps process and bring the Development, Security and Operations teams together. We’ve seen this work with companies and we know it reduces both the number of vulnerabilities introduced, and also the time to fix those vulnerabilities. By making one team with the mission of fast, secure, and stable code we ensure that these teams no longer have competing priorities which hinder secure releases. I predict we’ll see many more cutting-edge companies go this direction, with the slower moving organizations to follow in the coming years.

The post Security Predictions 2018 appeared first on WhiteHat Security.
OWASP – The Superhero of AppSec

Posted:Thu, 07 Dec 2017 13:24:57 +0000

The security industry needs unbiased sources of information who share best practices with an active membership body who advocates for open standards. In the AppSec world, one of the best is the Open Web Application Security Project (or OWASP).

Standards and best practices have to evolve over time. Earlier this year, the OWASP community issued a request for comments (RFC) on updates that added a risk category for unmitigated issues, which implies a very true fact that many vulnerabilities stay open for a long time. As a security industry, web applications are the least attended to in priority in terms of funding, attention, and program support. (Back in April I was interviewed on my thoughts on the 2017 proposed OWASP updates to the 10 Most Critical Application Security Risks.)

That version of the RFC didn’t pass as written, but a very similar version was finalized November 18:

Summary of New Items:

A4 – XML External Entities: Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations. These flaws can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial of service attack as well as execute other attacks. This is more easily tested for via source code scanning (SAST) or manual business logic tests.

A8 – Insecure Deserialization: Exploitation of deserialization is somewhat difficult, as off-the-shelf exploits rarely work without changes or tweaks to the underlying exploit code. However, the impact of deserialization flaws can be dire, leading to remote code execution attacks. This, also, is most easily detected via SAST technology.

A10 – Insufficient Logging & Monitoring: This isn’t, technically, a vulnerability in code or business logic which is being exploited, which is why this entry has been somewhat controversial. As I noted in the 2017 draft, this entry isn’t inherently a vulnerability, however, it still counts as a website risk due to a lack of monitoring or timely response to events – and a limitation of the logging available for cyber investigators to determine what precisely happened during a web application-based incident. Websites need logging turned on, but at the same time need to avoid printing log results to the console or a plain text file within the application which can, in turn, be accessed and erased or tampered with.

We’re exploring multiple ways of determining the various mitigation methods to offset this risk, including projects such as scanning API calls which handle logging or integration with other security devices for mitigation, monitoring, and logging. This is a very exciting opportunity to educate our own customers on what they’re doing right, could improve, or need to work on in terms of averting risk. Because A10 isn’t a vulnerability covered by an obvious scan rule pack, we have a great opportunity to find multiple approaches to identifying this risk for our customers and helping them with remediation, mitigation, or in the case of WAF, RASP, and NGFW technologies, virtual patching.

Security controls and ecosystem inter-weaving is the best way to secure the whole software development lifecycle. And you know the best thing about open standards in security projects like the Top 10 list?

You can be a superhero and start your own. OWASP provides a forum here.

The post OWASP – The Superhero of AppSec appeared first on WhiteHat Security.