Category Archives: Linux

Linux Users Are Unable To Manage Their Apple ID on Applecom

For some reason, Apple's website where you can manage your Apple ID (appleid.apple.com) is blocking users of Linux browsers from accessing it. From a report: Having access to the website is important to manage things such as payment information, two-factor authentication, and other account details. Even though the number of Linux users accessing the website must be relatively small compared to other operating systems, some iPhone users who use Linux on the desktop noticed the issue. This behavior was first explained by user Alexander Martin on Mastodon. He discovered that when the browser reports itself as being a Linux browser, Apple's website will block the access by throwing a "Bad Gateway" error.

Read more of this story at Slashdot.

Download Kali Linux 2019.1 with Metasploit 5.0

By Waqas

Download Kali Linux 2019.1 now! – This is the first major update for Kali Linux ever since version 4.0 was released in 2011. Kali Linux is one of the most popular Debian-based Linux distribution for advanced Penetration Testing and that is why the InfoSec community eagerly waits for its new versions. So wait no more and download Kali Linux […]

This is a post from HackRead.com Read the original post: Download Kali Linux 2019.1 with Metasploit 5.0

Kali Linux 2019.1 Released, Download Now!!!

Kali Linux 2019.1 security OS released with an updated version of Metasploit and wider support for ARM devices

Offensive Security yesterday announced its first release of 2019, Kali Linux 2019.1. This Kali release brings kernel up to version 4.19.13, fixes numerous bugs, and includes many updated packages.

For those unaware, Kali Linux is one of the best Linux distros for hackers, pen-tester, and security researchers due to the fact that most of the hacking tools that are available online are built-in this Linux Distro.

What’s new in Kali Linux 2019.1?

The major highlight of this latest Kali release is the update of Metasploit to version 5.0, which is the software’s first major release since version 4.0 came out in 2011.

“Metasploit 5.0 is a massive update that includes database and automation APIs, new evasion capabilities, and usability improvements throughout,” reads the Kali Linux project official announcement page.

Kali Linux 2019.1 also includes updated packages for theHarvesterDBeaver, and more. Please refer to the Kali Bug Tracker Changelog for the complete list of updates, fixes, and additions.

Support added for Banana Pi and Banana Pro ARM boards

Another major change in the Kali Linux 2019.1 is its release for ARM, which includes the return of support for both Banana Pi and Banana Pro, which are on the 4.19 kernel. In addition, the Raspberry Pi images have been simplified to make it easier to decide which one to use.

“There are no longer separate Raspberry Pi images for users with TFT LCDs because we now include re4son’s kalipi-tft-config script on all of them, so if you want to set up a board with a TFT, run ‘kalipi-tft-config’ and follow the prompts,” the announcement added.

How To Download Kali Linux 2019.1 ISO Files And Torrent Files

In order to update to the latest Kali release, visit the Kali Downloads page where you can find download links for ISOs and Torrents. In addition, you will also find links to the Offensive Security virtual machine and ARM images that have been updated to 2019.1.

How To Update Existing Kali Installation

If you have already installed Kali Linux on your computer, then you can run the following command to upgrade to the new Kali Linux 2019.1 version.

root@kali:~# apt update && apt -y full-upgrade

The post Kali Linux 2019.1 Released, Download Now!!! appeared first on TechWorm.

Security Affairs: PoC Exploit Code for recent container escape flaw in runc published online

The Proof-of-concept (PoC) exploit code for a recently discovered vulnerability in runc tracked as CVE-2019-5736 is now publicly available.

Last week, Aleksa Sarai, a senior software engineer at SUSE Linux GmbH, disclosed a serious vulnerability tracked CVE-2019-5736 affecting runc, the default container runtime for Docker, containerd, Podman, and CRI-O.

The vulnerability was discovered by the security researchers Adam Iwaniuk and Borys Popławski.

Such kind of vulnerabilities could have a significant impact on an IT environment, its exploitation could potentially escape containment, impacting the entire container host, ultimately compromising the hundreds-to-thousands of other containers running on it

The flaw could affect popular cloud platforms, including AWS, Google Cloud, and several Linux distros.

The PoC exploit code for the container escape was published on GitHub, its execution requires root (uid 0) inside the container. 

“This is a Go implementation of CVE-2019-5736, a container escape for Docker. The exploit works by overwriting and executing the host systems runc binary from within the container. ” states the author of the code on Github.

“An attacker would need to get command execution inside a container and start a malicious binary which would listen. When someone (attacker or victim) uses docker exec to get into the container, this will trigger the exploit which will allow code execution as root,”

runc PoC code

The PoC code allows a malicious container to (with minimal user interaction) to overwrite the host runc binary and gain root-level code execution on the host.

The implementation ensures the system will no longer be able to run Docker containers.

you will overwrite your implementation of runc which will ensure your system will no longer be able to run Docker containers. Please backup either /usr/bin/docker-runc or /usr/bin/runc (depending on which you have; also check /usr/sbin).” contin

The expert pointed out that there is a second scenario for the exploitation of the flaw, it involves the use of a malicious Docker image that triggers the exploit, without requiring to exec into the container. 

Docker released the v18.09.2 version to address the issue, but according to the experts, thousands of Docker daemons exposed online are still vulnerable, most of them in the US and China.

Default configurations of Red Hat Enterprise Linux and Red Hat OpenShift are protected, Linux distros Debian and Ubuntu are working to address the issue. Both Google Cloud and AWS published security advisories to recommend customers to update containers on affected services.

VMware also confirmed that its products are impacted, and released patches to address the vulnerability in VMware Integrated OpenStack with Kubernetes (VIO-K), VMware PKS (PKS), VMware vCloud Director Container Service Extension (CSE), and vSphere Integrated Containers (VIC). 

“VMware product updates resolve mishandled file descriptor vulnerability in runc container runtime. Successful exploitation of this issue may allow a malicious container to overwrite the contents of a host’s runc binary and execute arbitrary code,” reads the advisory published by VMware.

Pierluigi Paganini

(SecurityAffairs – runc, hacking)

The post PoC Exploit Code for recent container escape flaw in runc published online appeared first on Security Affairs.



Security Affairs

PoC Exploit Code for recent container escape flaw in runc published online

The Proof-of-concept (PoC) exploit code for a recently discovered vulnerability in runc tracked as CVE-2019-5736 is now publicly available.

Last week, Aleksa Sarai, a senior software engineer at SUSE Linux GmbH, disclosed a serious vulnerability tracked CVE-2019-5736 affecting runc, the default container runtime for Docker, containerd, Podman, and CRI-O.

The vulnerability was discovered by the security researchers Adam Iwaniuk and Borys Popławski.

Such kind of vulnerabilities could have a significant impact on an IT environment, its exploitation could potentially escape containment, impacting the entire container host, ultimately compromising the hundreds-to-thousands of other containers running on it

The flaw could affect popular cloud platforms, including AWS, Google Cloud, and several Linux distros.

The PoC exploit code for the container escape was published on GitHub, its execution requires root (uid 0) inside the container. 

“This is a Go implementation of CVE-2019-5736, a container escape for Docker. The exploit works by overwriting and executing the host systems runc binary from within the container. ” states the author of the code on Github.

“An attacker would need to get command execution inside a container and start a malicious binary which would listen. When someone (attacker or victim) uses docker exec to get into the container, this will trigger the exploit which will allow code execution as root,”

runc PoC code

The PoC code allows a malicious container to (with minimal user interaction) to overwrite the host runc binary and gain root-level code execution on the host.

The implementation ensures the system will no longer be able to run Docker containers.

you will overwrite your implementation of runc which will ensure your system will no longer be able to run Docker containers. Please backup either /usr/bin/docker-runc or /usr/bin/runc (depending on which you have; also check /usr/sbin).” contin

The expert pointed out that there is a second scenario for the exploitation of the flaw, it involves the use of a malicious Docker image that triggers the exploit, without requiring to exec into the container. 

Docker released the v18.09.2 version to address the issue, but according to the experts, thousands of Docker daemons exposed online are still vulnerable, most of them in the US and China.

Default configurations of Red Hat Enterprise Linux and Red Hat OpenShift are protected, Linux distros Debian and Ubuntu are working to address the issue. Both Google Cloud and AWS published security advisories to recommend customers to update containers on affected services.

VMware also confirmed that its products are impacted, and released patches to address the vulnerability in VMware Integrated OpenStack with Kubernetes (VIO-K), VMware PKS (PKS), VMware vCloud Director Container Service Extension (CSE), and vSphere Integrated Containers (VIC). 

“VMware product updates resolve mishandled file descriptor vulnerability in runc container runtime. Successful exploitation of this issue may allow a malicious container to overwrite the contents of a host’s runc binary and execute arbitrary code,” reads the advisory published by VMware.

Pierluigi Paganini

(SecurityAffairs – runc, hacking)

The post PoC Exploit Code for recent container escape flaw in runc published online appeared first on Security Affairs.

Kali Linux 2019.1 Released — Operating System For Hackers

Wohooo! Great news for hackers and penetration testers. Offensive Security has just released Kali Linux 2019.1, the first 2019 version of its Swiss army knife for cybersecurity professionals. The latest version of Kali Linux operating system includes kernel up to version 4.19.13 and patches for numerous bugs, along with many updated software, like Metasploit, theHarvester, DBeaver, and more.

rud.is: Conquering Caffeinated Amazon Athena with the metis Trio of Packages

I must preface this post with the posit that if you’re doing anything interactive() with Amazon Athena you should seriously consider just using their free ODBC drivers as it’s the easiest way to wire them up to R DBI- and tidyverse-wise. I’ve said as much in previous posts. Drop a note in the comments if you don’t know the incantations for repackaging the provided Linux ODBC drivers to work on your flavor of Linux.

However

There are times—say, when you’re trying to stand up an R service in your kubernetes cluster which bridges data in Athena to analyses & visualizations in R—when ODBC drivers can be more of a hindrance than help and JDBC is the path of least resistance.

Sure, there’s the in-CRAN AWR.Athena package but it’s a fairly constrained and low-feature RJDBC shim which gets the basic job done but not much more.

Enter:

a trio of packages which aims to make it super-straightforward to wire up R to Amazon Athena when ODBC is not available.

Why Three Packages?

For starters, there are CRAN hopes for the metis-trio and one key component of that is separating out the JARs into one package (metis.jars) and actual functionality into others (metis and metis.tidy). We’ll see how the CRAN attempt goes since the JAR package weighs in at sufficient weight to warrant a NOTE. The packaging of the driver reduces the need for you to pre-load the JAR (locally or into, say, a Docker image) or perform a package-initiated download-dance like AWR.Athena does (which I still don’t understand why that hasn’t kicked it out of CRAN the way it does it but ¯\_(ツ)_/¯).

metis.jars also has three helper functions which do some (basic) fun things:

library(metis.jars)

simba_driver_version()
## [1] "02.00.06.1008"

athena_supported_types()
##  [1] "BOOLEAN"   "TINYINT"   "SMALLINT"  "INT"       "INTEGER"  
##  [6] "BIGINT"    "REAL"      "FLOAT"     "DOUBLE"    "DECIMAL"  
## [11] "DATE"      "TIMESTAMP" "BINARY"    "VARBINARY" "CHAR"     
## [16] "VARCHAR"   "STRING"    "ARRAY"     "MAP"       "ROW"      
## [21] "STRUCT"   

metis_jar_path()
## [1] "/Library/Frameworks/R.framework/Versions/3.5/Resources/library/metis.jars/java/AthenaJDBC42_2.0.6.jar"

The first uses the rJava interface to directly query the version (since Amazon seems to update the Simba JAR twice a year). By separating out the JAR into a separate package, updates can be made to the other two sibling packages more frequently without crushing CRAN’s disk space. metis.jars is also versioned to the included JAR so configuration management will be easier for folks.

The reason for the second type-lister function is that there’s hope Amazon will add support for all Presto data types, especially IPADDRESS. It, again, performs JDBC driver introspection to collect the supported types.

Finally, the third function abstracts the JAR location from the metis package or even your own interface package should you choose to depend on it.

OK, But Why Not Just Two?

The metis package is a more functional RJDBC superclass of a DBI wrapper than AWR.Athena. One thing it does that its CRAN cousin cannot is handle BIGINTs properly:

library(metis)

dbConnect(
  metis::Athena(),
  Schema = "sampledb",
  AwsCredentialsProviderClass = "com.simba.athena.amazonaws.auth.PropertiesFileCredentialsProvider",
  AwsCredentialsProviderArguments = path.expand("~/.aws/athenaCredentials.props")
) -> con

dbGetQuery(con, "
SELECT
  CAST('chr' AS CHAR(4)) achar,
  CAST('varchr' AS VARCHAR) avarchr,
  CAST(SUBSTR(timestamp, 1, 10) AS DATE) AS tsday,
  CAST(100.1 AS DOUBLE) AS justadbl,
  CAST(127 AS TINYINT) AS asmallint,
  CAST(100 AS INTEGER) AS justanint,
  CAST(100000000000000000 AS BIGINT) AS abigint,
  CAST(('GET' = 'GET') AS BOOLEAN) AS is_get,
  ARRAY[1, 2, 3] AS arr1,
  ARRAY['1', '2, 3', '4'] AS arr2,
  MAP(ARRAY['foo', 'bar'], ARRAY[1, 2]) AS mp,
  CAST(ROW(1, 2.0) AS ROW(x BIGINT, y DOUBLE)) AS rw,
  CAST('{\"a\":1}' AS JSON) js
FROM elb_logs
LIMIT 1
") %>% 
  dplyr::glimpse()
## Observations: 1
## Variables: 13
## $ achar     <chr> "chr "
## $ avarchr   <chr> "varchr"
## $ tsday     <date> 2014-09-29
## $ justadbl  <dbl> 100.1
## $ asmallint <int> 127
## $ justanint <int> 100
## $ abigint   <S3: integer64> 100000000000000000
## $ is_get    <lgl> TRUE
## $ arr1      <chr> "1, 2, 3"
## $ arr2      <chr> "1, 2, 3, 4"
## $ mp        <chr> "{bar=2, foo=1}"
## $ rw        <chr> "{x=1, y=2.0}"
## $ js        <chr> "\"{\\\"a\\\":1}\""

PrestoAthena arrays and maps and rows and JSON come across as characters from the Athena driver and they’re formatted so badly that there’s little hope of full R support for list columns for them. But, you do get real, big integers with metis along with full support for all other current Athena types.

R folk who may be users of the old, standalone metis package need to be aware of some things.

First, dbConnect() has breaking changes. The snake_case names that still exist in the higher-level athena_jdbc() function are gone. In exchange for this pain, you now have full naming-parity with all the Athena JDBC connection properties and can more easily use alternate credential providers which metis‘ cousin totally cannot do for you which is illustrated in the example above and in the package README.

The metis package also makes it easier to see documentation for all available Athena connection properties since it has a vignette with a descriptive table of all of them (rendered here).

There is also nascent support for the “streaming API” (TLDR: faster result set downloads) but that won’t be fully tested until some AWS policy tweaks happen this week.

Gotcha. But, Why Not Just Two?

As awesome as it is (including base Docker image support) the tidyverse is not without overhead in terms of compilation time and dependencies, both of which are especially painful on Linux systems and some Docker environments. You can absolutely get by with some well-crafted SQL and JDBC and the thinner the image the easier it is to deploy and scale.

But! The tidyverse is so helpful that ensuring smooth support for Athena is critical. On its own, metis wires up to dplyr/dbplyr fine, but by providing (in metis.tidy) some enhanced db_data_type() support (primarily for BIGINT) and some extra 💙 in sql_translate_env() )for those of us who continue to mindlessly use R-only verbs like grep() or as.POSIXct() in non-R contexts) we can level-up interactive() use and tidyverse-infused service use:

library(metis.tidy)
library(dbplyr)
library(dplyr)

metis::dbConnect(
  metis::Athena(),
  Schema = "sampledb",
  AwsCredentialsProviderClass = "com.simba.athena.amazonaws.auth.PropertiesFileCredentialsProvider",
  AwsCredentialsProviderArguments = path.expand("~/.aws/athenaCredentials.props")
) -> con

elb_logs <- tbl(con, "elb_logs")

filter(elb_logs, grepl("20", elbresponsecode)) %>%
  mutate(
    tsday = as.Date(substring(timestamp, 1L, 10L)),
    host = url_extract_host(url),
    proto_version = regexp_extract(protocol, "([[:digit:]\\.]+)"),
  ) %>%
  select(tsday, host, receivedbytes, requestprocessingtime, proto_version) %>%
  head(1) %>%
  glimpse()
## Observations: ??
## Variables: 5
## Database: AthenaConnection
## $ tsday                 <date> 2014-09-29
## $ host                  <chr> "www.abcxyz.com"
## $ receivedbytes         <S3: integer64> 0
## $ requestprocessingtime <dbl> 9.5e-05
## $ proto_version         <chr> "1.1"

FIN

A fairly big impetus for this radical refactoring was the need to use the Athena JDBC interface in R at $DAYJOB in a serverless context. So, if I/we needed it, others may as well. All three packages have tests (that work with my personal Athena setup which is easily replicated since it’s just the default schema & table you get when you enable Athena), pass CRAN checks and will be live in a real production environment by the time you read this.

Note that I do have CRAN plans for these three amigos, but all three packages will need to go in at the same time and I need to get tests into- and prove tests are live in Travis before submitting. Now’s the time for feature requests, problem reports or issues. Until SourceHut’s (sr.ht) API is finished, said contributions are best left to GitLab (preferably) or GitHub (if you must continue to fill the coffers of giant multional companies that undermine your freedom).

POSTSCRIPT

One other reason for re-visiting metis was this R-crashing rJava issue that is really a Simba Athena implementation issue (OS signals in a JDBC driver, rly?)

This Rprofile entry:

options(
  "java.parameters" = c(getOption("java.parameters", default = NULL), "-Xrs")
)

has been a solid workaround until rJava is updated. Note that metis.jars warns about this on load if it detects your setup is at risk.



rud.is

Windows 10 will soon allow you to access your Linux files

Windows Subsystem for Linux update will allow you to access Linux files from Windows 10

Microsoft yesterday announced in a blog post that Windows 10’s April 2019 Update will bring in some new features to the Windows Subsystem for Linux (WSL) in version 1903. The changelog for build 18836 has also been updated to reflect the changes.

In the past, one couldn’t launch Windows applications from a Linux terminal. But now you can easily access all the files in your Linux distros from Windows. All you need to do is open your favorite distro, and type in explorer.exe. This will open a File Explorer window, located inside of your Linux distro.

“From here you can access whatever Linux files you would like, just like you would any other file through File Explorer. This includes operations such as: dragging files back and forth to other locations, copy and paste, and even interesting scenarios like using the context menu to open VSCode in a WSL directory!” reads the blogpost.

Currently, the path will look something like \\wsl$\<running_distro_name>\. Microsoft’s Craig Loewen says developers are “actively investigating ways to improve the discoverability of your Linux files inside of File Explorer” in the future.

Since this is a new feature, there are some known issues such as your Linux distro needs to be running for you to access the files. However, that may change in a future update. Further, Linux files is treated the same as accessing a network resource, which means any rules for accessing network resources will still apply. Lastly, Microsoft warns that you should not access your Linux files inside of the AppData folder.

Microsoft has also made some improvements to the command line by consolidating their commands to wsl.exe and adding more command line functionality. The tech giant has also added some new commands that will give you more functionality when using wsl.exe. You can now run commands as different users, terminate running distributions, and even export and import different distros!

You can read more about the latest changes to the WSL here.

The post Windows 10 will soon allow you to access your Linux files appeared first on TechWorm.

You can now install Linux on Windows 10 ARM laptops

This Open Source Project Allows To Run Linux On Windows 10 ARM Laptops

Back in December 2016, Microsoft had announced a partnership with Qualcomm to create Windows 10 on ARM, a new operating system that runs Windows 10 on ARM-based processors, that was later released in December 2017.

