Category Archives: Security

Had the pleasure of attending the live concert of Pandit Hridaynath Mangeshkar (Feb 21, 2009). It was a blast - with Panditjee's rendition of the memorable songs that he has composed and sung (in some cases). There were around 400 people attending and still it had a feel of a private mehfil with Panditjee responding to farmaish for most of the concert. He also broke into the background stories of each of the songs and the people behind the magic of them. He also showed his typical tricks like making plenty of fun of the Marathi Mandal's secretary and testing the local singer by starting out the opening lines of the duets in different scales

Here is a list of all the songs in sequence: (The video links are not the videos from the program, but just links to youtube videos of the same song)

Here is a quick tip, hopefully it helps someone, I struggled with this for some time...

I have been using GNU screen program since a long time. This program is like a window manager for terminals and is especially useful for ISP and home shell accounts. You can have multiple shells running under the same session and can easily detach the sessions and reattach them from a different computer later etc.

I usually password protect my sessions by using the password command (ctrl A :password). But I had a hard time figuring out how to set that password in .screenrc file. The file obviously does not store it in plaintext and uses a crypted version of password. To get the crypted password, simply set your password in the screen session (ctrl A :password and then enter the password twice), then the crypted version gets automatically saved to screen's copy buffer! All you need to do is have a line in your .screenrc which looks like this
password DTWxS2voQWkgI

After this all your new screen sessions will be automatically password protected (meaning you will need the password to reattach a session.)

Listen to ॐ भूर्भुव: स्व:
We meditate on the glory of the Creator, ; Who has created the Universe;
Who is worthy of Worship; Who is the embodiment of Knowledge and Light;
Who is the remover of all Sin and Ignorante; May He enlighten our Intellect.

That (pure consciousness) is full (perfect); this (the manifest universe of matter;
of names and forms being maya) is full. This fullness has been projected
from that fullness. When this fullness merges in that fullness, all that
remains is fullness.

Om. We worship the three-eyed One (Lord Shiva) Who is fragrant and
Who nourishes well all beings; may He liberate us from death for the sake of
immortality, even as the cucumber is severed from its bondage (to the creeper).

If this does not work try turning debug to true above if you want to see the encoding.

Update: This still uses the GET method for checking the URL. Phishtank recommends using the POST interface (which will remove limitations on URL length: base64 inflates the length by 33%). Implementing that would need some kind of xmlhttprequest hackery. Stay tuned...

Update2: I got the AJAX bookmarklet ready, (thanks!)but it hits the infamous "uncaught exception: Permission denied to call method XMLHttpRequest.open" bug. i.e. you cannot do cross-domain xmlhttprequests. To solve that I think I need to convince PhishTank to host the javascript code, so the bookmarklet will insert a hidden iframe into the current page which will load the javascript from phishtank page, which will eventually make xmlhttprequest to phistank and display the result back. Are you listening PhishTank ?

Update3: Thanks to "till" who commented below, here is the bookmarklet using the POST method so now the solution will also work for really long URLs. Till's solution is good, but it makes users trust his site (in addition to phishtank). So basically user has to trust that he is not trying to filter the results being presented..

I have also merged the two earlier bookmarklets so that the current site location will be autopopulated in the prompt, so that user can easily change it if he wants to check a URL different from the one he currently is on.

Against All Enemies: Inside America's War on Terror is a fascinating account of events that happened inside the White House before and after 9/11 and how the focus shifted from fighting the terrorists to war with Iraq. I got to know about this book after watching Clinton's interview with Fox News. where he repeatedly asks the interviewer to read this book. The book starts off describing events in situation room and then goes back in history and explains the background of how Al-Qaeda started appearing on CIA's radar. There is an interesting account of different presidents and their view of terrorism and the changes in the mindset from Cold-War era to terrorism.

http://www.phishtank.com is a new service which aims to help weed out phishing URLs and email addresses using wisdom of the crowds. Users can submit emails/URLs which they suspect of fraud and others can vote if they really are fraudulent or not. I think it is a great concept. There is a REST API using which applications can embed this webservice within them. So for example, there could be a outlook plugin which will display "phishy" email addresses in a special way in order to alert the user immediately. Same for web browsers which can render phishing websites in a special stylesheet. The applications can also add interface for the user to submit suspect pages and email easily without using web browsers.

I checked out the API and it does not feel like it is fully baked! There are interfaces for authorization and checking email/url status and submitting new emails/urls. Some things that stand out immediately are:

Exclusive use of SSL for the API access.

Parameter authentication (i.e. including cryptographic digest of all the parameters to ensure that parameters are not changed using man-in-the-middle attack)

User registers on the web for API access and gets api key and shared secret

Using the API, application gets a frob (what is behind the name ?) and authorization url using auth.frob.request

User has to authorize the frob using the authorization url specified in the response. (optionally you can specify callback url which the server will call for authorization, I will need to check this from home when I have access to a server -- the docs are very thin about the mechanism)

Once authorized, app uses the frob and gets a token for short time API access (30 minutes in my tests) (auth.token.request)

App can check token status which tells remaining time on token.(auth.token.status)

App can revoke the token when it is done using it. (auth.token.revoke)

The APIs for check.url, check.email, submit.url, submit.email then use the token.

