Pentagon Hacked in New U.S. Air Force Bug Bounty Program

The Hack the Air Force 2.0 bug bounty program kicked off earlier this month with researchers finding a critical vulnerability that could have been exploited to gain access to a network of the U.S. Department of Defense.

Hack the Air Force 2.0 started on December 9 with a live hacking competition hosted by the HackerOne platform at the WeWork Fulton Center inside the Fulton Center subway station in New York City.

During the event, Mathias Karlsson and Brett Buerhaus demonstrated how malicious actors could have breached an unclassified DoD network by exploiting a vulnerability in the Air Force’s website. They earned $10,650 for their findings, which is the largest single payout coming from any bug bounty program run by the U.S. government.

Seven U.S. Airmen and 25 civilian white hat hackers discovered a total of 55 vulnerabilities during the event, for which they earned $26,883. Hack the Air Force 2.0 bug bounty program

Hack the Air Force 2.0 will run until January 1, 2018 and anyone can apply as long as they are a citizen or a permanent resident of Five Eyes countries, NATO countries, or Sweden. People from 31 countries can take part in the initiative, which makes it the most open government bug bounty program to date. Members of the U.S. military can also participate, but they are not eligible for bounties.

While anyone from these countries can apply, not everyone will be invited to actually take part. The Air Force will invite 600 people, 70 percent of which based on their HackerOne reputation score and the other 30 percent will be selected randomly.

“Hack the Air Force allowed us to look outward and leverage the range of talent in our country and partner nations to secure our defenses,” said Air Force CISO Peter Kim. “We’re greatly expanding on the tremendous success of the first challenge by opening up approximately 300 public facing AF websites. The cost-benefit of this partnership is invaluable.”

Hack the Air Force 2.0 was announced following the success of the first Hack the Air Force program, which resulted in more than $130,000 being paid out for over 200 valid vulnerability reports.

Previous DoD bug bounty projects included Hack the Pentagon, which resulted in payouts of roughly $75,000, and Hack the Army, with rewards totaling approximately $100,000. The Pentagon has paid more than $300,000 for over 3,000 flaws discovered in its public-facing systems, but the organization estimates that it saved millions of dollars by running these programs.

Roughly one year ago, the Pentagon announced a vulnerability disclosure policy that aims to provide guidance to researchers on how to disclose security holes found in the organization’s public-facing websites. While no monetary rewards are being offered, the policy provides a legal avenue for reporting flaws.

Eduard Kovacs is a contributing editor at SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/J_7XAYx-cXE/pentagon-hacked-new-us-air-force-bug-bounty-program

Google Researcher Finds Critical Flaw in Keeper Password Manager

Google Project Zero researcher Tavis Ormandy recently discovered that the Keeper password manager had been affected by a critical flaw similar to one he identified just over one year ago in the same application.

Ormandy found the security hole after noticing that Keeper is now installed by default in Windows 10. He remembered a vulnerability he reported last year and managed to reproduce the same attack with only a few minor modifications.

“I’ve heard of Keeper, I remember filing a bug a while ago about how they were injecting privileged UI into pages,” the researcher said. “I checked and, they’re doing the same thing again with this version.”

The vulnerability affects the Keeper browser extensions, which, unless users opt out, are installed alongside the Keeper desktop application. The security hole allows attackers to steal passwords stored by the app if they can convince an authenticated user to access a specially crafted website.

Keeper released a patch within 24 hours of being notified by Ormandy. The fix has been rolled out with version 11.4.4 and it has already been delivered to Edge, Chrome and Firefox users via the browsers’ automatic extension update process. Safari users will need to manually update the extension.

“This potential vulnerability requires a Keeper user to be lured to a malicious website while logged into the browser extension, and then fakes user input by using a clickjacking and/or malicious code injection technique to execute privileged code within the browser extension,” Keeper said in a blog post informing customers of the vulnerability and the patch.

The company said there had been no evidence of exploitation in the wild, and pointed out that the mobile and desktop apps were not affected by the flaw.

Ormandy has made available a proof-of-concept (PoC) exploit that steals a user’s Twitter password from Keeper.

Tavis Ormandy finds critical vulnerability in Keeper password manager

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/ACi9ABCaBkM/google-researcher-finds-critical-flaw-keeper-password-manager

vBulletin to Patch Disclosed Code Execution, File Deletion Flaws