The Asus NovaGo convertible laptop, the HP Envy x2 2-in-1 tablet, and the Lenovo Miix 630 2-in-1 tablet were some of the first laptops that came with Windows 10 on ARM architecture running on the Qualcomm Snapdragon 835 chip. Since their launch, these devices were greeted with mixed reviews for being slow, its poor performance and app incompatibilities around the ‘x86’ emulator.

Now, the folks behind the AArch64 Laptops have come up with a way to install Ubuntu 18.04 LTS on ARM-running laptops. The open-source project page on GitHub mentions that the pre-built images are currently available for the Asus NovaGo, HP Envy x2, and Lenovo Mixx 630.

In order to run Ubuntu on the above-mentioned devices, the pre-built images need to be first downloaded on to an SD card via the supplied Flash Tool, then the SD card needs to be put into a computer to run Ubuntu instead of Windows. The current status of these AArch64 Linux images can be found here.

However, the project currently has certain limitations. For instance, in the case of Asus, Touchpad input is not yet functional, so one has to plug a mouse into a USB port and use that instead. Also, Wi-Fi isn’t working on all the devices under Linux. In addition, there are some problems related to hardware accelerated graphics support and inaccessibility to onboard storage.

Meanwhile, AArch64 Laptops project say upstream Linux kernel work could soon resolve Wi-Fi and other issues. Additionally, accelerated graphics could be taken care of by using the work of the Freedreno project, notes Linux benchmarking website Phoronix.

Once the said problems are resolved, Windows 10 on ARM laptops running on Linux could turn out to be great high-performance devices than on Windows.

Are you excited to see Windows 10 on ARM laptops run Linux? Do let us know your thoughts in the comments section mentioned below.

The post You can now install Linux on Windows 10 ARM laptops appeared first on TechWorm.

Snapd Flaw Lets Attackers Gain Root Access On Linux Systems

Ubuntu and some other Linux distributions suffer from a severe privilege escalation vulnerability that could allow a local attacker or a malicious program to obtain root privileges and total control over the targeted system. Dubbed "Dirty_Sock" and identified as CVE-2019-7304, the vulnerability was discovered by security researcher Chris Moberly, who privately disclosed it to Canonical, the

Snapd flaw gives attackers root access on Linux systems

A vulnerability affecting Snapd – a package installed by default in Ubuntu and used by other Linux distributions such as Debian, OpenSUSE, Arch Linux, Fedora and Solus – may allow a local attacker to obtain administrator privileges, i.e., root access and total control of the system. About Snapd Snapd is a service used to deliver, update and manage apps (in the form of snap packages) on Linux distributions. “This service is installed automatically in Ubuntu … More

The post Snapd flaw gives attackers root access on Linux systems appeared first on Help Net Security.

RunC container escape flaw enables root access to host system

A serious vulnerability in runC, a widely used CLI tool for spawning and running containers, could be exploited to compromise the runC host binary from inside a privileged runC container, allowing the attacker to gain root access on the underlying host system. RunC is the container runtime underneath infrastructure and engines such as Docker, CRI-O, containerd, Kubernetes, etc. About the vulnerability (CVE-2019-5736) CVE-2019-5736 was reported by researchers Adam Iwaniuk and Borys Popławski to runC maintainers, … More

The post RunC container escape flaw enables root access to host system appeared first on Help Net Security.

New cryptomining malware removes other malware from Linux, then latches onto systems

A script capable of deleting known Linux malware and coin mining software in systems has been discovered by Trend Micro.  It then downloads a cryptocurrency-mining malware as well as install

The post New cryptomining malware removes other malware from Linux, then latches onto systems appeared first on The Cyber Security Place.

RunC Flaw Lets Attackers Escape Linux Containers to Gain Root on Hosts

A serious security vulnerability has been discovered in the core runC container code that affects several open-source container management systems, potentially allowing attackers to escape Linux container and obtain unauthorized, root-level access to the host operating system. The vulnerability, identified as CVE-2019-5736, was discovered by open source security researchers Adam Iwaniuk and

Docker runc flaw opens the door to a ‘Doomsday scenario’

Security experts found a serious flaw tracked CVE-2019-5736 affecting runc, the default container runtime for Docker, containerd, Podman, and CRI-O.

Aleksa Sarai, a senior software engineer at SUSE Linux GmbH, has disclosed a serious vulnerability tracked CVE-2019-5736 affecting runc, the default container runtime for Docker, containerd, Podman, and CRI-O.

The vulnerability was discovered by the security researchers Adam Iwaniuk and Borys Popławski.

Such kind of vulnerabilities could have a significant impact on an IT environment, its exploitation could potentially escape containment, impacting the entire container host, ultimately compromising the hundreds-to-thousands of other containers running on it

“The disclosure of a security flaw (CVE-2019-5736) in runc and docker illustrates a bad scenario for many IT administrators, managers, and CxOs.” reads a blog post. published by Red Hat.

“While there are very few incidents that could qualify as a doomsday scenario for enterprise IT, a cascading set of exploits affecting a wide range of interconnected production systems qualifies…and that’s exactly what this vulnerability represents,”

“The vulnerability allows a malicious container to (with minimal user interaction) overwrite the host runc binary and thus gain root-level code execution on the host.” Sarai wrote in a post to the OpenWall mailing list.

“The level of user interaction is being able to run any command (it doesn’t matter if the command is not attacker-controlled) as root within a container in either of these contexts:

  • Creating a new container using an attacker-controlled image.
  • Attaching (docker exec) into an existing container which the attacker had previous write access to.”

Sarai, which is one of the maintainers of runc, has pushed a git commit to address the vulnerability, but all the project built on runc need to include the changes.

Docker released the v18.09.2 version to address the issue, but according to the experts, thousands of Docker daemons exposed online are still vulnerable, most of them in the US and China.

runc dockers

Default configurations of Red Hat Enterprise Linux and Red Hat OpenShift are protected, Linux distros Debian and Ubuntu are working to address the issue. Both Google Cloud and AWS published security advisories to recommend customers to update containers on affected services.

Pierluigi Paganini

(SecurityAffairs – runc, hacking)

.

The post Docker runc flaw opens the door to a ‘Doomsday scenario’ appeared first on Security Affairs.

New Linux Crypto-Mining Malware Kills Other Malicious Miners Upon Installation

Security analysts identified a sample of Linux crypto-mining malware that kills any other malicious miners upon installation.

Trend Micro researchers discovered the malware while doing a routine log check after spotting a script within one of their honeypots that began downloading a binary connected to a domain. This binary turned out to be a modified version of the cryptocurrency miner XMR-Stak.

The script didn’t stop at downloading this sample of Linux malware, which Trend Micro detected as Coinminer.Linux.MALXMR.UWEIU. It removed other crypto-mining malware and related services affecting the machine at the time of infection. The malware also created new directories and files and stopped processes that shared connections with known IP addresses.

A Likeness to Other Threats

In their analysis of Coinminer.Linux.MALXMR.UWEIU, Trend Micro found that the malware’s script shares certain attributes with other threats it previously detected. Specifically, researchers observed similarities between this malicious coin miner and Xbash, a malware family discovered by Trend Micro in September 2018 that combines ransomware, cryptocurrency mining, worm and scanner capabilities in its attacks against Linux and Windows servers.

Researchers also noted that the threat’s code is nearly identical to that of KORKERDS, crypto-mining malware Trend Micro uncovered back in November 2018. There are a few differences, however.

The new script simplified the routine by which KORKERDS downloads and executes files and loads the Linux coin malware sample. It also didn’t uninstall security solutions from or install a rootkit on the infected machine. In fact, the script’s kill list targeted both KORKERDS and its rootkit component. This move suggests that those who coded the script are attempting to maximize their profits while competing with the authors of KORKERDS.

Strengthen Your Crypto-Mining Malware Defenses

Security professionals can help defend against Linux crypto-mining malware by using an endpoint management and security platform capable of monitoring endpoints for suspicious behavior. Organizations should also leverage security information and event management (SIEM) tools that can notify security teams of high central processing unit (CPU) and graphics processing unit (GPU) usage — key indicators of cryptocurrency mining activities — during nonbusiness hours.

The post New Linux Crypto-Mining Malware Kills Other Malicious Miners Upon Installation appeared first on Security Intelligence.

New Linux coin miner kills competing malware to maximize profits

Security experts from Trend Micro have discovered a new strain of coin miner that targets the Linux platform and installs the XMR-Stak Cryptonight cryptocurrency miner.

Security experts from Trend Micro have discovered a new strain of coin miner that targets the Linux platform and installs the XMR-Stak Cryptonight cryptocurrency miner, researchers observed it killing other Linux malware and coin miners present on the infected machine.

coin miner linux-deletes-other-malware_1

The experts detected a coinminer script on one of their honeypots and, the malicious code shares some parts with the Xbash malware and the KORKERDS cryptocurrency miner that leverages rootkit to avoid detection.

“We found the script capable of deleting a number of known Linux malware, coin miners, and connections to other miner services and ports, and we observed some parts of the script to be reminiscent of Xbash features and KORKERDS.” reads the analysis published by Trend Micro.

“It installs a cryptocurrency-mining malware as well as implant itself into the system and crontabs to survive reboots and deletions.”

Experts noticed that this specific variant of KORKERDS leverages the rootkit to download a binary of a modified version of a universal Stratum XMR-Stak pool miner.

According to the experts, the infection started from some IP cameras and web services via TCP port 8161, where the attacker attempts to upload a crontab file.

The crontab file allows to launch a second stage that implements the following three functions:

  • Function B kills previously installed malware, coin miners, and all related services referenced to an accompanying malware (detected by Trend Micro as SH.MALXMR.UWEIU). It also creates new directories, files, and stop processes with connections to identified IP addresses.
  • Function D downloads the coin miner binary from hxxp://yxarsh.shop/64 and runs it.
  • Function C downloads a script from hxxp://yxarsh.shop/0, saves it to /usr/local/bin/dns file, and creates a new crontab to call this script at 1 a.m. It also downloads hxxp://yxarsh.shop/1.jpg and puts it in different crontabs.

The malware attempts to hide its presence by clearing system logs and achieve persistence using implanted crontab files.

