Another day

Another day will be lost in code

Siri Validation Data and Access Token

Well Apple did some changes this week in the Siri protocol let analyse them

1. Apple sends a set activation token that is ignored by most devices using Spire, including the 4s
This doesn't affect much devices except that sometimes when they connect to other servers they need to delete the assistant.plist. Why? I gues because it wasn't activated before or something like that. Need more time to analyze the packets and find out why! (I was currently focused on the Validation expiration system)

2.The validation expiration

• Some time before when a device used invalid or expired 4s data and made a request to guzzoni servers, Guzzoni replied with Validation Expired or command Failed.
  This made it easy for proxies to detect these relies and set the invalid 4s key as expired!
• Apple changed the above method, in my opinion due to similar to DDOS attacks behavior when the Validation data where invalid!
  Now Guzzoni wont reply back to packets that have invalid or expired validation thus making it hard to detect invalid keys.

I made a work around this and i can find witch keys have expired with the help of packet analysis!
Lets see how this works: 

1. A device makes a request with a valid key. 

• Apple sends the activation token
• The proxy server detects the token and increases the total activation tokens for this key by one

2. A device makes a request with an invalid key

• Apple wont send the activation token
• The proxy server detects a finishspeech (waiting for recognition) request without an activation token, and increases the finishspeech requests for this key by one

3. When the Finishspeech requests are more than the sensitivity nubmer (5) and NO activation token is recieved then the key is marked as expired! 

In short, if a key is used and apple wont reply back after some tries (sensitivity) then the key is marked as expired. 

Its a complicated algo and this is a very short description of how this works!

Cheers,

Jimmy

Siri Protocol Exploit for multiple key generation

Requires JailBroken iPhone4s. 
This is a rally simple exploit.

Logic:

Every time an iDevice uses Siri for the first time or creates a new assistant in apple database, guzzoni replies with a property validityDuration  that tells for how long the generated validation data from the iDevice are valid.
Default reply on this by apple is: 90000 sec = 25h!!!

So response from apple is:


{"class"=>"CreateSessionInfoResponse",
 "properties"=>
  {"sessionInfo"=>
    "\x02\b N\xF7\x88o\t!\xEE\xE4w\x83\x1AH\x1E\x81\x00\x00\x00@\xEA\xE2\x17\x1F!\xD4\xF6%-\xB7\x0FRr\x8D\x1D\x9D\xDF\xE1@&=\x96\xEDkf(\xC6f\xA4\xDBl\xA5oE\xD1\x13\xE9G\xFEj\xA0\x83\xDF\xDB\xCE\xDA\x0F\xFE'\xB7p9\x8Egz\x14\xEA\xC0\xD3[t\xBCW\xE1\x01\xF0R]\xED\xF1\t\x87]5\xE9\x9Da{\xCC\x0F\x12z\xCF\xA9Y\x00\x00\x006\x05\x03\x8A\xC2\xD6w\xA6\xF5\xD8*4\\\xB8\xA2\xB2\xE7\x0F\x12O; \x95luD\x83:\xA3\xAC,,,.\x81\xF9\xE2i\xD6\xED\xCC\x9Ee9\xADuN\x83F[\x06\xC2\x8D2\xB2",
   "validityDuration"=>90000}


And we just change the validityDuration to whatever we please

This will force the 4S to regenerate its validation data every time it uses siri after the above elapsed time.

This can also probably (I haven't tested it!) be done by editing the assistant.plist on the 4S and setting the time to an expired point, eg 5 hours before, but may generate only one key. Repeat as pleased

Updated in TLP source here... 
And experimental source here...

The Three Little Pigs Authentication System

The Three Little Pigs Experimental Authentication System and Ban Protection ;-)

source on the experimental branch: https://github.com/jimmykane/The-Three-Little-Pigs-Siri-Proxy

The above bubble diagram explains how the authentication system works internally when the private mode is ON!!!

The authentication is based upon Appleid and contact card. This means that the user must have a apple iCloud id, and also must be using his contact card for Siri and have a clean assistant.plist

So lets see how the authentication system of The Three Little Pigs works in simple...

• There are 2 categories of Clients: New and Old! 
• When a new client connects his apple account id number, name, nickname and appledbid are inserted in the clients table in the database. By default the status of the client is set to invalid thus denying access!
  That's all for new clients. In other words the are just inserted to database (becoming old Client) and access is denied! 
• When an Old Client connects , the server checks if the Client is valid or not and denies or grants access to that user. 

How to use this? Right now there is no webgui for this and you will have to use phpmyAdmin or navicat in order to manually connect to the database set. A webinterface will be published soon when the beta is finished!

-----How to Use the Authentication Feature-----

• Step 1: Setup the server as normal and don't forget to put private mode to "ON" on the config.yml

• Step 2: Give the certificates and host to any people you like and dont worry if they share that. You can also put other protection methods on that like, passwords, udid etc. 

• Step 3: By now people will be trying to connect but with no luck and you will have the Client table populated with many records. Now you need to get in contact with the person that wants access, browse thought the database records, find his name or nickname, set him to valid='True' and done. If you can find the person, maybe he has the same name with some other and he doesnt have a unique nicknacme ask him to put one in his contact card, the one that he has put in Siri Settings for Siri to use. The record will be updated and thus you will be able to recognize that person on the database.Remeber each client is unique based upon appleid so don't worry about duplicate names etc

Info: Every client creates one or more Assistants in the assistant Table.
Every Assistant is linked to a client and has info on what device the client uses! :-)

