Skip navigation
All Places > Information Security > Blog

This is a guest post from our frequent contributor Kevin Beaver. You can read all of his previous guest posts here.

 

2016 marks the 15th year that I have been working for myself as an independent information security consultant. People who are interested in working for themselves often ask for my thoughts on what it takes to go out - and stay out - on your own. Early on, I thought it was about business cards and marketing slicks. In fact, I spent so much time, effort, and money on company tchotchkes that I'm confident I could have earned twice as much money in my first year alone had I focused on what was truly important. I soon found out that starting my information security consulting practice wasn't about "things". Instead, I saw the value of networking and surrounding myself with successful people – people that I could learn not only about information security but, more importantly, what it takes to be successful in business.

 

In what ways does this apply to your career in IT and information security? Every way! If you look at the essence of what it takes to be successful in our field, it's not about being a master of the technical stuff. Anyone can learn those things. Sure, some are better than others, but at the end of the day, the technical challenges are not our real challenges. Instead, it's about being able to master emotional intelligence including, among other things, the relationships we have with people who are in a position to both help us and hurt us. The relationships you have with others has an enormous impact on how effective you can be in your job and how far you can go in your career.

 

You certainly don’t have to work for yourself to benefit from this. Whether you work for a large corporation, a small startup, a government agency or a nonprofit, think about who you currently know and who you should get to know that can have a positive influence on your IT/security career. It might be a current executive in your own organization. It might be a fellow IT pro, auditor, or entrepreneur you meet at a security conference. It might be the parent of your child’s friend who’s an attorney or a doctor. It might be someone else in the information security field who you could reach out to on LinkedIn to start having a dialog with. There are a lot of people – many of which you probably haven’t thought about – who can help you out in tremendous ways. Not to make money off of but to learn from and collaborate. This leads me to an important point: whenever you are reaching out and meeting new people, make sure that you are also giving to this person in some capacity. The last thing anyone wants is a user of their relationship with nothing in return.

 

Looking back, the first few years of starting my business I should have spent surrounding myself with people in/around IT as well as those who were in a position to coach and mentor me along to be a better business person. This would've created more opportunities for me earlier on than anything else. As recently as a few weeks ago, I interacted with a young salesman who was more concerned about whether I had a marketing brochure rather than getting to know
me and understanding how I might be able to help him with his information security needs (he was hoping to sell my services to his clients). This is a common approach to one’s career: have a beautiful marketing slick or website and
they will come, and buy. If it were that simple, countless people would be super successful in every field. Instead, it takes persistence, year after year. Work on building and maintaining your relationships both inside and outside of your
organization as that’s what will help you succeed the most in your IT and security endeavors long-term.

The following issues affect ExaGrid storage devices running firmware prior to version 4.8 P26:

 

CVE-2016-1560: The web interface ships with default credentials of 'support:support'. This credential confers full control of the device, including running commands as root. In addition, SSH is enabled by default and remote root login is allowed with a default password of 'inflection'.

 

CVE-2016-1561: Two keys are listed in the root user's .ssh/authorized_keys file: one labeled "ExaGrid support key" and one "exagrid-manufacturing-key-20070604". A copy of the private key for the latter authorized key ships on the device in /usr/share/exagrid-keyring/ssh/manufacturing.

 

These issues have been rectified in firmware version 4.8 P26, available from the vendor.

 

Credit

Discovered by James @egyp7 Lee of Rapid7, Inc., and disclosed to the vendor and CERT per Rapid7's disclosure policy.

 

Product Description

ExaGrid provides a series of disk backup appliances based on Linux. The vendor's website states, "ExaGrid's appliances are deduplication storage targets for all industry leading backup applications." In addition, ExaGrid provides several hundred customer testimonials, demonstrating its popularity as a backup solution across several vertical markets.

 

Exploitation

Exploiting these issues require a standard ssh client for the first two issues, and a standard web browser with the third.

 

The SSH private key, which is common to every shipping device, is located on the device at /usr/share/exagrid-keyring/ssh/manufacturing, available to anyone who owns a device or anyone who can download and extract the firmware.

 

In order to facilitate detection of this exposure, the private key is provided below.

 

Fingerprints

MD5:22:c8:a9:c3:01:a0:17:31:a5:43:f2:70:4a:1c:55:f6

SHA1:1szdeYNwqO2Jom6rby+RTybD9cA

 

Public Key

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBnZQ+6nhlPX/JnX5i5hXpljJ89bSnnrsSs51hSPuoJGmoKowBddIS K7s10AIpO0xAWGcr8PUr2FOjEBbDHqlRxoXF0Ocms9xv3ql9EYUQ5+U+M6BymWhNTFPOs6gFHUl8Bw3t 6c+SRKBpfRFB0yzBj9d093gSdfTAFoz+yLo4vRw==

 

Private Key

-----BEGIN RSA PRIVATE KEY-----

MIICWAIBAAKBgGdlD7qeGU9f8mdfmLmFemWMnz1tKeeuxKznWFI+6gkaagqjAF10

hIruzXQAik7TEBYZyvw9SvYU6MQFsMeqVHGhcXQ5yaz3G/eqX0RhRDn5T4zoHKZa

E1MU86zqAUdSXwHDe3pz5JEoGl9EUHTLMGP13T3eBJ19MAWjP7Iuji9HAgElAoGA

GSZrnBieX2pdjsQ55/AJA/HF3oJWTRysYWi0nmJUmm41eDV8oRxXl2qFAIqCgeBQ

BWA4SzGA77/ll3cBfKzkG1Q3OiVG/YJPOYLp7127zh337hhHZyzTiSjMPFVcanrg

AciYw3X0z2GP9ymWGOnIbOsucdhnbHPuSORASPOUOn0CQQC07Acq53rf3iQIkJ9Y

iYZd6xnZeZugaX51gQzKgN1QJ1y2sfTfLV6AwsPnieo7+vw2yk+Hl1i5uG9+XkTs

Ry45AkEAkk0MPL5YxqLKwH6wh2FHytr1jmENOkQu97k2TsuX0CzzDQApIY/eFkCj

QAgkI282MRsaTosxkYeG7ErsA5BJfwJAMOXYbHXp26PSYy4BjYzz4ggwf/dafmGz

ebQs+HXa8xGOreroPFFzfL8Eg8Ro0fDOi1lF7Ut/w330nrGxw1GCHQJAYtodBnLG

XLMvDHFG2AN1spPyBkGTUOH2OK2TZawoTmOPd3ymK28LriuskwxrceNb96qHZYCk

86DC8q8p2OTzYwJANXzRM0SGTqSDMnnid7PGlivaQqfpPOx8MiFR/cGr2dT1HD7y

x6f/85mMeTqamSxjTJqALHeKPYWyzeSnUrp+Eg==

-----END RSA PRIVATE KEY-----

 

Mitigations

Removing the two backdoor keys from /root/.ssh/authorized_keys and /root/.ssh/authorized_keys2 files and changing the root user's password will prevent exploitation of the first vulnerability.

 

As for the web UI exposure, it appears to be possible to change the password for the 'support' account through the web interface. However, this is likely to break software updates as the update process uses that account with a hard coded password.

 

Vendor Response

The vendor has fixed the reported vulnerabilities in firmware version 4.8 P26. Customers are urged to contact their support representative to acquire this firmware update.

 

"ExaGrid prides itself on meeting customer requirements," said Bill Andrews, CEO of ExaGrid. "Security is without question a top priority, and we take any such issues very seriously. When we were informed by Rapid7 of a potential security weakness, we addressed it immediately. We value Rapid7's involvement in identifying security risks since strong security will always be a key customer requirement."

 

Disclosure Timeline

This vulnerability advisory was prepared and released in accordance with Rapid7's disclosure policy.

 

  • Tue, Jan 26, 2016: Initial discovery by James Lee of Rapid7
  • Fri, Jan 29, 2016: Initial contact to vendor
  • Mon, Feb 01, 2016: Response from vendor and details disclosed
  • Mon, Feb 23, 2016: Disclosure to CERT
  • Tue, Mar 08, 2016: Vendor commits to a patch release in March.
  • Thu, Mar 24, 2016: Vendor provides an updated firmware image
  • Thu, Apr 07, 2016: Public disclosure and Metasploit module published.

A major area of focus in the current cybersecurity policy discussion is how growing adoption of encryption impacts law enforcement and national security, and whether new policies should be developed in response. This post briefly evaluates several potential outcomes of the debate, and provides Rapid7's current position on each.

 

Background

 

Rapid7 has great respect for the work of our law enforcement and intelligence agencies. As a cybersecurity company that constantly strives to protect our clients from cybercrime and industrial espionage, we appreciate law enforcement's role in deterring and prosecuting wrongdoers. We also recognize the critical need for effective technical tools to counter the serious and growing threats to our networks and personal devices. Encryption is one such tool.

 

Encryption is a fundamental means of protecting data from unauthorized access or use. Commerce, government, and individual internet users depend on strong security for our communications. For example, encryption helps prevent unauthorized parties from reading sensitive communications – like banking or health information – traveling over the internet. Another example: encryption underpins certificates that demonstrate authenticity (am I who I say I am?), so that we can have high confidence that a digital communication – such as a computer software security update – is coming from the right source and not a man-in-the-middle attacker. The growing adoption of encryption for features like these has made users much more safe than we would be without it. Rapid7 believes companies and technology innovators should be able to use the encryption protocols that best protect their customers and fit their service model – whether that protocol is end-to-end encryption or some other system.

 