The details of two potentially serious vulnerabilities affecting version 5 of the vBulletin forum software were disclosed by researchers last week. The flaws are currently unpatched, but vBulletin developers have promised to release fixes soon.

The security holes were disclosed via Beyond Security’s SecuriTeam Secure Disclosure program by a researcher from Italy-based security firm TRUEL IT and an expert who has not been named.

One of the vulnerabilities has been described as a file inclusion issue. The flaw affects vBulletin installations that use a Windows-based server, and an unauthenticated attacker can exploit it by sending a specially crafted GET request to index.php.

An attacker can inject malicious PHP code into a file on the server (e.g. access.log) and then “include” that file by manipulating the routestring= parameter in the request. This results in the attacker’s code getting executed.

The second vulnerability, tracked as CVE-2017-17672, has been described as a deserialization issue that can be exploited by an unauthenticated attacker to delete arbitrary files and possibly even execute arbitrary code.

“vB_Library_Template’s cacheTemplates() function is a publicly exposed API which allows to fetch information on a set of given templates from the database in order to store them inside a cache variable,” Beyond Security’s advisory explains. “The $temnplateidlist variable, which can come directly from user-input, is directly supplied to unserialize(), resulting in an arbitrary deserialization primitive.”

Detailed technical information and proof-of-concept (PoC) code have been made available for both vulnerabilities.

Beyond Security claims it has been trying to report the vulnerabilities to vBulletin developers since November 21, but has not received any response. vBulletin, on the other hand, told SecurityWeek that it received no email into its ticket system regarding the vulnerabilities until last week. A patch has already been developed and it will be released once it’s tested.

Malicious actors exploiting vBulletin vulnerabilities in the wild is not unheard of. A couple of years ago, researchers had started seeing thousands of daily attempts to exploit a critical flaw less than two weeks after it was patched.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/P9R8aRdNKps/vbulletin-patch-disclosed-code-execution-file-deletion-flaws

For 8 days Windows bundled a password manager with a critical plugin flaw

For about eight days, some versions of Windows 10 quietly bundled a password manager that contained a critical vulnerability in its browser plug in, a researcher said Friday. The flaw was almost identical to one the same researcher disclosed in the same manager plugin 16 months ago that allowed websites to steal passwords.

Google Project Zero researcher Tavis Ormandy said in a blog post that the Keeper Password Manager came pre-installed on a newly built Windows 10 system derived directly from the Microsoft Developer Network. When he tested the unwanted app, he soon found the browser plugin the app prompted him to enable contained a bug that represents “a complete compromise of Keeper security, allowing any website to steal any password.” He said he uncovered a flaw 16 months ago in the non-bundled version of the Keeper browser plugin that posed the same threat.

With only basic changes to “selectors,” Ormandy’s old proof-of-concept exploit worked on the new Keeper plugin. Ormandy’s post linked to this publicly available proof-of-concept exploit, which steals an end user’s Twitter password if it’s stored in the Keeper app and the plugin is enabled. After this post went live, a Keeper spokesman said the bug was different than the one Ormandy reported 16 months ago. He said it affected only version 11 of the app, which was released on December 6, and then only when a user followed Keeper prompts to install the browser plugin. The developer on Friday fixed the flaw in the just-released version 11.4 by removing the vulnerable “add to existing” functionality. The fix came 24 hours after Ormandy privately reported the flaw to Keeper.

Fortunately, Windows 10 users wouldn’t have been vulnerable unless they opened Keeper, trusted it with their passwords, and followed prompts to install the browser plugin. If an outsider can find a bug similar to the 16-month-old vulnerability so quickly and easily, it stands to reason people inside the software company should have found it first. Microsoft officials declined to say what testing it gives to third-party apps before they’re pre-installed, and by some accounts these apps are repeatedly reinstalled against users’ wishes even after being uninstalled. Microsoft representatives also declined to say what conditions caused Windows 10 computers to install the app.

In a statement, the representatives wrote: “We are aware of the report about this third-party app, and the developer is providing updates to protect customers.”

While Ormandy reported Keeper was installed on a virtual machine created from a version of Windows intended for developers, people participating in the above-linked Reddit discussion reported Keeper was also installed on laptops, in one case right after it was taken out of the box and in another after it had been wiped clean and had Windows reinstalled. A third person reported Keeper being installed on a virtual machine created with Windows 10 Pro.