Compared to the original KORKERDS cryptocurrency miner, the new script improved the way it downloads and executes the files. It inserts a single crontab that fetches all the code and the miner component.

“While a malware routine that includes the removal of other malware in the system is not new, we’ve never seen the removal of Linux malware from the system on this scale. Removing competing malware is just one way cybercriminals are maximizing their profit.” concludes Trend Micro.

Further details, including indicators of compromise, are reported in the analysis published by Trend Micro.

Pierluigi Paganini

(SecurityAffairs – coin miner, malware)

The post New Linux coin miner kills competing malware to maximize profits appeared first on Security Affairs.

Security Affairs: New Linux coin miner kills competing malware to maximize profits

Security experts from Trend Micro have discovered a new strain of coin miner that targets the Linux platform and installs the XMR-Stak Cryptonight cryptocurrency miner.

Security experts from Trend Micro have discovered a new strain of coin miner that targets the Linux platform and installs the XMR-Stak Cryptonight cryptocurrency miner, researchers observed it killing other Linux malware and coin miners present on the infected machine.

coin miner linux-deletes-other-malware_1

The experts detected a coinminer script on one of their honeypots and, the malicious code shares some parts with the Xbash malware and the KORKERDS cryptocurrency miner that leverages rootkit to avoid detection.

“We found the script capable of deleting a number of known Linux malware, coin miners, and connections to other miner services and ports, and we observed some parts of the script to be reminiscent of Xbash features and KORKERDS.” reads the analysis published by Trend Micro.

“It installs a cryptocurrency-mining malware as well as implant itself into the system and crontabs to survive reboots and deletions.”

Experts noticed that this specific variant of KORKERDS leverages the rootkit to download a binary of a modified version of a universal Stratum XMR-Stak pool miner.

According to the experts, the infection started from some IP cameras and web services via TCP port 8161, where the attacker attempts to upload a crontab file.

The crontab file allows to launch a second stage that implements the following three functions:

  • Function B kills previously installed malware, coin miners, and all related services referenced to an accompanying malware (detected by Trend Micro as SH.MALXMR.UWEIU). It also creates new directories, files, and stop processes with connections to identified IP addresses.
  • Function D downloads the coin miner binary from hxxp://yxarsh.shop/64 and runs it.
  • Function C downloads a script from hxxp://yxarsh.shop/0, saves it to /usr/local/bin/dns file, and creates a new crontab to call this script at 1 a.m. It also downloads hxxp://yxarsh.shop/1.jpg and puts it in different crontabs.

The malware attempts to hide its presence by clearing system logs and achieve persistence using implanted crontab files.

Compared to the original KORKERDS cryptocurrency miner, the new script improved the way it downloads and executes the files. It inserts a single crontab that fetches all the code and the miner component.

“While a malware routine that includes the removal of other malware in the system is not new, we’ve never seen the removal of Linux malware from the system on this scale. Removing competing malware is just one way cybercriminals are maximizing their profit.” concludes Trend Micro.

Further details, including indicators of compromise, are reported in the analysis published by Trend Micro.

Pierluigi Paganini

(SecurityAffairs – coin miner, malware)

The post New Linux coin miner kills competing malware to maximize profits appeared first on Security Affairs.



Security Affairs

New Linux Backdoor “SpeakUp” Found Exploiting Flaws In Multiple Linux Distros

Researchers have discovered a new Trojan campaign that creates a Linux backdoor. Referred to as SpeakUp, the backdoor malware exploits

New Linux Backdoor “SpeakUp” Found Exploiting Flaws In Multiple Linux Distros on Latest Hacking News.

Flaws in RDP protocols leaving machines prone to remote code execution

By Waqas

Major Security Flaws Identified in RDP Protocols making Machines Prone to Remote Code Execution and Reverse RDP Attacks. Check Point researchers have identified that three remote desktop protocol (RDP) tools, which are probably the most popular ones for Windows, macOS, and Linux systems, are plagued with not one or two but twenty-five CVE-listed security flaws. […]

This is a post from HackRead.com Read the original post: Flaws in RDP protocols leaving machines prone to remote code execution

Speak Up Malware Targets Linux, Mac in New Campaign

Linux servers are the target of a new crypto-mining campaign in which a malware dubbed “Speak Up” implants a backdoor Trojan by exploiting known vulnerabilities in six different Linux distributions, according

The post Speak Up Malware Targets Linux, Mac in New Campaign appeared first on The Cyber Security Place.

Attack Campaign Targets Linux Servers to Install New SpeakUp Trojan

Security researchers observed an attack campaign that is targeting Linux servers to install samples of SpeakUp, a new backdoor Trojan.

According to Check Point Research, the campaign is currently targeting servers in East Asia and Latin America. The attack begins with the exploitation of CVE-2018-20062, a reported vulnerability affecting ThinkPHP. The campaign then uses command injection techniques to upload a PHP shell, which is responsible for delivering and executing the SpeakUp Trojan as a Perl backdoor.

Upon execution, SpeakUp continuously communicates with its command and control (C&C) server to receive a variety of instructions. It can use the newtask command to execute arbitrary code or execute a file from a remote server, for example. This ability enables SpeakUp to deliver additional backdoors, each of which comes equipped with a Python script designed to scan and infect more Linux servers within its internal and external subnets.

Furthermore, the Trojan can leverage the newconfig command to update the configuration file for XMRig, a cryptocurrency miner that it serves to listening infected servers.

Linux Servers Under Attack

SpeakUp isn’t the only malware targeting Linux servers. On the contrary, these IT assets are under attack from a range of malicious software.

In December 2018, Slovakian security firm ESET identified 21 Linux malware families that serve as OpenSSH backdoors. Around the same time, Anomali Labs unveiled its discovery of Linux Rabbit and Rabbot, two malware families served by a campaign targeting Linux servers in Russia, South Korea, the U.K. and the U.S. that are both capable of installing crypto-miners.

Also in December, Bleeping Computer learned of a new campaign that had leveraged unsecured Intelligent Platform Management Interface (IPMI) cards to infect Linux servers with JungleSec ransomware.

How to Defend Against the SpeakUp Trojan

Security professionals can help defend against malware like SpeakUp by utilizing a unified endpoint management (UEM) tool to monitor assets such as Linux servers for malicious activity. Experts also recommend practicing timely patch management to defend endpoints against cryptocurrency miners, and investing in education and role-based training to help cultivate a security-aware workforce.

The post Attack Campaign Targets Linux Servers to Install New SpeakUp Trojan appeared first on Security Intelligence.

New cryptocurrency malware SpeakUp hits Linux & Mac devices

By Waqas

The IT security researchers at Check Point have identified a new malware called SpeakUp targeting Linux and macOS – The new findings prove that there has been a surge in malware attacks against Linux and Apple devices. SpeakUp is a new backdoor Trojan that is being distributed by cybercriminals through a malicious new campaign designed […]

This is a post from HackRead.com Read the original post: New cryptocurrency malware SpeakUp hits Linux & Mac devices

Canonical Updates Ubuntu 18.04 While Patching Numerous Other Security Flaws

Canonical has released updates for Ubuntu 18.04. The updates include patches for numerous security vulnerabilities in the Linux Kernel. Ubuntu

Canonical Updates Ubuntu 18.04 While Patching Numerous Other Security Flaws on Latest Hacking News.

Security Affairs: Researchers published the PoC exploit code for Linux SystemD bugs

Security researchers at the security firm Capsule8 have published exploit code for the vulnerabilities in Linux systemD disclosed in January.Security researchers at the security firm Capsule8 have published exploit code for the vulnerabilities in Linux systemD disclosed in January.

Early this month, security firm Qualys disclosed three flaws (CVE-2018-16864, CVE-2018-16865, and CVE-2018-16866 ) in a component of systemd, a software suite that provides fundamental building blocks for a Linux operating system used in most major Linux distributions.

The flaws reside in the systemd–journald, a service of the systemd that collects and stores logging data.

Both CVE-2018-16864 and CVE-2018-16865 bugs are memory corruption vulnerabilities, while the CVE-2018-16866 is an out of bounds issue that can lead to an information leak. Qualys experts were working on an exploit for another Linux vulnerability when noticed that passing several megabytes of command-line arguments to a program that calls syslog(), they were able to crash the systemd–journald.

The experts developed a PoC exploit for both CVE-2018-16865 and CVE-2018-16866 that is able to obtain a local root shell in 10 minutes on i386 and 70 minutes on amd64, on average. 

linux systemd

In an attack scenario against a Linux box, the CVE-2018-16864 can be exploited by a malicious code or an ill-intentioned logged-in user, to crash and hijack the systemd–journald system service, and elevated access previleges. The chaining of the CVE-2018-16865 and CVE-2018-16866 could allow a local attacker to crash or hijack the root-privileged journal service.

If you haven’t already applied the patches your system, now you have a good reason to do it because experts at security firm Capsule8 have published exploit code for the flaws.

The exploit code was rendered harmless and shouldn’t work for massive attacks in the wild. However, security experts may devise ways to bypass security protections of Linux installs.

Nick Gregory, security research at Capsule8, published a blog post that revealed that his company has developed a proof-of-concept exploit for the above vulnerabilities.

“As Qualys did not provide exploit code, we developed a proof-of-concept exploit for our own testing and verification.” reads the post published by
Gregory.

“There are some interesting aspects that were not covered by Qualys’ initial publication, such as how to communicate with the affected service to reach the vulnerable component, and how to control the computed hash value that is actually used to corrupt memory,”

The Python exploit script written by the expert targets the 20180808.0.0 release of the ubuntu/bionic64 Vagrant image when the address space layout randomization (ASLR) is disabled (an uncommon condition for production environment).

The script triggers the CVE-2018-16865 flaw via the alloca() function, the expert uses it to allocate a specified number of bytes of memory space in the stack frame of the caller and manipulate the stack pointer.

“Our general approach for exploiting this vulnerability is to initially send the right size and count of entries, so as to make the stack pointer point to libc’s BSS memory region , and then surgically overwrite the free_hook function pointer with a pointer to system.” continues the researcher.

“This grants us arbitrary command execution upon the freeing of memory with content we control.”

The exploitation of the flaws requires controlling all 64 bits of output that the hash function produces, but it is very hard to pre-image that hash.

