CryptoPHP a week later: more than 23.000 sites affected

Fox-IT International blog

On November 20th we published our report on CryptoPHP. Since publishing we have, together with other parties, been busy dealing with the affected servers and taking down the CryptoPHP infrastructure.

Sinkhole statistics

With the help of the NCSC,, Shadowserver and Spamhaus we have been able to gather data about the scale of the operation ran by the CryptoPHP authors. Most C2 domains that were active at the time of publishing have been either sinkholed or taken down. From the sinkholed domains we’ve been able to gather statistics.

In total 23.693 unique IP addresses connected to the sinkholes. We are already seeing a decline in sinkhole connections, on the 22nd 20.305 connections were made, on the 23rd 18.994 and on the 24th it was already down to 16.786. These numbers are however not a clear indication, mostly because the servers connecting to our sinkholes were shared hosting with…

View original post 431 more words

Now e-cigarettes can give you malware

Better for your lungs, worse for your hard drives, e-cigarettes can potentially infect a computer if plugged in to charge

 An e-cigarette charges from the wall.
E-cigarette can either be charged from the wall or by plugging the cigarette itself into a USB port. Photograph: Ian West/PA

Many e-cigarettes can be charged over USB, either with a special cable, or by plugging the cigarette itself directly into a USB port. That might be a USB port plugged into a wall socket or the port on a computer – but, if so, that means that a cheap e-cigarette from an untrustworthy supplier gains physical access to a device.

A report on social news site Reddit suggests that at least one “vaper” has suffered the downside of trusting their cigarette manufacturer. “One particular executive had a malware infection on his computer from which the source could not be determined,” the user writes. “After all traditional means of infection were covered, IT started looking into other possibilities.

“The made in China e-cigarette had malware hardcoded into the charger, and when plugged into a computer’s USB port the malware phoned home and infected the system.”

Rik Ferguson, a security consultant for Trend Micro, says the story is entirely plausible. “Production line malware has been around for a few years, infecting photo frames, MP3 players and more,” he says. In 2008, for instance, a photo frame produced by Samsung shipped with malware on the product’s install disc.

Even more concerning is a recent proof-of-concept attack called “BadUSB”, which involves reprogramming USB devices at the hardware level. “Very widely spread USB controller chips, including those in thumb drives, have no protection from such reprogramming,” says Berlin-based firm SRLabs, which released the code.

Combine the two, says Ferguson, “and a very strong case can be made for enterprises disabling USB ports, or at least using device management to allow only authorised devices.

“For consumers it’s a case of running up-to-date anti-malware for the production line stuff and only using trusted devices to counter the threat.”

Dave Goss, of London’s Vape Emporium, says that vapers can remain safe by buying from respected manufacturers such as Aspire, KangerTech and Innokin, and by checking for “scratch checkers” on the box, which mark out authentic goods from counterfeits.

“Any electrical device that uses a USB charger could be targeted in this way, and just about every one of these electrical devices will come from China,” he adds.

In early November, figures obtained by the Press Association revealed that e-cigarettes and related equipment, such as chargers, were involved in more than 100 fires in less than two years.

Original post on Reddit


What you can do to protect yourself?

SyncStop (previously USB Condom)


Stealthy Regin malware discovered by Security Researchers

An advanced spying tool, Regin displays a degree of technical competence rarely seen and has been used in spying operations against governments, infrastructure operators, businesses, researchers, and private individuals.

It is likely that its development took months, if not years, to complete and its authors have gone to great lengths to cover its tracks. Its capabilities and the level of resources behind Regin indicate that it is one of the main cyberespionage tools used by a nation state.


Microsoft identified Trojan:WinNT/Regin.A in 2011.


Someone submitted one of the malware sample to VirusTotal early in 2008.

Backdoor.Regin is a multi-staged threat and each stage is hidden and encrypted, with the exception of the first stage.  Executing the first stage starts a domino chain of decryption and loading of each subsequent stage for a total of five stages.  Each individual stage provides little information on the complete package. Only by acquiring all five stages is it possible to analyze and understand the threat.

Figure 1. Regin’s five stages

Regin also uses a modular approach, allowing it to load custom features tailored to the target. This modular approach has been seen in other sophisticated malware families such as Flamer and Weevil (The Mask), while the multi-stage loading architecture is similar to that seen in the Duqu/Stuxnet family of threats.

Timeline and target profile
Regin infections have been observed in a variety of organizations between 2008 and 2011, after which  it was abruptly withdrawn. A new version of the malware resurfaced from 2013 onwards. Targets include private companies, government entities and research institutes. Almost half of all infections  targeted private individuals and small businesses. Attacks on telecoms companies appear to be designed to gain access to calls being routed through their infrastructure.

Figure 2. Confirmed Regin infections by sector

Infections are also geographically diverse, having been identified in mainly in ten different countries.


Figure 3. Confirmed Regin Infections by country

Infection vector and payloads
The infection vector varies among targets and no reproducible vector had been found at the time of writing. Symantec believes that some targets may be tricked into visiting spoofed versions of well-known websites and the threat may be installed through a Web browser or by exploiting an application. On one computer, log files showed that Regin originated from Yahoo! Instant Messenger through an unconfirmed exploit.