It’s possible Microsoft has a process in place for ensuring the security of third-party apps that get installed on Windows 10 machines and that somehow the Keeper vulnerability slipped through anyway. It’s also possible third-party apps don’t come with the same security assurances of other Microsoft software. Microsoft should provide an explanation how this happened and explain the precise conditions under which Keeper and other apps do and don’t get installed.

This post, including the headline, was updated to add comment from Keeper and Microsoft and to reflect details about the vulnerability and the Windows 10 versions reported to receive automatic installs. It was later edited to remove characterization the Keeper was forced on some Windows 10 users and to clarify the amount of time the prebundled version was vulnerable and the role of the browser plugin.

https://arstechnica.com/?p=1233523

Iran Used “Triton” Malware to Target Saudi Arabia: Researchers

The recently uncovered malware known as “Triton” and “Trisis” was likely developed by Iran and used to target an organization in Saudi Arabia, according to industrial cybersecurity and threat intelligence firm CyberX.

FireEye and Dragos reported on Thursday that a new piece of malware designed to target industrial control systems (ICS) had caused a shutdown at a critical infrastructure organization somewhere in the Middle East.

CyberX has also obtained samples of the malware and based on its threat intelligence team’s investigation, Triton/Trisis was likely created by Iran and the victim was likely an organization in Saudi Arabia.

“It’s widely believed that Iran was responsible for destructive attacks on Saudi Arabian IT networks in 2012 and more recently in 2017 with Shamoon, which destroyed ordinary PCs. This would definitely be an escalation of that threat because now we’re talking about critical infrastructure — but it’s also a logical next step for the adversary,” Phil Neray, VP of Industrial Cybersecurity for CyberX, told SecurityWeek.

“Stuxnet and more recently Industroyer showed that modern industrial malware can be used to reprogram and manipulate critical devices such as industrial controllers, and Triton appears to be simply an evolution of those approaches,” Neray added.

FireEye and Dragos would not comment on CyberX’s theory about Triton being developed and used by Iran. FireEye did however note in its report that the methods used were consistent with attacks previously attributed to Russian, Iranian, U.S., North Korean and Israeli nation-state actors.

Triton is designed to target Schneider Electric’s Triconex Safety Instrumented System (SIS) controllers, which are used to monitor the state of a process and restore it to a safe state or safely shut it down if parameters indicate a potentially dangerous situation.

The malware uses the proprietary TriStation protocol to communicate with SIS controllers, and it’s capable of adding new ladder logic that allows the attackers to manipulate devices.

In the attack analyzed by FireEye and Dragos, the hackers’ activities resulted in the SIS controller triggering a process shutdown, which led to the discovery of the attack. However, experts believe the shutdown was likely an accident. One possible scenario is that the attackers were conducting reconnaissance as part of an operation whose ultimate goal was to cause physical damage.

Schneider Electric has published an advisory to inform customers about the incident and provide recommendations on how to prevent potential attacks. The company says there is no evidence that the malware exploits any vulnerabilities in the Triconex product, but it’s still working on determining if there are any other attack vectors.

“I think it’s a little comical that Schneider Electric felt obliged to state that the attack did not leverage any vulnerabilities in the Tritex product,” Neray commented. “OT environments are ‘vulnerable by design’ because they lack many of the controls we now take for granted in IT networks such as strong authentication. As a result, once an attacker gets into the OT network — by stealing credentials or connecting an infected laptop or USB, for example — they have almost free reign to connect to any control device they choose, and then reprogram them with malicious ladder logic to cause unsafe conditions. Based on the FireEye report, this appears to be exactly what the TRITON attackers did, similar to the way Industroyer modified ABB configuration files to perform its attack on the Ukrainian grid.”

Eduard Kovacs is an international correspondent for SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/A6nPGUCGz_o/iran-used-triton-malware-target-saudi-arabia-researchers

Synaptics to Remove “Keylogger” Functionality From Drivers

Synaptics says recent reports inaccurately characterized a debugging tool found in its touchpad drivers as a keylogger, but the company has decided to remove the functionality from its products.

Earlier this month, a researcher reported finding what appeared to be keylogger functionality in a Synaptics touchpad driver shipped with hundreds of HP laptops. The functionality is disabled by default, but a user with administrator privileges can enable it and abuse it to log keystrokes.

