Daily Archives: December 9, 2019

MoJ Reports Over 400% Increase in Lost Laptops in Three Years

Apricorn, the leading manufacturer of software-free, 256-bit AES XTS hardware-encrypted USB drives, today announced new findings from Freedom of Information (FoI) requests submitted to five government departments into the security of devices held by public sector employees. The Ministry of Justice (MoJ) lost 354 mobile phones, PCs, laptops and tablet devices in FY 2018/19 compared with 229 between 2017/2018. The number of lost laptops alone, has risen from 45 in 2016/17 to 101 in 2017/18 and up to 201 in 2018/2019, an increase of more than 400% in three years.

FoI requests were submitted to the MoJ, Ministry of Education (MoE), Ministry of Defence (MoD), NHS Digital and NHS England during September-November 2019. Of the five government departments contacted, three out of five government departments responded. The MoE also reported 91 devices lost or stolen in 2019, whilst NHS Digital have lost 35 to date in 2019.

“Whilst devices are easily misplaced, it’s concerning to see such vast numbers being lost and stolen, particularly given the fact these are government departments ultimately responsible for volumes of sensitive public data. A lost device can pose a significant risk to the government if it is not properly protected” said Jon Fielding, Managing Director, EMEA, Apricorn.

When questioned about the use of USB and other storage devices in the workplace, or when working remotely, all three departments confirmed that employees use USB devices. The MoJ added that all USB ports on laptops and desktops are restricted and can only be used when individuals have requested that the ports be unlocked. Each of the responding departments noted that all USB and storage devices are encrypted.

“Modern-day mobile working is designed to support the flexibility and efficiency increasingly required in 21st-century roles, but this also means that sensitive data is often stored on mobile and laptop devices. If a device that is not secured is lost and ends up in the wrong hands, the repercussions can be hugely detrimental, even more so with GDPR now in full force”, noted Fielding.

In a survey by Apricorn earlier this year, roughly a third (32%) of respondents said that their organisation had already experienced a data loss or breach as a direct result of mobile working and to add to this, 30% of respondents from organisations where the General Data Protection Regulation (GDPR) applies were concerned that mobile working is an area that will most likely cause them to be non-compliant.

All responding sectors did confirm that they have security policies in place that cover all mobile, storage and laptop devices.

“Knowing that these government departments have policies in place to protect sensitive data is somewhat reassuring, however, they need to be doing a lot more to avoid the risk of a data breach resulting from these lost devices. Corporately approved, hardware encrypted storage devices should be provided as standard. These should be whitelisted on the IT infrastructure, blocking access to all non-approved media. Should a device then ‘go missing’ the data cannot be accessed or used inappropriately” Fielding added.

About the FoI Requests
The research was conducted through Freedom of Information requests submitted through Whatdotheyknow.com. The requests, submitted between September and November 2019, along with the successful responses can be found at: https://www.whatdotheyknow.com/list/successful.

GNU Radio Primer

Ray Felch // Disclaimer: Be sure to use a faraday bag or cage before transmitting any data so you don’t accidentally break any laws by illegally transmitting on regulated frequencies. Additionally, intercepting and decrypting someone else’s data is illegal, so be careful when researching your traffic. Preface: Recently, I introduced myself to the world of […]

The post GNU Radio Primer appeared first on Black Hills Information Security.

Optiv Announces New Software Assurance as-a-Service Offering Powered by Veracode

In an effort to help drive collaboration between security, development, and operations, improve speed to market, and ensure software is secure from the start, Optiv has released its new Software Assurance as-a-Service (SAaaS) offering. This program pairs Optiv’s consulting and security services with Veracode’s cloud-based, end-to-end application security solutions to give companies a programmatic approach to DevSecOps.

In today’s world, every company is a software company and, as a result, one of the top attack vectors for software-driven and supported organizations is the application. Just as development teams are increasingly integrating automated security into their workflows, security teams are looking for support to plan, build, and run strong application security programs that deliver on the overarching goals of the business.

Through SAaaS, DevSecOps teams are assisted with detection, analysis, and response to application vulnerabilities with Veracode Static Analysis, Veracode Dynamic Analysis, and Veracode Software Composition Analysis. In order to ensure that the flaws aren’t just found, but also fixed, the Optiv SAaaS solution is inclusive of software assurance expertise for code review, threat modeling, SDLC workshops, architectural review, and program development.