Regin uses a modular approach, giving flexibility to the threat operators as they can load custom features tailored to individual targets when required. Some custom payloads are very advanced and exhibit a high degree of expertise in specialist sectors, further evidence of the level of resources available to Regin’s authors.

There are dozens of Regin payloads. The threat’s standard capabilities include several Remote Access Trojan (RAT) features, such as capturing screenshots, taking control of the mouse’s point-and-click functions, stealing passwords, monitoring network traffic, and recovering deleted files.

More specific and advanced payload modules were also discovered, such as a Microsoft IIS web server traffic monitor and a traffic sniffer of the administration of mobile telephone base station controllers.

Regin’s developers put considerable effort into making it highly inconspicuous. Its low key nature means it can potentially be used in espionage campaigns lasting several years. Even when its presence is detected, it is very difficult to ascertain what it is doing. Symantec was only able to analyze the payloads after it decrypted sample files.

It has several “stealth” features. These include anti-forensics capabilities, a custom-built encrypted virtual file system (EVFS), and alternative encryption in the form of a variant of RC5, which isn’t commonly used. Regin uses multiple sophisticated means to covertly communicate with the attacker including via ICMP/ping, embedding commands in HTTP cookies, and custom TCP and UDP protocols.

Regin is a highly-complex threat which has been used in systematic data collection or intelligence gathering campaigns. The development and operation of this malware would have required a significant investment of time and resources, indicating that a nation state is responsible. Its design makes it highly suited for persistent, long term surveillance operations against targets.

The discovery of Regin highlights how significant investments continue to be made into the development of tools for use in intelligence gathering.

Further reading
Symantec – Regin: Top-tier espionage tool enables stealthy surveillance

Kaspersky – Regin: Nation-state ownage of GSM networks


Penetration Testing Methodology for Web Applications

Establishing a penetration testing methodology is becoming increasingly important when considering data security in web applications. The more we come to rely on networked communication and cloud-based data systems, the more we leave ourselves vulnerable to potentially damaging cyber attacks by outside parties.

While designing and safeguarding secured systems has become standard, how can you be certain these systems work? The answer lies in building a comprehensive penetration testing methodology to protect your information assets.

What is Penetration Testing?

Think of a penetration testing methodology—or “pentesting” for short—as a controlled cyber attack during which your best defenses are put to the test and exploited to determine the extent of vulnerabilities in your web applications.

Essentially, designing and implementing a penetration testing methodology allows you to:

  • Hack your own system in a proactive, authorized environment, focusing on elements such as IT infrastructure, OS vulnerabilities, application issues and user and configuration errors;
  • Analyze and validate both system defenses and user adherence to system protocols; and
  • Assess potential attack vectors such as web applications, wireless networks and devices and servers.

Unfortunately, no data is safe 100 percent of the time. But an effective penetration testing methodology can do wonders for eliminating unnecessary vulnerabilities.

What Are the Benefits of a Penetration Testing Methodology?

The stakes are high for data security. With an effective penetration testing methodology, you can:

  • Identify vulnerabilities that scanning software cannot;
  • Not only test those vulnerabilities, but also determine how prepared network defenders are to both detect and respond to attacks in a timely manner;
  • Determine the potential magnitude of a successful attack; and
  • Ensure all compliance protocols for data security are being met (a consideration especially important in thepayments industry).

Another benefit of taking your penetration testing methodology seriously is its potential affect on internal culture. When organizational leadership demonstrates a clear commitment to data security, it reinforces its importance to employees, who will then be encouraged to follow user-end protocols to the best of their abilities.

How Often Should a Penetration Testing Methodology Be Performed?

An effective penetration testing methodology is executed regularly. As the general wisdom goes, it’s better to be proactive and strengthen your web applications’ defenses now than to wait until you’ve already suffered an attack, losing valuable data in the process.

In planning your penetration testing methodology, consider your industry. Not everyone is going to have the same security needs, but it’s your company’s responsibility to make sure confidential information stays confidential.

Your organization should deploy its penetration testing methodology regularly, but especially when any of the following occurs:

  • Regulations specific to your industry mandate it. For the payments industry, for example, this can be a quarterly requirement. In other sectors, pentests might only be an annual requirement.
  • Any alterations to network infrastructure or web applications (internal or external). This could entail upgrades, modifications, security patches, new additions or total overhauls.
  • Policies change. This is especially common on the end user side of the equation. Policy changes affect the nature of the user’s interaction with the web application, which could create new challenges.
  • Your organization moves or adds a new location. This includes remote employees, who will be accessing web applications through their ISP rather than your organization’s secure network.

Finally, when designing your penetration testing methodology, err on the side of caution. If you think you may need a pentest, you probably do. Pentesting may not be free, but the cost is preferable to a data breach.

Building and Effective Penetration Testing Methodology

In the previous decade, although support was building for establishing a more widely practiced penetration testing methodology, no standard materialized until 2010 with the introduction of the Penetration Testing Execution Standard(PTES).

In the current version of the standard, PTES is divided into seven main sections:

  • Pre-engagement Interactions
  • Intelligence Gathering
  • Threat Modeling
  • Vulnerability Analysis
  • Exploitation
  • Post Exploitation
  • Reporting

