Friday, September 23, 2011

BEAST beating SSL & TLS :: What You Can do to be Secured

B.E.A.S.T.?
Browser Exploit Against SSL/TLS Tool [B.E.A.S.T.], is the new Javscript utility created by J. Rizzo & T. Duong capable of breaking SSL3.0 & TLS1.0 level protection for HTTPS connections and deciphering the secure connection data.

What It Does?
There have been previous mention of cryptanalysis attacks over
+ SSL3.0
 |   (a Paper 'Analysis of SSL3.0 Protocol' by D.Wagner & B.Schneier in 1999 ), &
+ TLS1.0
 |   (a Paper 'Renegotitating TLS' by Marsh Ray in 2009).
B.E.A.S.T. is a pure exploit tool built over these (or similar) visions.
B.E.A.S.T. is based upon blockwise-adaptive chosen-plaintext attack approach exploited on victim's end via man-in-the-middle attack.

Point-to-Note!
It's a MitM over Browser, javascript injected does all harvesting of plaintext attack (which currently takes around 30 minutes for useful data) and then enables you to break the encrypted session.

Security Measures until F!XED
  1. Use a different browser (totally different, i.e. just not a new instance of same browser but a new browser, as in FireFox & Chrome are different) for browsing your Secured Connection. And a different browser for you general web surfing experience, even any external links from your secured session used browser should be copied and opened in the general web-surfing browser.
  2. It's better if the browser used for secured session is used in Private Browsing Mode.
  3. Don't keep log-in active in any service if you are not using it currently.

Something you should already be doing, if not start now...
Use browser extensions like AdBlock & NoScript, to protect your browser from injected IFrames and infected AdServices which are the major source channel for BEAST also.

To get a more detailed insight at the exploit Paper & Code, get your hands over
http://www.insecure.cl/Beast-SSL.rar

What to do at Server Side
http://isc.sans.edu/diary/SSL+TLS+part+3+/11635

Tuesday, September 13, 2011

Open Intelligence Gathering FOR Passive Reconnaissance FROM "Eden Guide To Hacking"


Open Intelligence Gathering : github.com/abhishekkr.....Open_Intelligence..
FOR 
FROM 
The following content structure is discussed in detail @
https://github.com/abhishekkr/eden_guide_to_hacking/blob/b00ef1502b9f91953f5d734efd4a03c3a0f04002/part1_Hacking_Cycle/chapter4_Reconnaissance/section0_Passive_Recon/article0_Open_Intelligence_Gathering.txt

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[+] Open Intelligence Gathering
 |
 |[+] What Is Open Intelligence?
 |
 |[+] Legal Documents Got Them
 |
 |[+] Search Engines Sort Them
 |
 |[+] Web Activity Caught Them
 | |
 | |[+] You Blog/Comment
 | |[+] You Socialize
 | |[+] You Subscribe
 | |[+] You Show/Click Ads
 | |[+] Even If You Surf Web
 | |_
 |
 |[+] Automating the Act
 | |
 | |[+] Paterva Maltego CE
 | | |[+] URL
 | | |[+] What it does?
 | | |[+] Example Usage
 | | |_
 | |
 | |[+] The Harvester
 | | |[+] URL
 | | |[+] What it does?
 | | |[+] Example Usage
 | | |_
 | |_
 |_

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Monday, August 29, 2011

"DevOps with SecOps" ~ short intro to Security Implications in DevOps Process

It's a short introduction to Security Implications in the new emerging & highly required domain of DevOps.


As currently, the major concern around DevOps world is 'The Mantra of Automation' at the level of
+ System/Environments Provisioning
    (easy & fast using Cloud Support)
+ Idempotent Configuration
    (using Automated Configuration Services)
+ Logging & Analytics
    (using automated detailed logging and clever analysis )

This presentation just mentions the security considerations related to all these 3 DevOps processes...

+ Provisioning being affected by
 |=+ Non-Robust Cloud Frameworks,
 |=+ Vulnerable Service APIs, &
 |=+ Virtualization BreakOuts
 |
+ Configuration Management threatened by
 |=+ Non-Robust Services, &
 |=+ Non-preferred storage of sensitive
 |     configuration data
 |
+ Analytics
 |=+ Log Analysis frameworks have been 
 |     several times attacked by infecting 
 |     the received logs resulting in service
 |     level non-sanitized input attacks. 
 |_

Thursday, August 11, 2011

howto check for safety of Shorten URLs before opening them in your browsers

Short URLs were in fashion a while back and now they are in requirement.
No matter which social, professional or public web portal you browse, you get to see short url.

But Short URLs from so many sources are not secure as a carefully planted short url redirecting (sometimes single redirection and sometimes multiple) to an infected web portal.
So, all the short links from non-reliable sources must be first traced back to original links and only visited if they cross-check successfully.