The vulnerability, tracked as CVE-2017-17556, was reported to HP and patched by the company in November.

HP classified the vulnerability as medium severity (CVSS score of 6.1), and Synaptics has assigned it a low severity rating (CVSS score of 2.0). Some people agree that the flaw is not serious, arguing that an attacker with administrator privileges can install a proper keylogger and other types of malware.

Synaptics said the functionality was added to some of its drivers for diagnosing, tuning and debugging touchpads, but it was disabled before being shipped to customers. The same drivers are provided to other PC manufacturers, not just HP, but no other company has been named to date.

“Synaptics believes now, for best industry practices, that it should remove this debug tool for production versions of the driver,” the firm said. “Synaptics is unaware of any breach of security related to this debug tool.”

The company says it’s working with partners to identify affected products and release new drivers. It also recommends restricting administrator access to systems in order to prevent unauthorized activities.

“Synaptics takes great pride in making sure that its TouchPad drivers and other products meet industry-best security standards. In our new normal of heightened concern for security and privacy, Synaptics would like to apologize for any concerns that our debug tool may have raised. We have a path to immediately address this issue and other security concerns should they arise,” Synaptics stated.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/uSkC3RSfzrA/synaptics-remove-keylogger-functionality-drivers

New “Triton” ICS Malware Used in Critical Infrastructure Attack

A new piece of malware designed to target industrial control systems (ICS) has been used in an attack aimed at a critical infrastructure organization, FireEye reported on Thursday. Experts believe the attack was launched by a state-sponsored actor whose goal may have been to cause physical damage.

Few have been provided about the targeted organization, and FireEye has not linked the attack to any known group, but believes with moderate confidence that it’s a nation state actor. This assumption is based on the apparent lack of financial motivation and the amount of resources necessary to pull off such an attack.

The activity observed by FireEye may have been conducted during the reconnaissance phase of a campaign, and it’s consistent with attacks previously attributed to Russian, Iranian, U.S., North Korean and Israeli nation-state actors.

The malware, which FireEye has dubbed “Triton,” is designed to target Schneider Electric’s Triconex Safety Instrumented System (SIS) controllers, which are used to monitor the state of a process and restore it to a safe state or safely shut it down if parameters indicate a potentially hazardous situation.

According to analysis (PDF) conducted by ICS cyber security firm Dragos, which calls the malware “TRISIS”, the victim was an industrial asset owner in the Middle East. Triton ICS malware targets Schneider Triconex controllers

The engineering and maintenance tool used by Triconex SIS products is TriStation. The TriStation protocol is proprietary and there is no public documentation for it, but Triton does leverage this protocol, which suggests that the attackers reverse engineered it when creating their malware.

Triton, which FireEye has described as an attack framework, is designed to interact with Triconex SIS controllers. The malware can write and read programs and functions to and from the controller, and query its state, but not all capabilities had been leveraged in this specific attack.

The hackers deployed Triton on a Windows-based engineering workstation. The malware had left legitimate programs running on the controllers in place, but added its own programs to the execution table. The threat attempts to return the controller to a running state in case of a failure, or overwrite the malicious program with junk data if the attempt fails, likely in an effort to cover its tracks.

In general, once the SIS controller has been compromised, the attacker can reprogram the device to trigger a safe state, which could cause downtime and result in financial losses. Attackers could also reprogram the SIS so that it allows dangerous parameters without triggering the safe state, which can have a physical impact, including on human safety, products and equipment, FireEye said.

However, the physical damage that can be done via the SIS controller is limited by the mechanical safety systems deployed by an organization.

In the case of the critical infrastructure attack investigated by FireEye, the attackers shut down operations after causing the SIS controllers to initiate a safe shutdown, but they may have done it inadvertently while trying to determine how they could cause physical damage.

On the other hand, FireEye noted that “intrusions of this nature do not necessarily indicate an immediate intent to disrupt targeted systems, and may be preparation for a contingency.”

Schneider Electric has launched an investigation into this incident, but initial evidence suggests that Triton does not leverage any vulnerabilities in the Triconex product and the company is not aware of any other attacks.

“It is important to note that in this instance, the Triconex system responded appropriately, safely shutting down plant operations. No harm was incurred by the customer or the environment,” the industrial giant said.