Even if there are some tools to calculate exact preimages in a few seconds, but for the PoC the experts used a pre-computed hash for the Vagrant image.

To use the same PoC exploit code with other Linux distros it is necessary to calculate the hash, experts at Capsulate8 will details possibility in a follow-up post.

“As the first in our series on this topic, the objective of this post is to provide the reader with the ability to write a proof-of-concept capable of exploiting the service with Address Space Layout Randomization (ASLR) disabled. In the interest of not posting an unreadably-long blog, and also not handing sharp objects to script-kiddies before the community has had chance to patch, we are saving some elements for discussion in future posts in this series, including details on how to control the key computed hash value.” concludes the expert.

“We are also considering providing a full ASLR bypass, but are weighing whether we are lowering the bar too much for the kiddies,”

Pierluigi Paganini

(SecurityAffairs – Linux, systemd )

The post Researchers published the PoC exploit code for Linux SystemD bugs appeared first on Security Affairs.



Security Affairs

Researchers published the PoC exploit code for Linux SystemD bugs

Security researchers at the security firm Capsule8 have published exploit code for the vulnerabilities in Linux systemD disclosed in January.Security researchers at the security firm Capsule8 have published exploit code for the vulnerabilities in Linux systemD disclosed in January.

Early this month, security firm Qualys disclosed three flaws (CVE-2018-16864, CVE-2018-16865, and CVE-2018-16866 ) in a component of systemd, a software suite that provides fundamental building blocks for a Linux operating system used in most major Linux distributions.

The flaws reside in the systemd–journald, a service of the systemd that collects and stores logging data.

Both CVE-2018-16864 and CVE-2018-16865 bugs are memory corruption vulnerabilities, while the CVE-2018-16866 is an out of bounds issue that can lead to an information leak. Qualys experts were working on an exploit for another Linux vulnerability when noticed that passing several megabytes of command-line arguments to a program that calls syslog(), they were able to crash the systemd–journald.

The experts developed a PoC exploit for both CVE-2018-16865 and CVE-2018-16866 that is able to obtain a local root shell in 10 minutes on i386 and 70 minutes on amd64, on average. 

linux systemd

In an attack scenario against a Linux box, the CVE-2018-16864 can be exploited by a malicious code or an ill-intentioned logged-in user, to crash and hijack the systemd–journald system service, and elevated access previleges. The chaining of the CVE-2018-16865 and CVE-2018-16866 could allow a local attacker to crash or hijack the root-privileged journal service.

If you haven’t already applied the patches your system, now you have a good reason to do it because experts at security firm Capsule8 have published exploit code for the flaws.

The exploit code was rendered harmless and shouldn’t work for massive attacks in the wild. However, security experts may devise ways to bypass security protections of Linux installs.

Nick Gregory, security research at Capsule8, published a blog post that revealed that his company has developed a proof-of-concept exploit for the above vulnerabilities.

“As Qualys did not provide exploit code, we developed a proof-of-concept exploit for our own testing and verification.” reads the post published by
Gregory.

“There are some interesting aspects that were not covered by Qualys’ initial publication, such as how to communicate with the affected service to reach the vulnerable component, and how to control the computed hash value that is actually used to corrupt memory,”

The Python exploit script written by the expert targets the 20180808.0.0 release of the ubuntu/bionic64 Vagrant image when the address space layout randomization (ASLR) is disabled (an uncommon condition for production environment).

The script triggers the CVE-2018-16865 flaw via the alloca() function, the expert uses it to allocate a specified number of bytes of memory space in the stack frame of the caller and manipulate the stack pointer.

“Our general approach for exploiting this vulnerability is to initially send the right size and count of entries, so as to make the stack pointer point to libc’s BSS memory region , and then surgically overwrite the free_hook function pointer with a pointer to system.” continues the researcher.

“This grants us arbitrary command execution upon the freeing of memory with content we control.”

The exploitation of the flaws requires controlling all 64 bits of output that the hash function produces, but it is very hard to pre-image that hash.

Even if there are some tools to calculate exact preimages in a few seconds, but for the PoC the experts used a pre-computed hash for the Vagrant image.

To use the same PoC exploit code with other Linux distros it is necessary to calculate the hash, experts at Capsulate8 will details possibility in a follow-up post.

“As the first in our series on this topic, the objective of this post is to provide the reader with the ability to write a proof-of-concept capable of exploiting the service with Address Space Layout Randomization (ASLR) disabled. In the interest of not posting an unreadably-long blog, and also not handing sharp objects to script-kiddies before the community has had chance to patch, we are saving some elements for discussion in future posts in this series, including details on how to control the key computed hash value.” concludes the expert.

“We are also considering providing a full ASLR bypass, but are weighing whether we are lowering the bar too much for the kiddies,”

Pierluigi Paganini

(SecurityAffairs – Linux, systemd )

The post Researchers published the PoC exploit code for Linux SystemD bugs appeared first on Security Affairs.

Vulnerable cloud infrastructure experiencing increasing attacks

Attackers are increasingly targeting vulnerable cloud infrastructure to exploit it for covert cryptojacking or to deliver ransomware, Securonix researchers warn. Some attacks are fairly trivial, but others are multi-vector/multi-platform threats where multiple functionalities are combined as part of the same malicious threat (e.g., XBash, which combines cryptomining, ransomware and botnet/worm activity). The way in The attacks are automated and probe the infrastructure and cloud services for vulnerabilities and/or weak or default login credentials. Among the … More

The post Vulnerable cloud infrastructure experiencing increasing attacks appeared first on Help Net Security.

Critical flaw in Linux APT package manager could allow remote hack

Expert discovered a remote code execution vulnerability in the APT package manager used by several Linux distributions, including Debian and Ubuntu.

The independent security consultant Max Justicz has discovered a remote code execution vulnerability in the APT package manager used by several Linux distributions, including Debian and Ubuntu.

The flaw, tracked as CVE-2019-3462, affects package manager version 0.8.15 and later, it could be exploited by an attacker in a MiTM position to execute arbitrary code as root on a machine and install any package.

“I found a vulnerability in apt that allows a network man-in-the-middle (or a malicious package mirror) to execute arbitrary code as root on a machine installing any package.” reads a blog post published by
Justicz.

“The bug has been fixed in the latest versions of apt. If you’re worried about being exploited during the update process, you can protect yourself by disabling HTTP redirects while you update.”

Vulnerable versions of APT fail in sanitizing certain parameters during HTTP redirects and a remote man-in-the-middle attacker could to inject malicious content and trick the system into installing tainted packages.

While using apt-get command, HTTP redirects allow Linux systems to automatically request packages from a mirror server when others are unavailable. When the first server is not able to provide the package, it respond by providing the next suitable server.

“The code handling HTTP redirects in the HTTP transport method doesn’t properly sanitize fields transmitted over the wire. This vulnerability could be used by an attacker located as a man-in-the-middle between APT and a mirror to inject malicious content in the HTTP connection.” reads the Debian Security Advisory “This content could then be recognized as a valid package by APT and used later for code execution with root privileges on the target machine.”

The expert published a video PoC that shows an attacker intercepting HTTP traffic between APT package manager and a mirror server, or a rogue mirror, and replace the legitimate package with a malicious one.

https://justi.cz/assets/aptpoc.mp4

According to Justicz, the flaw could affect all package downloads, including packages installed by the user for the first time.

Linux APT package manager

In order to mitigate this flaw, it is possible to implement HTTPS that could prevent exploitation of the vulnerability.

“Supporting http is fine. I just think it’s worth making https repositories the default – the safer default – and allowing users to downgrade their security at a later time if they choose to do so. I wouldn’t have been able to exploit the Dockerfile at the top of this post if the default package servers had been using https.” wrote the expert.

APT maintainers quickly patched the CVE-2019-3462 vulnerability with the release of version 1.4.9, Linux users must update their systems as soon as possible.

Pierluigi Paganini

(SecurityAffairs – Linux distribution, APT package manager)

The post Critical flaw in Linux APT package manager could allow remote hack appeared first on Security Affairs.

Critical RCE Flaw in Linux APT Allows Remote Attackers to Hack Systems

Just in time… Some cybersecurity experts this week arguing over Twitter in favor of not using HTTPS and suggesting software developers to only rely on signature-based package verification, just because APT on Linux also does the same. Ironically, a security researcher just today revealed details of a new critical remote code execution flaw in the apt-get utility that can be exploited by a

Monero Price Analysis: Stronger Malware to Mine Monero; XMR/USD Has Room for Another Potential Squeeze South

Researchers: a stronger malware has been uncovered, which can mine Monero. XMR/USD price action remains stuck in a narrowing range, subject to an imminent breakout. The XMR/USD price has seen some upside on Saturday, holding gains of around 3% towards the latter stages of the day. Despite the press higher from the bulls, a move […]

The post Monero Price Analysis: Stronger Malware to Mine Monero; XMR/USD Has Room for Another Potential Squeeze South appeared first on Hacked: Hacking Finance.

36-Year-Old SCP Clients’ Implementation Flaws Discovered

A set of 36-year-old vulnerabilities has been uncovered in the Secure Copy Protocol (SCP) implementation of many client applications that can be exploited by malicious servers to overwrite arbitrary files in the SCP client target directory unauthorizedly. Session Control Protocol (SCP), also known as secure copy, is a network protocol that allows users to securely transfer files between a

Howto install Bitwarden in a LXC container (e.g. Proxmox)

As many of you know me, I’m quite serious about security and therefore a believer in the theory that a service which is not reachable (e.g. from the Internet) cannot be attacked as easily as one that it. Looking at password managers this makes choosing not that easy. Sure there is Keepass and the descendants, but they have the problem that the security is based solely on the master password and the end device security. Knowing friends that use Google Drive for syncing the password file between their devices, I looked at that option, but it was not right for me (e.g. Browser integration, 2FA, …).

Password managers like Lastpass or 1Password are also not the right solution for me. Yes, I believe that their crypto is good, and they never see the passwords of their users, but the 2FA is only as good as the lost password/2FA reset feature is. I’ve read and seen to many attacks on that to rely on it.