So, how to know the actual portal to be visited without using that URL and following it to final location.

[] from your shell
$ curl --head -L http://short.en/url | grep Location:
so, place the short url to be checked in place of "http://short.en/url" in the command provided above and then you can see the entire url trace and the final url to be visited...
~~~~~~~~~~~~~~~~~~~~

[] from the web-app
Link: http://webhoudini.appspot.com/
At this portal paste in the link in Short URL text box and click the 'Unshorten' button to see the actual redirected URL.

~~~~~~~~~~~~~~~~~~~~

Thursday, July 28, 2011

[Eden Guide to Hacking] 'Hacking Philosophy' ~ from Rig Veda and Sun Tzu's Art of War

This is a part of "Eden Guide to Hacking" which is my writing attempt for a quick to read, broadway guide to HACKING ~ for anyone to have grasp of important concepts and skills which makes up the knowledge base of a hacker.
W.I.P. @ https://github.com/abhishekkr/eden_guide_to_hacking/


'Hacking Philosophy' ~ from Rig Veda and Sun Tzu's Art of War
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[+] Art of Hacking
 |
 |[+] from 'Rig Veda'
 | |
 | |[+] "Who so would kill us, 
 | |  whether he be a strange foe or one of us."
 | |  Means: "The security parameters could be defeated by
 | |   (un/mis)-handled feature or an already compromised
 | |   component present within an un-breakable system."
 | |
 | |[+] "Loosed from the Bowstring fly away, thou arrow,
 | |   sharpened by our Prayer.
 | |  Go to the foemen, strike them home, and let not one
 | |   be left alive."
 | |  Means: "Make an exploit robust, accurate, infectious
 | |   and untraceable."
 | |_
 |
 |[+] skills could be seen as 13 chapters of Sun Tzu's
 | | 'Art of War' ~
 | |
 | |[+] Laying Plans
 | | |
 | | |[+] Exploit the parameter never thought to be a
 | | |  part of the security implications of the system.
 | | |_
 | |
 | |[+] Waging War
 | | |
 | | |[+] Don't overburden yourself with complex routes,
 | | |  if there exist less techie but more easy options.
 | | |_
 | |
 | |[+] Strategic Attack Planning
 | | |
 | | |[+] Exploit the parameter never thought to be a
 | | |  part of the security implications of the system.
 | | |_
 | |
 | |[+] Tactical Disposition
 | | |
 | | |[+] First secure your own location & technologies,
 | | |  then you are in safe & stronger place to attack.
 | | |_
 | |
 | |[+] Directed Energy
 | | |
 | | |[+] Attacking a complex security infrastrucure is
 | | |  no different than a simple one. Break it down.
 | | |_
 | |
 | |[+] Weaknesses & Strengths
 | | |
 | | |[+] Analyze the system well to aim its vulnerability
 | | |  and leave it's alarm system untouched.
 | | |_
 | |
 | |[+] Engaging the Force
 | | |
 | | |[+] One can't defeat an opponent without knowledge
 | | |  of opponent's security & service design.
 | | |_
 | |
 | |[+] Variations & Adaptability
 | | |
 | | |[+] The system, service & security could be set up
 | | |  with any kind of tweaking and hence makes the 
 | | |  pre-analysis for attack a failure.
 | | |  Attacker must be always ready to amend its ways.
 | | |_
 | |
 | |[+] The Army on the March
 | | |
 | | |[+] When to attack, and when to wait.
 | | |  Instincts to stay out of trap & sense enemies.
 | | |_
 | |
 | |[+] Situational Positioning
 | | |
 | | |[+] Access, attack & safety parameters involved.
 | | |_
 | |
 | |[+] The 9 Battlegrounds
 | | |
 | | |[+] Different types of security parameters lead to
 | | |  different attack or sometimes no attack practices.
 | | |_
 | |
 | |[+] 5 Ways of Attacking with Fire
 | | |
 | | |[+] Break-in target's system with deception
 | | |[+] Starve the resources powering security
 | | |[+] Attack availability of service
 | | |[+] Defeat the implemented security system
 | | |[+] Infect reachable systems related to target
 | | |_
 | |
 | |[+] Intelligence & Espionage
 | | |
 | | |[+] Gather as much information possible and 
 | | |  try attacks like spear phishing to have a slave.
 | | |_
 | |_
 |
 |[+] It's your Dharma to Hack, if you are a Geek.
 |
 |[+] & it all starts in following part of this Eden Guide
 |_
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thursday, June 30, 2011

User Authentication & Authorization [AT] Google AppEngine

AppEngine, a PaaS provided with a 'limited free' version to all GMail users (Google Account Owners). So, you can host your WebContent their making use of Python, Java or Go.

AppEngine enables you to use existing Google A/c of your Web-App users to be used for their authentication & authorization at your AppEngine-hosted Web-App also.

