Alternate title: Is that a purr or a
roar?
In the last episode we took a look at what kind of noise our Nexus 7 made when it was talking over the network. Next we're going to try to get in from the network before we take a look at the system from the inside.
Knocking at the door
Most computing systems these days have a network stack and most use the TCP/IP stack so until further info suggests there might be more, the following will be limited to searching through that stack.So far we have been looking exclusively at layer 7 at the HTTP sessions, ARP and NTP because that is where we saw connections to systems outside our network.
This begs the question, can anyone connect into the Nexus except over HTTP or 5228 (whatever that is)? Are those the only way any command and control can get into my device coming over the HTTP or 5228 channel?
Inbound connections would require a TCP, UDP or other layer 4 service listening for input that is not a response to something the Nexus software initiated to retrieve information from somewhere else (e.g. SYN).
There are many ways to find out what TCP/IP services are listening on a computer system. Most are more involved and require access to the system through avenues we haven't found yet. Fortunately, we have a number of tools in the security practitioner's toolbox that can help. I like the free ones so I'll just fire up my zenmap (or you can go straight to nmap if you like to show off your foo and don't like nicely organized views) and kick off a -A scan against the device. What did I find? Nothing listening besides layer 4 which gave up the MAC address to the router so it could find it when I asked for the IP again and enough detail for nmap to make a guess that this is running some type of *nix OS and maybe has phone or camera features.
All 65535 scanned ports on 192.168.X.X are closed
MAC Address: AC:22:0B:XX:XX:XX (Asustek Computer)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: webcam|general purpose|phone|storage-misc
Running: AXIS Linux 2.6.X, Linux 2.6.X, ZyXEL embedded
OS CPE: cpe:/h:axis:210a_network_camera cpe:/h:axis:211_network_camera cpe:/o:axis:linux_kernel:2.6 cpe:/o:linux:linux_kernel:2.6 cpe:/o:google:android:2.2 cpe:/h:zyxel:nsa-210
OS details: AXIS 210A or 211 Network Camera (Linux 2.6), Linux 2.6.14 - 2.6.34, Linux 2.6.17, Linux 2.6.17 (Mandriva), Linux 2.6.17 - 2.6.36, Android 2.2 (Linux 2.6), ZyXEL NSA-210 NAS device
So that helps set my mind at ease about the potential avenues of attack against this platform out of the box but we'll have to rerun this after any app install to see whether some app opens up a listener.
Now it's time to get inside.
Over the bridge and through the woods
A little research turned up some useful information that would help me get a look under the covers. I will be using two tools.- adb
is the Android Development Bridge. This enables me to have command
line access to explore the device as well as capability to export
files and images to explore in your favorite OS.
- Dalvik
Debug Monitor (DDM) Server is useful for looking at the logs in an
organized and easy to read way. I could run logcat from the command
line but then I have to parse the hard way. Also, it has capability
of looking at the specific software running to get a better
understanding of what each is doing.
Since the path looked like a *nix prompt I did what any *nix explorer would do and checked to see what privileges I had.
shell@flo:/ $ id
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0
This confirmed that I was on a *nix variant. So I tried uname to see if I could see what kernel I was running and the command didn't exist. No worries. cat /proc/version solved the problem well enough.
Linux version 3.4.0-g03485a6 (android-build@vpbs1.mtv.corp.google.com) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Tue Mar 18 15:02:27 PDT 2014
NOTE: It is interesting that they have “mtv” in a domain name inside Google's build environment. While this could be a reference to the channel, I am leaning toward some location identifier. Perhaps Mountain View, their home location (Thanks Mike G!)? Also it seems they use a surprisingly simple hostname format at least in the build environment.
A look at the Kernel archives shows me that this 4.4.4 version is running several minor revisions behind the currently available kernel and was compiled with a gcc version that is several versions old (will have to see where Android 5.0 is). This gives me a hint and a worry so I should probably look around for some vulnerability alerts that identify local attack vectors at some point.
Next I want to get a sense of where things are so I checked the $PATH variable.
shell@flo:/ $ echo $PATH
/sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
This is interesting because they put their commands in different locations than your average Linux. There are a lot of flavors of Linux after all so we'll just have to look for signs to see where their inspiration comes from (FOSS) and creates dependency risk vs how much is customized and in Google's control.
What about the other environment variables? I run set and see:
- There is some Java (BOOTCLASSPATH
variable shows jar files) involved but I cannot access the java
or javac commands to see the
version.
- The hostname is flo
- They use mksh
and link to it from /system/bin/sh
This is a big clue as to
Google's inspiration as this came from the MirOS
Project. I had never heard of this OS before so it was interesting
to see their self-characterization of the OS and Platform: “A
wonderful operating system for a world of peace”. Unfortunately,
a look at the mksh
version info identifies that this shell is vulnerable. The MirOS team ranks the vulnerability Low but we'd have to think for ourselves once we knew more to be sure we agree in our context.
Seeing the forest
Next I wanted to see what all could be seen. Unfortunately find wasn't available so I had to do an ls -alR and review the hard way.A couple interesting things I noted follow.
- They use SELinux
to help control the application and user access. Is this the
“sandbox” I've read about? Could be an interesting design gap
to look for in future application reviews if the OS even lets the
developers define their own settings.
- The only world writable files in the whole system are in the
/sys/fs/selinux directory but this is to be expected for that
directory.
- There are some files that are r-x for world but also have r-x
for a group I am in. I suppose these could be catch-all perms but
it seems a little un-necessary if I'm going to be the owner of any
net new applications added to the system. I will have to keep an open
mind about this.
- A lot of common Linux utilities are linked to a command called
toolbox.
lrwxr-xr-x
root shell 2013-02-08 19:00 cat -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:03 chcon -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 chmod -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 chown -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:03 clear -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 cmp -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 cp -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 date -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 dd -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 df -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 dmesg -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 du -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:03 getenforce -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 getevent -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 getprop -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:03 getsebool -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 grep -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 hd -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 id -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 ifconfig -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 iftop -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 insmod -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 ioctl -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 ionice -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 kill -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 ln -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:03 load_policy -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 log -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 ls -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 lsmod -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 lsof -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 md5 -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 mkdir -> toolbox
lrwxrwxrwx
root root 2014-11-13 19:35 mknod -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:16 mkswap -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 mount -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 mv -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 nandread -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 netstat -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 newfs_msdos -> toolbox
lrwxrwxrwx
root root 2014-11-13 19:35 nohup -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 notify -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 printenv -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 ps -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:16 readlink -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 renice -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:03 restorecon -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 rm -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 rmdir -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 rmmod -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 route -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:03 runcon -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 schedtop -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 sendevent -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:03 setenforce -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 setprop -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:03 setsebool -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 sleep -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 smd -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 start -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 stop -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:16 swapoff -> toolbox
lrwxrwxrwx
root root 2014-11-12 07:16 swapon -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 sync -> toolbox
-rwxr-xr-x
root shell 152152 2014-11-13 19:31 toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 top -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 touch -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 umount -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 uptime -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 vmstat -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 watchprops -> toolbox
lrwxr-xr-x
root shell 2013-02-08 19:00 wipe -> toolbox
- Using strings I was able to pull some version info that may help date the java binaries from /system/lib/libjavacore.so. Because of these details, I can date the binary to being created between April 2013 (release date of zlib) and Jan 2014 (release date of OpenSSL 1.0.1f.
- android.zlib.version=1.2.8 - This is the most current.
- android.openssl.version=OpenSSL 1.0.1e 11 Feb 2013 – There have been a number of vulnerabilities identified in OpenSSL since then. Will have to see if Android 5 addresses these.
- The logcat command gives
a lot of details about what is going on or going wrong with the
system. Will have to explore this later. Interesting that it
doesn't seem to have any timestamps. Won't be much help in an
incident without that but at least we can potentially identify
suspicious activity in real-time.
- They use iptables and
iptables6 but I'd have to be
root to see the rules.
- bugreport gives the
usual detail. Would be interesting to see if an installed app can
access this command since I can run it. I would assume so but
wonder if there is enforcement of approval from the user to allow the information to be sent out of the device. Review of the output identified some
interesting bits.
- They seem to have used a BSD style init but I cannot read any of the rc files to see for sure.
- There are a number of users identified in top
and ps content but there is no
/etc/passwd. A grep for one
of the users in the root and /etc
directory doesn't provide any leads to see how they manage
the mapping of UIDs and GIDs to usernames and groups.
- netd may be the
equivalent of inetd. An
attempt to get some help info causes some calls to the iptables.
- There are a number of apps placed into a selinux
domain called “untrusted_app”.
Will have to experiment with this someday to see how things change
if at all.
- Selinux is running in Enforcing mode. This is starting to
feel like a key component of their sandboxing approach.
Is that a light ahead?
No, but I am going to give you a break on the
detailed analysis here. What I want you to come away with is a
sense of the process I used. Also take away that this process
inevitably requires knowledge from outside your tool kit. This lack of knowledge is the main driver for using
frameworks and guides. We can't all have been in InfoSec for long
enough to tear apart any OS even if we had the time. As discussed before, not every business
can afford or wants to apply that level of skill to manage the risks
either. So we
have to trust management when they say No to the level of
research we might want to do to appease our level of doubt and do the best job we can within the constraints.
Next we'll take a look at logs and
debug features of the DDM to see what can be seen.
No comments:
Post a Comment