Enjoy and keep in mind that this is a Alpha version of auth. Contact me for any problems in GITHUB https://github.com/jimmykane/The-Three-Little-Pigs-Siri-Proxy/issues  not in twitter etc because 140 characters cant hold the log :-)

----The banning system and ban protection - Happy hour---

Lets talk a little on the banning system. 

After working some time on public servers like http://www.paradox-productions.net I ve found out several interesting things. Lets take it from start:

• When a new device uses Siri for the first time, the first thing that happen is to create a record in Apple Siri DB, containing an Assistintid and speechID (unique for every user). This I call creation of Assistnt objects.This also happens when a user changes the Spire Host or deletes the /var/mobile/Library/Preferences/com.apple.assistant.plist 

• If you notice the devices that have never used Siri, or cant connect to a Server don't have the Assistantid and speechId in /var/mobile/Library/Preferences/com.apple.assistant.plist . These devices are not setup!  

• In order to create these records in Apple Siri Db the older devices use 4S validation data to get approved by Apple to connect to the servers! But there is a limit by apple on that.
• Eg. a 4S key can allow up to 15 simultaneous Assistant object creation. Then Apple replies with commandFailed, thus blocking new, or not setup devices to connect. (Also there is a weekly/dayly limit of ~=50 assistants or more)
• If you have the ban protection on in the TLP config.yml then when this happens, the key used for that is marked as banned because it cannot support any more not setup devices.
• When marked as banned this key is still used for processing speech packets but not used for new devices.
• After some time these keys become unbanned by apple, and thus again allowing of more new or non setup devices to create assistant objects. This is where the happy hour setting comes in place.
   
• The happy hour setting waits for 6 hours (or what you please) and then sets all non expired keys to unbanned! This allows again new or non setup devices to make requests for assistant object creation until apple banns them again.

So as far as banning is concerned and people that think that they got their 4S phones banned: ONE WORD: They are not banned but cannot create any more assistants because they are juiced out!
Keep the 4S key not shared for a while or turn on the banning system in the config.yml (default is ON)


Thank you,

Jimmy Kane

The Three Little Pigs Siri Proxy

The Three Little Pigs Siri Proxy
This Server is based on @kmsbueromoebel proxy combined with Plamoni's Siri Proxy 

Give them also gredits for this project








OS: Linux Prefered and tested
Language: Ruby/PHP 
Database support: My SQL
Demo-site: down for now! 


