XENGUARD
LOGIN
e-mail
password
Don't have an account? Register now!

Xenguard tests the ultimate high-gain antenna

posted 2018-05-15 21:10:42 by zac

Xenguard researchers deployed this huge antenna in downtown Toronto. We collected information on approximately 40,000 people and analyzed 72 terabytes of data daily, while testing our Xenguard Agent software for a consulting project.

This is a 24 dBi antenna with a 130 degree beam. It's a good choice for point-to-point connections between line-of-sight nodes with appropriate mounting locations. It also makes a superb surveillance antenna for wide-area analytics, pulling in signals from condos and office buildings several kilometers away. During busy periods, our system detected over 2,000 people at one time. We captured information about the demographics and behaviors of the residents, visitors and shoppers in the Queen West area.

 

The amount of data our system provides about the environment, it's infrastructure and the human beings who travel carrying smart devices is absolutely staggering.

Specialized wireless equipment, like this huge antenna, can help provide deeper, more accurate analytics or deliver reliable wireless services over a large area.

This antenna could in theory handle several hundred watts of output power (if that were permissible under DoC regulations). For this test we operated in passive monitoring mode. One aspect that really affects the performance of Xenguard data collection is that we don't need a good signal between us and the wireless device -- we can analyze data as a "man in the middle". Devices entering coffee shops and offices five blocks away are reliably tracked.

Contact Xenguard for advanced wireless location analytics technology at more affordable prices than Cisco or Aruba.

reply to this article

Xenguard tests the ultimate high-gain antenna

posted 2015-01-03 11:31:38 by core

Every 27 seconds. Minute after minute, hour after hour, day after day, week after week, month after month. Canadian telecommunications providers, who collect massive amounts of data about their subscribers, are asked to disclose basic subscriber information to Canadian law enforcement agencies every 27 seconds. In 2011, that added up to 1,193,630 requests. Given the volume, most likely do not involve a warrant or court oversight (2010 RCMP data showed 941002172565f requests involving customer name and address information was provided voluntarily without a warrant).

In most warrantless cases, the telecommunications companies were entitled to say no. The law says that telecom companies and Internet providers may disclose personal information without a warrant as part of a lawful investigation or they can withhold the information until law enforcement has obtained a warrant. According to newly released information, three telecom providers alone disclosed information from 785,000 customer accounts in 2011, suggesting that the actual totals were much higher. Moreover, virtually all providers sought compensation for complying with the requests.

These stunning disclosures, which were released by the Office of the Privacy Commissioner of Canada, comes directly from the telecom industry after years of keeping their disclosure practices shielded from public view. In fact, the industry was reluctant to provide the information to even the Privacy Commissioner.

According to correspondence we obtained under the Access to Information Act, after the Commissioner sent letters to the 12 biggest telecom and Internet providers seeking information on their disclosure practices, Rogers, Bell and RIM proposed aggregating the information to keep the data from individual companies secret. The response dragged on for months, with Bell admitting at one point that only four providers had provided data and expressing concern about whether it could submit even the aggregated response since it would be unable to maintain anonymity.

The correspondence also confirms that the telecom providers were concerned about how the government and law enforcement would react to public disclosures. In one email, Bell says that "we are walking a delicate line between supporting privacy and not antagonizing Public Safety/LEAs [law enforcement agencies], so the materials will be pretty factual, not much commentary."

While the current situation, which amounts to disclosure of subscriber information thousands of times each day often without a warrant, is enormously problematic, the situation is about to get even worse. First, Bill C-13, the government's lawful access bill that heads to committee this week, will expand warrantless disclosure of subscriber information to law enforcement by including an immunity provision from any criminal or civil liability (including class action lawsuits) for companies that preserve personal information or disclose it without a warrant. The immunity provision makes it more likely that disclosures will occur without a warrant since the legal risks associated with such disclosures are removed.

Second, Bill S-4, the newly-introduced Digital Privacy Act, proposes extending the ability to disclose subscriber information without a warrant from law enforcement to private sector organizations. The bill includes a provision that allows organizations to disclose personal information without consent (and without a court order) to any organization that is investigating a contractual breach or possible violation of any law. This applies both past breaches or violations as well as potential future violations. The disclosure occurs in secret without the knowledge of the affected person.

Third, the industry has steadfastly refused to address the lack of transparency concerns regarding its practices. Providers admit that they do not notify customers that their information has been requested, thereby denying them the ability to challenge the demand in court. Moreover, documents released earlier this year suggested that companies such as Bell have even established a law enforcement database that may provide authorities with direct access to subscriber information. The systems may create great efficiencies for law enforcement - click, access subscriber data, and receive a bill from the telecom company - but they suggest a system that is entirely devoid of oversight with even the Privacy Commissioner excluded from ensuring compliance with the law.

reply to this article

Xenguard tests the ultimate high-gain antenna

posted 2014-12-26 10:06:31 by core

1. Instant messaging eavesdropping

For years now, every time a new instant messaging service has risen, lot of people ask questions about its security. Remember BlackBerry or Skype at the beginning, they claimed to be encrypted thus secure, impossible to eavesdrop. Years later, answers are coming from everywhere to deny that. For people working in the security industry, this is not a surprise. It is the role of a government to ensure security of people, and governments need ways to eavesdrop dangerous people. The question is more ethic than legal, and deals with the power given to intelligence agencies.

Recently, Snowden's leaks showed it was even worse than what many people imagined: crypto standard backdoored, collusion with major companies, massive data collection, intrusion everywhere, ... Despite that context and the legitimacy for government to practice lawful interception, all companies involved tried to minimize their role, and used a simple excuse: we just followed the law. However, one company has claimed it was impossible for them to eavesdrop their own instant messaging, and thus they are unable to collaborate with US government, even if requested to do so.

After Snowden's leaks, Apple published a statement, called Apple’s Commitment to Customer Privacy. As questions were around for some time on iMessage, Siri or Facetime, they clearly answered :

There are certain categories of information which we do not provide to law enforcement or any other group because we choose not to retain it. For example, conversations which take place over iMessage and FaceTime are protected by end-to-end encryption so no one but the sender and receiver can see or read them.Apple cannot decrypt that data.

According to that statement, Apple can provide some metadata (who sends a message to who, the date, ...) but the content of a conversation would be excluded. We will show in this article it is not true. Apple can get access to encrypted message, despite end-to-end encryption. Does it mean they do it? Only Apple and some 3 letters agencies can answer, we can not.