All of this leads to Bitwarden, it provides the same level of functionality as Lastpass or 1Password but is OpenSource and can be hosted on my own server. Not opening it up to Internet and using it from remote only via VPN (which I have anyway) make for a real small attack surface. This blog post shows how I installed it within a Proxmox LXC container, which I did to isolated it from other stuff and therefore there are no dependencies, if I need to upgrade something. I don’t like to install anything on the Proxmox host itself. As this is my first try, and I run into a problem with an unprivileged container and docker within it, this setup works currently only with a privileged container. I know this is not that good, but in this case it is a risk I can accept. If you find a solution to get it running in an unprivileged container please send me an email or write a comment.

LXC container

After creating the LXC container (2Gb RAM, >5GB HD) with Debian 9, don’t start the container at once. You need to add following to /etc/modules-load.d/modules.conf

aufs
overlay

And if you don’t want to boot load the modules with

modprobe aufs
modprobe overlay

If you don’t do this your installation will get gigantic (over 30gb). Now we just need to add following to /etc/pve/lxc/<vid>.conf

#insert docker part below
lxc.apparmor.profile: unconfined
lxc.cgroup.devices.allow: a
lxc.cap.drop:

Now you can start the container and enter it, we’ll check later if all was correct, but we need docker for this.

Docker and Docker Composer

Some requirements for docker

apt install apt-transport-https ca-certificates curl gnupg2 software-properties-common

and now we can add the repository for docker

curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"

and now we can install it with

apt-get update apt-get install docker-ce

The Docker Composer which is shipped with Debian is too old to work with this docker, so we need following:

curl -L "https://github.com/docker/compose/releases/download/1.23.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

and add /usr/local/bin/ to the path variable by adding

PATH=/usr/local/bin:$PATH

to .bashrc and calling it directly in the bash to get it set without starting a new bash instance. I know that a package would be better, couldn’t find one, so this is a temporary solution. If someone finds a better one, leave it in the comments below.

Now we need to check if the overlay stuff is working by calling docker info and hopefully you get also overlay2 as storage driver:

Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 18.06.1-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file

Bitwarden

Now we just need following:

curl -s -o bitwarden.sh https://raw.githubusercontent.com/bitwarden/core/master/scripts/bitwarden.sh
chmod +x bitwarden.sh
./bitwarden.sh install
./bitwarden.sh start
./bitwarden.sh updatedb

