30 May 2016

New IoT security certification aims to make the...

New IoT security certification aims to make the world safer

New IoT security certification aims to make the...

Underwriters Laboratories new Cybersecurity Assurance Program (CAP) looks to certify Internet of Things products. Columnist Rob Enderle writes that these CAP certification will improve IoT security and help CIOs sleep better at night.
Enterprise Social
Posted by at No comments:

Is the blockchain good for security?

Is the blockchain good for security?

Is the blockchain good for security?

The blockchain is now being hyped as the solution to all inefficient information processing systems, such as recording of property transfers, escrow services, and even legal contracts, but there are both security benefits and challenges to the technology
Enterprise Social
Posted by at No comments:

14 August 2011

Access Local Machine certificates without Admin rights

Digital certificates in windows, either the end entitty certificates, called Personal Certificates, the subCAs or the Root CAs, are stored in the so called Certificate Stores. There are different types of Certificate Stores but the more relevant ones are:



• Personal CA Store: Certificates, either end entities, subCAs or Root CAs, that apply to the current user

• Local Machine CA Store: Certificates, either end entities, subCAs or Root CAs, that apply to the system account. These apply to the user too. This means that a certificate issued by a Root CA available in the Local Machine CA Store but missing in the Personal CA Store would be treated as a valid.


In order to have access to the digital certificates used by Windows and integrated applications you need to follow these steps: (Have in mind that Firefox uses its own digital certificate stores).


From the command line open an MMC:

 


In the MMC add the Certificate snap-in




If you have local machine admin rights you have the right to choose the CA Store you want to open, if not it will automatically open the Personal CA Store

 
 
 
The naming can be a bit confusing but you should concentrate in the following folders:

• Personal: These are the end entity certificates assigned to the account (User or System)
• Trusted Root Certification Authorities: The Root CAs
• Intermediate Certificate Authorities: The subCAs

From the Certificate console, you are able to browse, add, delete all different types of certificates. If you need information of the other folders you can check the Microsoft article https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_cmuncertstor.mspx .

 
As said, if the user does not have admin rights he won´t be allowed to choose the “Computer account” where the certificates that apply to the System account are stored. Something that creates a bit of confusion is the fact that the Root CAs and subCAs from that store apply to the current user. Unfortunately these can only be examined by the end user in case his account has local admin machine rights. Although it’s understandable that a restricted user should not be available to apply changes that will affect all users, it makes no sense that it is not allowed to list the complete list of Root CAs available in the System account and that will be trusted in any SSL connection he establishes.

The good news is that the restrictions to access the Local Machine CA Store are rather weak and I just found a quick workaround for this.

From a computer where you have admin rights perform the steps above and repeat them adding the Computer Account. You should have a console with entries to the user and system accounts:

 
 
Go to "File -> Save as" and save the console (with extension msc) in a known directory. Transfer the file using a USB disk or by email to the target computer and you will be able to access the “restricted” Local Machine Store even if the logged user does not have local admin rights.


This is a simple hack but very useful when troubleshooting certificate related problems when users have restricted accounts. I have tested in a Windows 7, if you test it in other platforms let me know the results.

I  just hope that the rest of the Windows 7 access control mechanisms are more robust than this!
Posted by at 2 comments:
Labels: ,

04 May 2011

Android default (weak) signing configuration for the developer certificates


Some months ago I created a couple of Android applications.  As every Android developer  knows, in order to deploy applications on Android devices, these need to be signed. In other platforms like IOS, Symbian, Java or Windows Mobile, the signing process is a method used to prove the source of an application. Once an application is signed by a known certification authority, the platform will grant different execution permissions. Android  used code signing slightly different. The developer creates its own self signed certificate and uses this to sign any application he releases. This allows the platforms to recognize updates and also allow secure inter application communication.  The reason is simple, if there was no way to relate an application to its owner it would be trivial to impersonate him or her and deliver fake applications updates.

Without wanting to dig into the controversy between open and closed models, IOS vs Android, the part that caught my attention was that the developer would create a self signed certificate on his own and that that the only requirement is that the certificate must be valid until 2034. Today we all know that MD5 is proven to be weak and that key sizes should be at least 2048b, especially if we need to use it for a few years. On the other hand the default Android tools I used to create the certificate suggested to use a 1024b key and MD5 which is not a good idea, especially if that would be my identification until 2033!!