These elements can be considered the fundamental elements of any penetration testing methodology. We will explore each of these points in the following sections.

Pre-Engagement Interactions

When building your penetration testing methodology, remember that pentesting requires a lot of trust. You will want to find a provider that is both experienced and familiar with the particular needs of your business.

Remember, you’re essentially asking your provider to hack your system, so some ground rules should be established first:

  1. What is the Scope? Do you want a particular area of your business targeted, or your business in general? What (and who) is off limits?
  2. What Is the Schedule? You still have a business to run, so it’s important to establish during which hours the pentest is to be performed. The overall timeline of the pentest should be established as an essential element of your penetration testing methodology.
  3. Blackbox or Whitebox? In a whitebox test, the pentester is given baseline access or information to begin and is then charged with exploiting any weaknesses from that position. In a blackbox test, the pentester begins with nothing, just like an outside attacker.
  4. Who Are the Contacts? It’s important that communication channels be established between all involved parties, as lapses in communication could have a variety of unintended consequences.

As the foundation of your penetration testing methodology, pre-engagement interactions should be considered very carefully.

Intelligence Gathering

In this phase of your penetration testing methodology, your provider begins the preliminary steps of planning their attack. In a properly planned pentest, the provider will have a clear idea of what is off limits and what is fair game.

Understand that your provider is not doing their job if they’re not turning over every leaf looking for information about your business, its employees, its assets and its liabilities. As such, the time spent on this step of the penetration testing methodology can be quite extensive.

Again, remember that establishing ground rules is important in your penetration testing methodology. Providers (and the actual hackers) are accustomed to discovering information however they can—even if that means searching through the company garbage.

Threat Modeling

Once relevant documentation has been gathered, the next step of the penetration testing methodology is to use that information to build a complete profile of your company and its assets. Once this is established, target primary and secondary assets will be determined and further scrutinized.

Assets could entail a variety of different elements, including organizational data (e.g., policies, procedures, trade secrets), employee and customer data and “human assets”—high-level employees that could be exploited in a manner of ways. In a good penetration testing methodology, the provider won’t be biased in what assets they’re seeking out unless they are instructed to. Otherwise, they will work to identify those with the highest value.

Vulnerability Analysis

With the target assets established, the provider will then work to determine the best entry point to exploit those assets. A good penetration testing methodology will provide strict guidelines on project scope to ensure the client’s desired outcome is met.

Sometimes this analysis can be a no-limits effort to uncover all potential vulnerabilities. In other cases, the provider will be asked to target a specific set of potential trouble spots. In a thorough penetration testing methodology, the extent of the vulnerability is then assessed, including the level of weakness and the sensitivity of the information it might expose.

Exploitation & Post-Exploitation

The next step in the penetration testing methodology is the attack itself. Just as in a real-world data breach, a properly executed exploitation can happen very quickly.

Once the provider has gained access to your systems, they will not only continue working to avoid detection, but also attempt a strategy known as “privilege escalation” to gain greater access to the system, as well as additional potential assets.

As the penetration testing methodology progresses to post-exploitation after the target has been achieved, the provider will assess the value of the compromised machine or entry point and determine whether it could be further exploited for later use.


Clearly, a thorough penetration testing methodology involves a great deal of work in data collection, analysis and exploitation. But how will the provider report on this information so that your organization can turn it into actionable solutions? Here are some considerations:

  1. Get Specifics: High-level recommendations may provide a basic context for the problems with your web applications, but they aren’t always very helpful to the people charged with implementation.
  2. Walk-Throughs: Nothing beats learning through experience. Providers should be prepared to show relevant employees and specialists exactly what they did—and also how difficult it was to accomplish.
  3. Risk Level: Naturally, the more challenging an attack is to pull off, the harder it will be for others to do so. Providers should include a detailed report on the risk level of the vulnerabilities they encountered, as well as an assessment of the potential business impact if they are exploited.

Finally, don’t be afraid to ask questions of your provider. A good penetration testing methodology, after all, is all about being as informed as possible.

Malware Threat Assessment Template for Financial Institutions

Financial institutions conducting online brokerage, alternative payments, Internet banking and other similar activities have been facing a growing number of malware-based attacks. According to Wontok SafeCentral, modern malware ranging from botnets to keyloggers to ransomware to spyware is capable of emptying bank accounts in seconds.

The institutions responsible for monetary transactions can ill afford to earn a reputation as anything other than protectors of customer privacy. However, malware attacks continue to evolve in sophistication as cyber criminals continuously develop new methods to circumvent basic security implementations.

The following are the top malware threats to financial institutions:

Keyloggers: Record everything you type on a computer in order to steal your passwords, log-in credentials, and other sensitive information, and transfer it to the source of the program. This malware has been used to target the networksof financial institutions and perform unauthorized wire transfers.

Trojan: This is the most dangerous form of malware, written with the aim of discovering your financial information, and infiltrating your system resources. A banking Trojan was used earlier in the year to target customers of major banks around the globe.

Botnet: Bots enable attackers to take control over affected PCs. And they are a part of a network of infected PCs (botnet), which are made up of victim machines stretched across the globe. The most popular type is the Zeus Gameover botnet: it is estimated to have infected 1 million users and stolen information which might be useful at retrieving bank accounts.

