Wednesday, March 30, 2011

Full site SSL-ification is not an option, need to make SSL secure first

I have  heard (Recently and in past) security aware lives wasting a lot of their potential over the argument like 
+ 'Basic HTTP is insecure' {sometimes in novice past}
+ 'SSL-ify entire web service' {still a lot push is there}

Now, 'Basic HTTP' being insecure is not a flaw by design... but a flaw by choice.
First of all, when foundation of HTTP were laid attackers were not in the scene. The only concern was ultra productive usability and that is not possible putting all kind of security checks on the service.
Secondly, HTTP wasn't meant to be secure, it was just meant to transfer data in adhering to a protocol which can be used by web-services to recieve user's requests and deliver requested content, that's all.
Cryptography mixed into it will destroy the ease and speed it has. Cryptography over it is instead a necessary (in some cases) and correct (design) option.
Though it has been haunting the websites by attacks like
+[] SSL Stripping
It's due to a flaw in the way Security is implemented in a web application. For example, you visit Facebook Login page at facebook.com which have a HTTPS link in its unprotected page-content to send over the credentials in a protected manner. But what if some attacker using Monkey-in-the-Middle strategy changed that HTTPS link to a HTTP link and sniff your sent credentials... w00t right.
+[] Sidejacking
It occurs due to web-application sending cookie information over non-ssl links. This allows any Man-in-the-Middle to sniff the cookie then replicate in his/her own browser and use the service identifying user just on basis of cookie information... it pwn3d services like GMail, Y!Mail, Hotmail, etc. until Q1-2010.

Then, 'Full Site SSL-ification' is a good choice from theoretical security point-of-view, but just in theory.
Different SSL-Defeating attacks involving
+[] Flaws in Libraries like NSS
There was a (earlier exploited, later) famous flaw in libraries with the case of NULL inclusion in URLs used for Domain name on which SSL Certificate is being issued. Mozilla Engine used NSS Cryptography libraries purely written in C and using basic insecure string functions for comparisons were tricked by certificates for domain name like <<www.paypal.com\0innocent.com>> stopping at first null after <<www.paypal.com>>. Webkit, Opera used null-stripping but they were tricked in just reversed attack using certificates for domain-name like <<www.pay\0pal.com>> stripping out usefull null.
+[] Fake SSL Certificate generation
Not a flaw in SSL, neither in its implementation but in the authorities enforcing it.
In a recent disclosure, Comodo Inc (a major issuer of SSL Certificate) accepted that an attacker was able to get credentials of 'Comodo Registration Authority' based in Southern Europe.
An Iranian attacker used the privilege to issue 9 fraud SSL certificates to 7 web domains including those for Google, Yahoo and Skype.


  So, if you will look deeper into serial-murder case file of
  SSL Certificates, you'll see it ain't safe... 

  and so there is no point in argument over its mixed/full
  implementation.

Tuesday, March 15, 2011

Indian Airport Internet ~ Hacking Policies Not Tweaking Systems

Few Indian Airport avail WiFi Internet Connectivity to Customers... and what I'm going to discuss about is not hacking the WiFi Network but a simple naive way to hack the Service Scheme instead and gain much more free access than provided little i.e. 30min

I found it in two cities (Delhi, Bengaluru among visited Indian Airports) till now. Both have different hardware supporting it but the same service scheme.

The Service Acts in following way:
Step.1:
You'll get an Open WiFi Network by the name of Airport which lets you to connect without any credentials.
Connect to it.
Step.2:
Open web-browser and hit any URL; this will redirect you to a single page provided by Service Provider with details of how you can get credentials for free-demo WiFi-access.
Here, you'll have to submit your Mobile Phone number, which will receive SMS of credentials for demo access.
Get the credentials.
Step.3:
Use those credentials on the same page, under login section.
You are connected to WiFi for internet access until demo-time (30 minutes) pass.

Loopholes in Service Scheme:
[] Continuous Access For Longer Duration
The more mobile numbers you can have access to...

  •  give your friends/family/personal/official Mobile Numbers to gain more demo credentials... 
  •  and simply ask them to forward respective SMS to you

...the more duration you can have demo WiFi access.

Now, the system don't check your MAC Address for earlier demo privileged machines...
so you don't even require anything as simple as mac-changer.

[] Parallel Access For Same Credential Set
As, I already said MAC is not checked... so suppose you have multiple WiFi enabled devices.
You can use the same credentials on all devices at the same time.
Just need to consider what is the time-frame for that credential to expire.

Friday, March 4, 2011

Presentation on "XSS Defeating Concept in (secure)SiteHoster" : 'nullcon-2011'

this is the work that I presented in 'nullcon - 2011' an security conference held at Goa by an emerging Security Community of India known as 'null'
it's mainly regarding preventing XSS Attacks with an entire new Concept based on 'Bug-As-A-Service' and 'Attacking-The-Attacker'...
any views/questions/comments/critics/confusions
----------
Presentation:
----------
Concept-Part-1 WhitePaper:
----------
Concept-Part-2 WhitePaper:
----------