Now, let's go into the details of our analysis.


2. Lack of certificate pinning: so what?

First thing first, we notice than pretty much all the traffic is encrypted. Good point. All communications to Apple's servers are made through a secure SSL tunnel. We do not need to know what protocol is used or how packets are forged. The first thing we want to try when we see that is adding a certificate to perform a MITM. We were actually very surprised it worked as easily, which means there is no certificate pinning. We created a fake CA, and added it to the iPhone keychain. Then, we could proxify communications much more easily. When a SSL communication arrives to the proxy, we generate a certificate signed by the newly added CA, and everything becomes unencrypted.

Second surprise was actually bigger: we saw our AppleID and password going through this SSL communication. Yes, the clear text password... There can be a lot of good reason to send the password as cleartext, ssh does it for instance. But here, we dont see any reason for Apple to get our password.

Firstly, it means that Apple can replay our password using for instance our email also on many websites. Ok, Apple has no reason to do so. But what of intelligence agencies? Secondly, it also means that anyone capable of adding a certificate and able to proxify the communications can get user's AppleID and password, thus get access to iCloud accounts, backups, buy apps, ....

Here is an example of what we get:

POST /WebObjects/VCProfileService.woa/wa/authenticateUser
'content-length': 223,
'accept-language': en-us,
'accept-encoding': gzip,
'content-encoding': gzip,
'host': service.ess.apple.com,
'accept': */*,
'user-agent': com.apple.invitation-registration [Mac OS X,10.8.3,12D78,Macmini4,1],
'connection': keep-alive,
'x-protocol-version': 7,
'content-type': application/x-apple-plist,
'x-ds-client-id': t:3A5DC02C47249FC50EF0FF1B8CF3073C9EBD0668

And here are content of posted data:

<plist version="1.0">

    password
    Icandoaproperkeynote
    username
    tim_c@icloud.com


We tried to play with the certificates for a while. We came up with iPhone Configuration Utility. This software is Apple's solution for enterprise to manage their iPhone. When this software is used for the 1st time and a device is plugged, a CA is added to the device. MDM administrators can do this transparently to enrolled devices

The consequence is that in a company where iPhones are managed by IT, they want to setup a proxy and invisibly proxify communications from / to the iPhone, thus gain access to very personal information. Note the certificate pinning is not performed at any layer, PUSH or iMessage, so various problems can happen here and there.


3. The protocols: the client, PUSH & ESS servers

In this part, we will describe the usual process, with all the protocols and cryptographic steps involved.


3.1 The client on the device

Each device has its own certificate, which is 1024 RSA with a CN= (obviously, GUID has to be replaced with device's GUID). The client is MobileSMS / Message.app, but this application also relies on other services. The 2 mains are:

  • apsd: the Apple PUSH server daemon, in charge of carrying the messages from Apple to the devices.
  • imagent: the background process for iMessage tasks, like keeping connection when app is closed, etc.

When a message is sent to someone, Apple is in charge of transporting the message. It means 2 things:

  • Given a destination address (an URi, it can be a phone number or an email for instance), Apple has a way to link it with all devices related to that URI (iPhones, iPads or OS X systems).
  • Once Apple knows all the devices involved, Apple brings the message to the proper devices.

Let's start with the second point, the transport protocol, called PUSH.


3.2 The PUSH protocol

PUSH protocol has been designed as a remote notification protocol over networks. It is used for iMessage of course, but also for FaceTime, GameCenter or by send party application when they want to notify of an event. Think about Facebook, Whatsapp or any news application notifying you than something just happened. Each time, it is based on the very same protocol, PUSH.

Here is how Apple defines it:

Local and push notifications are great for keeping users informed with timely and relevant content, whether your app is running in the background or inactive. Notifications can display a message, play a distinctive sound, or update a badge on your app icon.

PUSH behaves as a transport protocol, in charge of delivering a payload, whatever it is, to set of devices. Hence, iMessage itself is a payload in regard of the transport protocol.

All PUSH communications are made in TLS to server port 5223 when it comes to iMessage:

  • Hostnames are taken from [0, ..., 255]-courier.push.apple.com
  • The client certificate, specific to a device, which is explained right after.

The client certificate

The PUSH certificate is generated when the device is registered and activated at Apple. During the 1st connection to Apple's server, a certificate request is sent to albert.apple.com. This server runs a certificate authority, called Apple Iphone Device CA, in charge of signing every request.

This certificate is very sensitive as it is the one in charge of ALL PUSH communications from the device: PUSH communications are secured with it, with both client and server authentication.

As such, this certificate is not directly involved in iMessage, but since iMessage is carried over PUSH, it has a role to play anyway.


The Push-Token

From the PUSH layer, how it works is kind of magic known only by Apple. From client side, here is what we see. First, we write a message, and press the send button. Doing so, the client requests from Apple's ESS servers the information needed to send the message. The ESS Server sends back 3 pieces of information:

  • A Push-Token, which is a unique identifier for a pair iDevice.
  • Two cryptographic keys we will describe right after.

The Push-Token is computed by Apple when a device registers to the service. The generation of the Push-Token is defined as opaque by Apple since it is made server side, same goes for its precise usage. For now, we see it as the registration of a provider and a routing information.

As a provider because one needs to register itself as a iMessage provider, but also as a routing information because Apple needs to know where to deliver the messages. As a matter of fact, Apple fanatics users often have more than one device, and a iMessage must be delivered to all the devices at once.

So, when the client sends one message, it actually sends as many messages as the recipients has Push-Tokens, so that the message can be delivered to each iDevice. These messages are sent to the Apple Push Network Service (APNS) through a gateway on port 5223 as explained earlier.

For instance, on a OS X system, one can see:

root@joker:~>> ps aux |grep apsd
root 90 0.0 0.1 2467868 8052 ?? Ss Thu09AM 0:06.06 /System/Library/PrivateFrameworks/ApplePushService.framework/apsd
root 20295 0.0 0.0 2432768 588 s003 S+ 3:08PM 0:00.00 grep apsd
root@joker:~>> lsof -p 90 |grep TCP
apsd 90 root 9u IPv4 0x667b30bc14a94f93 0t0 TCP joker.lan:65158->17.172.232.179:5223 (ESTABLISHED)
root@joker:~>> whois 17.172.232.179
NetRange:       17.0.0.0 - 17.255.255.255
CIDR:           17.0.0.0/8
OriginAS:
NetName:        APPLE-WWNET
NetHandle:      NET-17-0-0-0-1
Parent:
NetType:        Direct Assignment
RegDate:        1990-04-16
Updated:        2012-04-02
Ref:            http://whois.arin.net/rest/net/NET-17-0-0-0-1
OrgName:        Apple Inc.
OrgId:          APPLEC-1-Z
Address:        20400 Stevens Creek Blvd., City Center Bldg 3
City:           Cupertino
StateProv:      CA
PostalCode:     95014
Country:        US
RegDate:        2009-12-14
Updated:        2011-03-08
Ref:            http://whois.arin.net/rest/org/APPLEC-1-Z
...

When the APNS servers receive that, PUSH magic comes into play. That is not described in the documentation, but we can assume, reading from that Apple relies on a connection between the APNS and the devices. Based on the Push-Token for each message, Apple is able to select to what device a PUSH notification must be sent to.


MITM at the PUSH layer

What about attacking that PUSH layer? Attacking it means being in between the client and Apple' servers in order to read the messages. But since the communication relies on TLS, some efforts are needed to provide certificates.

There is a very convenient tool for that: PushProxy. It provides a simple API to mess with both received and sent messages. Since a lot a prerequisites are needed to perform that on a real communication, we will work locally on the device itself for now.

First, we need to add a root CA to the system's keychain, so that proxy's certificates are trusted. That way, the real client will trust the messages from the proxy. This is easy, but we also need to communicate with Apple. And as we said, the authentication is mutual, so we need either to inject a new certificate to albert.apple.com, or to use an already signed certificate.

We pick the 2nd option: we extract the private part of the device's PUSH certificate and give it to the proxy. Last but not least, we need to redirect all connections to the proxy, which we did by modifying the /etc/hosts file of the device.

We are now ready to see what is in the PUSH messages. So, the PUSH layer of an iMessage payload looks like that (XX bytes are not set as they depends on the content of the message):

0a                    >> Message Type
XX XX XX XX           >> Next Length
04 00 04 XX XX XX XX  >> Identifier (4 bytes)
01 00 14 XX .. .. XX  >> Topic Hash (20 bytes)
02 00 20 XX .. .. XX  >> Push-Token (32 bytes)
03 XX XX ...          >> iMessage payload

Before going into iMessage payload, we need to give a brief explanation on iMessage IDs.


3.3 The iMessage IDs

From now on, we will refer to iMessage simply as IM. There are a lot of information involved at the IM layer:

  • AppleID: as already explained, that is the very heart of an account for Apple.
  • URI: same format as an AppleID, which is either an email address or a phone number. One AppleID can have several URI. When it is an email, it is verified with a link to click. When it is a phone number, they are authorized only from the SIM card.
  • Push-Token: as explained earlier, it is used for iMessage to identify a device on which an URI is registered. As such, a Push-Token is unique for each URI used on a device.

3.4 Sending an iMessage

When a user wants to send an iMessage, he firstly provide one or several destination URI. Since the communication is end-to-end encrypted, it means either the devices directly exchange the needed keys, or there is a key directory involved somewhere.

There is actually such a directory, called ESS servers (dont ask us what ESS stands for, ask Apple). So, to retrieve the keys, the iDevice sends the following request to the server:

GET /WebObjects/QueryService.woa/wa/query?uri=tel:+33123456789
'Host': service1.ess.apple.com
'Content-Type': application/x-apple-plist
'x-id-cert': [Provision Certificate]
'x-id-nonce': [Random Nonce with Timestamp]
'x-id-sig': [Query Signed with Provision Cert.]

In this example, the iDevice wants to retrieve the keys for URI "+33123456789".

It is important to notice this request is signed with yet another certificate, called Provision. This certificate is generated client-side, and signed by the authority called Apple IDS DS-ID Realm CA during iMessage authentication. It is valid for one month.

The corresponding answer looks like:

{
  'push-token': [PushToken]
  'client-data':
  {
    'show-peer-errors': True,
    'public-message-identity-version': 1.0,
    'public-message-identity-key': [Public Keys Buffer]
  }
}

It is actually a XML plist. We converted it to JSON to make it more readable. In our example, there is only one identity returned. However, if the destination URI have several devices and registered accounts under his AppleID, the same information would be given for each of them.

The answer contains the Push-Token, well-known now. But it also carries a buffer full of public keys:

  • One ECDSA (256-bit) used to verify the signature of messages sent by the destination URI on this device. That way, when the destination URI replies, we'll already have the ECDSA key to check the signature.
  • One RSA (1280-bit) used to encrypt iMessage sent to the destination URI.

With both these keys, we can setup a secured (?) communication with the destination URI, and all the related devices.


3.5 The iMessage Payload

We finish our explanation of the PUSH protocol by providing an iMessage payload. Now, we will see what this payload is made of.

This payload is in an Apple specific format, called bplist (binary-plist). It is designed to embed serialized data as dictionary. Several kinds of data are defined, including the usual ones: NSString, NSNumber, NSDate, NSArray, NSData and NSDictionnary, and so on.

Here is an example of such a bplist:

D:   True
E:   'pair'
P:    (iMessage payload, deflate compressed)
U:    (iMessage UID)
c:   100
i:    (messageId, same as in PUSH header)
sP:  mailto:tim_c@icloud.com  (sender URI)
t:    (sender Push-Token)
tP:  mailto:mark_z@facebook.com (receiver URI)
ua:  [Mac OS X,10.8.5,12F37,MacBookPro10,2] (sender OS and hardware version)
v:   1

The ua field is totally useless but is sent on every request, for Apple statistics?

Anyway, the P field is the IM payload. It is encrypted then compressed (yes, yes, encrypted first, compressed after). It is composed with the following keys:

(byte)     0x02          version?
(short)    ciphertext    length
(data)     ciphertext    RSA / AES-CTR data : ciphered with the RSA public key of the recipient
(byte)     signature     length
(data)     signature     ECDSA signature of  : computed with the ECDSA private key of the emitter

In cleartext, the data is also a bplist, which we called inner bplist:

p: array of URIs in the discussion group
t: iMessage text (for iOS)
v: version (1)
x: iMessage html (attachments, and style - for OS X)

Let's spend some lines on the RSA / AES-CTR data. This data is the actual message sent to the target (the URIs, the message itself, attachment if any). Let us describe how it is built:

  1. Let's call ibplist the cleartext data.
  2. A 16 random byte are generated to be the AES key.
  3. The data is encrypted with AES in CTR mode, giving AES(ibplist)
  4. The 128-bit key is put at the beginning of the output buffer

5. The 128-bit key and 808-bit of AES encrypted data are ciphered with RSA-1280 using a public exponent of 65537 and PKCS1 OAEP padding. It gives a 1280-bit buffer.

  1. That buffer is then signed with the owner's ECDSA key.

The RSA key used here is the one retrieved from ESS server, as mentioned above.


Sending attachment with iMessage

As most instant messaging service, iMessage allows to send attachment. Most of the time, people are sending picture from their iPhone. But any kind of file can actually be used.

When an attachment is sent, it is actually stored on iCloud servers, on a dedicated repository. The attachment is encrypted with AES, and the key is sent to the destination as payload in the iMessage, altogether with the link to the file. Since this is encrypted with the destination RSA key, this is as safe as the RSA key itself.

All this is performed with the in the HTML message:

<file
   name=""
   width=""
   height=""
   datasize=""
   mime-type=""
   uti-type=""
   mmcs-owner=""
   mmcs-url=""
   mmcs-signature-hex=""
   file-size=""
   decryption-key=""
/>

Note that it seems to be OS X specific.


Easter eggs or tricks

  • Adding a subject: there is an option to add a subject to the iMessage in the configuration panel. This is triggered with the s key and a text to the inner plist.
  • For IRC geeks, /me is working ... only on OS X. Send a message starting with "/me" and it will be displayed differently on OS X and iOS.
  • The existence of a URI is not verified in the discussion group, which means you can add fake URI. Of course, a real URI has to be in the list but you can then make believe to the destination you actually send an iMessage to Tom Cook for instance.

4. MITM attacks

iMessage is complex because it relies on PUSH and a lot of crypto is involved at all layers. In this section, we will study what are the conditions to perform a MITM attack on iMessage, now that we hopefully made the protocol less opaque.

In order to do that, we will set an attacker in various positions: between the sender and Apple, between Apple and the receiver. If you want a quick and dirty overview, you might want to have a look at our original paperwork describing the MITM.


4.1 Test protocol

As we have seen, the 2 main services for iMessage are the PUSH servers and the ESS ones. So, in order to perform any attack, we need to impersonate these servers. There are lots of ways to do that, from ARP spoofing to injecting BGP routes (if you can), but we simply keep playing with /etc/hosts, as for the PUSH proxy earlier.

Here are the tools we used:

  • Python to be able to run following tools
  • PushProxy with Quarkslab’s imessage-mitm.py handler to intercept iMessages
  • Quarkslab’s ess-mitm.py to intercept and modify Apple ESS responses
  • A DNS proxy software. We used dnschef.

From the crypto point of view, we added a root CA to the target keychain so that we are able to serve our own certificates with no complaint from the iDevice.

From there, we have all our tools running locally, we are ready.


4.2 One-sided MITM

Here, the attacker is between the sender and Apple's server, on sender's iDevice. Let's call the sender Dhillon, and the receiver Belinda. We will explain step by step how it is going on. An evil guy called Evil, is in the middle.

First, let's start with the emission of a message:

  1. Dhillon writes a message to Belinda.
  2. Dhillon's iDevice makes a request to ess.apple.com
  3. Evil intercepts that request:
  1. Evil requests from ess.apple.com Belinda's information (Push-Token, RSA and ECDSA keys)
  2. Evil replaces Bel's RSA and ECDSA keys with his own
  1. Dhillon sends his message to Belinda: it is encrypted with assumed Bel's RSA (Evil's actually) key, signed with Dhillon's ECDSA key.
  2. Evil intercepts the IM payload:
  1. He can decrypt it with his own key
  2. He can alter it and recipher it with Belinda's real RSA key
  3. Since he is on the device, he can use Dhillon's ECDSA private key to re-sign the message.
  1. Belinda gets the message, it is properly signed and she can read it.

As everyone can notice, a very strong requirement here is that the attacker, Evil, gets access to sender's ECDSA private key.

Let's see now what is happening when Belinda is answering to the message:

  1. Belinda writes a message.It is ciphered with Dhillon's RSA key, and signed with Belinda ECDSA key.
  2. The message is sent to Apple Push servers, then to Dhillon's mobile
  3. Evil intercepts that message:
  1. Evil can decrypt the message as he has access to Dhillon's RSA private key.
  2. Evil can change the message, and recipher with with Dhillon's RSA public key.
  3. Evil signs the modified message with his own ECDSA key as Dhillon's believe it is Bel's (see step 3.2 in the previous description).
  1. Dhillon receives the forged message:
  1. He checks the signature with Evil's ECDSA key (believing it is Bel's): everything is fine.
  2. He decipher the message with his own private RSA key.

Once again, in reception, there is a strong requirement: the attacker, Evil, needs to get access to the RSA private key.


4.3 Two-sided MITM

Now, we are thinking big: we want to perform a MITM on Dhillon and Belinda at the same time. So, we assume now that Evil is running his MITM on both Dhillon's and Belinda's iDevice.

As example, Dhillon is sending a message to Belinda:

  1. Dhillon writes a message to Belinda.
  2. Dhillon's iDevice makes a request to ess.apple.com
  3. Evil intercepts that request:
  1. Evil requests from ess.apple.com Belinda's information (Push-Token, RSA and ECDSA keys)
  2. Evil replaces Bel's RSA and ECDSA keys with his own.
  1. Dhillon sends his message to Belinda: it is encrypted with assumed Bel's RSA (Evil's actually) key, signed with Dhillon's ECDSA key.
  2. Evil intercepts the IM payload:
  1. He can decrypt it with his own key
  2. He can alter it and recipher it with his own key.
  3. He signs with his own key too.
  1. The message is sent to APSN and delivered to Belinda's device.

Since Evil is now on both side, things are symmetric here, so let's go:

  1. Evil receives the message on Bel's iDevice.
  2. Evil deciphers the payload with his own RSA private key.
  3. Evil encrypts the message with Bel's RSA public key.
  4. Evil signs the encrypted message with his own ECDSA key, since he provided this key to Belinda presenting it as Dhillon's.
  5. Evil delivers the message to Belinda
  6. Belinda checks the signature, which is ok and appears to be from Dhillon (since it has been signed with Evil's key, which is Dhillon's ECDSA alleged key).
  7. Belinda deciphers the message.

The main requirement here is for Evil to be, at the same time, in between Dhillon and Apple on on end, and Belinda and Apple at the other end. Still a strong requirement for most attackers, but we didn't need users' private keys anymore!


4.4 MITM by replacing Apple

Let us perform an excise assuming an attacker is able to replace Apple to perform the MITM. This assume huge requirements:

  • Huge network control to redirect the traffic of the iDevice (through DNS or whatever).
  • Verified PUSH and ESS certificates, for each target.

Clearly, not the many people have such capabilities. Maybe 3 letters agencies... Who knows.

How would it work? Like a classical MITM:

  1. Evil gives his RSA and ECDSA to Dhillon
  2. Evil gives his RSA and ECDSA to Belinda
  3. When Dhillon sends a message, Evil can read it, change it and resign it before passing it to Belinda
  4. When Belinda receives it, she deciphers the message with her RSA key, and check the signature with Evil's ECDSA key, even through she believes it is Dhillon's.

Since, Evil is really in the middle, things are the same when Belinda answers to Dhillon:

So, what are the requirements here:

  1. For that to work, he needs a valid CA in the devices of the targets.
  2. The attacker needs to redirect the traffic from both targets to himself.
  3. He needs to provide keys to each target impersonating the other end of the communication.

Obviously, this attack is not realistic for the average attacker.


4.5 MITM being Apple, or why end-to-end encryption is not enough

Actually, not all attackers can fulfill the above requirements. But now, let's have a look at Apple's position there:

  1. For that to work, he needs a valid CA in the devices of the targets.

    > Apple has such a certificate.

  2. The attacker needs to redirect the traffic from both targets to himself.

    > Apple does not need to do that since all traffic is going anyway through the PUSH server.

  3. He needs to provide keys to each target impersonating the other end of the communication.

    > Apple owns the key server, ESS.

So, definitely, Apple can perform the MITM, they just have to tamper with the keys the send to the targets. Then, you remember how iMessages are encrypted: a RSA key encrypts an AES key.

Since Apple can change the keys, Apple can then decrypt the AES key, and as a consequence, the content of the message.

Remember Apple's statement:

For example, conversations which take place over iMessage and FaceTime are protected by end-to-end encryption so no one but the sender and receiver can see or read them.Apple cannot decrypt that data.

So, yes, there is end-to-end encryption as Apple claims, but the key infrastructure is not trustworthy, so Apple can decrypt your data, if they want, or more probably if they are ordered to.


5. Preventing MITM from Apple or others

There are actually not that many solutions. The main problem here comes from Apple as they control the key infrastructure. So, the 2 solutions are:

  1. Make the key infrastructure less opaque and more public
  2. Encrypt message with key not controlled by Apple.

These 2 solutions are under active development. Stay tuned for more information.


5.1 iMITMProtect

We have developed a simple Mac OS X application, iMITMProtect which hooks some functions involved on iMessage. The application is very simple / stupid:

  • When Push-Tokens and keys are received, they are stored in a local database.
  • Each time a token or a key is received, we look up for the corresponding URI in the database, and check it is the same or not. If not, Houston, we have a problem.

As soon as a jailbreak will be available, we will port it as a Cydia package.


5.2 iMessage over-encryption

If one considers iMessage as an insecure channel, the solution is to encrypt the data sent to that channel. Setting up such an encryption is not easy, even without considering the General Conditions of Use.

We cant say more on that now, except it is tricky!


6. Last words

Apple's claim that they cant read end-to-end encrypted iMessage is definitely not true. As everyone suspected: yes they can!

Suspecting is not knowing, and we hope to have dig enough in the protocol to show how Apple could do it.

But shall we continue to use iMessage? MITM attacks on iMessage are unpractical to the average hacker, and the privacy of iMessage is good enough for the average user.

If the informations being exchanged are sensitive to the point that you don’t want any government agencies to look into them, don’t.

Apple, make a more transparent PKI and document the protocol, and it could be considered the most practical and secure real-time messaging system available.


Can Apple read your iMessages? A fast answer.

Yes.

You should skip this part if you dont want to spoil the details. If you are in a hurry and just want the answers, this part is for you. We have analyzed iMessage, Apple's instant messaging service, wondering: how to eavesdrop iMessage.

Here are the facts:

  • Involved cryptography is based on well-known algorithms (AES, RSA, ECDSA) with proper key sizes and implementation.
  • Code in charge of key generation is open source.
  • No certificate pinning is performed between client and PUSH servers (Apple's servers involved in iMessage).
  • Authentication between client and Apple's servers is protected with strong obfuscation and whitebox cryptography, preventing the development of 3rd party iMessage clients.
  • User password is sent clear-text through a secure SSL channel to Apple. This is clearly an issue for people using the same password at several places (mail, bank, whatever) as Apple knows this password.
  • No pinning + cleartext password means that if somebody manages to add a certificate in a device, he can perform a MITM, thus get the user's AppleID and password. That is the key to everything belonging to the user.
  • Bonus: if the device is connected to iPhone Configuration Utility, Apple's enterprise solution for management of iPhones, a trusted CA is added. Consequence is that all subsequent certificates signed by that CA will be trusted to create the SSL communication. It means all companies using that are able to retrieve their employee's AppleID and password by simply proxifying the SSL communication.
  • iMessage is carried over Push protocol, the very same protocol used but FaceTime, GameCenter or notification services.
  • PUSH is tunneled inside SSL to Apple's PUSH servers on port 5223.
  • Every Apple device is identified by a unique Push-Token.
  • When someone sends one message, the client looks for all Push-Tokens related to that destination (called an URI) to transport the message to every device where the URI is registered.
  • When one sends an iMessage, the client firstly connects to an Apple key server, called ESS, to get the target public keys.
  • The clients retrieves 2 keys:
  • One ECDSA (256-bit) used to verify the signature of messages sent by the destination URI on this device. That way, when the destination URI replies, we'll already have the ECDSA key to check the signature.
  • One RSA (1280-bit) used to encrypt iMessage sent to the destination URI.
  • The iMessage payload is actually a binary plist, designed to embed serialized data as dictionary.
  • The iMessage payload is encrypted with a random AES key, the key is appended at the beginning of the encrypted payload, the 1280 first bits are encrypted with destination RSA key.
  • Every message is signed with sender ECDSA key.
  • iMessage can be used to send attachment. They are stored on iCloud, encrypted with an AES session key as explained above.
  • Since Apple controls ESS servers, and all iMessages are routed to Apple's PUSH servers, Apple is able to perform MITM:
  • Apple sends fake public RSA / ECDSA key to the sender
  • Apple can then decipher, alter the payload of the message and sign it before sending to its final destination.
  • So, yes, there is end-to-end encryption as Apple claims, but the weakness is in the key infrastructure as it is controlled by Apple: they can change a key anytime they want, thus read the content of our iMessages.
reply to this article

preview - XPS-1P design with plastic case and GPS!

posted 2018-01-25 19:00:53 by zac

Xenguard's XPS-1 sensors have served reliably for a few years now. They've helped us distribute our technology around the world. Their low power consumption and rock-solid Xenguard firmware means that they continue to perform very well. Although we have more powerful devices available, the XPS-1 continues to be popular because it's cheap, reliable and easy to use.

But no technology is perfect, and Xenguard is continously developing new and more powerful solutions based on what our customers ask for. Our users reported that for truly "pocket-sized" applications, the external antenna was getting in the way.

Here is a preview of Xenguard's newest XPS-1 design, the XPS-1P. Our engineers call it the SPIPod. This design features an all-plastic enclosure with no protruding components. The only port is a 2.5-mm plug for USB charging.

It's the lightest, smallest XPS sensor yet. It features 3,000 mA/H of battery power, a single Atheros® radio and GPS. We've now got an on-board GPS reciever for the first time.

Like all our models, many components used are made in the US, Canada and the UK.

You can absolutely slip this into a pocket, and you'll get a solid 10 hours of battery life. It's perfect for discreet applications.

It's also very affordable.

This particular model will probably not reach production, because we've got an even more amazing design in development! But if any users would like to try them out, we have a few prototypes available in Canada.

reply to this article

more about Xenguard

posted 2018-01-10 19:35:31 by zac

more about Xenguard

Xenguard is a global company which develops intrusion protection technology. We deliver security consulting and disaster recovery services to clients in need of serious protection for enterprise systems. We ensure your security investments yield provable bottom-line results. Xenguard backs up our IPS technology with no-nonsense security consulting and disaster recovery services. Xenguard's security professionals use proven methods to assess current systems, policies and capabilities. The other guys don't even come close, and we'll prove it with a free security probe.

The Xenguard Intrusion Protection System (IPS) is an advanced, event-driven network security management system Which delivers cost-effective securification of network assets against existing and emergent threats. The Xenguard Intrusion Protection System is the first product on the market offering protection for both physical and information assets the foundation of an effective integrated security infrastructure. Beyond mere detection, the Xenguard IPS is capable of intelligent response to intrusion attempts -- following evasive attackers across the network and adjusting dynamically system configuration to eliminate points of vulnerability. A wide array of plug-in modules are available, fully customizing the Xenguard Intrusion Protection System to meet specific user requirements.

Information security refers to the controls that protect information from unauthorized access, destruction, modification, disclosure, and delay. Information security addresses safeguards in the processes of data origination, input, processing, and output. The goal of information security is to safeguard the system's assets, to protect and ensure the accuracy and integrity of information, and to minimize the damage that does occur if the information is modified or destroyed. Information security requires accountability for all events that create, modify, provide access to, or disseminate information.

Many organizations recognize the benefits of using formal guidelines and methodologies from neutral third parties in establishing their security policies. Some groups have never developed policies; others have been unable to devote enough time to maintaining those policies. Sometimes the information technology staff lack expertise in information security; other times upper management have refused to support the measures known by the staff to be important for protecting corporate information assets. In all these cases, external organizations such as consultants, professional associations and certifying authorities can serve a useful purpose to alter the corporate culture and make the best use of security expertise. A Xenguard security assessment can help those who are responsible for the decisions. This widely recommended procedure, which is used to evaluate the many threats an information system faces, is a well-planned action to forsee the consequences of a failure in security. Xenguard keeps clients apprised of potential risks and suggest proactive security strategies. Xenguard provides security training at all levels, from highly technical programs for professionals in the field, to overviews for executives and managers, to general awareness for employees across a corporation or organization. If a company prefers implementing its own systems and networks, Xenguard provides security engineering support and technical assistance to augment the design team in the specialized areas of information security. Among other things, risk analysis considers the value of the assets to be protected, including the costs of disruption, the nature and probability of potential threats, and the cost of proposed safeguards.

Xenguard's exceptional reporting capabilities provide insight into the true state of your network. Unlike "black box" solutions which may block attacks but provide no active status reporting, Xenguard gives you the information you need to know to stay secure; get comprehensive reporting of who is visiting what web sites on your network; status reports can be delivered via e-mail, web access or even telephone -- on any schedule and in any detail level you require. Deliver the intelligence required to those who need it -- when it's needed; integrate your Xenguard security assets throughout your organization's nervous system using SQL database connectivity; customize report content with your organization's theme and layout preferences; verify the integrity of the network with one click. Efficiently conduct installations and provisioning with the hard data you need to make critical choices. Compile historical statistics to guide future security decisions. Easily determine the impact of configuration changes or security incidents. Determine your network's level of standards compliance without expensive third-party auditing. Visualize trends and spot hidden anomalies with easy-to-use graphical charts.

who uses Xenguard?

Xenguard products are designed to meet the needs of our users. Our customers range in size from individuals and small businesses to government agencies. Were constantly discovering new applications for our technology. Xenguard solutions are about more than just security; we can help your business achieve greater success by giving you the critical business intelligence you need to make key decisions. If your business involves information, Xenguard is your solution of choice for securing and leveraging that information.

security and surveillance

Everyone who has a network needs effective network security. Xenguard solutions are a cost-effective option to put you in control of your infrastructure.

corporate networks and data centers

Xenguard solutions are ideal for telecommunications carriers. We can enforce most any security standard you wish to implement. Detect and block infected devices in real-time, to stop the spread of malware and the disclosure of sensitive information. Mitigate Denial-of-Service attacks and corporate espionage. Get detailed deep data on user behaviors and ensure compliance with corporate policies.

network device manufacturers

Xenguards solutions are excellent for performance and compliance testing of network-enabled products. Xenguard can provide insights into how and why your IoT subsystems fail.

marketing agencies

Marketing agencies use Xenguard technology to collect and analyze information about customer behaviors. Going beyond the web, Xenguard sees behaviors that conventional marketing systems simply cant track.

Just take one look at a Xenguard Map of your environment and youll see exactly what we mean. With a Xenguard Map, you can see what is happening in the environment around you. Where people are coming from, where they are going, and what they are doing on your network. There has never been a more cost-effective and accurate way to get key demographic information from both physical and spaces. Its like every person walking past your business is handing you a business card.

The metrics generated by Xenguard products transform data into bottom line revenue. Offered to retailers, brands and commercial property owners, we provide continuous tools to measure how your brick-and-mortar locations are performing and how your actions are influencing shopper behaviour.

We place small sensors in relevant locations within your environment to enable the collection of real-time anonymous movement information. We then begin to provide you with relevant, sales related metrics and analytics about the movement of shoppers in your location.

We want to help you find answers to the most elusive questions you have about your environment.How long do consumers spend in my environment? How often do consumers visit my environment? What time of day do I have the greatest potential? Where do consumers go when they are in my environment? How do consumers reach their destinations inside my environment?

Discover how much potential you are missing out on from visitors turning away from your door. You could be selling more. Improve your customer service, staff volumes, shopper engagement and take advantage of those missed opportunities.

Dwell time tells you how long consumers spend in your environment. By understanding dwell times, you are able to see how you can influence your vital revenue source consumers.

Traffic flow information tells you what time of day you have the greatest potential to do business. By understanding your flow potential you are able to capitalize on missed sales opportunities.

Gross Shopping Hours (GSH) is a dwell-time related, proven retail performance indicator with a direct sales relationship. A metric tested and verified by retailers. By understanding and developing your GSH you directly influence your bottom line.

Routes tell you where consumers come from, where do they go and how they move between zones within your environment. Increase profitability by re-directing consumer flow towards areas that matter to you.

Loyalty is key. Our loyalty measurements tell you how frequently shoppers visit. Every visit equals spend. Increasing visiting frequency increases revenues. Understanding current loyalty and working towards improving loyalty are the first steps toward business growth.

Hot or not? Usage of Areas tells you how different zones are being used within your environment. Discovering where consumers move enables you to maximize the efficiency of your space for profit.

Know what your pull is. Gain knowledge about how many visitors are you able to pull in from the potential passing your location. Measure how your own marketing initiatives can increase your pull. Impact your pull with store-level actions and increase profits.

Xenguard systems can be integrated with your existing marketing campaigns, triggering events (such as e-mails, text messages or phone calls) based on the conditions you specify.

personal use

Aside from all the serious functionality Xenguard provides, our technology is a lot of fun, too! Everyone can benefit from knowing what electronic devices are in the environment, where they came from, and what theyre doing. You dont even need any special hardware.

reply to this article

Xenguard SPIPhone now available!

posted 2018-05-22 09:18:07 by max

Xenguard SPIPhone™ mobile device

 

We're so excited! Something amazing happened at the Xenguard office today.

Our latest hardware prototypes were revealed for the first time in North America! Even our own engineers can't believe we managed to pull this off in such a short time. Is it a little black box? Not quite -- it's a phone.

Look, we know this device isn't going to win any beauty contests. At first glance, one could be forgiven for exclaiming : gosh, what an UGLY phone! But take a closer look. This is NO ordinary phone!

(No ordinary phone cannot operate as a Xenguard sensor. They simply don't have the hardware.)

When you pick up the device, the first thing you'll notice is it's heft. That's due to the massive 8,000 mAh power pack -- which is about five times the capacity of an Apple iPhone. That's because this device contains many more components than an ordinary phone -- about triple the silicon.

Since this version is so new and advanced, we've provided three micro-USB ports to facilitate rapid diagnostics and limitless expansion options. Dual SIM slots. Dual SD card slots allow rapid firmware upgrades and storage expansion -- up to a whopping total of 384 gigabytes of storage! You can trust that this device is the product of some of the most advanced design and manufacturing processes and facilities available anywhere in the world.

Once you turn it on, you will not be disappointed. This monster makes an iPhone look like a Speak-and-Spell. 12 (yes, 12) total CPU/SoC cores might just make this the fastest phone in the world right now in terms of raw processing power. The display is huge, rich and vibrant. 8 GB of RAM, 128 GB of on-board storage. Even a 13-MP camera and stereo speakers! In terms of specs, forget about it -- this thing is loaded. It's even got a real headphone jack.

Okay, enough about what it looks like. What really makes this phone different than any other is what you can NOT see -- the dedicated Xenguard processor chip inside this device enables this hand-held unit to function just like our full-sized XPS-series sensors. You get all of the incredible surveillance and diagnostic capabilities of our "little black boxes" -- in a PHONE!

Because this unit runs Xenguard firmware and contains advanced SoC technology not normally found in mobile phones, it's incredibly secure. Apple and Google have absolutely zero control or involvement over our firmware code. That means this phone does EXACTLY what we tell it to, and nothing more. If you're the kind of user for whom security risks are not an option, this is the device for you.

Need a mobile device that lets you be REALLY secure -- even against advanced threats? Don't want your location, messages, photos and other data shared with unauthorized parties? Want to be invisible to all known wireless surveillance technologies? Don't want your company exposed to security threats due to insecure mobile devices? Are your confidential communications too important to trust to devices that don't take security seriously? That's exactly why we built this device.

When you launch the Xenguard app, you'll see it's identical to our web interface. Now you can command, monitor and control your entire network, right from one hand-held device. You don't need to share your sensitive data with Google or Apple anymore. In fact, this phone can operate as a full-featured sensor while being completely invisible to all known tracking technologies. That means you can "see" the environment around you, but they can't see YOU.

This phone is ideal for use by public safety and security professionals in airports, transportation hubs, conference centers, border crossings, shopping malls and other data-rich environments.

Never before has so much surveillance power been packed into a single mobile device. If you're informed enough to understand the state of the art in secure communications technology, then you know you need this device.

We invite you to join us in celebrating this amazing technical achievement. Check out the Xenguard Phone today! If you care about information security, you'll never want to carry anything else. You can get your hands on the phone that is scaring the crap out of Apple and Google (and some of the other guys, too) -- and you don't even need to line up to get one.

We have a limited number of block 1 devices available for sale in North America to qualified users at a unit price of $30,000. Block 2, with a 50 10ecrease in device dimensions and featuring a gold-finish aluminum enclosure, is expected to ship in Q3 2017. Contact Xenguard to get your SPIPhone now!

This is a highly specialized device for intelligence and security professionals. It is not a consumer device.

reply to this article

top wireless access points

posted 2018-09-14 16:05:17 by zac

top access point manufacturers

The Canadian wifi AP market is dominated by the big two internet service providers : Bell and Rogers (which provide routers from Hitron and Sagemcom). Next we have a few commercial-grade brands (Cisco and Aruba), and a couple of consumer-grade brands (Netgear, D-Link, Mitsumi, TP-Link and Asus). HP printers have a "direct print" mode which qualifies them as an access point; these have 2Successarket share. Roughly half of Canadians use the wifi router provided by their ISP, with the other half buying their own routers.

This suggests a major lack of competition both in Canadian internet service providers and wifi hardware -- in other parts of the world, there's a much more diverse population of vendors.

Bell and Rogers routers actually outnumber all the iPhones in the country combined; and the domination of Bell and Rogers in access points is even more dramatic than Samsung and Apple when we talk about mobile devices.

This suggests a major lack of competition both in Canadian internet service providers and wifi hardware -- in other parts of the world, there's a much more diverse population of vendors for both mobile devices and network access points.

Lack of operating system software diversity also tends to have security implications.

reply to this article

most popular mobile device brands

posted 2018-09-11 14:35:55 by zac

top 40 mobile device manufacturers

  • SAMSUNG : 24.012 %
  • APPLE : 13.5 %
  • LG : 8.181 %
  • MOTOROLA : 7.07 %
  • MURATA : 6.029 %
  • ALPS : 3.839 %
  • INTEL : 3.802 %
  • HUAWEI : 2.122 %
  • HON HAI : 1.771 %
  • ASUS : 1.555 %
  • HTC : 1.549 %
  • ONEPLUS : 1.436 %
  • ROUTERBOARD : 1.295 %
  • SONY : 1.257 %
  • SPARKLAN : 1.109 %
  • TCT : 1.051 %
  • LITE-ON : 1.013 %
  • RIM : 0.996 %
  • GOOGLE : 0.974 %
  • TI : 0.789 %
  • AZUREWAVE : 0.777 %
  • HP : 0.742 %
  • MICROSOFT : 0.71 %
  • HITRON : 0.694 %
  • EZURIO : 0.607 %
  • XIAOMI : 0.587 %
  • ZTE : 0.482 %
  • SONOS : 0.414 %
  • ALFA : 0.387 %
  • CANON : 0.375 %
  • SUMMIT : 0.351 %
  • BLU : 0.335 %
  • AMPAK : 0.319 %
  • TP-LINK : 0.264 %
  • FORD : 0.262 %
  • ZCOM : 0.262 %
  • ECOBEE : 0.262 %
  • GEMTEK : 0.258 %
  • SONIM : 0.244 %
  • ESSYS : 0.242 %
reply to this article

Xenguard XG-SPI-2 SPInode portable mesh AP

posted 2019-03-09 15:40:48 by zack

 

Xenguard SPIbox®

portable meshing access point

 

 

The XG-SPI-BOX features four wifi high-gain radios and a huge 10-amp power supply. Its the perfect solution for mobile access points and industrial applications, offering simultaneous coverage of the entire 2.4-ghz spectrum plus a high-performance uplink. With 10,000 mA/h of power, youve got at least a full day of run-time no matter what your application -- and plenty of radios for meshing, access points or firewall scenarios. The plastic enclosure is dust and water-resistant, and can be placed in an optional locking ruggedized ABS case for use in most any environment. The unit is charged via an included 5-amp AC or automotive transformer.
  • form factor : cigar box
  • architecture : Broadcom 2xxx series System-on-Chip
  • battery : 10,000 mA/H
  • application : meshing, industrial, special events
  • user interface : direct wifi application to any smart phone, laptop or tablet
  • storage : 64 Gb
  • charging method : 5-amp transformer
  • run-time : minimum 24 hours at full load
  • radios : 4 x 2-Ghz

 

 

With an available Pelican® case, you can get several days of runtime in a watertight, ruggedized package suitable for harsh environments.
 
reply to this article

Xenguard XG-SPI-1H hand-held security sensor

posted 2018-08-06 11:44:35 by max

Xenguard XG-SPI-1H hand-held

mobile network security sensors

 

The Xenguard XG-SPI-1 SPIPhone® mobile sensors are robust mobile processors suitable for field data collection applications. These nodes can be customized for your specific requirements - contact us for details. They are ideal for use in vehicles, as stationary CPE access points (public portals or private wireless networks) or for specialized data-harvesting applications.

It doesn't look like much -- and that's the idea. It's minimal design fits perfectly in a pocket or purse and has no buttons or display of any kind.

Out of the box, all you need to do is charge it via the included USB cable. Manage all your devices via the Xenguard management application -- any way you want.

  • form factor : hand held
  • architecture : Atheros 9000 series System-on-Chip
  • battery : 3,000 mA/H
  • application : personal mobility, network diagnostics
  • user interface : none
  • storage : 64 Gb
  • charging method : 1-amp USB cable
  • run-time : minimum 8 hours at full load
  • radios : 1 2-Ghz

 

The XG-SPI-1H variant is housed in an attractive, comfortable hand-held enclosure. It feels great in the hand and fits in a purse or jacket pocket. This model is perfect for network security engineers on the go. Plug in your favorite earphones and get real-time, hands-free audio alerts when events of interest occur for example, if a visitor is a returning customer or someone your company might want to keep an eye on. With one of these units in your pocket you'll be fully aware of your network environment.

 
reply to this article
Xenguard management system
contact Xenguard
Xenguard services
Xenguard software
Xenguard news
Xenguard library
Copyright © 2019 by Xenguard Corporation. All rights reserved.