Ransomware: This malware restricts access to a network/PC/account and locks you out until you pay a sum of money or give access to certain data. Cryptolocker is an example of ransomware that targets employees and customers of financial institutions through phishing attacks.

Backdoor: It opens a ‘backdoor’ onto a machine, providing a network connection for cyber criminals to enter or for spam to be sent. Hackers have used the backdoor malware to steal millions from ATM machines lacking adequate security implementations.

Threat assessment

The problem occurs when financial institutions conflate all malware as one threat for the purpose of threat assessment. That is a mistake as individual malware types should be assessed as a separate entity. Also, there are some questions that need to be addressed during the course of assessment, such as:

  • What is the potential harm to customers, partners and other parties if your network/system is infected with a particular malware?
  • How can you detect the infiltration?
  • If you are unable to address the infection, is there someone else to do the job?
  • If you are unable to detect the malware attack, when/how will you become aware of its consequences?
  • Is there a stage of the breach where you might detect the attack before it causes damage?

Answering these questions requires an individual application profile for each malware threat and how that malware could be addressed. Here is a sample risk assessment profile for Cryptolocker.

Threat name: Cryptolocker

General description: Cryptolocker prevents victims from accessing their systems and then uses social engineering to convince them that failing to follow instructions will lead to consequences such as facing a prosecution or owning a fine. It also aggressively encrypts files on a victim’s PC and returns access to them only after a ransom is paid

Malware type: Ransomware

Data attack classification: Customer-related, sensitive and confidential

Inherent risk: High

Entry points: Malicious emails, malicious websites, third-party software

Affected victims: Customer, employee, manager, administrator, vendor

Revenue generated: Around $3 million

Business impact: Financial loss due to unauthorized money transfer, reputation loss due to breach of customer data, lawsuits and regulations because of account & transaction compromise and non-compliance

Customer impact: Theft of personal information, theft of important credentials, loss of money from personal and business accounts

Mitigation: Reevaluate permissions on network drives, implement software restriction policies (SRPs) to prevent execution, implement Group Policy Objectives (GPOs) to create permissions on registry keys

External identification & mitigation sources: APWG, Trusteer, Massive’s attack intelligence, CERT, etc.

Next, it is important to define the potential role of vendors in minimizing malware threat to the financial institution ecosystem. Here is an outline of the potential stakeholders, their activity and control type:

Name: Certificate authorities (CA)

Activity: Certificate authorities are responsible for securing online banking applications when customers enter credentials to login to banking sites. However, CA administration functions have been vulnerable to the issuance of valid EV-SSL and SSL certifications to adversaries. The service offerings need to evolve to prevent malicious threats.

Control type: Prevent

Name: Anti-malware solution providers

Activity: Improve detection capabilities and make efforts to create advanced detection metrics. They should also improve fail in safe mode, and provide solutions with better default security settings. Solution providers should also do a better job at:

  • Managing online security threats
  • Reducing the cost of fraudulent transactions
  • Protecting customer data from insecure transactions

Control type: Prevent and recover

Name: Application providers or application stores

Activity: Provide software for digital devices used to access banking accounts, including tablets, laptops and smartphones. They should enhance due diligence to ensure their software doesn’t include malicious code.

Control type: Prevent

With the risk assessment profile and potential role of vendors in place, you can develop a fairly good picture of the behavior of a particular malware, and then work with internal and external IT security departments to define the best course of mitigation.

Financial institutions should also gather threat data by:

  • Examining the malicious files on a system/network/device
  • Examining the volatile data
  • Examining the programs executed on the infected system/network/device
  • Examining the host-based logs
  • Examining suspected files and specific artifacts
  • Performing a malware search and a timeline analysis

Researching/documenting the threat further requires creating your own virtual machines and manually infecting systems to familiarize yourself with the threats associated with malware execution. This would require malware samples so that you can review the technical information to see the modifications made by the malware.

The aim is to search for a malware and assess how it can infect a system, rather than reversing the malware to see its functionality. The virtual machine can be used to execute malicious files, software as well as websites that serve malware. The final step of the approach is to analyze and monitor the URLs and program execution artifacts.

Changing exposures of malware

Most of the new malware exposures to financial institutions are a consequence of an extremely complex and evolving threat environment.

The sale of underground toolkits at a low-cost has also enhanced the nature and number of malware-based attacks; with financial institutions conducting monetary transactions on the highest scale, the industry continues to be a lucrative target for cyber gangs.

Third party vendors and partner businesses are potential contributors to increased exposure and should be included in the template for malware threat assessment. For the occasions where conventional threat assessment fails to recognize malware, following a security template and updating it frequently can help institutions look for signals the malware may be executing.

For instance, is the malware doing something strange that standard programs rarely do? This can be combined with conventional analysis about the execution. A document that looked less risky initially might behave in ways that contribute to threat and signal the concerned institution to block it immediately.

Even though massive amounts of data are required to stay one step ahead of malware-breach practices, following a threat assessment template can help in securing vulnerable endpoints. This will also reduce the non-compliance to legal regulations set by the Security Exchange Commission (SEC), the Foreign Corrupt Practices Act (FCPA) and other similar governing bodies.


