Friday, February 18, 2011

Apache SOLR ~ a talented yet careless server

SOLR... what it is?
link: http://wiki.apache.org/solr/FAQ#What_is_Solr.3F
in short... it's an enterprise class search server

SOLR Security Consideration... are clearly stated
link: http://wiki.apache.org/solr/SolrSecurity


[] Solr does not concern itself with security either at the document level or the communication level.


[] It strongly recommends that the application server containing Solr be firewalled such that the only clients with access to Solr are your own


[] Default installation of Solr allows any client with access to it to add, update, and delete documents (and of course search/read too), including access to the Solr configuration and schema files and the administrative user interface.


[] Even if firewalled, it might be vulnerable to CSRF because Solr's basic behavior is to receive updates and deletes via HTTP...
So if you restricted Solr's /update handler to accept connections from approved hosts/clients... then also approved clients can be tricked to open another page with malicious script while they are authenticated at Solr.


[] Basic technique to mitigate this risk is to configure Servlet Container to server speicifc IPs or with HTTP-Authentication.


[] Solr doesn't aim to for Document Level Security, recommended way is through Apache Lucene Connector Framework.

SOLR is a very capable search server, but if you need to use it... be sure to make it unreachable.

Wednesday, December 29, 2010

Weak Excuses after Weak Security :: Mozilla's user a/c on Public Server

now this year has been filled with loads of news related to user-data getting leaked from different websites... but it wasn't much disturbing as web-vulnerabilities in Facebook are well known and accepted as cons of the deal and neither 1.3m a/c details leaked from Gawker came as a shock (it was more of a Tweet-Flood)
but
On Dec-17-2010, Mozilla was reported about availability of its user-accounts (partially, which were used on addons.mozilla.org) over a public server.
They have projects like Firefox (super famous web-browser), NSS (one of the most famous libraries for developing secured client-server application), and more... if an organization like them do a mistake like this, oh yeah... hackers paradise

it's how they defend themselves...
  • database included 44,000 inactive accounts using older
    but don't you think... even inactive users on a site deserve their privacy, and if they were inactive and not important then better purge the information pertaining to account... why keep it instead
  • md5-based password hashes
    they don't use it now... for active users they support SHA-512 per-user-salt mechanism; now that's good
  • current addons.mozilla.org users and accounts are not at risk
    so if I don't use Mozilla anymore... they wouldn't respect my a/c details anymore and still keep it... so that in future they could 'arrrrgh sorrry' me, brutally nice
  • incident did not impact any of Mozilla’s infrastructure
    it was available on a public server and not a hacked-n-fetched... bravo
  • only outsider who accessed the data was the security researcher that reported the mistake to Mozilla
    how are they so sure... if none else reported it doesn't mean that none else saw it, and it is not necessary that everyone accessing it will 'remain in' logs.

References:
http://blog.mozilla.com/security/2010/12/27/addons-mozilla-org-disclosure/
http://www.thetechherald.com/article.php/201052/6620/Mozilla-password-disclosure-a-non-event

Tuesday, December 21, 2010

bypass of user level restrictions, a case of bug in 'Scribd.com'

http://www.youtube.com/watch?v=g-ETsFjRhqsFew weeks back, saw Scribd.com offering me to buy/upload something for downloading a Document uploaded on it. Second time when I opened some document, in another browser it shows disabled 'download', 'print', and 'mobile' option.

As I didn't get that Document to download, I didn't felt like reading it online also... so just thought why not try to download it and if I succeed, then I'll read it online.
And I read it online :)

So, here is a bug (which  has now been fixed) in Scribd.com... that allowed users to get a local copy of documents which were devoid of download and print options.

It's how layered limitation can be broken, and why restrictions must be implemented root-level-up and not just as user-level module.

@YouTube: http://www.youtube.com/watch?v=g-ETsFjRhqs
How-To download the not-allowed ]
example: Bypass Scribd.com disabling Downloading/Print/Mobile on some links

Example Website Bug : a bug of Scribd.com (reported & got fixed) from aBionic@Vimeo

so, now you can either Print the document or create a PDF/image printing this document using softwares like PDFCreator.

Friday, December 17, 2010

only '.org' and '.net' domains under DNSSEC protection till now, WHAT ABOUT YOU

Are you protected with DNSSEC:
[] in mid-2010, DNSSEC got deployed over 'root-DNS-server' and '.org' domain
[] on 10-Dec-2010, Verisign deployed DNSSEC in '.net' zone too
   {securing more than 13million registrations online}