I did not understand why there is a need for FROB in this, why can't you just get the token from api key and shared secret ? What problem are they solving by this indirection ?

Anyway, here is the ruby script that I used for testing this... I am planning to turn this into a module, but providing it here for early access...phishtank.rbconfig.yml

P.S. the check_url interface is not working, I am getting invalid token error. and the same token can be revoked successfully.
P.P.S. The API uses SSL (no cleartext api available) and ruby's open-uri library insists on checking the server SSL certificate which always fails (probably because signer needs to be trusted by openssl), I had to change it locally to ignore ssl verification in order to proceed.

Update (Oct/12/06): the check.url interface is finally working. For this API, the signature needs to be calculated before escaping the url. I refactored the ruby script a bit to remove redundant code and moved the configuration to a seperate file. I still need to work with the response parser and make it general for all types of responses. XML parsing gets so ugly so fast, it's amazing!

I have struggled a lot to get the GPG working inside corporate firewalls. It is so cumbersome to set the tools to automatically request keys from keyserver for signature validations. Finally found the magic options for doing this from behind HTTP proxy. Just keeping this command here for reference.

On the internet nobody knows you are a dog
Unfortunately it's only true in cartoons! Basically you are leaving a surprisingly easy trail of the websites you visit. Visit Test anonymity if you want to find what web servers can know about you. A determined person can find out about the websites you browsed, what you did on each of them etc.

There are some commercial services like anonymizer that insert a random proxy between you and the destination web server. There are also a number of HTTP/Socks proxies that you can use. But then all of your traffic is subject to monitoring by these people.

Freenet project takes anonymity to other extreme and you can access content that you may not access otherwise, and also provides anti sensorship / banning features. But it has always been very slow, prone to protocol changes. (i.e. sites working the previous day do not work the next day because of release of new protocol and peer software).

Tor project takes another approach for this. The endpoints are still the same, but all your packets are routed using random combinations of tor routers. The routing technology is called onion routing where the encryption is only between hops in the route and none of the intermediate hops know either the contents of the packet or the sender. There is a provision for hidden services(any TCP protocol), which are not accessible from regular internet, which comes close to achieving what freenet does. I have been using tor for some time now and noticing some things:
* The performance is improving a great deal (as more and more tor nodes are commissioned, it will yield better performance)
* You can get routed through completely different continent, so going to google might open their german page (because they send you german page if they detect your IP address is from germany)
* This service might be easily abused by spammers who will definitely want to route spam through tor, child pornographer who can host "hidden services", illegal content downloaders. (Though I believe many tor nodes block SMTP and peer-to-peer traffic). I guess there is a price to be paid for "really free speech"

I have decided to blog about mobile security and security in general here.

San Diego Telecom Council had arranged a talk by Greg Rose of Qualcomm today with the topic "Hackers and Mobile Phones: who will win ?". Greg Rose is an Australlian cryptographer who had "accidentally" cracked the weaknesses in CDMA on air ciphering. I had attended one of his earlier talks while I was at Qualcomm. So I had to attend this...

It was a very short talk (only about 45 mins). Greg explained the basics of security:
Protocols - Usually assume agreed upon behaviour.
Attack breaks it by unagreed upon behaviour.
Risk = Threats * Loss

Security is a process of managing the cost of the risk due to attacks.

Why bother about security ? (depends on what is to be protected) It needs to be designed in and not added on later.

Current practices in 2G/3G - Use of keys (only symmetric due to hardware costs for asymmetric?). Smaller length (64 bits?) Message Authentication Codes (digest), ciphering. Attacks - evesdropping, impersonation. He emphasized end-to-end security as the ultimate end. So it is not enough to protect the radio protocols and ignore the security of the backhauls. With the introduction of downloadable code (Brew/Java/Bluetooth) and COTS operating systems on the phones like WinCE, Symbian, it will be easier for hackers to be able to inject unauthorized code & viruses on the phones. Service providers need to demand more security from the chipset designers, e.g. memory protection. Many times, security is just not properly implemented by the service providers. e.g. TMSI. Canada e.g. does not turn on encryption.

There is a need for the phones to authenticate base stations as well. Usually only the base stations authenticate the phones on their network. (Fake network attack - addressed in 3G) Discussion of an attack where authentication based on SIM card fails if it only uses the authentication in the beginning. (Need for base station to optionally verify that the phone still has the SIM card)

Some quotes:
If we trust everyone, we don't need security.
Early day security based on some wrong assumptions/optimizations. (e.g. Base station costs 0.5 million dollars, nobody will go to that extent to steal some secrets. Test equipment costs much less and even 0.5 million is not much for governments/mafia)
Kirkoff's maxim: Only thing secret should be the key (not the algorithm or implementation)
Security Protocols should be open to analysis.

Q&A:

If I am in a crowd of 100 phones, how many are infected with worms/spyware ? Answer - 1-2 (writing spyware for cellphones not very common). But if the question is how many can be compromised, then the answer is 99! (I just thought to myself, the remaining must be switched off due to dead battery)

How important is hardware security for overall security - Ans: Very important

What is current status of security of 3G wireless as opposed to Wireless Lan security ? - Both are equally bad!

P.S. Greg was kind to send the presentation slides. I will link to it whenever sdtelecom.org updates the website.