Malware threat assessment is a higher priority for most companies today than it was a few years ago. However, not many industries are seeing the impact of the observation more profoundly than the financial sector. As became evident from some of the outcomes of new malware breaches, failure to assess the risk from an enterprise-wide perspective can result in negative consequences for the industry and the economy as a whole.

The end user will remain the most common weakness during a malware attack. Institutions, as a result, need to be open about risks and continue to access the security issues they encounter, as well as frequently update the threat assessment template they’re following. As more users turn to Internet banking to replace conventional, over-the-phone, and in-branch-banking, banks must ensure they are assessing threats on a regular basis and implementing adequate protections to ensure safety of users. Focusing on risk assessment is not only a way to avoid breaches from happening, but also can be a source to gain a competitive edge.

How to Test the Security of IoT Smart Devices

Just when we thought we had our applications secured, they pull us back in.

No, this isn’t a case of directory traversal bugs reappearing in IIS, access bugs resurfacing in Tomcat, or trained web developers deciding to abandon sound security principles. Instead, it is a result of up to 300,000 toasters, cameras, cars and other “smart devices” being added to the Internet every hour.

Before you think this is a minor problem, consider this recent quote: “As part of a large-scale hack over a number of weeks, [Proofpoint found that] more than 750,000 malicious emails were sent from more than 100,000 everyday devices, including – astonishingly – a refrigerator.” (CapGemini, October 2014)

WASP Internet of Things (IoT) Top 10 List

Fortunately, our security peers at the Open Web Application Security Project (OWASP) have noticed the problem too. Since their “OWASP Top Ten” list has become the most popular collection of potential risks to web applications, they decided to compose a similar list for the “Internet of Things” (IoT).

Released in June 2014, the OWASP IoT Top 10 list covers concepts familiar to application security experts, concepts familiar to network security experts and a few new items as well. The complete list for 2014 is provided below.

  • I1 – Insecure Web Interface
  • I2 – Insufficient Authentication/Authorization
  • I3 – Insecure Network Services
  • I4 – Lack of Transport Encryption
  • I5 – Privacy Concerns
  • I6 – Insecure Cloud Interface
  • I7 – Insecure Mobile Interface
  • I8 – Insufficient Security Configurability
  • I9 – Insecure Software/Firmware
  • I10 – Poor Physical Security

Staying with the idea that some items on this list will be new to you, whatever your security background, the rest of this article digs into every item on the OWASP IoT Top 10 list and offers practical guidance that you can use to evaluate the security of any IoT device.

Testing an IoT Device for Insecure Web Interface (OWASP I1)

The fact that your TV, toaster or baby monitor includes a web server is often a surprise. The fact that the web application it hosts was written by someone who missed the last ten years of application security developments is often an unpleasant one.

The most famous example of this to date is the case of the web application on TrendNet cameras that exposed a full video feed to anyone who accessed it. In this case, there was enough of a “sign on” interface to make end users believe that only authorized people could access the feeds remotely. However, a hacker group called Console Cowboys quickly demonstrated that the authentication mechanism was just for show. In the end, the United Stated Federal Communications Commissions (FCC) stepped in and required TrendNet to redesign their products and submit to an independent security assessment for 20 years.

On IoT devices, OWASP recommends looking specifically for default credentials that should be changed during initial setup, ensuring complex passwords are enforced, checking for cross-site scripting (XSS), SQL injection (SQLi) and cross-site request forgery (CSRF) vulnerabilities.

Fortunately, testing for these kinds of vulnerabilities on IoT devices will be second nature to many of you in the application security community. Tools such as OWASP’s own Zed Attack Proxy (ZAP) and a number of commercial penetration testing packages (also called “dynamic application security testing” or “DAST”) can also be used to look for these types of vulnerabilities.

Some unique challenges presented by IoT device web applications are that the apps are often on unusual ports (e.g., not 80 for HTTP or 443 for HTTPS), that the apps are sometimes disabled by default, and that different apps (e.g., for device administrators and users, or two different applications) may listen on different ports. To mitigate these challenges, you should plan on using a standard port scanner or (shudder) reading the manual to discover what web services a particular device offers.

Testing an IoT Device for Poor Authentication/Authorization (OWASP I2)

When security professionals like us, who are used to working in corporate environments, think of “weak authentication,” we might think of passwords that aren’t changed regularly, or 6-to-8 character passwords that are nonetheless easy to guess. Unfortunately, the bar is much lower with many smart devices.

Many IoT devices are secured with “Spaceballs quality” passwords like “1234″, put their password checks in client-side Java code, send credentials without using HTTPS or other encrypted transports, or require no passwords at all.

An example of this revealed before my eyes at DEFCON 2014 was the simple password
(slide 67) on Zoll X series defibrillators, but there are many, many

Fortunately, you probably already know how to test for weak passwords by checking the initial installation, trying to set no or weak passwords, and using proxies and sniffers to look for passwords in the clear or weakly encoded with schemes such as BASE64. If you can get access to any storage on a device (as a USB-attached drive, for example), it is also a good idea to scan the available files for any passwords left in the clear at rest.

Testing an IoT Device for Insecure Network Services (OWASP I3)