However, we also recognize this increased data security creates a security trade-off. Law enforcement will at times encounter encryption that it cannot break by brute force and for which only the user – not the software vendor – has the key, and this will hinder lawful searches. The FBI's recently concluded efforts to access the cell phone belonging to deceased terrorist Syed Farook of San Bernardino, California, was a case study in this very issue. Although the prevalence of systems currently secured with end-to-end encryption with no other means of access should not be overstated, law enforcement search attempts may be thwarted more often as communications evolve to use unbreakable encryption with greater frequency. This prospect has tempted government agencies to seek novel ways around encryption. While we do not find fault with law enforcement agencies attempting to execute valid search or surveillance orders, several of the options under debate for circumventing encryption pose broad negative implications for cybersecurity.

 

Weakening encryption

 

One option under discussion is a legal requirement that companies weaken encryption by creating a means of "exceptional access" to software and communications services that government agencies can use to unlock encrypted data. This option could take two forms – one in which the government agencies hold the decryption keys (unmediated access), and one in which the software creator or another third party holds the decryption keys (mediated access). Both models would impose significant security risks for the underlying software or service by creating attack surfaces for bad actors, including cybercriminals and unfriendly international governments. For this reason, Rapid7 does not support a legal requirement for companies or developers to undermine encryption for facilitating government access to encrypted data.

 

The huge diversity of modern communications platforms and software architecture makes it impossible to implement a one-size-fits-all backdoor into encryption. Instead, to comply with a hypothetical mandate to weaken encryption, different companies are likely to build different types of exceptional access. Some encryption backdoors will be inherently more or less secure than others due to technical considerations, the availability of company resources to defend the backdoor against insider and external threats, the attractiveness of client data to bad actors, and other factors. The resulting environment would most likely be highly complex, vulnerable to misuse, and burdensome to businesses and innovators.

 

Rapid7 also shares concerns that requiring US companies to provide exceptional access to encrypted communications for US government agencies would lead to sustained pressure from many jurisdictions – both local and worldwide – for similar access. Companies or oversight bodies may face significant challenges in accurately tracking when, by whom, and under what circumstances client data is accessed – especially if governments have unmediated access to decryption keys. If US products are designed to be inherently insecure and "surveillance-ready," then US companies will face a considerable competitive disadvantage in international markets where more secure products are available.

 

Legal mandates to weaken encryption are unlikely to keep unbreakable encryption out of the hands of well-resourced criminals and terrorists. Open source software is commonly "forked," and it should be expected that developers will modify open source software to remove an encryption backdoor. Jurisdictions without an exceptional access requirement could still distribute closed source software with unbreakable encryption. As a result, the cybersecurity risks of weakened encryption are especially likely to fall on users who are not already security-conscious enough to seek out these workarounds.

 

Intentionally weakening encryption or other technical protections ultimately undermines the security of the end users, businesses, and governments. That said, if companies or software creators voluntarily choose to build exceptional access mechanisms into their encryption, Rapid7 believes it is their right to do so. However, we would not recommend doing so, and we believe companies and creators should be as transparent as possible with their users about any such feature.

 

"Technical assistance" – compelled malware

 

Another option under debate is whether the government can force developers to build custom software that removes security features of the developers' products. This prospect arose in connection with the FBI's now-concluded bid to unlock Farook's encrypted iPhone to retrieve evidence for its terrorism investigation. In that case, a magistrate judge ordered Apple to develop and sign a custom build of iOS that would disable several security features preventing the FBI from using electronic means to quickly crack the phone's passcode via brute force. This custom version of iOS would have been deployed like a firmware update only to the deceased terrorist's iPhone, and Apple would have maintained control of both the iPhone and the custom iOS. However, the FBI ultimately cracked the iPhone without Apple's assistance – with help, according to some reports, from a third party company – and asked the court to vacate its order against Apple. Still, it's possible that law enforcement agencies could again attempt to legally compel companies to hack their own products in the future.

 

In the Farook case, the government had good reason to examine the contents of the iPhone, and clearly took steps to help prevent the custom software from escaping into the wild. This was not a backdoor or exceptional access to encryption as traditionally conceived, and not entirely dissimilar to cooperation Apple has offered law enforcement in the past for unencrypted older versions of iOS. Nonetheless, the legal precedent that would be set if a court compels a company or developer to create malware to weaken its own software could have broad implications that are harmful to cybersecurity.

 

FBI Director James Comey confirmed in testimony before Congress that if the government succeeded in court against Apple, law enforcement agencies would likely use the precedent as justification to demand companies create custom software in the future. It's possible the precedent could be applied to a prolonged wiretap of users of an encrypted messaging service like WhatsApp, or a range of other circumstances. Establishing the limits of this authority would be quite important.

 

If the government consistently compelled companies to create custom software to undermine the security of their own products, the effect could be proliferation of company-created malware. Companies would need to defend their malware from misuse by both insiders and external threats while potentially deploying the malware to comply with many government demands worldwide, which – like defending an encryption backdoor – would be considerably burdensome on companies. This outcome could reduce user trust in the security of vendor-issued software updates, even though it is generally critical for cybersecurity for users to keep their software as up to date as possible. Companies may also design their products to be less secure from the outset, in anticipation of future legal orders to circumvent their own security.

 

These scenarios raise difficult questions for cybersecurity researchers and firms like Rapid7. Government search and surveillance demands are frequently paired with gag orders that forbid the recipient (such as the individual user or a third party service provider) from discussing the demands. Could this practice impact public disclosure or company acknowledgment of a vulnerability when researchers discover a security flaw or threat signature originating from software a company is compelled to create for law enforcement? When would a company be free to fix its government-ordered vulnerability? Would cybersecurity firms be able to wholeheartedly recommend clients accept vendor software updates?

 

Rapid7 does not support legal requirements – whether via legislation or court order – compelling companies to create custom software to degrade security. Creating secure software is very difficult under the best of circumstances, and forcing companies to actively undermine their own security features would undo decades of security learnings and practice. If the government were to compel companies to provide access to its products, Rapid7 believes it would be preferable to use tools already available to the companies (such as that which Apple offered prior to iOS 8) in limited circumstances that do not put non-targeted users at risk. If a company has no means to crack its products already available, the government should not compel a company to create custom software to undermine their products' security features. Software developers should also be free to develop patches or introduce more secure versions of their products to fix vulnerabilities at any time.

 

Government hacking and forensics

 

Finally, there is the option of government deploying its own tools to hack products and services to obtain information. End-to-end encryption provides limited protection when one of the endpoints is compromised. If government agencies do not compel companies to weaken their own products, they could exploit existing vulnerabilities themselves. As noted above, the government's exploitation of existing vulnerabilities was the outcome of the FBI's effort to compel Apple to provide access to Farook's iPhone. Government has also turned to hacking or implanting malware in other contexts well before the Farook case.

 

In many ways, this activity is to be expected. It is not an irrational priority for law enforcement agencies to modernize their computer penetration capabilities to be commensurate with savvy adversaries. A higher level of hacking and digital forensic expertise for law enforcement agencies should improve their ability to combat cybercriminals more generally. However, this approach raises its own set of important questions related to transparency and due process.

 

Upgrading the technological expertise of law enforcement agencies will take time, education, and resources. It will also require thoughtful policy discussions on what the appropriate rules for government hacking should be – there are few clear and publicly available standards for government use of malware. One potentially negative outcome would be government stockpiling of zero day vulnerabilities for use in investigations, without disclosing the vulnerabilities to vendors or the public. The picture is clouded further when the government partners with third party organizations to hack on the government's behalf, as may have occurred in the case of Farook's iPhone – if the third party owns a software exploit, could IP or licensing agreements prevent the government from disclosing the vulnerability to the vendor? White House Cybersecurity Coordinator Michael Daniel noted there were "few hard and fast rules" for disclosing vulnerabilities, but pointed out that zero day stockpiles put Internet users at risk and would not be in the interests of national security. We agree and appreciate the default of vulnerability disclosure, but clearer rules on transparency and due process in the context of government hacking are quickly becoming increasingly important.

 

No easy answers

 

We view the complex issue of encryption and law enforcement access as security versus security. To us, the best path forward is that which would provide the best security for the most number of individuals. To that end, Rapid7 believes that we should embrace the use of strong encryption without compelling companies to create software that undermines their product security features. We want the government to help prevent crime by working with the private sector to make communications services, commercial products, and critical infrastructure trustworthy and resilient. The foundation of greater cybersecurity will benefit us all in the future.

 

 

Harley Geiger

Director of Public Policy, Rapid7

todb

Getting Ahead of Badlock

Posted by todb Employee Mar 30, 2016

badlock-tay-selly.jpgWhile we are keeping abreast of the news about the foretold Badlock vulnerability, we don't know much more than anyone else right now. We're currently speculating that the issue has to do with the fundamentals of the SMB/CIFS protocol, since the vulnerability is reported to be present in both Microsoft's and Samba's implementations. Beyond that, we're expecting the details from Microsoft as part of their regularly scheduled patch Tuesday.

 

How Bad Is It?

Microsoft and the Samba project both clearly believe this is a more critical than usual problem, but in the end, it's almost certainly limited to SMB/CIFS, much like MS08-067 was. This comparison should be alternatively comforting and troubling. While the SMB world isn't the same as it was in late 2008, MS08-067 continues to be a solid, bread and butter vulnerability exploited by internal penetration testers. We are very concerned about the population of chronically unpatched SMB/CIFS servers that lurk in the dusty corners of nearly every major IT enterprise.

 

What Can I Do Now?

