Is That A Penguin In My Windows?

705 views

Published on

Windows Subsystem for Linux (WSL) Overview
BSides Las Vegas
Wednesday August 3rd, 2016

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
705
On SlideShare
0
From Embeds
0
Number of Embeds
46
Actions
Shares
0
Downloads
26
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Is That A Penguin In My Windows?

  1. 1. Is That A Penguin In My Windows? Spencer (@zeroSteiner) McIntyre BSides Las Vegas Wednesday August 3rd, 2016
  2. 2. Agenda • About Me • Windows Subsystem for Linux Overview • Why are we here and why do we care? • How does it work? • Implementation Details • Syscall functionality • Filesystem details • Attacker Notes • Fingerprinting WSL • Payload Compatibility • Inter process access
  3. 3. About Me • Spencer McIntyre • Work at SecureState • Research, Development, “Special” Projects • BSOD-inducer • Avid open source contributor (Metasploit among others) • Python enthusiast • I can haz acronyms? • OSCP, OSEE
  4. 4. Overview • Windows Subsystem for Linux • Objective is to allow native x86-64 ELF binaries to run natively on Windows platforms • It’s not virtualization • Supposedly Linux executables run at normal speeds • Linux processes are “picoprocesses” • WSL Core implementation provided by two Windows drivers • LXCORE • Larger of the two, provides all of the Linux Syscalls • LXSS
  5. 5. Microsoft’s Diagram Source: https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/
  6. 6. Implementation Details
  7. 7. Driver Architecture • LXCORE Provides the main functionality • Including Driverlxss object • No accompanying lxcore object • LXSS loads LXCORE and calls LxInitialize
  8. 8. Picoprocesses • Container process with a limited access to the Kernel API • Product of Microsoft’s research project dubbed “Drawbridge” from 2011 • Project goal was to provide faster isolated / sandboxed execution • Speed came from the lack of a virtualization overhead • First added to Windows 8.1 and Server 2012 R2 • Process does not contain PEB / TEB / NTDLL.DLL / user32!gSharedInfo • Windows Kernel still provides thread scheduling and memory management
  9. 9. Syscalls You Say? • Picoprocesses get a separate syscall dispatcher • Driver registers itself as a picoprocess provider and dispatches it’s own syscalls • Linux syscalls implemented in LXCORE!LxpSyscall_* • 216 in Windows 10 Preview 14385 vs 345 in Linux 3.4-rc7 • 62.6% coverage • Missing syscalls include some *32 equivalents • Existing are 16-bit not 64-bit, 32-bit calls were introduced in Linux 2.4
  10. 10. Syscalls You Say? • The kernel dispatches to the picoprovider for fulfillment • Linux calls with NT equivalents forward the call to be fulfilled by the kernel • Syscall is made by the user process with the convention expected by the pico driver • In this case, the one specified by Linux x86-64 / System V ABI • System V ABI Syscall Convention • Syscall number -> RAX • Arguments -> RDI, RSI, RDX, RCX, R8, R9 (remaining on the stack)
  11. 11. Debugging Syscalls • Useful for bug hunting • We can break on specific conditions using the Linux calling convention • Example call stack for MMAP LXCORE!LxpSys_MMAP <- Break here for mmap syscalls and/or args to mmap LXCORE!LxpSysDispatch LXCORE!PicoSystemCallDispatch <- Break here for all WSL syscalls nt!PsPicoSystemCallDispatch <- Break here for all picoprocess syscalls nt!KiSystemServiceUser
  12. 12. Filesystems • WSL 2 main file systems • VoIFs • Linux root directories • Not accessible by Windows applications • DriveFs • Access to the Windows filesystem • /mnt/c • Additional filesystems for /proc, /sys, etc. • Control file systems are incomplete • /proc/net results in broken ifconfig
  13. 13. DriveFS Specific • Despite being root, files can only be read as user that started bash • Linux file permissions are stored in NTFS extended attribute • Permissions and owner are ignored for files created by root
  14. 14. Attacker Notes
  15. 15. Identifying WSL • Obvious: • grep Microsoft /proc/version && echo “WSL Detected” • Check for mounted drives in /mnt • Behavioral clues: • 1 module in /sys/modules (lack of drivers is suspicious) • /proc missing modules entry • Strict checks of mmap syscall flags • mmap(NULL, 4096, PROT_READ|PROT_WRITE|0x1000, …
  16. 16. Very Subtle Microsoft…
  17. 17. Metasploit Payload Compatibility • Each was tested as a native ELF executable • Working payloads can’t access network configuration details Payload Name Compatible? linux/x64/mettel/reverse_tcp no* linux/x64/shell_reverse_tcp yes linux/x86/meterpreter/reverse_tcp no** python/meterpreter/reverse_tcp yes * Strict mmap syscall implementation ** 32-bit ELF files are not supported
  18. 18. Python Meterpreter
  19. 19. Linux Kernel Protections • All the basics are implemented • Usermode ASLR (randomize_va_space) • Data Execution Prevention (DEP) • NULL page mapping prevention (mmap_min_addr)
  20. 20. Cross Process Access • Desirable for an attacker to infect the Linux container or Windows host • Linux processes can not list Windows processes • Windows can list Linux processes • PIDs do not match
  21. 21. Linux -> Windows Access • No process access • Windows processes are objects exposed through the Win32 API • Linux exposes information through files in /proc • Win32 API requires that the process make syscalls into NT kernel • Picoprocesses have a separate syscall dispatcher
  22. 22. Windows -> Linux Access • Limited information is available • Linux processes can not be debugged (OpenProcess fails) • Acceptable flags: (PROCESS_QUERY_LIMITED_INFORMATION | SYNCHRONIZE) • Without this Meterpreter’s migrate will not function • Low 8-bits of Linux process exit code can be retrieved with GetExitCodeProcess from Windows • dwStatus >> 8 • Windows user processes can obtain same info for “root” processes • The Windows permissions are effectively the same (Can’t write to %Systemroot%System32wbemMOF etc.)
  23. 23. Cross User Access • WSL Environments are specific to the user who started them • Hence the inherited permissions • Resources in one running WSL environment can not be accessed from another • Multiple invocations of “bash” as one user do share an environment • Files, processes, etc. are all inaccessible • Primarily relevant in multi-user environments like Server 2012
  24. 24. Closing Thoughts • “root” doesn’t mean much • Nuances in what root means and how its handled will be a source of user mistakes
  25. 25. References • https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/ • https://blogs.windows.com/windowsexperience/2016/04/06/announcing-windows-10-insider- preview-build-14316/ • http://research.microsoft.com/en-us/projects/drawbridge/ • https://blogs.windows.com/buildingapps/2016/03/30/run-bash-on-ubuntu-on-windows/ • https://github.com/Microsoft/BashOnWindows • https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/ • https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-calls/ • https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/
  26. 26. Thanks for your time! Spencer McIntyre @zeroSteiner github.com/zeroSteiner

×