In your modern corporate network, you may think Telnet and FTP are dead, but the IOT smart device world would disagree. Old and/or potentially insecure services like Telnet, FTP, Finger, TFTP, SMB and others are common on devices, especially if they were built on top of a Linux or Windows kernel that never underwent hardening.

Examples of these types of services abound in IoT documentation and are regularly lit up by security researchers. In August 2014, a sweep of more than 32,000 devices found “at least 2000 devices with hard-coded Telnet logins.” A slightly more sophisticated example can be found in the October 2014 research that demonstrated more than a million deployed routers were vulnerable to misconfigured NAT-PMP services.

Fortunately, you probably already know how to use both port scan tools like Nmap and penetration testing tools likeNessus or OpenVAS to look for these types of dangerous services. You also already know how to track and block them with firewalls, but they may still pose a threat within your walls that can only be mitigated by locking them away in their own network.

Testing an IoT Device for Lack of Transport Encryption (OWASP I4)

When IoT devices fail to use transport encryption to protect the data and credentials they send, they put those items at risk the same way an insecure web application would. Since this type of vulnerability is familiar to any security researcher, we won’t spend much time on it in this article, except to point out that insecure transport is a contributed component to most of the other types of vulnerabilities covered in the OWASP IoT Top 10.

Testing an IoT Device for Privacy Concerns (OWASP I5)

Home users may not understand computer security, but they do understand physical security (“is my door locked?”) and privacy (“is that camera watching me?”). Furthermore, their fears are widespread. For example a Fortinet “Connected Home Survey” in June 2014 suggested that “69% of respondents were concerned that a connected appliance couldresult in data breach of sensitive information.”

While the OWASP IoT Top Ten is a little light on its evaluation of IoT privacy from the perspective of a consumer (a gap that groups like IoT Security Labs are working on), it does cover three important points: ensure minimal data is collected, data is protected, and data is encrypted if possible. It also calls out three common examples of sensitive data: personal data (e.g., home address), financial data (e.g., credit card numbers) and health information. However, in its current state, OWASP’s list should not be considered to be an exhaustive list of sensitive data, since information such as social security numbers, medical test scores, private images and other examples of sensitive information are not listed.

Examples of violations of privacy are unfortunately very common. Some are due to insecure devices, such as the TrendNet issues that let Peeping Toms into the bedrooms of thousands of unsuspecting people. However, other violations are due to unnecessarily expansive privacy policies, such as the TV that allegedly came with a “46-page” document which included the following phrase: “please be aware that if your spoken words include personal or other sensitive information, that information will be among the data captured and transmitted to a third party.”

In the case of specific classes of devices, such as medical devices, you may have the advantage of industry regulation. For example, the FDA has released guidance on securing wireless medical devices since at least October 2013. However, many classes of devices, such as cameras, can span many different types of use, so the privacy rules you need to follow can change radically depending on the purpose and location of the deployed device.

All this ambiguity means that determining the appropriate level of privacy a device needs to deliver is a decision that often involves people outside our traditional disciplines of application and network security. It might even involve your legal department.

Even after you determine the appropriate level of privacy needed from your devices, testing privacy compliance can still be a challenge. Your device’s terms of use or explicit privacy policy may tell you exactly what a device will and will not record, how the information will be protected, and how it is used, but many devices omit this information. You may also need to determine whether or not a device actually performs these functions as advertised, for example by checking to see if a device’s stated retention policy is actually enforced on its storage.

As a security professional, you should already have many of the skills to perform this kind of technical analysis, but you should also plan to spend additional time with IoT devices evaluating claims around secure storage, retention, and the parties who will get copies of data or statistics from the devices.

Testing an IoT Device for Insecure Cloud Interface (OWASP I6)

Many IoT devices exchange information with an external cloud interface or ask end users to connect to a remote web server to work with their information or devices. These web applications and web services can suffer from the same vulnerabilities that all other web applications can. In addition to obvious vulnerabilities such as a lack of HTTPS, the OWASP IoT Top Ten list asks you to look for authentication problems such as username harvesting (a.k.a. “user enumeration”) and no lockouts after a number of brute-force guessing attempts.

Since most security professionals already know how to evaluate systems for these types of vulnerabilities, we won’t spend much time on it in this article, except to remind you that you should get the permission of any remote cloud service before you attempt to perform any type of penetration test against it. (Fortunately some leading cloud services, such as Amazon, now provide well-documented procedures that let you perform your job.)

Testing an IoT Device for Insecure Mobile Interface (OWASP I7)

In addition to unexpected web, Telnet and other application-level services, people are often surprised to find that their IoT devices may also act as wireless access points (WAPs).

In my own office I was surprised one day to see one of the 48-inch smart TVs we use for teleconferencing appear in a list of available wireless access points. Apparently there was an onboard feature that allowed people to connect directly to the TV for advanced streaming functionality, but since it appeared in a secure business setting (and was already connected to the Internet as a wireless client for updates) it was a most unpleasant discovery.

The official OWASP advice for mobile interfaces is currently almost identical to its advice for cloud interfaces (I would expect this to change in future releases) and covers basic authentication issues like username harvesting, lockouts and appropriate levels of transport security (e.g., WPA2).