With that in mind I was curious to see how the digital certificates used to sign Android applications would look like. I analyzed nearly 4.000 applications, extracted the certificates and put together some statistics. For this I used unique certificates, which means that if two applications (in most cases these were updates) were signed with the same certificate I only took into consideration one occurrence.

First lets have a look at the algorithms being used:

As you can see the most used algorithm is RSA with SHA1 as a hashing algorithm but nearly one every 5 uses MD5 as a hashing algorithm. 
The strongest hashing algorithm found was SHA256 (1 occurrence, removed from the char) and the weakest MD5. It´s remarkable to see a 6% of DSA which is a n algorithm rarely used for X509 certificates, although perfectly valid.

Regarding key sizes for RSA we have the following distribution:

The most used key size is 1024b. Although I removed them from the pie charts, the weakest key size was 1023b (9 occurrences) and the strongest 8192b (1 occurrence). 

Developers, and some sysadmins too, tend to see digital certificates, and everything else around it, private keys, Root CAs, CRLs, etc as an annoyance and in the best cases as another “configuration” file.   Having in mind that Android forces you to use selfsigned certificates valid until 2033 it would be good to invest some time explaining developers the importance of the certificate/key and even more important enforce the use by default of stronger algorithms. Seeing the capabilities of the platform I don´t understand why Google did not enforce a minimum key length of 2048b and SHA1 or even better SHA256, instead of using default weaker settings especially when forcing developers to generate certificates valid for so long.
Posted by at 1 comment:
Labels:

17 February 2011

How to validate the Subject Key Identifier (SKI) from a X509 certificate

Some days ago I received an odd complain that some of the Root CAs we use had the wrong Subject Key Identifier (SKI). I knew that the claim was false but I also knew that I'll have to prove it. The guy did dig on our own specifications and calculated the SKI as we required, the hash of the certificate public key but unfortunately the identifiers did not match.

In order to reproduce the problem I extracted the public key of the Root CA, converted to DER, hashed it with SHA1 and verified that indeed the hash did not match. Let’s do a demonstration of what I did with a public available Root CA:



Now let's calculate the SHA1 of the public key:



As reported, both hashes did not match!

At this point I was a bit confused and decided to read some documentation before moving forward. After some reading I found the answer in the 4.2.1.2 section of the the RFC3280 “Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile ” (http://www.ietf.org/rfc/rfc3280.txt)



In our case we use method 1) for the SKI but in my calculations I was taking into consideration the whole public key, including tag, length, etc, while I should have used the key bits only.
With the following command I was able to locate the “BIT STRING” with the naked key:



And I only need to extract it and put it on a file in DER format:



The remaining part was to calculate the SHA1 hash which was the same as the SKI:



The same method was used to verify the SKI of a Root CA using SHA256 as a hashing algorithm.
Posted by at 9 comments:

27 September 2010

Mobile operators header enrichment assessment 6/6: Summary

During the last weeks I have been posting the results of header enrichment assessment I've done in several mobile operators. Let's do a quick check and summarize the results.

1) All operators in the same country have similar configurations. I was surprised to see how mobile operators appear to mimic other operators in the same territory.
2) Most operators have transparent proxies operating on the "Internet" connections.
3) As seen, some operators allow third parties to track users without the user consent and without allowing them to change or hide these traces. They add an HTTP header with an ID that uniquely identify the user. Some operators will change that ID every 24h like Orange Spain or Orange UK but some will keep the same ID forever. The worst ranking operators from the user privacy point of view are TIM Italy, Vodafone Italy, Telefonica Spain and Vodafone Spain.
4) Several ones are disclosing unnecessary information that reveals data that could be misused. From the information disclosure point of view the worst operator is Orange UK followed by SFR in France.
5) The winner of the header overhead would be Orange Spain which doubles all the Accept Headers,
6) and the winners of the header manipulation are TIM in Italy and Eplus in Germany.
I hope you enjoyed this series of posts. Feel free to leave your comment and let me know if some of the results change.
Posted by at 3 comments:

22 September 2010

Mobile operators header enrichment assessment: Part 5/6 - UK

And today, the last group of mobile operators assessed. We had a look at the mobile operators in the UK: TMobile, Vodafone, Orange, O2/Telefonica and 3, and these are the results:

=== TMobile UK through WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
Cache-Control: max-age=43200
Connection: keep-alive

=== TMobile UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Cache-Control: max-age=43200
Connection: keep-alive

We can see that TMobile UK is adding just a couple of proxy related HTTP headers and also that all the request in the Internet connections go trough a transparent proxy.

=== Vodafone UK through WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Encoding: deflate, gzip, identity
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
Via: HTTP/1.1 begwsl12 (XMS 724Solutions HTG XFW_004_M00_B133 20100521.012244)
Connection: close

=== Vodafone UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Encoding:
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Connection: TE, close

In Vodafone UK we have a similar behavior as in TMobile, all connections go through a proxy, even the Internet ones.  In the WAP connection they add a "Via" HTTP header. Although that is a standard proxy header, seeing that it is not added by most operators I would not add it here either.

=== O2/Telefonica through WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
X-Forwarded-For: 10.86.161.95
Cache-Control: max-age=43200
Connection: keep-alive

=== O2/Telefonica UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Cache-Control: max-age=43200
Connection: keep-alive

In O2/Telefonica we see a similar behavior as in Vodafone UK or TMobile UK. Everthing goes trough a proxy but in here we see that the WAP connection adds the X-Forwarded-For, which, although it is a standard, nowadays adds little or no value.

=== 3 UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Cache-Control: max-stale=0
Connection: Keep-Alive
X-BlueCoat-Via: 03F39CF1D18B00C3

3 in UK, as 3 in Italy, does not have a WAP connection with a fixed proxy.  Nevertheless we see they use a transparent proxy too as they are adding some extra HTTP headers.

=== Orange UK through WAPGW/Proxy ===
X-ICAP-Version: 1.0
Connection: keep-alive
Content-Length: 0
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
X-Nokia-RemoteSocket: 10.37.7.162:11961
X-Nokia-LocalSocket: 193.35.132.107:8080
X-Nokia-Gateway-Id: NBG/1.0.91/91
X-Nokia-BEARER: GPRS
X-Nokia-CONNECTION_MODE: TCP
X-Orange-ID: 2/oj/g2sxXXXXXXXXXXXX==
X-Forwarded-For: 10.37.7.162, 193.35.132.106
Via: 1.1, 1.1 pg-proxy1 (NetCache NetApp/6.0.6P1)

=== Orange UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
X-Nokia-BEARER: GPRS
X-Operator-Domain: orange.co.uk
X-Orange-Roaming: NO
X-Orange-ID: OR4B9UD7xXXXXXXXXXXXXX==
Via: 1.1 pg_squid4_3 (squid)
X-Forwarded-For: 172.24.36.9
Cache-Control: max-age=259200
Connection: keep-alive

In Orange UK we see one of the examples of HTTP header overhead. We can see all the useless Nokia headers and this time I´d like to highlight the following ones:

X-Nokia-RemoteSocket: 10.37.7.162:11961
X-Nokia-LocalSocket: 193.35.132.107:8080

The bigmouthed Nokia GW is telling us that the mobile device has the IP  10.37.7.162 and a socket connecting from port 11961 to the GW IP 193.35.132.107 and port 8080. I can think of a couple of tests that could be done with this information...

Another piece of useful information is that Orange is using a Nokia GW for the WAP connection and a Squid proxy as a transparent proxy.
Regarding the header

X-Orange-ID: OR4B9UD7xXXXXXXXXXXXXX==

this is a unique ID that is being updated every 24h. Needed?.... not really. Harmful? not too much.


Except Orange, the Mobile Operators in the UK seam to do a good job, not allowing third parties to track their customers and having light proxys. What they all have is a transparent proxy on the Internet connection which seems to be quite common in most operators. Next post will be a summary of the assessed operators.
 
Posted by at No comments:
Subscribe to: Posts (Atom)