And now you’re done, you’ve your own password manager server which also supports Google Authenticator (Time-based One-time Password Algorithm (TOTP) as second factor. Maybe I’ll write a blogpost how to setup a Yubikey as 2FA (desktop and mobile) later.

New Systemd Privilege Escalation Flaws Affect Most Linux Distributions

Security researchers have discovered three vulnerabilities in Systemd, a popular init system and service manager for most Linux operating systems, that could allow unprivileged local attackers or malicious programs to gain root access on the targeted systems. The vulnerabilities, assigned as CVE-2018-16864, CVE-2018-16865, and CVE-2018-16866, actually resides in the "systemd-journald" service

Assessing the security of a portable router: a look inside its hardware, part deux

In part two of our blog assessing the security of a portable router, we will acquire the tools and equipment to make a copy of the firmware on our target router so that we can assess the full firmware.

Sometimes, the manufacturer has an updated firmware that is available on their website. It could be just that—an update—and therefore incomplete. We want to be able to compare the updated and existing firmware to see what was changed.

With a complete firmware, we can browse the file system of the router and look for interesting security developments. Is there an administrative backdoor? Is there functionality that might be undocumented or concerning?

Ultimately, we want to better understand how this device works, and without the complete picture, that isn’t possible (or it’s significantly harder).

More shopping

The third arm solution I had purchased in our first blog was under performing. It didn’t have enough arms, was a little on the flimsy side, and tended to tip over easily. I purchased a more robust solution. This will be used to hold the router, lights, USB microscope, and other devices when we acquire the firmware.

This contraption looks like a space octopus is on my desk, but is infinitely more useful.

We will also need a SOIC 8 PIN clip.

This will be used to connect to the eeprom without de-soldering the actual chip. (Desoldering tends to result in the chip not working ever again, at least for me.) I bought several SOIC clips, mainly because my original was taking forever to get here, and also because I read online comments on how effectiveness varied wildly between the “cheap” SOIC clips and the more expensive ones. The cheap ones have a tendency to pop off if the cabling is disturbed.

I also bought some jump wires for plumbing the clip to any diagnostic device I choose to use.

In addition, I bought a small USB microscope. Nothing fancy: 200X magnification. The writing on the chips was so small that I was struggling to read it. SuperEyes touts its use for dental purposes. It works fine for reading the small markings on various chips, too.

Acquisition hardware

There are several options to achieve this. The most common one is the Bus Pirate from Dangerous Prototypes.

 

After some online research, I found that there are several versions of the Bus Pirate available. I elected version 3 (v3.6 to be precise) after seeing this comment on the Dangerous Prototype page: Bus Pirate v3 is still the best choice if you want something you can use without a lot of hassle. The v4 firmware is rough around the edges, but it is improving all the time.

I bought three Bus Pirates in total: two v3.6’s and a v4.0. The plan is to have a stock v3.6, with whatever loader and firmware it comes with, and have a spare to update it to the community loader and community firmware that can be found here.

The 4.0 Bus Pirate is for the remote possibility that neither 3.6’s or other solutions work successfully. (The Bus Pirate v4 is still making its way though our postal system.)

The Bus Pirate has the highest number of blog posts and YouTube videos demonstrating its use, but during my research, I came across some information that gave me some pause.

The development by Dangerous Prototypes of the Bus Pirate seems to have stopped. It could be that it has all the needed features, but when I used the Bus Pirate in conjunction with flashrom, the software I used on my Linux development machine, it complained about the firmware revisions that came with my v3.6 models.

Further research also turned up the Shikra, made by Xipiter. I also acquired one of these, with the intention to use it to dump the router firmware with it and compare it to the one acquired with the Bus Pirate. It never hurts to have multiple ways of achieving the same results.

Let’s begin!

A fast and loose rule, when looking at the router mainboard, is that the big chip in the center is the processor, and the small chip at the side is an eeprom. If there’s any doubt, Googling the numbers on all the chips will help identify them. In some cases, there will be three chips and the third will be RAM. Some more fully featured devices may have even more chips.

In our case, we’re looking for the eeprom. The eeprom is used to store relatively small amounts of data, but allows individual bytes to be erased and reprogrammed. Hardware manufacturers can get clever by erasing the chip identifiers, covering them up in epoxy, or even both. Ours was just hard to read.

The eeprom on our target device is the smaller chip, with 8 “feet” as seen on the left of this picture.

Once we have dumped the firmware, we can also compare the latest firmware available on the website of manufacturer and the one we extracted. If we were hunting for vulnerabilities, it would actually be preferable for us to have an older firmware on our router. It gives us good hints as to what was changed in the new version. What did the patch address?

Investigating the eeprom

Rather than using the Chinese language only application that came with the SuperEyes microscope, I installed “Cheese” in Linux. Cheese can use any webcam detected, so I selected the USB 2.0 camera in the preferences and was able to use it in Ubuntu.

And here is where things get fuzzy. We have to map the pin out of the eeprom to the SOIC clip pins, and then from the SOIC clip to the BusPirate or the Shikra interface. We can Identify pin 1 by the dot on the chip, but we need to go online and try to find the data sheet for this chip to know how to connect it. I Googled several data sheets and wasn’t able to find an exact match.

At this point we could use an oscilloscope, but thats a little out of our budget, so we’re going to fudge it and use the pin from a similar eeprom chip and hope for the best.

Many of the searches I conducted indicated that this might be a Gigadevice chip. While there doesn’t seem to be a standard for which pins do what, most of the data sheets have diagrams such as this one:

I connected the SOIC chip clip by grabbing the chip. Seen from directly above, it would look like this:

And I used the microscope to verify that the pins were properly seated and making contact with the “feet” of the eeprom, as such:

The protocol we will be using to read the eeprom is SPI, and the Shikra pin documentation has a chart for SPI. We need to map the pins from the eeprom to the Shikra to successfully dump the contents of the chip. I investigated each acronym from the chip, as well as each for the Shikra (for SPI) and made a chart to know which pins go from one to the other. The eeprom is on the left of the chart; the Shikra is on the right.

And here is the finished result, from chip to clip, through jump wires to Shikra.

On our research Linux laptop, we can issue the command “$ dmesg | grep tty” to confirm the Shikra is properly detected and is located at ttyUSB0. This is what we should see as an output:

We will need an application called flashrom. A simple “$ sudo apt-get install flashrom” will do this for us. To dump the firmware, we issue this command to the Shikra “$ flashrom -p ft2232_spi:type=232H -r spidump.bin”

Flashrom identifies the chip as a GD21Q16(B) and, armed with this knowledge, Google searches yielded the exact data sheet. It feels like the long way around to get the proper data sheet in PDF form, but our gamble paid off. We now have a dump of the eeprom and we can continue our research. I reproduced the same steps as the ones I had done with the Shikra with the Bus Pirate and dumped the firmware with it as well. The Bus Pirate did take considerably longer to dump the firmware.

Flashrom did complain somewhat during the dumping process when I used the Bus Pirate, but it completed successfully.

Until next time

So we now have the firmware that was on the router. In our next and final part of this blog series, we will look at the firmware we extracted and see if we can find any vulnerabilities or other interesting changes. We will also look at the updated firmware we downloaded from the manufacturer’s website and compare the two.

The post Assessing the security of a portable router: a look inside its hardware, part deux appeared first on Malwarebytes Labs.

Rootkit Umbreon / Umreon – x86, ARM samples



Pokémon-themed Umbreon Linux Rootkit Hits x86, ARM Systems
Research: Trend Micro


There are two packages
one is 'found in the wild' full and a set of hashes from Trend Micro (all but one file are already in the full package)






Download

Download Email me if you need the password  



File information

Part one (full package)

#File NameHash ValueFile Size (on Disk)Duplicate?
1.umbreon-ascii0B880E0F447CD5B6A8D295EFE40AFA376085 bytes (5.94 KiB)
2autoroot1C5FAEEC3D8C50FAC589CD0ADD0765C7281 bytes (281 bytes)
3CHANGELOGA1502129706BA19667F128B44D19DC3C11 bytes (11 bytes)
4cli.shC846143BDA087783B3DC6C244C2707DC5682 bytes (5.55 KiB)
5hideportsD41D8CD98F00B204E9800998ECF8427E0 bytes ( bytes)Yes, of file promptlog
6install.sh9DE30162E7A8F0279E19C2C30280FFF85634 bytes (5.5 KiB)
7Makefile0F5B1E70ADC867DD3A22CA62644007E5797 bytes (797 bytes)
8portchecker006D162A0D0AA294C85214963A3D3145113 bytes (113 bytes)
9promptlogD41D8CD98F00B204E9800998ECF8427E0 bytes ( bytes)
10readlink.c42FC7D7E2F9147AB3C18B0C4316AD3D81357 bytes (1.33 KiB)
11ReadMe.txtB7172B364BF5FB8B5C30FF528F6C51252244 bytes (2.19 KiB)
12setup694FFF4D2623CA7BB8270F5124493F37332 bytes (332 bytes)
13spytty.sh0AB776FA8A0FBED2EF26C9933C32E97C1011 bytes (1011 bytes)Yes, of file spytty.sh
14umbreon.c91706EF9717176DBB59A0F77FE95241C1007 bytes (1007 bytes)
15access.c7C0A86A27B322E63C3C29121788998B8713 bytes (713 bytes)
16audit.cA2B2812C80C93C9375BFB0D7BFCEFD5B1434 bytes (1.4 KiB)
17chown.cFF9B679C7AB3F57CFBBB852A13A350B22870 bytes (2.8 KiB)
18config.h980DEE60956A916AFC9D2997043D4887967 bytes (967 bytes)
19config.h.dist980DEE60956A916AFC9D2997043D4887967 bytes (967 bytes)Yes, of file config.h
20dirs.c46B20CC7DA2BDB9ECE65E36A4F987ABC3639 bytes (3.55 KiB)
21dlsym.c796DA079CC7E4BD7F6293136604DC07B4088 bytes (3.99 KiB)
22exec.c1935ED453FB83A0A538224AFAAC71B214033 bytes (3.94 KiB)
23getpath.h588603EF387EB617668B00EAFDAEA393183 bytes (183 bytes)
24getprocname.hF5781A9E267ED849FD4D2F5F3DFB8077805 bytes (805 bytes)
25includes.hF4797AE4B2D5B3B252E0456020F58E59629 bytes (629 bytes)
26kill.cC4BD132FC2FFBC84EA5103ABE6DC023D555 bytes (555 bytes)
27links.c898D73E1AC14DE657316F084AADA58A02274 bytes (2.22 KiB)
28local-door.c76FC3E9E2758BAF48E1E9B442DB98BF8501 bytes (501 bytes)
29lpcap.hEA6822B23FE02041BE506ED1A182E5CB1690 bytes (1.65 KiB)
30maps.c9BCD90BEA8D9F9F6270CF2017F9974E21100 bytes (1.07 KiB)
31misc.h1F9FCC5D84633931CDD77B32DB1D50D02728 bytes (2.66 KiB)
32netstat.c00CF3F7E7EA92E7A954282021DD72DC41113 bytes (1.09 KiB)
33open.cF7EE88A523AD2477FF8EC17C9DCD7C028594 bytes (8.39 KiB)
34pam.c7A947FDC0264947B2D293E1F4D69684A2010 bytes (1.96 KiB)
35pam_private.h2C60F925842CEB42FFD639E7C763C7B012480 bytes (12.19 KiB)
36pam_vprompt.c017FB0F736A0BC65431A25E1A9D393FE3826 bytes (3.74 KiB)
37passwd.cA0D183BBE86D05E3782B5B24E2C964132364 bytes (2.31 KiB)
38pcap.cFF911CA192B111BD0D9368AFACA03C461295 bytes (1.26 KiB)
39procstat.c7B14E97649CD767C256D4CD6E4F8D452398 bytes (398 bytes)
40procstatus.c72ED74C03F4FAB0C1B801687BE200F063303 bytes (3.23 KiB)
41readwrite.cC068ED372DEAF8E87D0133EAC0A274A82710 bytes (2.65 KiB)
42rename.cC36BE9C01FEADE2EF4D5EA03BD2B3C05535 bytes (535 bytes)
43setgid.c5C023259F2C244193BDA394E2C0B8313667 bytes (667 bytes)
44sha256.h003D805D919B4EC621B800C6C239BAE0545 bytes (545 bytes)
45socket.c348AEF06AFA259BFC4E943715DB5A00B579 bytes (579 bytes)
46stat.cE510EE1F78BD349E02F47A7EB001B0E37627 bytes (7.45 KiB)
47syslog.c7CD3273E09A6C08451DD598A0F18B5701497 bytes (1.46 KiB)
48umbreon.hF76CAC6D564DEACFC6319FA167375BA54316 bytes (4.21 KiB)
49unhide-funcs.c1A9F62B04319DA84EF71A1B091434C644729 bytes (4.62 KiB)
50cryptpass.py2EA92D6EC59D85474ED7A91C8518E7EC192 bytes (192 bytes)
51environment.sh70F467FE218E128258D7356B7CE328F11086 bytes (1.06 KiB)
52espeon-connect.shA574C885C450FCA048E79AD6937FED2E247 bytes (247 bytes)
53espeon-shell9EEF7E7E3C1BEE2F8591A088244BE0CB2167 bytes (2.12 KiB)
54espeon.c499FF5CF81C2624B0C3B0B7E9C6D980D14899 bytes (14.55 KiB)
55listen.sh69DA525AEA227BE9E4B8D59ACFF4D717209 bytes (209 bytes)
56spytty.sh0AB776FA8A0FBED2EF26C9933C32E97C1011 bytes (1011 bytes)
57ssh-hidden.shAE54F343FE974302F0D31776B72D0987127 bytes (127 bytes)
58unfuck.c457B6E90C7FA42A7C46D464FBF1D68E2384 bytes (384 bytes)
59unhide-self.pyB982597CEB7274617F286CA80864F499986 bytes (986 bytes)
60listen.shF5BD197F34E3D0BD8EA28B182CCE7270233 bytes (233 bytes)

part 2 (those listed in the Trend Micro article)
#File NameHash ValueFile Size (on Disk)
1015a84eb1d18beb310e7aeeceab8b84776078935c45924b3a10aa884a93e28acA47E38464754289C0F4A55ED7BB556489375 bytes (9.16 KiB)
20751cf716ea9bc18e78eb2a82cc9ea0cac73d70a7a74c91740c95312c8a9d53aF9BA2429EAE5471ACDE820102C5B81597512 bytes (7.34 KiB)
30a4d5ffb1407d409a55f1aed5c5286d4f31fe17bc99eabff64aa1498c5482a5f0AB776FA8A0FBED2EF26C9933C32E97C1011 bytes (1011 bytes)
40ce8c09bb6ce433fb8b388c369d7491953cf9bb5426a7bee752150118616d8ffB982597CEB7274617F286CA80864F499986 bytes (986 bytes)
5122417853c1eb1868e429cacc499ef75cfc018b87da87b1f61bff53e9b8e86709EEF7E7E3C1BEE2F8591A088244BE0CB2167 bytes (2.12 KiB)
6409c90ecd56e9abcb9f290063ec7783ecbe125c321af3f8ba5dcbde6e15ac64aB4746BB5E697F23A5842ABCAED36C9146149 bytes (6 KiB)
74fc4b5dab105e03f03ba3ec301bab9e2d37f17a431dee7f2e5a8dfadcca4c234D0D97899131C29B3EC9AE89A6D49A23E65160 bytes (63.63 KiB)
88752d16e32a611763eee97da6528734751153ac1699c4693c84b6e9e4fb08784E7E82D29DFB1FC484ED277C70218781855564 bytes (54.26 KiB)
9991179b6ba7d4aeabdf463118e4a2984276401368f4ab842ad8a5b8b730885222B1863ACDC0068ED5D50590CF792DF057664 bytes (7.48 KiB)
10a378b85f8f41de164832d27ebf7006370c1fb8eda23bb09a3586ed29b5dbdddfA977F68C59040E40A822C384D1CEDEB6176 bytes (176 bytes)
11aa24deb830a2b1aa694e580c5efb24f979d6c5d861b56354a6acb1ad0cf9809bDF320ED7EE6CCF9F979AEFE451877FFC26 bytes (26 bytes)
12acfb014304b6f2cff00c668a9a2a3a9cbb6f24db6d074a8914dd69b43afa452584D552B5D22E40BDA23E6587B1BC532D6852 bytes (6.69 KiB)
13c80d19f6f3372f4cc6e75ae1af54e8727b54b51aaf2794fedd3a1aa463140480087DD79515D37F7ADA78FF5793A42B7B11184 bytes (10.92 KiB)
14e9bce46584acbf59a779d1565687964991d7033d63c06bddabcfc4375c5f1853BBEB18C0C3E038747C78FCAB3E0444E371940 bytes (70.25 KiB)

Howto setup a Debian 9 with Proxmox and containers using as few IPv4 and IPv6 addresses as possible

My current Linux Root-Server needs to be replaced with a newer Linux version and should also be much cheaper then the current one. So at first I did look what I don’t like about the current one:

  • It is expensive with about 70 Euros / months. Following is responsible for that
    • My own HPE hardware with 16GB RAM and a software RAID (hardware raid would be even more expensive) – iLo (or something like it) is a must for me 🙂
    • 16 additional IPv4 addresses for the visualized container and servers
    • Large enough backup space to get back some days.
  • A base OS which makes it hard to run newer Linux versions in the container (sure old ones like CentOS6 still get updates, but that will change)
    • Its time to move to newer Linux versions in the containers
  • OpenVZ based containers which are not mainstream anymore

Then I looked what surrounding conditions changed since I did setup my current server.

  • I’ve IPv6 at home and 70% of my traffic is IPv6 (thx to Google (specially Youtube) and Cloudflare)
  • IPv4 addresses got even more expensive for Root-Servers
  • I’m now using Cloudflare for most of the websites I host.
  • Cloudflare is reachable via IPv4 and IPv6 and can connect back either with IPv4 or IPv6 to my servers
  • With unprivileged containers the need to use KVM for security lessens
  • Hosting providers offer now KVM servers for really cheap, which have dedicated reserved CPUs.
  • KVM servers can host containers without a problem

This lead to the decision to try following setup:

  • A KVM based Server for less than 10 Euro / month at Netcup to try the concept
  • No additional IPv4 addresses, everything should work with only 1 IPv4 and a /64 IPv6 subnet
  • Base OS should be Debian 9 (“Stretch”)
  • For ease of configuration of the containers I will use the current Proxmox with LXC
  • Don’t use my own HTTP reverse proxy, but use exclusively Cloudflare for all websites to translate from IPv4 to IPv6

After that decision was reached I search for Howtos which would allow me to just set it up without doing much research. Sadly that didn’t work out. Sure, there are multiple Howtos which explain you how to setup Debian and Proxmox, but if you get into the nifty parts e.g. using only minimal IP addresses, working around MAC address filters at the hosting providers (which is quite a important security function, BTW) and IPv6, they will tell you: You need more IP addresses, get a really complicated setup or just ignore that point at all.

As you can read that blog post you know that I found a way, so expect a complete documentation on how to setup such a server. I’ll concentrate on the relevant parts to allow you to setup a similar server. Of course I did also some security harding like making a secure ssh setup with only public keys, the right ciphers, …. which I won’t cover here.

Setting up the OS

I used the Debian 9 minimal install, which Netcup provides, and did change the password, hostname, changed the language to English (to be more exact to C) and moved the SSH Port a non standard port. The last one I did not so much for security but for the constant scans on port 22, which flood the logs.

passwd
vim /etc/hosts
vim /etc/hostname
dpkg-reconfigure locales
vim /etc/ssh/sshd_config
/etc/init.d/ssh restart

I followed that with making sure no firewall is active and installed the net-tools so I got netstat and ifconfig.

apt install net-tools

At last I did a check if any packages needs an update.

apt update
apt upgrade

Installing Proxmox

First I checked if the IP address returns the correct hostname, as otherwise the install fails and you need to start from scratch.

hostname --ip-address

Adding the Proxmox Repos to the system and installing the software:

echo "deb http://download.proxmox.com/debian/pve stretch pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list
wget http://download.proxmox.com/debian/proxmox-ve-release-5.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-5.x.gpg
apt update && apt dist-upgrade
apt install proxmox-ve postfix open-iscsi

After that I did a reboot and booted the Proxmox kernel, I removed some packages I didn’t need anymore

apt remove os-prober linux-image-amd64 linux-image-4.9.0-3-amd64

Now I did my first login to the admin GUI to https://<hostname>:8006/ and enabled the Proxmox firewall

Than set the firewall rules for protecting the host (I did that for the whole datacenter even if I only have one server at this moment). Ping is allowed, the Webgui and ssh.

I mate sure with

iptables -L -xvn

that the firewall was running.

BTW, if you don’t like the nagging windows at every login that you need a license and if this is only a testing machine as mine is currently, type following:

sed -i.bak 's/NotFound/Active/g' /usr/share/perl5/PVE/API2/Subscription.pm && systemctl restart pveproxy.service

Now we need to configure the network (vmbr0) for our virtual systems and this is the point where my Howto will go an other direction. Normally you’re told to configure the vmbr0 and put the physical interface into the bridge. This bridging mode is the easiest normally, but won’t work here.

Routing instead of bridging

Normally you are told that if you use public IPv4 and IPv6 addresses in containers you should bridge it. Yes thats true, but there is one problem. LXC containers have their own MAC addresses. So if they send traffic via the bridge to the datacenter switch, the switch sees the virtual MAC address. In a internal company network on a physical host that is normally not a problem. In a datacenter where different people rent their servers thats not good security practice. Most hosting providers will filter the MAC addresses on the switch (sometimes additional IPv4 addresses come with the right to use additional MAC addresses, but we want to save money here 🙂 ). As this server is a KVM guest OS the filtering is most likely part of the virtual switch (e.g. for VMware ESX this is the default even).

With ebtables it is possible to configure a SNAT for the MAC addresses, but that will get really complicated really fast – trust me with networking stuff – when I say complicated it is really complicated fast. 🙂

So, if we can’t use bridging we need to use routing. Yes the routing setup on the server is not so easy, but it is clean and easy to understand.

First we configure the physical interface in the admin GUI

Two configurations are different than at normal setups. The provider gave you most likely a /23 or /24, but I use a subnet mask /32 (255.255.255.255), as I only want to talk to the default gateway and not the other servers from other customers. If the switch thinks traffic is ok, he can reroute it for me. The provider switch will defend its IP address against ARP spoofing, I’m quite sure as otherwise a incorrect configuration of a customer will break the network for all customer – the provider will make that mistake only once. For IPv6 we do basically the same with /128 but in this case we also want to reuse the /64 subnet on our second interface.

As I don’t have additional IPv4 addresses, I’ll use a local subnet to provide access to IPv4 addresses to the containers (via NAT), the IPv6 address gets configured a second time with the /64 subnet mask. This setup allows use to route with only one /64 – we’re cheap … no extra money needed.

Now we reboot the server so that the /etc/network/interfaces config gets written. We need to add some additional settings there, so it looks like this

The first command in the red frame is needed to make sure that traffic from the containers pass the second rule. Its some kind lxc specialty. The second command is just a simple SNAT to your public IPv4 address. The last 2 are for making sure that the iptable rules get deleted if you stop the network.

Now we need to make sure that the container traffic gets routed so we put following lines into /etc/sysctl.conf

And we should also enable following lines

Now we’re almost done. One point remains. The switch/router which is our default gateway needs to be able to send packets to our containers. For this he does for IPv6 something similar to an ARP request. It is called neighbor discovery and as the network of the container is routed we need to answer the request on the host system.

Neighbor Discovery Protocol (NDP) Proxy

We could now do this by using proxy_ndp, the IPv6 variant of proxy_arp. First enable proxy_ndp by running:

sysctl -w net.ipv6.conf.all.proxy_ndp=1

You can enable this permanently by adding the following line to /etc/sysctl.conf:

net.ipv6.conf.all.proxy_ndp = 1

Then run:

ip -6 neigh add proxy 2a03:5000:3d:1ee::100 dev ens3

This means for the host Linux system to generate Neighbor Advertisement messages in response to Neighbor Solicitation messages for 2a03:5000:3d:1ee::100 (e.g. our container with ID 100) that enters through ens3.

While proxy_arp could be used to proxy a whole subnet, this appears not to be the case with proxy_ndp. To protect the memory of upstream routers, you can only proxy defined addresses. That’s not a simple solution, if we need to add an entry for every container. But we’re saved from that as Debian 9 ships with an daemon that can proxy a whole subnet, ndppd. Let’s install and configure it:

apt install ndppd
cp /usr/share/doc/ndppd/ndppd.conf-dist /etc/ndppd.conf

and write a config like this

route-ttl 30000
proxy ens3 {
router no
timeout 500
ttl 30000
rule 2a03:5000:3d:1ee::/64 {
auto
}
}

now enable it by default and start it

update-rc.d ndppd defaults
/etc/init.d/ndppd start

Now it is time to boot the system and create you first container.

Container setup

The container setup is easy, you just need to use the Proxmox host as default gateway.

As you see the setup is quite cool and it allows you to create containers without thinking about it. A similar setup is also possible with IPv4 addresses. As I don’t need it I’ll just quickly describe it here.

Short info for doing the same for an additional IPv4 subnet

Following needs to be added to the /etc/network/interfaces:

iface ens3 inet static
pointopoint 186.143.121.1

iface vmbr0 inet static
address 186.143.121.230 # Our Host will be the Gateway for all container
netmask 255.255.255.255
# Add all single IP's from your /29 subnet
up route add -host 186.143.34.56 dev br0
up route add -host 186.143.34.57 dev br0
up route add -host 186.143.34.58 dev br0
up route add -host 186.143.34.59 dev br0
up route add -host 186.143.34.60 dev br0
up route add -host 186.143.34.61 dev br0
up route add -host 186.143.34.62 dev br0
up route add -host 186.143.34.63 dev br0
.......

We’re reusing the ens3 IP address. Normally we would add our additional IPv4 network e.g. a /29. The problem with this straight forward setup would be that we would lose 2 IP addresses (netbase and broadcast). Also the pointopoint directive is important and tells our host to send all requests to the datacenter IPv4 gateway – even if we want to talk to our neighbors later.

The for the container setup you just need to replace the IPv4 config with following

auto eth0
iface eth0 inet static
address 186.143.34.56 # Any IP of our /29 subnet
netmask 255.255.255.255
gateway 186.143.121.13 # Our Host machine will do the job!
pointopoint 186.143.121.1

How that saved you some time setting up you own system!

Linux.Agent malware sample – data stealer



Research: SentinelOne, Tim Strazzere Hiding in plain sight?
Sample credit: Tim Strazzere


List of files

9f7ead4a7e9412225be540c30e04bf98dbd69f62b8910877f0f33057ca153b65  malware
d507119f6684c2d978129542f632346774fa2e96cf76fa77f377d130463e9c2c  malware
fddb36800fbd0a9c9bfffb22ce7eacbccecd1c26b0d3fb3560da5e9ed97ec14c  script.decompiled-pretty
ec5d4f90c91273b3794814be6b6257523d5300c28a492093e4fa1743291858dc  script.decompiled-raw
4d46893167464852455fce9829d4f9fcf3cce171c6f1a9c70ee133f225444d37  script.dumped

malware_a3dad000efa7d14c236c8018ad110144
malware fcbfb234b912c84e052a4a393c516c78
script.decompiled-pretty aab8ea012eafddabcdeee115ecc0e9b5
script.decompiled-raw ae0ea319de60dae6d3e0e58265e0cfcc
script.dumped b30df2e63bd4f35a32f9ea9b23a6f9e7


Download


Download. Email me if you need the password