So, there are two main ways to acieve that:
  1. to import google.appengine.api.users
    this USERS module from AppEngine APIs enables your Web-App to identify the users on the basis of their Google A/c ID (GMail ID) and then make the decision of routing the user to secured Resource or forbidden resource error message.
    [ An Example on Usage ]
  2. to specify 'login' under 'app.yaml'
    so the major basic configuration about your Web-App and routing configuration reside in 'app.yaml' file which has default location of Web-App root location.
    So, you can specify at secured 'url' specifications to enforce user for a Google A/c (GMail) login.
    [ An Example Of Usage ]
In, both of these implementations whenever a user tries to visit a 'secured url' on your Web-App, they are automatically redirected to Google A/c Log-In page further redirecting them back to your Web-App on succesful log-in.


The Curious Case of static_dir

Initially while working for my newly initiated opensource project 'py-gae-legs', I added entire 'secure URL' logic by method#1 i.e. using 'users' api.
It was all working fine & secured until I added some static-content using static_dir and tried securing it's url using the same tactic.

But, there was a thing about 'static_dir' which I investigated after my supposed-to-be secure static_dir's content was all publicly available if someone could enumerate/know the complete url.
{I'm in the category of people who keep their learning pace up along with working over it... and anyway I wasn't gonna read the entire #^(

The thing about it was... the directories marked to be 'static_dir' in 'app.yaml' are no more located on the AppEngine Server in the same location after you update your Web-App.
So, the entire directory structure would remain same... it's just that the 'static_dir' marked locations would somehow vanish from it on your Web-App's location at AppEngine and served from some other provision made by Google which maps back to the location.

So, to secure the 'static_dir' located urls... the only way ( that I know of ) is to implement it at the very core of Web-App configurations i.e. in 'app.yaml' using the Method#2.

So, you can enforce Google Login to be mandatory by setting 'login:required' for that 'url' setting. If you want only a selected Users to see that, then you'll have to add all those Google A/c (GMail) IDs by doing following
[a.] goto Dashboard of your GoogleAppEngine Web-App,
the URL-Box link would look like:
https://appengine.google.com/permissions?app_id=s%7E$GAE_APPLICATION_NAME
[b.] click the link 'Permission' from Right-Menu-Column,
[c.] now, invite all those user's by providing their e-mail ID and changing their role to 'Viewer'and at app.yaml provide 'login:admin' instead of 'login:required'.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lately, I've been involved at starting an OpenSource project 'py-gae-legs'.

It's a very basic subset of WebApp-Framework for the lovers of RoR (have been working on it for past few months, love the ease it gives but hate the convention being the soul) style of web-app creation.

This project just aims web-development specifically aimed to be hosted over AppEngine (currently).
Almost done with it's basic starters to look at:
[] gae-flat-web : to create an architecture hosting your already created static website, http://gae-flat-web.appspot.com
[] gae-private-web : [W.I.P.] to host all your private content hosted securely (by Google) in an by-invite only website

Wednesday, May 25, 2011

How I got "2 Time Life-Time Banned" From Google Adsense

A Life-Time Ban from Google Adsense


I kin'of registered for Google Adsense service on my portal [ http://www.alwayspost.cjb.net/ (it's dead now, no more belongs to me) ] in very initial days, probably starting 2004.
I used to have few newbie blogs (not these, other newbie blogs) on blogger related to movies, wallpapers & technology.
So, in a very honest way I added the provided AdSense code to my blogs and started posting regularly. It was working at a sloooow rate but I was Ok with it.

I recently moved over from C++ to play with VB6 and was trying all fun stuff I could get my hands on.
One of the fun things I found was making mouse-clicks at desired locations.
& zooom~click~drag~code~drag~adjust~code... 
there was an ie-ocx-control in a form, loading all my blogs one-by-one and code (pre-loaded with specific locations of X-Y locations of Ads on the pages) forging mouse-left-clicks on all Ads... all repeated with a simple Timer.


Just left it on for a night... had LOADS of Ad Clicks and never tried it again.
One week later, there was a mail from AdSense in my GMail A/c stating I've been banned for life-time from Google's AdSense service.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

'Second Life' in Google AdSense

I signed-up for a new e-mail address and tried registering with a new mailing address, and there it was... my new AdSense account.
This time I did nothing against the rules.

Google released Page Creator (which is closed now) and I registered a new portal on my mailing-address at [ http://abhikumar163.googlepages.com ] and start linking it on forums with nice technological content to get valid page hits.


And, I made a mistake. I placed a link to my old-&-no-more-existing-portal [ http://www.alwayspost.cjb.net/ ] which was the portal registered with my earlier AdSense account.

Google's Crawler & Staff noticed it after I attained some amount in my account, and blocked my account and banned me for life-time Second time.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Currently, I'm on my Second Life-time Ban... and don't wanna Third Play, may be when I get bored again.