[] preparations are up to sign the '.com' zone in first quarter of 2011

Verisign has even launched a cloud based DNSSEC implementation service to ease its implementation in organisations.
Refer to http://www.securityweek.com/verisign-launches-new-dnssec-signing-service
For those who are not much familiar with DNSSEC, its a security layer standardized to be implemented over traditional DNS services... it will help the users counter DNS vulnerabilities exposed by researchers like 'Dan Kaminsky' including DNS poisoning attacks.
Refer to http://www.dnssec.net

Its implementation would require more processing power, bandwidth usage and more storage needs as it uses intensive encryption mechanism over all DNS traffic.

Though, I was surprised hearing initially of its implementation over root DNS server as its alterantive DNSCURVE (suggested by Dan Kaminsky) was conceptually better in security and easy on resources too. Don't know it was fair selection or just another political/community-biased decision.

=begin :footer
# waited about a week to have time doing this post in detail... 
# but more delay would deny its usability... so its here
=end :footer  

Sunday, September 26, 2010

XSSed Orkut after Twitter after Facebook <xss/>

'Are you social?'
ohhh... let me rephrase it 'Are you net-social?'
yeah... then how much socially secure are you when the plain-text attacks are htting millions.

2 months back with Facebook
now almost treated as synonym of Social Networking, and more than 400 million active users... Facebook was exposed to be vulnerable of a XSS vulnerability instead of proper implementation of HTTPOnly cookie protection as that doesn't count for XSS. The PoC video is being linked below along with article.
Article: http://www.acunetix.com/blog/news/cross-site-scripting-xss-facebook/
Video: http://www.youtube.com/watch?v=iTddmr_JRYM&hl&fmt=22

Last Week with Twitter
the microblogging favorite of masses, and offering a newer promising UX... Twitter accidently resurfaced the XSS hole while site update procedure. Famous as 'onMouseOver' flaw simply injected the XSS code as tweet to execute the function on mouse hover event by victim
Article: http://blog.twitter.com/2010/09/all-about-onmouseover-incident.html

Previous Day with Orkut
previous day was a 'Good Saturday' (i.e. what 'Bom Sabado' means in Portugese) 'scrapping' off the privacy of Orkut Users. This attack is supposed to originate from Brazil and compromised enormous Orkut accounts in a span of few hours. The code with details can be viewed at the link below.
Article: http://antrix.net/posts/2007/orkut-xss/

Monday, September 6, 2010

Problem with IEEE 802.1x implementation's fallback option

Problem with IEEE 802.1x implementation's fallback option
---------------------------------------------------------
I was just looking over some gyan for 802.1x implementation on Cisco's Portal.
They have a very nice guide over Phase Deployment Model for Identity Based Network Services.
While learning a bit, I saw mention of fallback option for IEEE 802.1x. Then I checked whether Juniper has it or not and it supports it too.

MAB i.e. MAC Authnetication Bypass porviding support for Legacy Devices (say Printers) which are not capable of IEEE 802.1x and hence require some other method of authentication.
And the method provided to them is adding the incapable device's MAC Address to a static (or even dynamic based on implementation) MAC list on 802.1x provider.

There goes the cocroach surviving Nuclear Attack. The super-strong 802.1x bypassed by a MAC ...are they really having faith on this, or have it implemented in super-man style. Though currently I can't think of any super-man for MAC Authentication. All I see is Sipper-Man :( sipping my security away.

Attacker just have to DUPLICATE allowed MAC, and enjoy the falling security.

Seriously, I'm afraid... if anyone know the manner of its implementation hidden to me till now, which makes it secure. Please, let me know asap.


If you want their support to make your environment vulnerable:
Cisco Support: http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/standalone_mab.html
Juniper Support: http://kb.juniper.net/KB11429

XSS Defeating PoC : if have any time for Experimentation


It's still in experimental state, if you find some time please try it and let me know of your experience.

Video Demo of the same PoC: http://www.youtube.com/watch?v=ENiiAccY1v0


I was working on a XSS-Patch PoC, which I now feel works proper enough to prove its point.
This neither require Web-Developers for any Filtering/Validation, nor any javascript blocking add-on on user's browser.

I'm not good at explaining still I've tried to do that in the above linked WhitePaper.

And the ZIP file can be extracted, having 'StartDemo.bat' to be executed to start the server already patched with XSS Subverting Module.
Then browse, 'http://localhost/tweet.htm' in any browser... and it lets you Submit any text to Server w/o validation which is as it is saved there. But when retrieved on 'Read...' remains inactive for any