Schneider said the targeted safety controllers are widely used in critical infrastructure, and it’s working on determining if there are any additional attack vectors. In the meantime, customers have been advised not to leave the front panel key position in “Program” mode when the controller is not being configured. The malware can only deliver its payload if the key switch is set to this mode. Signatures of the malware samples identified by FireEye have been provided to cybersecurity firms so security products should be able to detect at least some variants of the threat.

There are only a handful of malware families specifically designed to target industrial systems, including the notorious Stuxnet, and Industroyer, the malware used in the December 2016 attack aimed at an electrical substation in Ukraine. Last year, FireEye identified an ICS malware dubbed IRONGATE, but it had not been observed in any actual attacks, leading experts to believe that it may have been developed for research purposes.

*Updated with additional details from Dragos

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/qs12NxEi-iU/new-ics-malware-triton-used-critical-infrastructure-attack

Critical 0-Day Allows Remote Hacking of DirecTV Video Bridge

An unpatched critical vulnerability impacting a wireless video bridge used by DirecTV allows for an attacker to remotely execute code on the vulnerable devices, Zero-Day Initiative researchers reveal.

The security vulnerability was discovered in the Linksys WVBR0-25 wireless video bridge, which was designed to pair with the Wireless Genie Mini (C41W) cable box to ensure communication with DirecTV’s main Genie DVR.

Tracked as CVE-2017-17411 and featuring a CVSS score of 10, the vulnerability was discovered by Trend Micro DVLabs researcher Ricky Lawshae, who says that authentication isn’t necessary when attempting to exploit the vulnerability for executing arbitrary code.

“The specific flaw exists within the web management portal. The issue lies in the lack of proper validation of user data before executing a system call. An attacker could leverage this vulnerability to execute code with root privileges,” a ZDI advisory reads.

While attempting to browse to the web server on the device, Lawshae discovered that, instead of a login prompt or an index page, the service would deliver “the output of several diagnostic scripts containing just about everything you could want to know about the bridge, including the WPS pin, connected clients, running processes, and much more.”

Not only is this an information disclosure issue, but the log file also revealed the commands being executed and the output of every command. Moreover, it showed that the user’s IP address and user-agent were used in a system command as a form of access logging or tracking functionality.

Nonetheless, the device isn’t properly sanitizing the user-agent it is given and the researcher was able to change the user-agent and send untrusted data to the system for execution. What Lawshae discovered was that the system executed the command as root, without a login prompt or input sanitization before sending the command to the function responsible for its execution.

Because the lighttpd process runs with root privileges, executed commands run with root privileges as well, even if they come from untrusted input.

“It literally took 30 seconds of looking at this device to find and verify an unauthenticated remote root command injection vulnerability,” Lawshae says.

After performing a deeper analysis of the device, the researcher discovered that it was running a lighttpd web server. It was configured to render a SysInfo.asp file when browsing to the root of the website, and this file was the page displaying all the diagnostic output.

“It also showed dispatcher.cgi was actually a symbolic link to apply.cgi, which itself is a compiled ARC executable file used as kind of a “do everything” agent for the web server. It was in apply.cgi that I found the actual root cause,” Lawshae, who also published a video detailing the vulnerability, explains.

The ZDI attempted to work with Linksys to address the vulnerability, but to no avail. Although it was informed on the bug in June, the company hasn’t even acknowledged it yet, which determined ZDI to publish the 0-day report.

SecurityWeek contacted Linksys for a comment on the matter but hasn’t received a response yet. We’ll update the article as soon as we hear back from them.

“In the absence of an actual patch from the vendor, users should protect themselves by limiting the devices that can interact with the WVBR0-25 to those that actually need to reach it,” Lawshae concludes.

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/1EYzkfi7_-4/critical-0-day-allows-remote-hacking-directv-video-bridge

Open Source Vulnerabilities: Are You Prepared to Run the Race?

After going through 24 seasons of cross-country, winter track, and spring track with my boys, I fully understand that if you put your toe on the line, you had better be prepared to race, or bad things happen.

As the use of open source continues to rise, many organizations are putting their toes on the line for a race they are ill-prepared to run, much less win. In this race, losing could put your organization squarely into some unwanted headlines.

When developers in your organization use open source, they are putting your toe on the line because that open source component may have vulnerabilities that put you at risk.