Version 0.8b 

*Updated with new Web-Interface! Thanks to @WouterDS
**Updated with plugins thanks to @thpryrchn

Features

• Plugins api and config capable (NEW).  Now Enjoy Your new plugins!
• E-Mail Notifications! (New)
• MySql Database connection support: Supports MySQL database connection for storing configuration,keys and runtime statistics.
• Multiple key support: You can connect more than 1 iPhone4S and store even more keys. The more the keys, the more the clients!
• Key Throttling: Each client uses a different key, if more than one Keys are available. The throttler makes sure that each Key is throttled thus enabling several client registration and assistant object creation.
• KeyLoad Safeguard: Never worry about how many people use your iPhone4S key. Each Key has a maximum keyload. Even when the key is still valid, if the keyload limit is exceeded, the safeguard disables the key and protects the iPhone4S from getting banned.
• KeyLoad Aware: Checks what key is not "Hot" anymore and periodically decreases the load, thus re-enabling Safeguarded Keys
• Web interface and monitoring: Always know what is happening without a CLI! With a web interface you can check statistics such as active connections, valid keys, server load, keyload etc.
• One certificate for all devices: Both Siri Capable devices (currently only iPhone4s) and older devices are using the same certificate and the same port (443 default for SSL)
• One instance of the server: Due to one certificate you can run only one instance of the server.
• Bug Free (I hope...):-) Never worry if the server has crashed. Most of the bugs that were causing the server to crash are fixed now.

Intro and how it works

This server uses a very simple but clever and precatius tactic to server a larger number of devices and at the same time protects the key.

I editing and forked  @kmsbueromoebel 's server just  because Apple followed a very bad tactic. That was Siri assistant  software restriction to older devices, done only for marketing reason (my humble opinion).

So lets get to the point how does this work?

Step 1: 

Lets say two Siri Capable Devices (currently only iPhone4s) connect to server. The server saves the keys on the Database. 

Each key has assistantid,speechid, sessionValidationData,expired,keyload and date_added columns. Lets see what they are about:

• assistantid - The assistant identifier. Unique for each device. In other words this defines your Siri and how it responds. eg. If I gave you my assistantid then Siri would get confused and sometimes respond to you with my nickname. Ugly.
  Although it's stored on the database its not used. Each older device that connects on the server creates a new assistantid via using the sessionValidationData.
• speechid - The speech identifier. Again unique for each device like above.
• sessionValidationData - The most importand field and the only thing needed for using siri on older devices. These validation data is a big string that gets generated every 24 hours on Siri Capable Devices via FairPlayed. These validation data allow only a small number of assistant's to be created and are somehow linked to the original Siri Capable Device
• expired - It changed to true when the sessionValidation Data (mentioned above) expire. Default value="False" as enum
• keyload - How much the key has been used. The default values is 0 and the maximum value is 1000. Each time a device connects and makes a session the keyload increases by 10. So each key can serve up to 100 connection sessions until it gets overloaded and pauses up for a period of time

Ok the keys are saved what now? 