Any large organization with a significant install base of Windows servers should take this time clearing patch and reboot schedules for production SMB/CIFS servers using their usual Patch Tuesday change control processes. Assuming it's even remotely as bad as the discoverers are making it out to be, this is the patch you want to release into production pretty much as fast as your change control processes allow. Therefore, given the high visibility of this particular issue, it would be wise to treat it as a mostly predictable emergency.

 

In the event you feel like you're set up for a rapid patch deployment, this is also a pretty great time to conduct an assessment of both your intentional and accidental SMB/CIFS footprint. While Windows machines today ship with an operating system-level firewall by default, all too often, users will "temporarily" disable these protections in order to get some specific file sharing task done, and there's really nothing more permanent in an IT environment than a temporary workaround.

 

In short, our advice is take advantage of the hype around this bug, and buy some time from your management to get some legwork done in advance of next Patch Tuesday. You might be surprised with what you find, but it's better to discover those rogue SMB/CIFS endpoints now, in a measured way, than during a panic-fueled crisis. And if you haven't exercised your emergency patch procedures in a while, well, now you have every excuse you could ask for, short of an actual, unplanned emergency.

by Suchin Gururangan & Bob Rudis

 

At Rapid7, we are committed to engaging in research to help defenders understand, detect and defeat attackers. We conduct internet-scale research to gain insight into the volatile threat landscape and share data with the community via initiatives like Project Sonar1 and Heisenberg2. As we crunch this data, we have a better idea of the global exposure to common vulnerabilities and can see emerging patterns in offensive attacks.

 

We also use this data to add intelligence to our products and services. We’re developing machine learning models that use this daily internet telemetry to identify phishing sites and find+classify devices through their certificate and site configurations.

 

We have recently focused our research on how these tools can work together to provide unique insight on the state of the internet. Looking at the internet as a whole can help researchers identify stable, macro level trends in the individual attacks between IP addresses. In this post, we’ll give you window into these explorations.

 

IPv4 Topology

First, a quick primer on IPv4, the fourth version of the Internet Protocol. The topology of IPv4 is characterized by three levels of hierarchy, from smallest to largest: IP addresses, subnets, and autonomous systems (ASes). IP addresses on IPv4 are 32-bit sequences that identify hosts or network interfaces. Subnets are groups of IP addresses, and ASes are blocks of subnets managed by public institutions and private enterprises. IPv4 is divided into about 65,000 ASes, at least 30M subnets, and 232 IP addresses.

 

Malicious ASes

There has been a great deal of academic and industry focus on identifying malicious activity in-and-across autonomous systems3,4,5,6, and for good reasons. Well over 50% of “good” internet traffic comes from a small subset of large, well-defined ocean-like ASes pushing content from Netflix, Google, Facebook, Apple and Amazon. Despite this centralization “cloud” content, we’ll show that the internet has become substantially more fragmented over time, enabling those with malicious intent to stake their claim in less friendly waters. In fact, our longitudinal data on phishing activity across IPv4 presented an interesting trend: a small subset of autonomous systems have regularly hosted a disproportionate amount of malicious activity. In particular, 200 ASes hosted 70% of phishing activity from 2007 to 2015 (data: cleanmx archives7). We wanted to understand what makes some autonomous systems more likely to host malicious activity.

 

overall_density-1.png

top_20-1.png

 

IPv4 Fragmentation

We gathered historical data on the mapping between IP addresses and ASes from 2007 to 2015 to generate a longitudinal map of IPv4. This map clearly suggested IPv4 has been fragmenting. In fact, the total number of ASes has grown 60% in the past decade. During the same period, there has been a rise in the number of small ASes and a decline in the number of large ones. These results make sense given that IPV4 address space has been exhausted. This means that growth in IPv4 access requires the reallocation of existing address space into smaller and smaller independent blocks.

 

RStudioScreenSnapz024.png

 

 

AS Fragmentation

Digging deeper into the Internet hierarchy, we analyzed the composition, size, and fragmentation of malicious ASes.

ARIN, one of the primary registrars of ASes, categorizes subnets based on the number of IP addresses they contain. We found that the smallest subnets available made up on average 56±3.0 percent of a malicious AS.

We inferred the the size of an AS by calculating its maximum amount of addressable space. Malicious ASes were in the 80-90th percentile in size across IPv4.

 

To compute fragmentation, subnets observed in ASes overtime were organized into trees based on parent-child relationships (Figure 3). We then calculated the ratio of the number of root subnets, which have no parents, to the number of subsequent child subnets across the lifetime of the AS. We found that malicious ASes were 10-20% more fragmented than other ASes in IPv4.

 

RStudioScreenSnapz024.png

 

These results suggest that malicious ASes are large and deeply fragmented into small subnets. ARIN fee schedules8 showed that smaller subnets are significantly less expensive to purchase; and, the inexpensive nature of small subnets may allow malicious registrars to purchase many IP blocks for traffic redirection or host proxy servers to better float under the radar.

 

 

Future Work

Further work is required to characterize the exact cost structure of buying subnets, registering IP blocks, and setting up infrastructure in malicious ASes.

 

We'd also like to understand the network and system characteristics that cause attackers to choose to co-opt a specific autonomous system over another. For example, we used Sonar’s historical forwardDNS service and our phishing detection algorithms to characterize all domains that have mapped to these ASes in the past two years. Domains hosted in malicious ASes had features that suggested deliberate use of specific infrastructure. For example, 'wordpress' sites were over-represented in some malicious ASes (like (like AS4808), and GoDaddy was by far the most popular registrar for malicious sites across the board.

 

We can also use our SSL Certificate classifier to understand the distribution of devices hosted in ASes across IPv4, as seen in the chart below:

 

overall_device_density-1.png

 

Each square above shows the probability distribution (a fancier, prettier histogram) of device counts of a particular type. Most ASes host fewer than 100 devices across a majority of categories. Are there skews in the presence of specific devices to propagate phishing attacks from these malicious ASes?

 

Conclusion

Our research presents the following results:

 

  1. A small subset of ASes continue to host a disproportionate amount of malicious activity.

  2. Smaller subnets and ASes are becoming more ubiquitous in IPv4.

  3. Malicious ASes are deeply fragmented

  4. There is a concentrated use of specific infrastructure in malicious ASes

  5. Attackers both co-opt existing devices and stand up their own infrastructure within ASes (a gut-check would suggest this is obvious, but having data to back it up also makes it science).

 

Further work is required to characterize the exact cost structure of buying subnets, registering IP blocks, and setting up infrastructure in malicious ASes along with what network and system characteristics cause attackers to choose to co-opt one device in one autonomous system over another.

 

This research represents an example of how Internet-scale data science can provide valuable insight on the threat landscape. We hope similar macro level research is inspired by these explorations and will be bringing you more insights from Project Sonar & Heisenberg over the coming year.


  1. Sonar intro

  2. Heisenberg intro

  3. G. C. M. Moura, R. Sadre and A. Pras, _Internet Bad Neighborhoods: The spam case,“_ Network and Service Management (CNSM), 2011 7th International Conference on, Paris, 2011, pp. 1-8.

  4. B. Stone-Gross, C. Kruegel, K. Almeroth, A. Moser and E. Kirda, “FIRE: FInding Rogue nEtworks”; doi: 10.1109/ACSAC.2009.29

  5. C. A. Shue, A. J. Kalafut and M. Gupta, “Abnormally Malicious Autonomous Systems and Their Internet Connectivity,”; doi: 10.1109/TNET.2011.2157699

  6. A. J. Kalafut, C. A. Shue and M. Gupta, “Malicious Hubs: Detecting Abnormally Malicious Autonomous Systems,”; doi: 10.1109/INFCOM.2010.5462220

  7. Cleanmx archive

  8. ARIN Fee Schedule

Recently, a number of Rapid7's customers have been evaluating the risks posed by the swift rise of ransomware as an attack vector. Today, I'd like to address some of the more common concerns.

 

What is Ransomware?

Cryptowall and Cryptolocker are among of the best known ransomware criminal malware packages today. In most cases, users are afflicted by ransomware by clicking on a phishing link or visiting a website that is either compromised is is hosting a compromised advertising network. While ransomware is usually associated with Windows PCs and laptops, there have been recent reports of new ransomware on Apple OSX called KeRanger.

 

Ransomware works by encrypting files that the user has access to, which is usually their local documents. However, some ransomware variants can target and encrypt files on mapped SMB drives as well. Once encrypted, the user is alerted with instructions on how to obtain the recovery key, typically for the price of $300-$500 equivalent in Bitcoin. Some attacks, however, are enterprise-centric and demand much more; the Hollywood Presbyterian Medical Center reportedly paid over $17,000 to a criminal enterprise to recover its encrypted data.

 

How Can I Avoid Ransomware?

Ransomware attacks happen similarly to other malware-based attacks. User education is the first line of defense -- people should not be clicking suspicious links, or visit websites that are known carriers of malvertising networks. In the event the user encounters a live link to a ransomware download, web-based threat prevention, email-based threat prevention, and application sandboxing can all help avoid infection.

 

In addition, enterprises can harden their user-based infrastructure preemptively by following some baseline cyber hygiene as described in Jason Beatty's blog post. Of special interest is the enforcement of role-based access control; all too often, organizations accrue "access cruft," where users inherit permission sets that are far too broad for their normal job functions as temporary access grants accidentally become permanent access grants. By limiting user access across network resources, the damage incurred by the compromise of a single user can be effectively contained.

 

I've Been Hit! How Can I Recover?

In the event a user or enterprise falls victim to a ransomware attack, the best solution is to treat the event as any other disaster: restore the lost data from backups, conduct an investigation into how the disaster occurred, and educate the users involved on how to avoid this disaster in the future. As of today, there is no known method for recovering lost data without cooperating with the criminals responsible for the ransomware.

 