Responsibly disclosing vulnerabilities

You see, the disclosure of a vulnerability kicks off an IT security race. Hackers seize on the new vulnerability and begin to ping externally facing websites to see whether they can find it. At the same time, IT security folks begin the process of determining whether any of their sites have that vulnerability and, if so, closing it before the hackers get there. If the hackers get there before the IT security people do, the result is most likely a breach.

A great example recently jumped to the headlines. In March, a vulnerability was disclosed for a popular and widely used open source web server, Apache. This vulnerability involved Apache Struts, a component of the Apache server that helps Apache users manage and deliver site content.

The disclosure of this vulnerability set off the race between IT security and the hackers. The hackers knew they had a 45- to 90-day window of opportunity, so they took off with a sense of urgency. In September, Equifax announced that it had been breached, and that the Apache Struts vulnerability was the entry point.

In the case of Equifax, the hackers won the race.

Acceleration of open source software

As open source usage continues to accelerate, it is not a stretch to believe that such scenarios will repeat with increasing frequency. Many studies now say most new software is made up of 60% open source components. As open source grows, it follows that vulnerabilities will increase proportionately.

Many organizations are ill-equipped to run the race because they do not have a handle on their use of open source. They don’t have the proper organizational policies, they don’t educate their developer teams, and they don’t deploy the proper tools to help secure and manage open source software.

This is too broad a subject to tackle in one sitting, so let’s get back to the race and how it could be affected by having the right tools in place. How many organizations track their use of open source? For the organizations who do, how do they do it?

Tracking open source

Regarding the first question, the truth is that many organizations have no process for tracking open source, and even for those who do, it may not be a pretty picture. There are tools to help organizations track their use of open source components. These software composition analysis (SCA) tools—the name given such products by a leading analyst firm—are readily available and have progressed significantly to keep pace with the growing adoption of open source. But for many organizations, Excel is the tool of choice.

Somewhere in the development shop is one or more people tasked with keeping track of open source usage by logging it into a spreadsheet. The process relies on the other developers communicating with these folks when they use open source components and when they make changes to those components. What could go wrong?

A lot could go wrong. If the Apache Struts vulnerability were announced today and your organization had no process in place for managing open source, you would be forced to go through your applications one by one to determine whether they used the offending Apache Struts component. Until you did that, you would have no idea as to the risk to your organization.

If you at least had a spreadsheet, you might have some idea of where to look, but you would be at the mercy of the keeper of the record—and the communication of the developers—regarding the accuracy of the information. It might save you some time, but because you can’t trust that information, you wouldn’t be much better off than those with no management system.

What happens when software composition analysis enters the race?

Applying a software composition analysis (SCA) tool to the process changes the picture dramatically. An SCA tool should be able to perform some basic tasks for any development organization:

• Identify – An SCA tool should be able to scan an organization’s software and identify the open source components in the code.

• Catalog – Once the tool identifies open source components, it should catalog them in a digital repository that can be readily queried.

• Evaluate – There are multiple sources for open source vulnerability data. The most commonly used is the National Vulnerability Database (NVD). These data sources can be referenced to see whether any of the open source in use has known vulnerabilities.

With an SCA tool in place, you would be able to quickly scan the information repository and know where Apache Struts was used, as well as additional information about the version. Furthermore, anyone who tried to use the offending version of Apache Struts after the vulnerability was disclosed should get a warning about that vulnerability from the SCA tool, so the problem is addressed before the code is deployed.

Using open source software makes good sense and provides organizations development speed and agility. But organizations need to know the risks. If you are going to toe the line, be prepared to race.

Jim Ivers is VP of Marketing for the Software Integrity Group at Synopsys. Jim is a 30-year technology veteran who has spent the last ten years in IT security. Prior to Cigital, Jim was the CMO at companies such as Covata, Triumfant, Vovici, and Cybertrust, a $200M security solutions provider that was sold to Verizon Business. Jim also served as VP of Marketing for webMethods and VP of Product Management for Information Builders.

Previous Columns by Jim Ivers:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/jedT3jKZueo/open-source-vulnerabilities-are-you-prepared-run-race

Threat Modeling the Internet of Things: Modeling Reaper