Optiv SAaaS enables modern organizations of all sizes and maturity levels to take advantage of a highly scalable platform and seamless integration to build a customized AppSec program that delivers secure software faster. This offering can help companies empower their development and security teams, lower their security risk, and turn security into a competitive advantage.

Learn more here.

Detecting unsafe path access patterns with PathAuditor



#!/bin/sh
cat /home/user/foo


What can go wrong if this command runs as root? Does it change anything if foo is a symbolic link to /etc/shadow? How is the output going to be used?

Depending on the answers to the questions above, accessing files this way could be a vulnerability. The vulnerability exists in syscalls that operate on file paths, such as open, rename, chmod, or exec. For a vulnerability to be present, part of the path has to be user controlled and the program that executes the syscall has to be run at a higher privilege level. In a potential exploit, the attacker can substitute the path for a symlink and create, remove, or execute a file. In many cases, it's possible for an attacker to create the symlink before the syscall is executed.

At Google, we have been working on a solution to find these potentially problematic issues at scale: PathAuditor. In this blog post we'll outline the problem and explain how you can avoid it in your code with PathAuditor.

Let’s take a look at a real world example. The tmpreaper utility contained the following code to check if a directory is a mount point:
if ((dst = malloc(strlen(ent->d_name) + 3)) == NULL)
       message (LOG_FATAL, "malloc failed.\n");
strcpy(dst, ent->d_name);
strcat(dst, "/X");
rename(ent->d_name, dst);
if (errno == EXDEV) {
[...]


This code will call rename("/tmp/user/controlled", "/tmp/user/controlled/X"). Under the hood, the kernel will resolve the path twice, once for the first argument and once for the second, then perform some checks if the rename is valid and finally try to move the file from one directory to the other.

However, the problem is that the user can race the kernel code and replace the “/tmp/user/controlled” with a symlink just between the two path resolutions.

A successful attack would look roughly like this:
  • Make “/tmp/user/controlled” a file with controlled content.
  • The kernel resolves that path for the first argument to rename() and sees the file.
  • Replace “/tmp/user/controlled” with a symlink to /etc/cron.
  • The kernel resolves the path again for the second argument and ends up in /etc/cron.
  • If both the tmp and cron directories are on the filesystem, the kernel will move the attacker controlled file to /etc/cron, leading to code execution as root.
Can we find such bugs via automated analysis? Well, yes and no. As shown in the tmpreaper example, exploiting these bugs can require some creativity and it depends on the context if they’re vulnerabilities in the first place. Automated analysis can uncover instances of this access pattern and will gather as much information as it can to help with further investigation. However, it will also naturally produce false positives.

We can’t tell if a call to open(/user/controlled, O_RDONLY) is a vulnerability without looking at the context. It depends on whether the contents are returned to the user or are used in some security sensitive way. A call to chmod(/user/controlled, mode) depending on the mode can be either a DoS or a privilege escalation. Accessing files in sticky directories (like /tmp) can become vulnerabilities if the attacker found an additional bug to delete arbitrary files.

How Pathauditor works

To find issues like this at scale we wrote PathAuditor, a tool that monitors file accesses and logs potential vulnerabilities. PathAuditor is a shared library that can be loaded into processes using LD_PRELOAD. It then hooks all filesystem related libc functions and checks if the access is safe. For that, we traverse the path and check if any component could be replaced by an unprivileged user, for example if a directory is user-writable. If we detect such a pattern, we log it to syslog for manual analysis.

Here's how you can use it to find vulnerabilities in your code:
  • LD_PRELOAD the library to your binary and then analyse its findings in syslog. You can also add the library to /etc/ld.so.preload, which will preload it in all binaries running on the system.
  • It will then gather the PID and the command line of the calling process, arguments of the vulnerable function, and a stack trace -- this provides a starting point for further investigation. At this point, you can use the stack trace to find the code path that triggered the violation and manually analyse what would happen if you would point the path to an arbitrary file or directory.
  • For example, if the code is opening a file and returning the content to the user then you could use it to read arbitrary files. If you control the path of chmod or chown, you might be able to change the permissions of chosen files and so on.
PathAuditor has proved successful at Google and we're excited to share it with the community. The project is still in the early stages and we are actively working on it. We look forward to hearing about any vulnerabilities you discover with the tool, and hope to see pull requests with further improvements.

Try out the PathAuditor tool here.

Marta Rożek was a Google Summer intern in 2019 and contributed to this blog and the PathAuditor tool