Unfortunately, this is an area where application security specialists are at a severe disadvantage to network security specialists. In addition to the items explicitly listed by application-centric OWASP, network security professionals would probably add eliminating unnecessary WAPs, turning off broadcasts of non-public SSIDs, disabling public wireless interfaces, considering the “two headed” ramifications of WAPs also connected to other networks, using strong wireless protocols to authenticate and secure traffic, and more.

Fortunately, the tools and procedures network security professionals already use to detect, test and deal with rogue WAPs apply equally well to IoT devices behaving like WAPs.

Testing an IoT Device for Insufficient Security Configurability (OWASP I8)

When OWASP talks about “security configurability” it is really talking about security features such as password policy enforcement, data encryption, and different levels of access. The good news is that most corporate environments now have an established security policy that tell you exactly what security controls your hardware and software need to have to be safely deployed in your environment. You probably also have the advantage of performing this type of analysis on dozens of things in your existing environment, usually from a remote interface.

Fortunately, all your experience evaluating hardware and software against the specific requirements of your security policy translates to performing the same kind evaluation against IoT devices. In some cases (such as a copier with a local flat-panel interface) you may also need to evaluate the available security features through a local user interface as well as any available web or other remote user interface. However, once you discover all the available interfaces on your devices, evaluating them against your security policy should be second nature.

If there is one additional aspect you need to be aware of when evaluating smart IoT devices is that they are often based on traditional operating systems such as Microsoft Windows or Linux which themselves have multiple levels of user access, including full administrator or root permissions. Known “privilege escalation” attacks against these operating systems should be attempted if they are ever found on a target device.

Testing an IoT Device for Insecure Software/Firmware (OWASP I9)

You already know why it is a bad idea for credentials and data to be sent across the wire in the clear: anyone who is listening can intercept your transmission. However, there are two additional threats posed to IoT devices that automatically download unencrypted and/or unsigned updates and configurations from HTTP-based sources.

The first problem is that the contents of updates could be changed or replaced before they get to automatically-updating devices. This has the effect of allowing any attacker to run any code that her or she wishes on the device, including backdoors or the data collection malware used in recent retail thefts at Target and Home Depot. The defenses against this are to cryptographically sign all updates, and to only use HTTPS (or other secure channels) where the identity of the providing server can be cryptographically established.

The second problem is that any sensitive data sent in updates, such as initial or hardcoded passwords or keys, can be read if not encrypted. Obviously, the defense against this is to encrypt updates whenever possible, both in transit and at rest.

Real life examples of corrupt update files abound, especially when people use “jailbroken” phones to disable the validation built in to their devices. Man-in-the-middle (MITM) attacks using insecure update sources, such as the HTTP-based update vulnerability that afflicted ASUS RT routers in October 2014, are also more common that you might think.

To test whether or not a device is using insecure updates, you generally need to use a proxy or sniffer to watch the data stream for use of secure transport. To examine the update itself, you can often use an attack proxy to divert the download or a simple URL (or utility) to download it to a desktop location for further inspection. For example, an online utility called “APK Downloader” lets you download and inspect Android installations and updates on any platform.

Testing an IoT Device for Poor Physical Security (OWASP I10)

OWASP asks security professionals to looks for at least five things when determining if a device’s exposed ports can be used for malicious purposes. These are ease of storage media removal, encryption of stored data, physical protection of USB and similar ports, ease of disassembly and removal or disabling of unnecessary ports.

At DEFCON 2014 an extensive hack of an “Internet kiosk” was made possible through a tiny USB port left exposed near the floor in the back of the appliance. A related presentation called “Hack all the things: 20 devices in 45 minutes” also demonstrated how to break into many devices using externally-exposed USB ports, USB headers on circuit boards, simple serial-based “terminal headers” (e.g., “RX” and “TX”) on circuit boards and bypasses of local storage components.

Some network security specialists may be familiar with some of the concepts required to examine devices for physical security, such as exposed interfaces, but many of the attack vectors here require training that has heretofore been reserved for (often, military or intelligence) professionals evaluating the security of hardened devices. Emerging concepts (at least in the commercial space) such as tamper-evident cases, sealed circuit boards and other technologies will likely be added to the list of things you are expected to know about when you evaluate IoT devices.


The rapid emergence of IoT devices will force you out of your comfort zone as a security professional. However, even as IoT security standards such as the OWASP IoT Top Ten evolve, you can take comfort in the fact that many of your skills as an application security or network security specialist will also be necessary to evaluate IoT security.

To help guide your IoT security education, a summary of the relative maturity of the OWASP IoT Top Ten items (in which “emerging” means “incomplete” or “likely to change significantly”), and the applicability of existing security skillsets is provided below.

Checklist for Next Gen Firewalls

Due to the ever-changing threat landscape, a few security products such as firewalls, IDS/IPS, etc. are becoming obsolete because of the older technologies being employed within them. In this article, we will learn about why the traditional firewall failed to cope with new threats and how the Next Generation Firewall will address the new needs of perimeter security. In this article we will also focus on the checklist that will come handy for organizations for implementing Next Gen Firewalls for securing their perimeter.

Why are Traditional Firewalls not sufficient anymore?

