Hackin9
 

By now youve probably heard about Docker, the application containerization tool. Lenny Zeltser has talked about using it for malware analysis, for example, and also looked at the security implications. Last week, however, I ran across my first incident where the system I needed to examine was running Docker. I hadnt used Docker, myself, so I didnt know what difficulties this might introduce into my investigation. I threw a quick note out on the SANS DFIR list to see if anyone else had had to deal with Docker during a forensic investigation and got a couple of responses, but not a lot of usable info, so after a phone call with Derek Armstrong, who was one of the folks who responded to the e-mail, I set out to figure out how Docker was going to complicate my life. What follows is what Ive learned in the last week. I know there is much more that can be done here and hopefully before this is all said and done, Ill write a few scripts that might be helpful in future investigations (hence, titling the post Part 1). So, when I began this investigation, I had a memory image and a disk image. I did not have access to the live system.

Memory Forensics

On first look at the memory image, my fear was that Docker was actually virtualization rather than containerization and that the process details were somewhere inside the process memory of the docker process. When I ran volatility and saw that the docker process didnt have any child processes, I was even more concerned. It turns out, I was worrying needlessly, however. It turns out that on this particular image, there werent any docker containers running at the time the memory image was taken. " />

Unfortunately, the linux_pstree volatility plugin doesnt show those processes as being offspring of the docker process (note this is still using Volatility 2.4 I encountered problems with my Linux profiles for 2.5 and havent had time to figure out how to fix them yet).

$ vol.py --plugins ~investigator/.zrk_cache -f XUbuntu\ 64-bit-Snapshot3\ -\ Copy.vmem --profile=Linux3_13_0_79_generic__123_Ubuntu_SMP_Fri_Feb_19_14_27_58_UTC_2016_x86_64x64 linux_pstree
Volatility Foundation Volatility Framework 2.4
Name Pid Uid
init 1 0
.upstart-udev-br 589 0
.systemd-udevd 593 0
.upstart-socket- 745 0
.dbus-daemon 924 102
.ModemManager 976 0
.systemd-logind 992 0
...snip...?
.docker 51914 0
...snip...
bash 52102 0
.top 52144 0

Even though ps clearly shows the PPID of that bash is PID 51914. However, it is possible to find all the descendants of the docker process using the linux_psenv plugin and grep-ing for the HOSTNAME environment variable. " />

You can also see that there is a docker layered filesystem mounted, but you can" />

Note that mount of /var/lib/docker/aufs/aufs, that wont be present if thre isnt a docker image running and the line for / will be different (showing the /dev/disk/... and ext4 instead of none and aufs). Also, if you do have access to the live system, it is interesting to note that df -h run as an unprivileged user won" />

The last snippet I want to look at is the output from the volatility linux_lsof plugin. This one shows some useful places we" />

That json log looks like something that could be very interesting. Well pick this up there in our next installment.

In the meantime, Im still just getting started trying to figure out how to deal with Docker artifacts, so if you have thoughts or suggestions, Id love to hear them. Feel free to comment here, or use our feedback form, or e-mail me (the address is below). Thanx.

References

https://www.docker.com/
https://zeltser.com/security-risks-and-benefits-of-docker-application/
https://zeltser.com/docker-application-distribution/
https://digital-forensics.sans.org/blog/2014/12/10/running-malware-analysis-apps-as-docker-containers

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 

A botched security fix released for the Java software framework 30 months ago has left millions of users vulnerable to attacks that Oracle had claimed were no longer possible, a security researcher said.

The bypass code, which was released Thursday by Polish security firm Security Explorations, contains only minor changes to the original proof-of-concept, according to an e-mail posted to the Full Disclosure security list. Security Explorations released the original exploit in October 2013 following the release of a patch from Oracle. Thursday's bypass changes only four characters from the 2013 code and uses a custom server to work. The bypass means that millions of Java users have remained vulnerable to the flaw, categorized as CVE-2013-5838, despite assurances from Oracle that the attacks were no longer possible.

"We implemented a Proof of Concept code that illustrates the impact of the broken fix described above," Security Explorations researchers wrote in a report. "It has been successfully tested in the environment of Java SE Update 97, Java SE 8 Update 74, and Java SE 9 Early Access Build 108. In all cases, a complete Java security sandbox escape could be achieved."

Read 2 remaining paragraphs | Comments

 

Not the message you want from your Web security firm.

A Web security company's systems are offline this morning after an apparent intrusion into the company's network. The servers and routers of Staminus Communications—a Newport Beach, California-based hosting and distributed denial of service (DDoS) protection company—went offline at 8am Eastern Time on Thursday in what a representative described in a Twitter post as "a rare event [that] cascaded across multiple routers in a system wide event, making our backbone unavailable."

That "rare event" appears to have been intentional. A data dump of information on Staminus' systems includes customer names and e-mail addresses, database table structures, routing tables, and more. The data was posted to the Internet this morning, and a Staminus customer who wishes to remain anonymous confirmed his data was part of the dump. The authors of the dump claim to have gained control of Staminus' routers and reset them to factory settings.

The dump, in a hacker "e-zine" format, begins with a note from the attacker. Sarcastically titled "TIPS WHEN RUNNING A SECURITY COMPANY," it details the security holes found during the breach:

Read 4 remaining paragraphs | Comments

 
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Internet Storm Center Infocon Status