Jump to content

Search the Community

Showing results for tags 'docker'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Site Related
    • News & Updates
    • Site / Forum Feedback
    • Member Introduction
  • News
    • General News
    • FileSharing News
    • Mobile News
    • Software News
    • Security & Privacy News
    • Technology News
  • Downloads
    • nsane.down
  • General Discussions & Support
    • Filesharing Chat
    • Security & Privacy Center
    • Software Chat
    • Mobile Mania
    • Technology Talk
    • Entertainment Exchange
    • Guides & Tutorials
  • Off-Topic Chat
    • The Chat Bar
    • Jokes & Funny Stuff
    • Polling Station


  • Drivers
  • Filesharing
    • BitTorrent
    • eDonkey & Direct Connect (DC)
    • NewsReaders (Usenet)
    • Other P2P Clients & Tools
  • Internet
    • Download Managers & FTP Clients
    • Messengers
    • Web Browsers
    • Other Internet Tools
  • Multimedia
    • Codecs & Converters
    • Image Viewers & Editors
    • Media Players
    • Other Multimedia Software
  • Security
    • Anti-Malware
    • Firewalls
    • Other Security Tools
  • System
    • Benchmarking & System Info
    • Customization
    • Defrag Tools
    • Disc & Registry Cleaners
    • Management Suites
    • Other System Tools
  • Other Apps
    • Burning & Imaging
    • Document Viewers & Editors
    • File Managers & Archivers
    • Miscellaneous Applications
  • Linux Distributions


  • General News
  • File Sharing News
  • Mobile News
  • Software News
  • Security & Privacy News
  • Technology News

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...