Of course, backing up valuable data before an attack is critical in order to recover from this kind of attack. Backup schedules can vary widely between people and enterprises, many backup plans are implemented but remain untested, and the appearance of ransomware seems to have dramatically increased the chances of a data loss disaster. IT administrators who are concerned about ransomware affecting their users should investigate the relevance and reliability of their existing backup solutions, and weigh the costs of a sudden loss of data against the cost of more robust and frequent backup plans.

 

That Didn't Work. Should I Pay?

In most areas of crime, paying blackmail or ransom demands is counterproductive. It funds criminal enterprise directly and encourages more blackmail and ransom activity for both the original victim and future victims.

 

However, even the United States FBI seems to be advising people that, given no other disaster recovery alternative, victims may want to consider paying for recovery. In October of 2015, Joseph Bonavolonta of the FBI admitted, "To be honest, we often advise people just to pay the ransom." This position was later clarified that victims should only consider paying when there is no other recourse, such as recovering from backups.

 

The criminal enterprises running ransomware campaigns today are remarkably organized, and can even be considered helpful when it comes to getting their victims in a position to pay the ransom, nearly always via Bitcoin transactions. There is significant "victim support" built into these campaigns that walk users through the process of acquiring Bitcoin and ensuring that recovery is actually possible once they are paid. That said, these organizations are criminal, after all, and operate across international borders. It would appear that they are making good on their offers to decrypt the data held hostage, but there is absolutely no guarantee that they will continue to do so.

 

Conclusions

While ransomware represents the latest trend in drive-by, opportunistic malware, it is avoidable and containable by following fundamental security and disaster recovery best practices. Encouraging secure habits in an enterprise's user base is the cornerstone of avoiding the problem in the first place. Enterprises struck by ransomware are urged to treat the event as they would any local disk disaster: restore from backups, conduct a post-mortem investigation into how the disaster happened, and take the lessons learned to become more resilient in the event of future disasters.

Building a reliable security team is tough; there is no defined approach nor silver bullet.  The people we are defending against are intelligent, dedicated, and have a distinct asymmetrical advantage, with nearly unlimited time to find the one thing we miss.  This past decade has taught us that what we have been doing is not working very well.

 

I've been lucky to have latitude for creativity when building the security team at Rapid7.  So when Joan Goodchild asked me to join her for CSO Online's first edition of "security sessions" it felt like the perfect time to start socializing how we've approached building our team.

 

Rapid7, like many high-growth technology companies, has introduced a significant set of SaaS offerings over the past few years. With the introduction of these offerings, we needed to build a platform we believed our customers could trust. Given the current status-quo, we didn't feel like blindly following failed 'best-practices' was the right path, so we decided to forge our own.

 

Head over to CSO to get a glimpse into how we tackle building our team and program.  During this CSO Security Session, I spend several minutes discussing with Joan who we hire, how we hire, my views on certifications, higher education, technology (and its stagnation), and how we measure the progress of our security organization.

 

I hope our discussion stimulates some meaningful conversations for you, and I encourage you to think about the five following items:

 

  1. Have you done the fundamentals? Two-factor authentication, network segmentation, and patch management are all far more tactically important than nearly anything else your program could do.
  2. Do you need that security engineer with 7-10 years of experience? What about a more junior engineer that can write code, automate, and solve problems (not just identify them)? 
  3. Do you measure success with practical indicators? Don’t try and fit into someone else’s mold of 'metrics.' Take a look at what areas of your program you want to focus on, and use something like CMMI to measure the maturity (opposed to effectiveness) of those operations.  You can take a look at something like BSIMM to see how this can be done effectively in some security verticals. 
  4. Is a college degree, or a security certification something that should disqualify a candidate?  If you let your HR system automatically weed out people that don’t have certifications or degrees, you are going to miss out on great resources.
  5. Do you understand what makes your company tick? If you can’t become part of the success of your business, you will always be viewed as a problem.

 

The landscape we deal with is constantly changing and we need to adapt with it.  While I don’t presume anything we’ve done is the silver bullet, the more we all push the envelope and approach our challenges creatively, the more likely we are to start shifting that asymmetrical balance into a more reasonable equilibrium.

 

I’d be interested to hear your thoughts on building out an effective security team. Share them in the comments or on Twitter -- I’m @TheCustos.

The U.S. Departments of Commerce and State will renegotiate an international agreement – called the Wassenaar Arrangement – that would place broad new export controls on cybersecurity-related software. An immediate question is how the Arrangement should be revised. Rapid7 drafted some initial revisions to the Arrangement language – described below and attached as a .pdf to this blog post. We welcome feedback on these suggestions, and we would be glad to see other proposals that are even more effective.

 

Background

 

When the U.S. Departments of Commerce and State agreed – with 40 other nations – to export controls related to "intrusion software" in 2013, their end goal was a noble one: to prevent malware and cyberweapons from falling into the hands of bad actors and repressive governments. As a result of the 2013 addition, the Wassenaar Arrangement requires restrictions on exports for "technology," "software," and "systems" that develop or operate "intrusion software." These items were added to the Wassenaar Arrangement's control list of "dual use" technologies – technologies that can be used maliciously or for legitimate purposes.

 

Yet the Arrangement's new cyber controls would impose burdensome new restrictions on much legitimate cybersecurity activity. Researchers and companies routinely develop proofs of concept to demonstrate a cybersecurity vulnerability, use software to refine and test exploits, and use penetration testing software – such as Rapid7's Metasploit Pro software – to root out flaws by mimicking attackers. The Wassenaar Arrangement could (depending how each country implements it) either require new licenses for each international export of such software, or prohibit international export altogether. This would create significant unintended negative consequences for cybersecurity since cybersecurity is a global enterprise that routinely requires cross-border collaboration. 

 

Rapid7 submitted detailed comments to the Dept. of Commerce describing this problem in July 2015, as did many other stakeholders. The Wassenaar Arrangement was also the subject of a Congressional hearing in January 2016. [For additional info, check out Rapid7's FAQ on the Wassenaar Arrangement – available here.]

 

Revising the Wassenaar Arrangement

 

To their credit, the Depts. of Commerce and State recognize the overbreadth of the Arrangement and are motivated to negotiate modifications to the core text. The agencies recently submitted agenda items for the next Wassenaar meeting – specifically, removal of the "technology" control, and then placeholders for other controls. A big question now is what should happen under those placeholders – a placeholder does not necessarily mean that the agencies will ultimately renegotiate those items.

                                                                  

To help address this problem, Rapid7 drafted initial suggestions on how to revise the Wassenaar Arrangement, incorporating feedback from numerous partners. Rapid7's proposal builds on the good work of Mara Tam of HackerOne and her colleagues, as well as that of Sergey Bratus, one of the most important contributions of which was to emphasize that authorization is a distinguishing feature of legitimate – as opposed to malicious – use of cybersecurity tools.

 

Our suggested revisions can be broken down into three categories:

 

1) Exceptions to the Wassenaar Arrangement controls on "systems," "software," and "technology." These are the items on which the Wassenaar Arrangement puts export restrictions. We suggest creating exceptions for software and systems designed to be installed by administrators or users for security enhancement purposes. These changes should help exclude many cybersecurity products from the Arrangement's controls, since such products are typically used only with authorization for the purpose of enhancing security – as compared with (for example) FinFisher, which is not designed for cybersecurity protection. It's worth noting that our language is not based solely on the intent of the exporter, since the proposed language requires the software to be designed for security purposes, which is a more objective and technical measure than intent alone. In addition, we agree with the Depts. of State and Commerce that the control on "technology" should be removed because it is especially overbroad.

 

Here is the Wassenaar Arrangement text with our suggested revisions in red and strikethrough:

4.A.5.   Systems, equipment, and components therefor, specially designed or modified for the generation, operation or delivery of, or communication with, "intrusion software".

Note:  4.A.5 does not apply to systems, equipment, or components specially designed to be installed or used with authorization by administrators, owners, or users for the purposes of asset protection, asset tracking, asset recovery, or ‘ICT security testing’.

 

4.D.4.  "Software" specially designed or modified for the generation, operation or deliver of, or communication with, "intrusion software".

Note:  4.D.4 does not apply to "software" specially designed to be installed or used with authorization by administrators, owners, or users for the purposes of asset protection, asset tracking, asset recovery, or ‘ICT security testing’. “Software” shall be deemed "specially designed" where it incorporates one or more features designed to confirm that the product is used for security enhancement purposes. Examples of such features include, but are not limited to:

a. A disabling mechanism that permits an administrator or software creator to prevent an account from receiving updates; or

b. The use of extensive logging within the product to ensure that significant actions taken by the user can be audited and verified at a later date, and a means to protect the integrity of the logs.

 

4.E.1.a. "Technology" [...] for the "development," "production" or "use" of equipment or "software" specified by 4.A. or 4.D.

 

4.E.1.c. "Technology" for the "development" of "intrusion software".

 

2) Redefining "intrusion software." Although the Wassenaar Arrangement does not directly control "intrusion software," the "intrusion software" definition underpins the Arrangement's controls on software, systems, and technology that operate or communicate with "intrusion software." Our goal here is to help narrow the definition of "intrusion software" to code that can be used for malicious purposes. To do this, we suggest redefining "intrusion software" as specially designed to be run or installed without authorization of the owner or administrator and extracting, modifying, or denying access to a system or data without authorization.

 

Here is the Wassenaar Arrangement text with our suggested revisions in red and strikethrough:

Cat 4 "Intrusion software"
1. "Software"

a. specially designed or modified to avoid detection by 'monitoring tools', or to defeat 'protective countermeasures', or to be run or installed without the authorization of the user, owner, or ‘administrator’ of a computer or network-capable device, and

b. performing any of the following:

a.1. The unauthorized extraction of or denial of access to data or information from a computer or network-capable device, or the modification of system or user data; or

b.2. The unauthorized modification of the standard execution path or a program or process in order to allow the execution of externally provided instructions system or user data to facilitate access to data stored on a computer or network-capable device by parties other than parties authorized by the owner, user, or ‘administrator’ of the computer or network-capable device.

 

3) Exceptions to the definition of "intrusion software." The above modification to the Arrangement's definition of "intrusion software" is not adequate on its own because exploits – which are routinely shared for cybersecurity purposes – are designed to be used without authorization. Therefore, we suggest creating two exceptions to the definition of "intrusion software." The first is to confirm that "intrusion software" does not include software designed to be installed or used with authorization for security enhancement. The second is to exclude software that is distributed for the purpose of preventing its unauthorized execution to particular end users. Those end users include 1) organizations conducting research, education, or security testing, 2) computer emergency response teams (CERT), 3) creators or owners of products vulnerable to unauthorized execution of the software, or 4) among an entities subsidiaries or affiliates. So, an example: A German researcher discovers a vulnerability in a consumer software product, and she shares a proof-of-concept with 2) CERT, and 3) a UK company that owns the flawed product; the UK company then shares the proof-of-concept with 4) its Ireland-based subsidiary, and 1) a cybersecurity testing firm. The beneficial and commonsense information sharing outlined in this scenario would not require export licenses under our proposed language.

 

Here is the Wassenaar Arrangement text with our suggested revisions in red and strikethrough:

 

Notes
1. "Intrusion software" does not include any of the following:

a. Hypervisors, debuggers or Software Reverse Engineering (SRE) tools;
b. Digital Rights Management (DRM) "software"; or
c. "Software" designed to be installed or used with authorization by manufacturers, administrators, owners, or users, for the purposes of asset protection, asset tracking, or asset recovery., or ‘ICT security testing’; or

d. “Software” that is distributed, for the purposes of helping detect or prevent its unauthorized execution, 1) To organizations conducting or facilitating research, education, or 'ICT security testing', 2) To Computer Emergency Response Teams, 3) To the creators or owners of products vulnerable to unauthorized execution of the software, or 4) Among and between an entity's domestic and foreign affiliates or subsidiaries.


Technical Notes

1.
Monitoring tools': "software" or hardware devices, that monitor system behaviours or processes running on a device. This includes antivirus (AV) products, end point security products, Personal Security Products (PSP), Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS) or firewalls.
2.
'Protective countermeasures': techniques designed to ensure the safe execution of code, such as Data Execution Prevention (DEP), Address Space Layout Randomisation (ASLR) or sandboxing.
3. ‘Authorization’ means the affirmative or implied consent of the owner, user, or administrator of the computer or network-capable device.

4. ‘Administrator’ means owner-authorized agent or user of a network, computer, or network-capable device

5. 'Information and Communications Technology (ICT) security testing’ means discovery and assessment of static or dynamic risk, vulnerability, error, or weakness affecting “software”, networks, computers, network-capable devices, and components or dependencies therefor, for the demonstrated purpose of mitigating factors detrimental to safe and secure operation, use, or deployment.

 

 

This is a complex issue on several fronts. For one, it is always difficult to clearly distinguish between software and code used for legitimately beneficial versus malicious purposes. For another, the Wassenaar Arrangement itself is a convoluted international legal document with its own language, style, and processes. Our suggestions are a work in progress, and we may ultimately throw our support behind other, more effective language. We don't presume these suggestions are foolproof, and constructive feedback is certainly welcome.

 

Time is relatively short, however, as meetings concerning the renegotiation of the Wassenaar Arrangement will begin again during the week of April 11th. It's also worth bearing in mind that even if many cybersecurity companies, researchers, and other stakeholders come to agreement on revisions, any final decisions will be made with the consensus of the 41 nations party to the Arrangement. Still, we hope suggesting this language helps inform the discussion. As written, the Arrangement could cause significant damage to legitimate cybersecurity activities, and it would be very unfortunate if that were not corrected.

Disclosure Summary

ManageEngine OpUtils is an enterprise switch port and IP address management system. Rapid7's Deral Heiland discovered a persistent cross-site scripting (XSS) vulnerability, as well as a number of insecure direct object references. The vendor and CERT have been notified of these issues. The version tested was OpUtils 8.0, which was the most recent version at the time of initial disclosure. As of today, the current version offered by ManageEngine is OpUtils 12.0.

 

R7-2016-02.1: Multiple Persistent XSS Vulnerabilities

While examining ManageEngine OpUtils v8.0, an enterprise switch port and IP address management software, it was discovered to be vulnerable to a persistent cross-site scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistent XSS containing JavaScript and HTML code into various fields within the products Application Program Interface (API) and the old style User Interface (UI) . When this data is viewed within the web console the code will execute within the context of the authenticated user. This can allow a malicious actor to conduct attacks which can be used to modify the systems configuration, compromise data, take control of the product or launch attacks against the authenticated user's hosts system.

 

The first series of persistent XSS attacks were delivered to the OpUtils product via the network discovery process. When a network device is configured with SNMP,  the SNMP OID object sysDescr 1.3.6.1.2.1.1.1 can contain HTML or JavaScript code.  The code will be delivered to the product for persistent display and execution without proper input sanitization. This is a similar vulnerability to those disclosed as Multiple Disclosures for Multiple Network Manage Systems.

 

The following example  shows the results of discovering a network device where the SNMP sysDescr has been set to <SCRIPT>alert(“XSS-sysDescr”)<SCRIPT> . In this example, when device is viewed within OpUtils API UI web console, the JavaScript executes rendering an alert box within the authenticated users; web browser.

 

fig1-oputils.png

Figure 1: JavaScript Alert Box

 

After switching version 8.0 from the API UI to the old UI schema several other XSS injection points where identified. This includes persistent XSS attacks, which was also delivered to the OpUtils old UI interface via the network discovery process. If the network device is configured with SNMP and the following SNMP OID objects contain HTML or JavaScript code, the code will be delivered to the product for persistent display and execution.

 

sysDescr        1.3.6.1.2.1.1.1

sysLocation   1.3.6.1.2.1.1.5.0

sysName        1.3.6.1.2.1.1.6.0

 

sysDescr and sysLocation triggered when viewed within IP History as shown in Figure 2 and Figure 3.

 

fig2-oputils.png

Figure 2: sysDescr injected XSS

 

fig3-oputils.png

Figure 3: sysLocation injected XSS

 

In addition, sysDescr,  sysLocation, and sysName triggered when viewed within device history as shown in Figure 4.

 

fig4-oputils.png

Figure 4: sysName injected XSS

 

The second method of injection involved SNMP trap messages. By spoofing an SNMP trap message and altering the data within that trap message, a malicious actor can inject HTML and JavaScript code into the product. When the trap information is viewed within the SNMP Trap Receiver the code will execute within the context of the authenticated user.  Figure 5 shows an example attack where a trap message was used with the following HTML code “<embed src=//ld1.us/4.swf>” to embed flash into the Trap Receiver section of the UI.

 

fig5-oputils.png

Figure 5: XSS Via SNMP Trap Injection

 

 

R7-2016-02.2: Multiple Insecure Direct Object References

During testing, it was discovered that URLs ending in .cc are accessible without proper authentication. This allowed for retrieval of a portion of the web page. The following URLs are able to be accessed without authentication:

 

http://IP-Address:7080/SystemExplorer.cc

http://IP-Address:7080/UserView.cc

http://IP-Address:7080/AuditView.cc

http://IP-Address::7080/AuditViewRogue.cc

http://IP-Address:7080/IPAMReport.cc

http://IP-Address:7080/ipAddressManager.cc

http://IP-Address:7080/ipAddressManagerInputPage.cc

 

As a result of this direct access without authentication, an attacker is able to view the HTML of the web page “SystemExplorer.cc.” Here, it was discovered that the product's configured SNMP community string is transmitted in clear text as shown in Figure 6.

 

fig-6-infoleak.png

Figure 6: Information leakage via Insecure Direct Object Reference

 

Disclosure Timeline

Thu, Jan 14, 2016: Issues discovered by Deral Heiland of Rapid7, Inc.

Fri, Jan 15, 2016: Initial contact to vendor

Mon, Feb 15, 2016: Details disclosed to CERT, tracked as VU#400736

Wed, Mar 9, 2016: Clarification requested by the vendor, via CERT

Thu, Mar 17, 2016: Public disclosure of R7-2016-02

This advisory was written by the discoverer of the NPort issue, Joakim Kennedy of Rapid7, Inc.

 

Securing legacy hardware is a difficult task, especially when the hardware is being connected in a way that was never initially intended. One way of making legacy hardware more connectable is to use serial servers. The serial server acts as a bridge and allows serial devices to communicate over TCP/IP. The device then appears on the network as a normal network-connected device. This allows for remote administration of, for example, medical devices, industrial automation applications, and point of sales (POS) systems as if they were connected directly to the computer with a serial cable.

 

Fig1: Moxa NPort used to connect a glucometer (source).

 