What a timely way to end this series on Threat Modeling the Internet of Things (IoT). An advanced thingbot, nicknamed Reaper (or IoTroop), was recently discovered infecting hordes of IoT devices. Reaper ups the ante for IoT security. It has a sophisticated C2 channel system and a Lua code execution environment (to deliver much more complicated attacks), and it comes prepackaged with 100 DNS open resolvers.

Researchers are tracking Reaper, even though it hasn’t launched any attacks yet. Let’s hope it’s like Conficker—an original virus/botnet that at its peak enslaved 10 million Windows boxes, but was never activated.

The discovery of Reaper in September 2017, in between the fourth and fifth installments of this series on Threat Modeling IoT, allows us to conduct an interesting thought experiment.

Could threat model have prevented Reaper?

Part 1 of this series put forth the premise that if we want to make a safer Internet of Things, we need to be doing more rigorous threat models. Part 2 introduced simple threat modeling, and Part 3 applied a threat model to a real-world IoT project. Part 4 discussed the mitigation for the most crucial component of IoT consumables, the authentication system.

Would the threat model presented in the series have mitigated Reaper? Let’s take a look.

Recall that a simple threat model consists of three steps:

1. Cataloging the assets at play.

2. Brainstorming the threats to those assets.

3. Scoring (prioritizing) those threats to create a mitigation strategy.

In Part 2, we mentioned that the OWASP IoT Project page contains a typical list of IoT project assets:

Device Threat Surface

Ecosystem Threat Surface

• Device Memory

• Device Firmware

• Physical Interfaces

• Device Network Services

• Local Data Storage

• Device Web Interface

• Update Mechanism

• Ecosystem Access Control

• Ecosystem Communications

• Administrative Interface

• Cloud Web Interface

• Vendor Backend APIs

• Third-Party Backend APIs

• Mobile Application

Recall from Part 3 of this series that you can use the STRIDE acronym to help you brainstorm threats to the asset list. STRIDE stands for:

• (S)poofing of user identity

• (T)ampering

• (R)epudiation

• (I)nformation disclosure

• (D)enial of service

• (E)scalation of privilege

Reaper is fascinating because it doesn’t just contain one infection threat vector; it contains at least nine! If we take those nine vulnerabilities that Reaper is using to infect IoT devices and put them in a table, we can see that the threat modeling we outlined in the previous articles could likely have uncovered them before distribution.

IoT Vulnerability Chart

A quick glance at the table shows that all nine of the vulnerabilities include escalation of privilege. The vulnerabilities are described as remote code execution (RCE) or command injection, but either way it’s mostly the same thing: unsanitized input. If you were a developer of an IoT device, this table should be a wake-up call. Obviously, sanitize your input; but also, maybe it’s time to whitelist process execution. There’s probably no reason that the administrative web server should be able to launch telnetd, for example.

In the OWASP device assets above, the final device threat surface item is Update Mechanism. One interesting aspect of Reaper is that it has a non-aggressive infection schedule. If all manufacturers had a way to push updates to their devices, they might be able to get ahead of Reaper by closing the listed vulnerabilities before the devices could get infected. It’s nearly 2018; IoT devices need to have push updates, because if they don’t, they will eventually get co-opted into Reaper, or perhaps a more malignant thingbot.

Conclusion

There are a lot of lessons to be learned from the IoT thingbot named Reaper. Reaper is holding itself up as a blinky light in front of our faces, reminding the InfoSec community that we really need to get ahead of IoT madness. The manufacturers of many of these devices are making some rookie mistakes. Threat modeling is a decent first step toward improving the situation.

But given the number of IoT devices coming online every day, I suspect the situation will get worse before it gets better.

David Holmes is an evangelist for F5 Networks‘ security solutions, with an emphasis on distributed denial of service attacks, cryptography and firewall technology. He has spoken at conferences such as RSA, InfoSec and Gartner Data Center. Holmes has authored white papers on security topics from the modern DDoS threat spectrum to new paradigms of firewall management. Since joining F5 in 2001, Holmes has helped design system and core security features of F5’s Traffic Management Operating System (TMOS). Prior to joining F5, Holmes served as Vice President of Engineering at Dvorak Development. With more than 20 years of experience in security and product engineering, Holmes has contributed to security-related open source software projects such as OpenSSL. Follow David Holmes on twitter @Dholmesf5.

Previous Columns by David Holmes:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/1CSmjFi03Wg/threat-modeling-internet-things-modeling-reaper