A decade back, traditional firewalls played the most important role in securing the perimeter of an organization’s network. Applications were simple, and to protect them an organization would just rely on port + protocol logic. If they blocked the port and protocol for a particular application, then it was considered secure at that time. But the Internet has come a long way from where it was a decade back. With the commencement of Web 2.0, applications now have gone to an altogether different level. The Internet is not about just surfing anymore.

Port based firewalls inspect the network stream by looking at the header of the first packet for a particular session and thus will go by the applied rules. They do not have the capability to distinguish between different applications using same port. Port based firewalls have no idea what is going on inside the packet, thus they cannot check for possible malware in packets destined for legitimate business applications’ traffic. Traditional firewalls were not intelligent enough to allow traffic on an authorized need basis. To revive firewalls, vendors came up with a concept of Unified Threat Management (UTM) which consists of several blades of other security products such as IDS/IPS. IDS/IPS works with protocol anomaly detection, signature or heuristic based analysis, but the problem is the same IDS/IPS does not understand the application and works blindly on anomaly detection.

What is a Next Gen Firewall?

Next Gen Firewalls have come to rescue the legacy of traditional firewalls with providing all the benefits of a traditional firewall like state full inspection, NAT/PAT support, VPN support, etc., along with some advanced security features like identifying applications regardless of ports, protocols etc., and high performance, policy-based control over applications. Basically, Next Gen Firewalls are intelligent firewalls which allow traffic on a need + security basis rather than traditional port + protocol concept.

How is a Next Gen Firewall different?

This section reveals some data points that make a Next Gen Firewall different and more superior than traditional firewalls.

  • Traditional firewalls collapsed, as they solely depend on port + protocol pair to allow or block traffic, whereas Next Gen Firewalls identify robust applications analyzing application signatures to identify applications regardless of ports and protocols. Next Gen Firewalls also perform decryption to see what is inside the traffic and decodes the protocols to see the in line hidden protocols. With this point, many would call it a twin of UTM, but UTM are never meant to provide high performance and are typically adequate in smaller environments.
  • Next Gen Firewalls integrate with user stores such as Active Directory (AD). This mapping of user-to-IP address and integration with AD will help firewalls harvest more information about the users such as user groups and roles. This will enable firewalls to behave more intelligently. This feature was totally missing in the traditional firewalls.
  • Next Gen Firewalls now can inspect the real time threats within the permitted traffic as well by decoding application streams by inspecting the traffic with a universal threat signature, which reduces the need to check for different threats under different engines and thus increases performance.

What Next Gen Firewalls are not

When it comes to functions of a Next Gen firewall, various security devices in the market can be thought of doing the same thing that is done by Next Gen Firewalls. However, Next Gen Firewalls should not be compared with:

  • UTM devices, which are not built for high performance.
  • A proxy that has firewalls and proxy capability, but not an application signature library like Next Gen, which means that all the applications there need to be applied.
  • Next Gen Firewalls should not be compared with Web Application Firewalls (WAF), as WAFs are designed to inspect only Layer 7 instead of a whole OSI stock, which a Next Gen Firewall does.

Checklist for Next Gen Firewalls

Before deploying a Next Gen Firewall, organizations must check for certain features that should be in the product to really act as a Next Generation Firewall device. Some of the features are listed below.

  • Next Gen Firewalls should identify applications and not ports: Organizations should always choose those vendors which have adopted a technology to store a library which consists of application signatures, as this will help the organizations to expose a business’s critical applications while blocking applications which can cause a threat.
  • Next Gen Firewalls should identify users and not just IP addresses: Organizations should check whether the NGFW offers user-to-IP address mapping. An offered NGFW device must have integration with directory services such as Active directory. Since user to IP address mapping will help to control the activity of specific users, this feature is a must. Techniques include login monitoring, which can help to correlate an IP address to user info when he logs in to the domain, and workstation IP address polling, which can help to verify IP address information and thus maintain accurate mapping when users move around the network.
  • Next Gen Firewalls should identify content and not just packets: Next Gen Firewalls must have the capability to inspect the packets to look out for threats. Next Gen firewalls should have the capability to inspect the files as soon as the first packet is received instead of waiting for a whole packet stream and then stream processing. Also the NGFW should have only one scanning engine to look out for all possible threats instead of multiple engines to look out for multiple attack vectors. This will greatly improve the performance. The NGFW should also have features like URL filtering, data filtering by type, size, etc.
  • Next Gen Firewalls should give more granular control: Next Gen Firewalls should provide more control than the traditional firewalls. Traditional firewalls have controls like allow, deny. Next Gen firewalls, because of their new features, must give controls like “Allow but Scan”, “Decrypt and Inspect”, Allow for Certain User Group”, etc.
  • High performance: Next Gen firewalls must provide real time protection with no latency. Features like a single scanning engine for all types of malwares can help greatly in scanning the packets in a time-efficient manner.
  • Reliable, flexible and easy to maintain: Next Gen Firewalls should be flexible enough to get fixed in an existing IT landscape. Next Gen firewalls should have features like IPv6 support, dynamic routing protocols like BGP, etc. Next Gen Firewalls should support active-passive and active-active failover architectures. Next Gen Firewalls should be easy to maintain and must support remote, local or centralized management. Also, features like role-based administration must be in the checklist to look out for in Next Gen Firewalls.

Up ↑