By connecting these devices to a network, the inherent security of the serial device is, in most scenarios, completely compromised. Many serial devices’ security hinges on physical access. If you have physical access to the devices, you are authorized to talk to the device. When these devices are connected to the internet via a serial server, the physical access model does not apply anymore, and the security is entirely dependent on the security offered by the serial server.  In most scenarios, these serial servers should NEVER be connected to a public network.

 

The Devices

In this blog post, we are reporting serial servers exposed on the internet which are manufactured by Moxa. The serial servers can be configured via multiple interfaces, the most common being a web interface or a terminal over SSH or TELNET. At the time this blog post was written, over 5000 web servers could be fingerprinted as Moxa devices.

 

These devices are designed to be as simple as possible to setup and consequently the server is very permissive in who is allowed to connect to the server. For example, Moxa’s NPort series enables a web interface and a TELNET which can be used to configure the server, neither of which are password protected by default. The consumer is not forced to set a password and many consumers are using the default, the non-password protected setup.

We have found over 2200 devices accessible over the internet in which 46% of them are not password protected. Most of the internet connected devices are located in Russia and Taiwan but many devices are also located in the USA and Europe.

 

Figure 2: Geographic location of the 2200 internet connected devices.

 

Figure 3: Geographic location of the unprotected devices connected to the internet.

 

Figure 4: Breakdown of the model types connected to the internet.

 

Figure 5: Breakdown of the model type for the unprotected devices connected to the internet.

 

The most common connected device models are from the NPort 5100 series. The NPort 5100 series are “are designed to make your industrial serial devices Internet ready instantly, and are well-suited for POS security market applications”.

 

The Vulnerabilities

We reported in 2013 about serial servers connected to the internet and security implications. The same issues that were reported then are also applicable for these devices. When connecting to one of these devices which is not password protected over TELNET, the following menu is presented:

 

-----------------------------------------------------------------------------

Model name       : xxxxxxx

MAC address      : xx:xx:xx:xx:xx:xx

Serial No        : xxxxxxxx

Firmware version : x.x.xx Build xxxxxxxx

System uptime    : 5 days, 12h:53m:49s

-----------------------------------------------------------------------------

<< Main Menu >>

  (1) Basic settings

  (2) Network settings

  (3) Serial settings

  (4) DIO setting

  (5) Operating settings

  (6) Accessible IP settings

  (7) Auto warning settings

  (8) Monitor

  (9) Ping

  (a) Change password

  (b) Advanced network settings

  (l) Load factory default

  (v) View settings

  (s) Save/Restart

  (q) Quit

 

Key in your selection:

 

The TELNET interface allows the same configuration options as the web interface. Both of these interfaces can be protected by setting a password.

 

The NPort device can operate in multiple modes. One is Real COM mode. In this mode, with COM/TTY drivers provided by the vendor, all serial signals are transmitted intact and the behaviour is identical to plugging the serial device into the COM port. In this mode, up to 4 different hosts can be connected. Connecting to a serial device connected to a NPort is very simple. One simply has to download the Real TTY drivers, install them, enter the IP address to connect to and the device shows up as being plugged in. No authentication is required.

 

The only way of restricting who can connect the device is by using the IP white listing option to restrict the IPs which can connect to the serial device or to use the TCP Client Mode. In the TCP Client Mode, the serial server initiates connections to predetermined hosts when serial data arrives.

 

The serial server does not offer any encryption, so all data is sent in the clear. This makes it possible to eavesdrop on the communication.

 

The lack of authentication on these devices, and the lack of encryption even when authentication is possible, was reported to CERT, and after some discussion, CVE-2016-1529 was assigned to identify this issue. More generally, CWE-306, Missing Authentication for Critical Function, appears to apply to Moxa NPort devices.

 

Remediation

As these serial servers are likely connected to something very sensitive, these devices should NEVER be directly connected to the internet. If remote access is required, and since these devices do not offer encrypted traffic, connect the serial servers to a local network which can only be accessible via, for example, a VPN. Also, restrict the IPs which can connect to the serial device, and don’t forget to password protect the admin consoles.

 

Conclusions

There is still little awareness on what can happen if you connect devices directly to the internet. With search engines like Shodan, it is very easy to find these devices, making it important to secure them. Securing legacy hardware is still very difficult, and this how not to do it. Security is being compromised for convenience, and consumers are, in many cases, just using the default settings. The easier you make it for yourself to connect, the easier you make it for the attacker.

Disclosure Timeline

Fri, Jan 15, 2016: Initial contact to the vendor

Mon, Jan 18, 2016: Response received from the vendor and details provided.

Mon, Feb 1, 2016: Details disclosed to CERT as VU#757136

Mon, Feb 1, 2016: CVE-2016-1529 assigned

Thu, Mar 17, 2016: Public disclosure (planned).

On Mar. 3rd, Rapid7, Bugcrowd, and HackerOne submitted joint comments to the Copyright Office urging them to provide additional protections for security researchers. The Copyright Office requested public input as part of a study on Section 1201 of the Digital Millennium Copyright Act (DMCA). Our comments to the Copyright Office focused on reforming Sec. 1201 to enable security research and protect researchers.

 

Our comments are available here.

 

Background

 

Sec. 1201 of the DMCA prohibits circumventing technological protection measures (TPMs) to access copyrighted works, including software, without permission of the owner. That hinders a lot of security research, tinkering, and independent repair. Violations of Sec. 1201 can carry potentially stiff criminal and civil penalties. To temper this broad legal restraint on unlocking copyrighted works, Congress built in two types of exemptions to Sec. 1201: permanent exemptions for specific activities, and temporary exemptions that the Copyright Office can grant every three years. These temporary exemptions automatically expire at the end of the three-year window, and advocates for them must reapply every time the exemption window opens.

 

Sec. 1201 includes a permanent exception to the prohibition on circumventing TPMs for security testing, but the exception is quite limited – in part because researchers are still required to get prior permission from the software owner, as we describe in more detail below. Because the permanent exemption is limited, many researchers, organizations, and companies (including Rapid7) urged the Copyright Office to use its power to grant a temporary three-year exemption for security testing that would not require researchers to get prior permission. The Copyright office did so in Oct. 2015, granting an exemption to Sec. 1201 for good faith security research that circumvents TPMs without permission. However, this exemption will expire at the end of the the three year exemption window,  after which security researchers will have to start from zero in re-applying for another temporary exemption.

 

The Copyright Office then announced a public study of Sec. 1201 in Dec. 2015. The Copyright Office undertook this public study, as the Office put it, to assess the operation of Sec. 1201, including the permanent exemptions and the 3-year rulemaking process. This study comes at a time that House Judiciary Committee Chairman Goodlatte is reviewing copyright law with an eye towards possible updates, so the Copyright Office's study may help inform that effort. Rapid7 supports the goal of protecting copyrighted works, but hopes to see legal reforms that reduce the overbreadth of copyright law so that it no longer unnecessarily restrains security research on software.

 

Overview of Comments

 

For its study, the Copyright Office asked a series of questions on Sec. 1201 and invited the public to submit answers. Below are some of the questions, and the responses we provided in our comments.

 

"Please provide any insights or observations regarding the role and effectiveness of the prohibition on circumvention of technological measures in section 1201(a)."

 

Our comments to the Copyright Office emphasized that Sec. 1201 adversely affects security research by forbidding researchers from unlocking TPMs to analyze software for vulnerabilities. We argued that good faith researchers do not seek to infringe copyright, but rather to evaluate and test software for flaws that could cause harm to individuals and businesses. The risk of harm resulting from exploitation of software vulnerabilities can be quite serious, as Rapid7 Senior Security Consultant Jay Radcliffe described in 2015 comments to the Copyright Office. Society would benefit – and copyright interests would not be weakened – by raising awareness and urging correction of such software vulnerabilities.

 

"How should section 1201 accommodate interests that are outside of core copyright concerns[?]"

 

Our comments responded that the Copyright Office should consider non-copyright interests only for scaling back restrictions under Sec. 1201 – for example, the Copyright Office should weigh the chilling effect Sec. 1201 has on security research in determining whether to grant an exemption for research to Sec. 1201. However, we argued that the Copyright Office should not consider non-copyright interests in denying an exemption, because copyright law is not the appropriate means of advancing non-copyright interests at the expense of activity that does not infringe copyright, like security research.

 

Should section 1201 be adjusted to provide for presumptive renewal of previously granted exemptions—for example, when there is no meaningful opposition to renewal—or otherwise be modified to streamline the process of continuing an existing exemption?

 

Our comments supported this commonsense concept. Currently, the three-year exemptions expire and must be re-applied for, which is a complex and resource-intensive process. We argued that a presumption of renewal should not hinge on a lack of "meaningful opposition," since the opposition to the 2015 security researcher exemption is unlikely to abate – though that opposition is largely based on concerns wholly distinct from copyright, like vehicular safety. Our comments also suggested that any presumption of renewal of exceptions to Sec. 1201 should be overcome only by a strong standard, such as a material change in circumstances.

 

Please assess whether the existing categories of permanent exemptions are necessary, relevant, and/or sufficient. How do the permanent exemptions affect the current state of reverse engineering, encryption research, and security testing?

 

Our comments said that Sec. 1201(j)'s permanent exemption for security testing was not adequate for several reasons. The security testing exemption requires the testing to be performed for the sole purpose of benefiting the owner or operator of the computer system – meaning research taken for the benefit of software users or the public at large may not qualify. The security testing exemption also requires researchers to obtain authorization of owners or operators of computers prior to circumventing software TPMs – so the owners and operators can dictate the circumstances of any research that takes place, which may chill truly independent research. Finally, the security testing exemption only applies if the research violates no other laws – yet research can implicate many laws with legal uncertainty in different jurisdictions. These and other problems with Sec. 1201's permanent exemptions should give impetus for improvements – such as removing the requirements1) that the researcher must obtain authorization before circumventing TPMs, 2) that the security testing must be performed solely for the benefit of the computer owner, and 3) that the research not violate any other laws.

 

 