• Each time a older device connects, the server finds the key with the least keyload and uses that to forge the packets with the sessionValidationData in order to be accepted by guzzoni.apple.com (Apple's siri servers)
• Each older device that connects uses the sessionValidationData to create a assistant.
• After the assistant is created it can use siri via the proxy for speech  recognition and views creation.
• When one of the keys are overloaded (reaches the keyload max values) the server then does not forge the packets thus stops misusement of  the key.
• After 15 minutes of  the overloaded key drops -100 lets another 10 sessions to be created and so on until the key expires.
• This helps a lot to pretend that its a normal everyday use (with some finetuning to the above values and limits) and spoofing/securing the Siri Capable Devices.
• Also a webgui can help you monitor the active concurrent connections, and all the above in realtime. You can forget ssh'ing to your VPS and using screen to view how the server is doing.

Tutorial: Get the Pigs Up and Running 

For a tutorial please refer to my github here

Enjoy!!!!!

That's it. If you like this project please support my work and others work by donations.

Dont forget to say a big thanks to @WouterDS who  created the web-interface and @thpryrchn  for the rake and gem guide

Credits,greetings and big thanks to all the following... (in line of order)
RESPECT

1. @plamoni
2. @kmsbueromoebel
3. @WouterDS
4. @thpryrchn
5. @Grant Paul (chpwn)
6. @Pod2g
7. @iH8sn0w
8. @MuscleNerd
9. @comex
10. @Zach Christopoulos
11. @Stan Hutcheon
12. @THiZIZMiZZ
13. @iP1neapple

SSH Cheat Sheet

SSH has several features that are useful during pentesting and auditing.  This page aims to remind us of the syntax for the most useful features.

NB: This page does not attempt to replace the man page for pentesters, only to supplement it with some pertinent examples.

SOCKS Proxy

Set up a SOCKS proxy on 127.0.0.1:1080 that lets you pivot through the remote host (10.0.0.1):

Command line:

ssh -D 127.0.0.1:1080 10.0.0.1

~/.ssh/config:

Host 10.0.0.1
DynamicForward 127.0.0.1:1080

You can then use tsocks or similar to use non-SOCKS-aware tools on hosts accessible from 10.0.0.1:

tsocks rdesktop 10.0.0.2

Local Forwarding

Make services on the remote network accessible to your host via a local listener.

NB: Remember that you need to be root to bind to TCP port <1024.  Higher ports are used in the examples below.

Example 1

The service running on the remote host on TCP port 1521 is accessible by connecting to 10521 on the SSH client system.

Command line:

ssh -L 127.0.0.1:10521:127.0.0.1:1521 user@10.0.0.1

~/.ssh/config:

LocalForward 127.0.0.1:10521 127.0.0.1:1521

Example 2

Same thing, but other hosts on the same network as the SSH client can also connect to the remote service (can be insecure).

Command line:

ssh -L 0.0.0.0:10521:127.0.0.1:1521 10.0.0.1

~/.ssh/config:

LocalForward 0.0.0.0:10521 127.0.0.1:1521

Example 3

In this example, 10.0.0.99 is a host that’s accessible from the SSH server.  We can access the service it’s running on TCP port 1521 by connecting to 10521 on the SSH client.

Command line:

ssh -L 127.0.0.1:10521:10.0.0.99:1521 10.0.0.1

~/.ssh/config:

LocalForward 127.0.0.1:10521 10.0.0.99:1521

Remote Forwarding

Make services on your local system / local network accessible to the remote host via a remote listener.  This sounds like an odd thing to want to do, but perhaps you want to expose a services that lets you download your tools.

NB: Remember that you need to be root to bind to TCP port <1024.  Higher ports are used in the examples below.

Example 1

The SSH server will be able to access TCP port 80 on the SSH client by connecting to 127.0.0.1:8000 on the SSH server.

Command line:

ssh -R 127.0.0.1:8000:127.0.0.1:80 10.0.0.1

~/.ssh/config:

RemoteForward 127.0.0.1:8000 127.0.0.1:80

Example 2

The SSH server will be able to access TCP port 80 on 172.16.0.99 (a host accessible from the SSH client) by connecting to 127.0.0.1:8000 on the SSH server.

Command line:

ssh -R 127.0.0.1:8000:172.16.0.99:80 10.0.0.1

~/.ssh/config:

RemoteForward 127.0.0.1:8000 172.16.0.99:80

Example 3

The SSH server will be able to access TCP port 80 on 172.16.0.99 (a host accessible from the SSH client) by connecting to TCP port 8000 on the SSH server.  Any other hosts able to connect to TCP port 8000 on the SSH server will also be able to access 172.16.0.99:80.  This can sometimes be insecure.

Command line:

ssh -R 0.0.0.0:8000:172.16.0.99:80 10.0.0.1

~/.ssh/config:

RemoteForward 0.0.0.0:8000 172.16.0.99:80

Configuration Files

~/.ssh/config

It’s sometimes easier to configure options on your SSH client system in ~/.ssh/config for hosts you use a lot rather than having to type out long command lines.

Using ~/.ssh/config also makes it easier to use other tools that use SSH (e.g. scp and rsync).  It’s possible to tell other tools that SSH listens on a different port, but it’s a pain.

Host 10.0.0.1
Port 2222
User ptm
ForwardX11 yes
DynamicForward 127.0.0.1:1080
RemoteForward 80 127.0.0.1:8000
LocalForward 1521 10.0.0.99:1521

The above lines are explained more fully in the other subsection on this page.

~/.ssh/authozied_keys

During a pentest or audit, you might want to add an authorized_keys file to let you log in using an SSH key.

The authorized_keys file lives in a user’s home directory on the SSH server.  It holds the public keys of the users allowed to log into that user’s account.

Generate a public/private key pair like this:

ssh-keygen -f mykey
cat mykey.pub # you can copy this to authorized_keys

If you want to shortest possible key (because your arbitrary-file-write vector is limited), do this:

ssh-keygen -f mykey -t rsa -b 768
cat mykey.pub # copy to authorized_key.  Omit the trailing user@host if you need a shorter key.

Connect to the target system like this (you need to know the username of the user you added an authorized key for):

ssh -i mykey user@10.0.0.1

Caveat: The authorized_keys file might not work if it’s writable by other users.  If you already have shell access you can “chmod 600 ~/.ssh/authorized_keys”.  However, if you’re remotely exploiting an arbitrary file-write vulnerability and happen to have a weak umask, you may have problems.

X11 Forwarding

If your SSH client is also an X-Server then you can launch X-clients (e.g. Firefox) inside your SSH session and display them on your X-Server.  This works well with from Linux X-Servers and from cygwin‘s X-server on Windows.

Command Line:

SSH -X 10.0.0.1
SSH -Y 10.0.0.1 # less secure alternative - but faster

~/.ssh/config:

ForwardX11 yes
ForwardX11Trusted yes # less secure alternative - but faster

SSH Agents

SSH agents can be used to hold your private SSH keys in memory.  The agent will then authenticate you to any hosts that trust your SSH key.

This has the following advantages:

• You don’t have to keep entering your passphrase (if you chose to encrypt your private key)
• But you still get to store your private SSH key in an encrypted format on disk.

Using an SSH agent is probably more secure than storing your key in cleartext, but agents can be hijacked.

Using an SSH Agent

First start your agent:

eval `ssh-agent`

Then add your keys to it – you’ll need to enter your passphrase for any encrypted keys:

ssh-add ~/dir/mykey

Hijacking SSH Agents

If you see SSH agents running on a pentest (process called “ssh-agent”), you might be able to use it to authenticate you to other hosts – or other accounts on that host.  Check out ~/.ssh/known_hosts for some ideas of where you might be able to connect to.

You can use any agents running under the account you compromised.  If you’re root you can use any SSH agent.

SSH agents listen on a unix socket.  You need to figure where this is for each agent (e.g. /tmp/ssh-tqiEl28473/agent.28473). You can then use the agent like this:

export  SSH_AUTH_SOCK=/tmp/ssh-tqiEl28473/agent.28473
ssh-add -l # lists the keys loaded into the agent
ssh user@host # will authenticate you if server trusts key in agent

This command illustrates how you could inspect the environment of every ssh-agent process on a Linux system.  It should yield a list of unix sockets for SSH agents.

ps auxeww | grep ssh-agent | grep SSH_AUTH_SOCK | sed 's/.*SSH_AUTH_SOCK=//' | cut -f 1 -d ' '

Agent Forwarding

If you enable SSH agent forwarding then you’ll be able to carry on using the SSH agent on your SSH client during your session on the SSH server.  This is potentially insecure because so will anyone else who is root on the SSH server you’re connected to.  Avoid using this feature with any keys you care about.