Found 6 results

  1. Container security: Privilege escalation bug patched in Docker Engine ‘An odd one, impact wise’ A vulnerability in a Docker Engine security feature potentially allowed attackers to escalate privileges from a remapped user to root. “The two avenues of exploitation I found would allow writing of arbitrary files as the real root user” or seizing ownership of files previously accessible only by the root user, security researcher Alex Chapman, who unearthed the flaw, tells The Daily Swig. The vulnerable function in question – ‘--userns-remap’ – “is an optional security enhancement which isolates container users within a user namespace”, he explains. “What this means is that, when enabled, the ‘root’ user within the container is actually mapped to a non-privileged user in the container host.” If an attacker has root access to, and can escape, a Docker container, “the user they can run commands as on the host is not the privileged root user”, he adds. “This bug allowed this non-privileged, remapped user to escalate to the real ‘root’ user by exploiting various race conditions in Docker when building or starting containers.” The flaw (CVE-2021-21284) resides in the Docker Engine package, docker-ce. Limited exploitation If --userns-remap is enabled and “the root user in the remapped namespace has access to the host filesystem, they can modify files under /var/lib/docker/<remapping> that cause writing files with extended privileges.” A security advisory posted by Docker’s Moby Project to GitHub on February 1 actually classifies the bug as ‘low’ impact, but Chapman describes it as “an odd one, impact wise” and said he “would have preferred medium impact”. However, the researcher acknowledged that “exploitation is a little limited”, given its contingency on escaping the container, and “another user (or system service) creating or building a container” so the attacker can “replace files written during the container creation or build process”. Moreover, “as far as I am aware the ‘--userns-remap’ is not that widely used”, he adds. The flaw was fixed in docker-ce versions 19.03.15 and 20.10.3. All previous versions on those release lines were affected by the vulnerability. Source: Container security: Privilege escalation bug patched in Docker Engine
  2. Three years after the first malware attacks targeting Docker, developers are still misconfiguring and exposing their Docker servers online. Towards the end of 2017, there was a major shift in the malware scene. As cloud-based technologies became more popular, cybercrime gangs also began targeting Docker and Kubernetes systems. Most of these attacks followed a very simple pattern where threat actors scanned for misconfigured systems that had admin interfaces exposed online in order to take over servers and deploy cryptocurrency-mining malware. Over the past three years, these attacks have intensified, and new malware strains and threat actors targeting Docker (and Kubernetes) are now being discovered on a regular basis. But despite the fact that malware attacks on Docker servers are now commonplace, many web developers and infrastructure engineers have not yet learned their lesson and are still misconfiguring Docker servers, leaving them exposed to attacks. The most common of these mistakes is leaving Docker remote administration API endpoints exposed online without authentication. Over the past years, malware like Doki, Ngrok, Kinsing (H2miner), XORDDOS, AESDDOS, Team TNT, and others, have scanned for Docker servers that left the Docker management API exposed online and then abused it to deploy malicious OS images to plant backdoors or install cryptocurrency miners. The latest of these malware strains was discovered last week by Chinese security firm Qihoo 360. Named Blackrota, this is a simple backdoor trojan that is basically a simplified version of the CarbonStrike beacon implemented in the Go programming language. Only a Linux version was discovered until now, and it is unclear how this malware is being used. Researchers don't know if a Windows version also exists, if Blackrota is being used for cryptocurrency mining, or if it's used for running a DDoS botnet on top of powerful cloud servers. What it is known is that Blackrota relies on developers who have made a mistake and accidentally misconfigured their Docker servers. The lesson from Blackrota and past attacks, is that Docker is not a fringe technology anymore. Threat actors are now targeting it on purpose with at-scale attacks on a near daily basis. Companies, web developers, and engineers running Docker systems part of production systems are advised to review the official Docker documentation to make sure they have secured Docker's remote management capabilities with proper authentication mechanisms, such as certificate-based authentication systems. Currently, there are plenty of tutorials around to guide even the most inexperienced developers with step-by-step guides. With Docker gaining a more prominent place in modern-day infrastructure setup, with attacks on the rise, and with the number of malware strains that target Docker systems growing by the month, it's time that developers took Docker security seriously. Source
  3. New Docker Container Escape Bug Affects Microsoft Azure Functions Cybersecurity researcher Paul Litvak today disclosed an unpatched vulnerability in Microsoft Azure Functions that could be used by an attacker to escalate privileges and escape the Docker container used for hosting them. The findings come as part of Intezer Lab's investigations into the Azure compute infrastructure. Following disclosure to Microsoft, the Windows maker is said to have "determined that the vulnerability has no security impact on Function users, since the host itself is still protected by another defense boundary against the elevated position we reached in the container host." Azure Functions, analogous to Amazon AWS Lambda, is a serverless solution that allows users to run event-triggered code without having to provision or manage infrastructure explicitly while simultaneously making it possible to scale and allocate compute and resources based on demand. By incorporating Docker into the mix, it makes it possible for developers to easily deploy and run Azure Functions either in the cloud or on-premises. Since the trigger code is an event (e.g., an HTTP request) that is configured to call an Azure Function, the researchers first created an HTTP trigger to gain a foothold over the Function container, using it to find sockets belonging to processes with "root" privileges. From there, one such privileged process associated with a "Mesh" binary was identified to contain a flaw that could be exploited to grant the "app" user that runs the above Function root permissions. While the Mesh binary in itself had little to no documentation to explain its purpose, Intezer researchers found references to it in a public Docker image, which they used to reverse engineer and achieve privilege escalation. In the final step, the extended privileges assigned to the container (using the "--privileged" flag) were abused to escape the Docker container and run an arbitrary command on the host. Intezer has also released a proof-of-concept (PoC) exploit code on GitHub to probe the Docker host environment. "Instances like this underscore that vulnerabilities are sometimes out of the cloud user's control," Intezer Labs researchers said. "Attackers can find a way inside through vulnerable third-party software. "It's critical that you have protection measures in place to detect and terminate when the attacker executes unauthorized code in your production environment. This Zero Trust mentality is even echoed by Microsoft." Source: New Docker Container Escape Bug Affects Microsoft Azure Functions
  4. straycat19

    Docker for Pentesters

    Table of Contents Background Useful Docker Aliases Example 1 - Exploring other OSs Example 2 - Compiling Code for old targets Example 3 - Impacket Example 4 - SMB Server with Impacket Example 5 - Serving HTTP Files Example 6 - Serving Files over WebDav Example 6 - Serving Files behind NAT with Ngrok Example 7 - Metasploit Example 8 - msfvenom Example 9 - Capturing HTTP Files Bonus Example - Windows Containers Conclusion tl;dr Over the last few years I have done a complete 180 on Docker (well, containerization in general). One of the very first posts I wrote on this blog was about plundering Docker images, and at the time I was not a fan. I didn't see the benefit of Docker, I thought it was confusing, I thought it was a fad and I couldn't understand why anyone thought it was better than just a VM. Fast forward 3 years and Docker has become an indespensible part of my day-to-day workflow, both professionally and personally. My hope in this post is to demonstrate some of my usecases and workflows, and illustrate how I think pentesters and security professionals in general can greatly benefit from Docker. Background Everybody has probably seen a diagram like this when Googling "Container vs VM" (in fact, this one is the top result) But that doesn't really explain much. Conceptually I always understood how containers technically differed from VMs, but I didn't understand the benefit to me. Now I won't go in to the benefit of containers for an organization (although I could easily!), but I'll focus on how Docker improves my workflow as a pentester (and developer). I use Docker containers as fast, purpose built, disposable environments for testing things and running applications. I think of containers less as a "Virtual Machine", and more as a self-contained executable or a "virtualenv" for an OS. And no matter what machine I am on (work, personal, etc), I will always have the exact same experience. In the following examples, hopefully you'll see the benefits of Docker containers. If you're of the camp that "VM's are still better", I won't try to convince you. If your workflow is amazing with VMs, maybe even automated using Vagrant and Packer, that's awesome. Keep doing you. This works for me and I just wanted to share Useful Docker Aliases I make heavy use of aliases when using Docker. These are an absolute life saver to me, and IMO should be added for anyone using Docker: alias dockershell="docker run --rm -i -t --entrypoint=/bin/bash" alias dockershellsh="docker run --rm -i -t --entrypoint=/bin/sh" function dockershellhere() { dirname=${PWD##*/} docker run --rm -it --entrypoint=/bin/bash -v `pwd`:/${dirname} -w /${dirname} "[email protected]" } function dockershellshhere() { dirname=${PWD##*/} docker run --rm -it --entrypoint=/bin/sh -v `pwd`:/${dirname} -w /${dirname} "[email protected]" } What do these do? They simply let me specify an image and drop into an interactive shell in a fresh, disposable environment. I can look around, make changes, test things, and then when I'm finished and type "exit", everything is destroyed and cleaned up. dockershell executes /bin/bash, while dockershellsh executes /bin/sh. This is useful since not every Docker image has bash installed. The ones that end in here take it one step further and mount my current working directory inside the disposable container. This lets me interact with my files inside the disposable environment, and anything I write to that directory while inside the container persists after exit. For example: No spinning up a VM, no SSH, just instant shell access to test something out. And when I'm done it's destroyed and the next time I run it I have a fresh instance again. I'll use these aliases a lot in the examples below. Example 1 - Exploring other OSs Early on in my pentest career, I would find myself with either a blind command injection or LFI on a server but didn't really know what to look for. I spent hours spinning up VMs to match the OS version or application stack just to do some local reconnaissance to know what to look for. With Docker this is painless now. Let's say I have LFI on a Tomcat 6 box - what files exist that I should go after? I'll just drop into a shell on a Tomcat 6 docker image and go exploring: This pulls the official Tomcat 6 Docker image which is based on Debian 8 and has Tomcat pre-installed. I can start exploring the configuration files and figure out which ones exist and might contain sensitive information (e.g. conf/server.xml or conf/tomcat-users.xml) Or what if I found an old CentOS box and need to know what version of glibc is on it? Instead of downloading an ISO and booting a VM, I can use Docker: Note: I highlighted my kernel version to demonstrate a point. I'm running on a very new Kernel because it's my Docker host's kernel - this is one of the key differences between containers and VMs CentOS 4 appears to have glibc 2.3.4 Example 2 - Compiling Code for old targets Taking the last example one step further, what if I need to compile something to target an older version of glibc? Back when I was doing boot2roots and CTFs this came up all the time. I needed to compile a specific exploit for a specific version - and often I would download an entire ISO and create a VM just to compile a single file. But now I can do it in Docker easily. First, I need to install the necessary build tools in a CentOS 5 docker image: yum install -y perl curl wget gcc c++ make glibc-devel glibc-devel.i386 But! The official CentOS 5 image doesn't have up-to-date sources to actually install anything. A little bit of Googling and somebody fixed that for me: https://hub.docker.com/r/astj/centos5-vault/ Now I can just dockershell into astj/centos5-vaule and run the yum commands. However, it's annoying to reinstall all the build tools every time I need them. So let's create another Docker image! This is another reason Docker is awesome - I'll just create a purpose-built image that instantly gets me a CentOS 5 box with all the build tools I need. And in terms of storage, this doesn't create a copy or a clone of the CentOS 5 image - I'm just creating another layer on top it. function dockershell() { docker run --rm -i -t --entrypoint=/bin/bash "[email protected]" } function dockershellsh() { docker run --rm -i -t --entrypoint=/bin/sh "[email protected]" } function dockershellhere() { dirname=${PWD##*/} docker run --rm -it --entrypoint=/bin/bash -v `pwd`:/${dirname} -w /${dirname} "[email protected]" } function dockershellshhere() { docker run --rm -it --entrypoint=/bin/sh -v `pwd`:/${dirname} -w /${dirname} "[email protected]" } function dockerwindowshellhere() { dirname=${PWD##*/} docker -c 2019-box run --rm -it -v "😄${PWD}:C:/source" -w "C:/source" "[email protected]" } impacket() { docker run --rm -it rflathers/impacket "[email protected]" } smbservehere() { local sharename [[ -z $1 ]] && sharename="SHARE" || sharename=$1 docker run --rm -it -p 445:445 -v "${PWD}:/tmp/serve" rflathers/impacket smbserver.py -smb2support $sharename /tmp/serve } nginxhere() { docker run --rm -it -p 80:80 -p 443:443 -v "${PWD}:/srv/data" rflathers/nginxserve } webdavhere() { docker run --rm -it -p 80:80 -v "${PWD}:/srv/data/share" rflathers/webdav } metasploit() { docker run --rm -it -v "${HOME}/.msf4:/home/msf/.msf4" metasploitframework/metasploit-framework ./msfconsole "[email protected]" } metasploitports() { docker run --rm -it -v "${HOME}/.msf4:/home/msf/.msf4" -p 8443-8500:8443-8500 metasploitframework/metasploit-framework ./msfconsole "[email protected]" } msfvenomhere() { docker run --rm -it -v "${HOME}/.msf4:/home/msf/.msf4" -v "${PWD}:/data" metasploitframework/metasploit-framework ./msfvenom "[email protected]" } reqdump() { docker run --rm -it -p 80:3000 rflathers/reqdump } postfiledumphere() { docker run --rm -it -p80:3000 -v "${PWD}:/data" rflathers/postfiledump } view raw Source
  5. Microsoft's risky strategy: Develop on Windows, deploy to Linux Visual Studio code with Docker and remoting to Windows Subsystem for Linux 2 Docker has published details of what its container technology will look like for developers working on Windows, after the release of Microsoft's Windows Subsystem for Linux 2 (WSL 2) that is currently in preview. WSL 2 takes a different approach than the existing WSL. Instead of redirecting system calls to run Linux binaries, WSL 2 runs a Linux kernel in a Hyper-V Virtual Machine, but with integration with the host Windows operating system, so you still get most of the features of WSL 1.0. Linux compatibility in WSL 1.0 was insufficient to support Docker containers, but in WSL 2 they will work. Docker is embracing this change. The brief history of Docker on Windows looks like this. First there was Docker Toolbox, released in August 2015, which uses the VirtualBox hypervisor to run Linux in a VM. Then came Docker Desktop, released in 2016, which uses Hyper-V for Linux support, to the relief of developers juggling with incompatible Windows hypervisors. Then in 2017, Docker, working with Microsoft, added support for Windows Server Containers – containers that run Windows rather than Linux applications. At the time, Microsoft enthused that this would "revolutionise the way [customers] build software and modernise existing applications, all with the same platform." The current version of Docker Desktop for Windows installs with Linux containers as the default, but with an option to switch to Windows containers. Diagram showing how Docker works with WSL 2E Now Docker has said it will: Replace the Hyper-V VM we currently use by a WSL 2 integration package. This package will provide the same features as the current Docker Desktop VM: Kubernetes 1-click setup, automatic updates, transparent HTTP proxy configuration, access to the daemon from Windows, transparent bind mounts of Windows files, and more. The big feature this will enable for developers is the ability to use Linux tools to interact with the Linux Docker daemon (service). Docker added: With WSL 2 integration, you will still experience the same seamless integration with Windows, but Linux programs running inside WSL will also be able to do the same. Other advantages include dynamic memory allocation in WSL 2, enabling Docker to make more efficient use of resources, much faster cold start-up which means the Docker daemon does not need to run when not in use, and more reliable container access to files on the Windows side. Docker envisages developers using the "Remote to WSL" extension in Visual Studio Code (VS Code) in order to edit code in Windows while interacting with Linux though the VS Code terminal. All good news? It is from Docker's perspective since it will have less work to do in order to run well on Windows, and the benefits for developers are real. Microsoft dons penguin suit The surprising aspect to all this is the effort Microsoft is making to promote Linux application development to its developers on Windows. The reason for this change of heart is the Azure platform, which means Microsoft can profit almost as much from hosting Linux applications as from Windows, particularly if those applications use other Azure services. Projects like the cross-platform .NET Core and SQL Server for Linux are also part of this trend. The Docker news is of no interest to developers using Windows Containers, but there are not many of them. At Microsoft's Build conference last month, Gabe Monroy, lead program manager for the Azure Container Compute team, was asked whether Windows Containers are for legacy and Linux Containers for new projects. "I think that is a fair description," he said, demonstrating how the company's thinking on the subject has shifted. Similarly, WSL 2 makes life better for developing Linux applications on Windows, but there are downsides. Running Linux in a VM as opposed to redirecting system calls is better for compatibility but inherently worse for integration. One aspect of this is that in WSL 2 I/O performance to files within the Linux VM is much faster, but I/O performance between Linux and the host is worse. Another is that WSL 2 has no access to serial or USB ports. "I primarily want my source of truth (my files) to be on the Windows side of things. WSL1 had the perfect working model for me," said a developer in response to the announcement of WSL 2 previews for those on Windows Insider builds. Microsoft's response? "We understand that this could be a blocker for many people, and so we aren't discontinuing working on WSL 1." This will be a half-truth though; Microsoft will now put most of its effort into WSL 2. Develop on Windows, deploy to Linux is an interesting strategy for Microsoft and one with obvious risks for the future of the Windows side. Source
  6. A newly discovered botnet malware exploits an API misconfiguration in the open-source version of the DevOps tool, Docker Engine-Community, to infiltrate containers and run a variant of the Linux botnet malware AESDDoS, according to a Trend Micro blog post. “Docker APIs that run on container hosts allow the hosts to receive all container-related commands that the daemon, which runs with root permission, will execute,” Trend Micro researchers wrote. “Allowing external access — whether intentionally or by misconfiguration — to API ports allows attackers to gain ownership of the host, giving them the ability to poison instances running within it with malware and to gain remote access to users’ servers and hardware resources,” the blog post noted. External access to API ports allows attackers to gain ownership of the host, giving them the ability to ultimately gain remote access to users’ servers and hardware resources. Researchers also noticed threat actors abusing a tool called a Docker Batch Test that was developed to detect vulnerabilities in Docker. To prevent similar container-based incidents from taking place, researchers recommended users check API configuration, implement the principle of least privilege, follow recommended best practices and employ automated runtime and image scanning to gain further visibility into a container’s processes. Source
  • Create New...