We sincerely appreciate the Copyright Office conducting this public study of Sec. 1201 and providing the opportunity to submit comments. Rapid7 submitted comments with HackerOne and Bugcrowd to demonstrate unity on the importance of reforming Sec. 1201 to enable good faith security research. Although the public comment period for this study is now closed, potential next steps include a second set of comments in response to any of the 60+ organizations and individuals that provided input to the Copyright Office's study, as well as potential legislation or other Congressional action on Sec. 1201. For each next step, we will aim to work with our industry colleagues and other stakeholders to propose reforms that can protect both copyright and independent security research.

This is the third post in a three-part series on threat intelligence foundations, discussing the fundamentals of how threat intelligence can be used in security operations. Here's Part 1 and Part 2.

 

Intelligence Analysis in Security Operations

In the first two parts of this series we talked about frameworks for understanding and approaching intelligence: the levels of intelligence (strategic, operational, tactical) as well as the different types of intelligence (technical, current, long-term, etc). Regardless of the level or type of intelligence, the consistent theme was the need for analysis. Analysis is the core of intelligence, it takes data and turns it into intelligence that we can use to help us make informed decisions about complicated issues.

 

Analysis: The Missing Piece

I recently gave a talk at RSA where I compared the traditional intelligence cycle: Screen Shot 2016-03-11 at 12.10.47 PM.png

 

 

 

to what the intelligence cycle often looks like in cyber threat intelligence:     Screen Shot 2016-03-11 at 12.11.07 PM.png

 

We are good at collection and processing, and we are good at dissemination, however we tend to leave a lot of the critical parts of the cycle out which results in overwhelming alerts, excessive false positives, and really, really confused people.

 

It’s easy to joke about or complain about, but here is the thing...analysis is hard. Saying that we should do more/better/more timely analysis is easy. Actually doing it is not, especially in a new and still developing field like cyber threat intelligence. Models and methods help us understand the process, but even determining what model to use can be difficult. There are multiple approaches; some work better in certain situations and others work best in others.

 

What is Analysis?

The goal of intelligence analysis is to evaluate and interpret information in order to reduce uncertainty, provide warnings of threats, and help make informed decisions. Colin Powell gave perhaps the most succinct guidelines for intelligence analysis when he said: “Tell me what you know, tell me what you don’t know, tell me what you think. Always distinguish which is which”. This statement sums up intelligence analysis.

 

Analysts take what is known—usually information that has been collected either by the analyst themselves or by others—identify gaps in the knowledge that might dictate a new collection requirement or may present a bias that needs to be taken into consideration, and then determine what they think that information means.

 

Before you begin any analysis you should have an idea of what it is that you are trying to figure out. Ideally this would be driven by requirements from leadership, teams you support, or some other form of standing intelligence needs. There are many situations in CTI, however, where those requirements are not as well defined as we might hope. Understanding what it is that the organization needs from threat intelligence is critical. Therefore, step one should always be to understand what problems, concerns, or issues you are trying to address.

 

Analytic Models

Once you understand what questions you are trying to answer through your analysis, there are various analytic models that can be used to conduct analysis. I have listed some good resources available to help understand some of the more popular models that are often used in threat intelligence.

 

Different models are used for different purposes. The SWOT method is good for conducting higher-level analysis to understand how your own strengths and weaknesses compared to an adversary’s capabilities. F3EAD, the Diamond Model, and the Kill Chain and are useful for analyzing specific instructions or how different incidents or intrusions may be related. Target Centric Intelligence is a lesser known model, but can help with not only understanding individual incidents, but provides a collaborative approach to intelligence including the decision makers, collectors, and analysts in an iterative process aimed at avoiding the stove-piping and miscommunications that are often present in intelligence operations.

 

 

A final note on collection

In many cases, analysis can only be as good as the information that it is based off of. Intelligence analysts are trained to evaluate the source of information in order to better understand if there are biases or concerns about the reliability that need to be taken into account. In cyber threat intelligence we, by and large, rely on data collected by others and may not have much information on its source, reliability, or applicability. This is one of the reasons that analyzing information from your own network is so important, however it is also important that we, as a community, are as transparent as possible with the information we are providing to others to be used in their analysis. There are always concerns about revealing sources and methods, so we need to find a balance between protecting those methods and enabling good analysis.

This is the second post in a three-part series on threat intelligence foundations, discussing the fundamentals of how threat intelligence can be used in security operations. Read Part One here.

 

Tinker, Tailor, Soldier, Spy: Utilizing Multiple Types of Intelligence

Just as there are different operational levels of intelligence—discussed in detail in the first post of this series—there are also different types of intelligence that can be leveraged in an organization to help them better understand, prepare for, and respond to threats facing them.

 

Don’t laugh—but a great basic resource for understanding the types of intelligence is the CIA’s Kid Zone, where they break intelligence down for the 6-12th graders that we all are at heart (or K-5, no judgement here).

 

They break intelligence down into several different types:

  • Scientific and Technical – providing information on adversary technologies and capabilities.

  • Current – looking at day-to-day events and their implications.

  • Warning – giving notice of of urgent matters that may require immediate attention.

  • Estimative – looking at what might be or what might happen.

  • Research – providing an in-depth study of an issue.

 

While most organizations may not work with all of these types of intelligence, or do so in the same way that the CIA does (and please don't tell me if you do), it is useful to understand the spectrum and what each type provides. The different types of intelligence require varying levels of human analysis and time. Some, like technical intelligence, are easier to automate and therefore can be produced at a regular cadence, while some, like threat landscape research, will always rely heavily on human analysis.

 

Screen Shot 2016-03-09 at 6.48.23 PM.png

Technical Intelligence

In information security operations, technical intelligence is used to understand the capabilities and the technologies used by an adversary. It can include details such as IP addresses and domains used in command and control, names and hashes of malicious files, as well as some TTP details such as vulnerabilities that a particular actor targets or a particular callback pattern for a beaconing implant.

 

Technical intelligence is most often used in machine-to-machine operations, and is therefore automated as much as possible to handle the large volume of information. In many cases, technical intelligence does not contain much context, even if context is available in other places, because machines do not care as much about the context as their humans do. A firewall doesn’t need to know why to block traffic to a malicious domain, it just needs to do it. The human on the other end of that firewall change might want to know, however, in case the change ends up triggering a massive amount of alerts. Technical intelligence must have been analyzed prior to consumption, otherwise it is just data or information at best. For more information see Robert Lee’s post on the data vs information vs intelligence debate.

 

If you are not using technical intelligence that you generated yourself, it is critical that you understand the source of the technical intelligence and how it was analyzed, especially if it was analyzed using automated means. I am going out on a limb here by stating that there is a way to analyze and produce threat intelligence in an automated fashion that can be utilized machine-to-machine. Do NOT prove me wrong—do the analysis!

 

Current Intelligence

Current Intelligence deals with day-to-day events and situations that may require immediate action. I have heard several people say that, “news isn’t intelligence,” and that is a true statement; however, threat information in the public domain, when analyzed for implications to your specific organization, network, or operations, becomes intelligence.

 

An example of the use of current intelligence is a report that an exploit kit has integrated a vulnerability that was just announced three days ago. If you know that you are on a thirty-day patch cycle that means (best case) you have twenty-seven days where you will be vulnerable to these attacks. Understanding how this threat impacts your organization and how to detect and block malicious activity associated with it is an example of current intelligence. Current intelligence can also be generated from information within an organization’s networks. Analyzing an intrusion or a spearphishing attack against executives can also generate current intelligence that needs to be acted on quickly.

 

When you do generate current intelligence from your own network, document it! It can then contribute to threat trending and threat landscape research, which we will discuss shortly. It can also be shared with other organizations.

 

Threat Trending (Estimation)

All of the intelligence gathered at the tactical level (technical intelligence, current intelligence) can be further analyzed to generate threat trends. Threat trending takes time because of the nature of trending, you are analyzing patterns over time to see how things change and how they stay the same. Threat trending can be an analysis of a particular threat that has impacted your network repeatedly, or it can be an analysis of how an actor group or malware family has evolved over time. The more relevant a threat trend is to your network or organization, the more useful it will be to you.

 

Threat trending allows us to move from an analysis of something that we have seen and know is bad towards predicting or estimating future threats.

 

Threat Landscape Research

Speaking of trending, there has been a long trend in intelligence analysis of focusing on time-sensitive, current intelligence at the expense of longer term, strategic research. Consider how many tactical level, technical IOCs we have in the community compared to strategic intelligence resources. How many new programs are focused on providing “real-time intelligence” versus “deliberate, in-depth analysis.” There are legitimate reasons for that: there are not enough analysts as it is, and they are usually focused on the time-sensitive tasks because they are, well, time sensitive. In addition, we don’t always have the right data to conduct strategic level analysis, both because we are not accustomed to collecting it from our own networks and most people who are willing to share tactical indicators of threats are not as willing to share information on how those threats impacted them.

 

We need to change this, because you cannot (or should not) make decisions about the future of your security program without a strategy, and you cannot (or should not) have a security strategy without understanding the logic behind it. Threat landscape research—which is a long term analysis of the threats in your environment, what they target, how they operate, and how you are able to respond to those threats—will drive your strategy. The tactical level information you have been collecting and analyzing from your network on a daily basis can all contribute to threat landscape research. Current intelligence, yours and public domain information, can also contribute to threat landscape research. One framework for capturing and analyzing this information is VERIS—the Vocabulary for Event Recording and Incident Sharing, which the DBIR is based off of. Just remember, this type of intelligence analysis takes time and effort, but it will be worth it.

 

Information Sharing

There is currently an emphasis on sharing IOCs and other technical information, however any of the types of intelligence we have discussed in this post are good candidates for information sharing. Sharing information on best practices and processes is also incredibly beneficial.

 

Sharing information on what has been seen in an organization’s network is a good way to understand new threats as they emerge and increase situational awareness. Information sharing essentially generates intelligence to warn others of threats that may impact them. Information sharing is becoming increasingly automated, which is great for handling higher volumes of information, however, unless there is an additional layer of analysis that focuses on how this information is relevant or impacts your organization then it will stay information (not intelligence) and will not be as useful as it could be. For more information see Alex Pinto’s presentation on his recent research on measuring the effectiveness of threat intelligence sharing.

 

Even if you are not yet convinced of the value of generating your own intelligence from your environment, consuming threat intelligence still requires analysis to understand how it is relevant to you and what actions you should take. A solid understanding of the different types of intelligence and how they are used will help guide how you should approach that analysis.

This is the first post in a three-part series on threat intelligence foundations, discussing the fundamentals of how threat intelligence can be used in security operations.

 

There is a consensus among many in threat intelligence that the way the community has approached threat intelligence in the past -  i.e, the “Threat Data → SIEM → Magical Security Rainbows” approach has left something to be desired, and that something is usually analysis. Rick Holland (@rickhholland) warned us early on that we were on the wrong track with his 2012 post My Threat Intelligence Can Beat Up Your Threat Intelligence where he wrote “The real story on threat intelligence is your organization’s ability to develop your own."

 

There are ways that we can take advantage of the threat intelligence that currently exists while learning how to better leverage the threat intelligence in our own networks. Doing this requires an understanding of intelligence fundamentals and how they can be applied in security operations. This series is designed to help those interested in threat intelligence -whether just starting out or re-evaluating their existing programs - understand the underlying fundamentals of threat intelligence and intelligence analysis.

 

In the first part of this three-part series we will discuss the levels of intelligence and the various ways threat intelligence can be utilized in operations.

 

Threat Intelligence Levels in Security Operations: Crawl

When an organization is determining how to best integrate threat intelligence into their security operations it is helpful to have a framework detailing the different ways that intelligence can be effectively utilized.

 

Traditionally, intelligence levels have aligned to the levels of warfare: strategic, operational, and tactical. There are several reasons for this alignment: it can help identify the decision makers at each level; it identifies the purpose of that intelligence, whether it is to inform policy and planning or to help detect or deter an attack; it can help dictate what actions should be taken as a result of receiving that intelligence.

 

At any level of intelligence it is critical to assess the value to your organization specifically. Please answer this for yourself, your team, and your organization, “How does this information add perspective to our security program? What decisions will this information assist us in making?”

 

Strategic intelligence

Strategic intelligence is intelligence that informs the board and the business. It helps them understand broader trends that are facing their organizations and other similar organizations in order to assist in the development of a strategy. Strategic Intelligence comes from analyzing longer term trends, and often takes the shape of analytic reports such as the DBIR and Congressional Research Service (CRS) reports. Strategic intelligence assists key decision makers in determining what threats are most impactful to their businesses and future plans, and what long-term efforts they may need to take to mitigate them.

 

The key to implementing strategic intelligence in your own business is to apply this knowledge in the context of your own priorities, data, and attack surface. No commercial or annual trend report can tell you what is important to your organization or how certain threat trends may impact you specifically.

 

Strategic intelligence - like all types of intelligence - is a tool that can be used to shape future decisions, but it cannot make those decisions for you.

 

Operational Intelligence

Operational intelligence provides intelligence about specific attacks that may impact an organization. Operational intelligence is rooted in the concept of military operations - a series of plans or engagements that may take place at different times or locations, but have the same overarching goal. It could include identified campaigns targeting an entire sector, or it could be hacktivist or botnet operations targeting one specific organization through a series of attacks.

 

Information Sharing and Analysis Centers (ISACs) and Organizations (ISAOs) are good places to find operational intelligence.

 

Operational intelligence is geared towards higher-level security personnel, but unlike strategic intelligence it dictates actions that need to be taken in the near to mid-term rather than the long term. It can help inform decisions such as whether to increase security awareness training, how to staff a SOC during an identified adversary operation, or whether to temporarily deny requests for exceptions to the firewall policy. Operational intelligence is one of the best candidates for information sharing. If you see something that is going on that may impact others in the near term, *please* share that information. It can help other organizations determine if they need to take action as well.

 

Operational intelligence is only useful when those receiving the intelligence have the authority to make changes to policies or procedures in order to counter the threats.

 

Tactical Intelligence

Tactical Intelligence focuses on the the “what” (Indicators of Compromise) and the “how” (Tactics, Techniques, and Procedures) of an attacker’s actions with the intent of using that knowledge to prevent, detect, or respond to incidents. Do attackers tend to use a particular method to gain initial access, such as social engineering or vulnerability exploitation? Do they use a particular tool or set of tools to escalate privilege and move laterally? What indicators of compromise might allow you to detect these activities? For a good list of various source of tactical intelligence check out Herman Slatman's list of threat intelligence resources.

 

Tactical intelligence is geared towards security personnel who are actively monitoring their environment and gathering reports from employees who report anomalous activity or social engineering attempts. Tactical Intelligence can also be used in hunt operations, where we are looking to identify attacker behaviors that vary only slightly from a typical user’s behavior. This type of intelligence requires more advanced resources, such as extensive logging, user behavioral analytics, endpoint visibility, and trained analysts. It also requires a security-conscious workforce, as some indicators may not be captured or alerted on without first being reported by an employee. You will always have more employees than attack sensors…listen to them, train them, gather the information they can provide, analyze it, and then act upon it.

 

Tactical threat intelligence provides specific, but perishable, information that security personnel can act on.

 

Understanding how threat intelligence operates at different levels can help an organization understand where it needs to focus their efforts and what it can do with the threat intelligence it has access to. It can also help guide how the organization should approach intelligence in the future. The intelligence you can generate from your own network will always be the most actionable intelligence, regardless of the level.

 

For more information on the levels of intelligence and the levels of warfare, check out these resources:

Deral Heiland

What's In A Hostname?

Posted by Deral Heiland Employee Mar 9, 2016

Like the proverbial cat, curiosity can often get me in trouble, but often enough, curiosity helps us create better security. It seems like every time I encounter a product with a web management console, I end up feeding it data that it wasn't expecting.

 

As an example, while configuring a wireless bridge that had a discovery function that would identify and list all Wi-Fi devices in the radio range, I thought: "I wonder what would happen if I broadcast a service set identifier (SSID) containing format string specifiers?"

 

I set up a soft AP on my Linux host using airobase-ng and configured the SSID to broadcast %x%x%x. I was shocked when the discovered AP's SSID displayed data from the wireless bridge's process stack as shown in Figure 1:

 

fsv.png

Figure 1: Format String Injected Via SSID

 

This data confirmed that this wireless bridge appliance was vulnerable to a format string exploit. This lead to the discovery of multiple devices vulnerable to injection attacks within the web management consoles via SSID, including format strings, persistent cross-site scripting (XSS) and cross-site request forgery (CSRF) (more details of these are discussed in a whitepaper I released at Blackhat).

 

Unfortunately, attacks against web management interfaces don’t stop with SSIDs. So many products inevitably consume data from various resources and then display that data within the web management console without conducting any validation checks of that data first. This often leads to vulnerabilities being exploited via the web management interfaces, and it appears to not be going away any time soon. Recently Matthew Kienow and myself released a number of advisories where XSS attacks were injected into web management consoles of Network Management Systems (NMS) using SNMP.

 

Again—several months back—while on a pen testing engagement, a coworker was running an open source tool used to launch relay style attacks. This tool captured hostname information from the network and stored it as part of its function and of course it had a web interface. Sadly his testing was interfering with my testing, so for fun I changed my Linux systems hostname to “><script>alert(“YOU-HAVE-BEEN-HACKED”)</script> .

 

Initially I wasn't sure if this XSS attack would work, but soon enough I heard a loud scream come from his corner of the room. Now this brings me around to the purpose of this blog: What would the impact be if everyone changed the name of their host system to contain XSS data—such as “><iframe>?  I am scared to even imagine the number of products that use the hostname data and display it within their web management interface. Based on all my testing against various application and embedded devices that use web interfaces for management, I have found roughly 40% of the systems I have tested to be vulnerable to some form of XSS injection attacks.

 

So, I wonder how many administration web consoles have this sort of problem with hostname parsing?

 

Want to Help Us Find Out?

Now if this idea intrigues you, don’t rush out and start renaming your systems, as even a simple XSS such as “><iframe>—which should create a simple box on the screen (Figure 2)—can have serious impact on the web interface functionality of some products and could easily prevent it from functioning normally.

 

However, if you want to try this out, first make sure you have permission and that you do it within a controlled environment—not within your production environment. If you end up giving this a try, I ask that you share the results with us at  security@rapid7.com (PGP KeyID: 0x8AD4DB8D) so we can follow-up with the results in a future blog.

 

Also, I highly recommend that you contact the product vendor for ethical disclosure so they can fix the issues.

 

box.png

Figure 2: <iframe> box

 

 

I am looking forward to hearing back on what you find.

Filter Blog

By date: By tag: