Showing posts with label Tech Updates. Show all posts
Showing posts with label Tech Updates. Show all posts

Friday, April 8, 2011

List of most useful online tools

Here is the list of some very useful n unique online handy tools for hackers,geeks :).Due to busy schedule I am not able to post description of every website will edit the information later.

If you like the post do share your views :)
SHARING IS CARING.

List of most useful online tools

Here is the list of some very useful n unique online handy tools for hackers,geeks :).Due to busy schedule I am not able to post description of every website will edit the information later.

If you like the post do share your views :)
SHARING IS CARING.

Monday, March 7, 2011

METASPLOIT v 3.6 RELEASED

All Metasploit editions are seeing an update to version 3.6 today, including an enhanced command-line feature set for increased proficiency and detailed PCI reports with pass/fail information for a comprehensive view of compliance posture with PCI regulations.

This release adds 15 new exploits for a total of 64 new modules since version 3.5.1. All editions of Metasploit now include Post Exploitation modules that provide local exploits and additional data gathering capabilities.


Metasploit Express and Metasploit Pro users benefit from the Project Activity Report and Global Search capabilities now available in the user interface. Metasploit Pro users now have access to the new Pro Console, PCI Report, and Asset Tagging features. The full release notes for the open source framework can be found online here  

METASPLOIT v 3.6 RELEASED

All Metasploit editions are seeing an update to version 3.6 today, including an enhanced command-line feature set for increased proficiency and detailed PCI reports with pass/fail information for a comprehensive view of compliance posture with PCI regulations.

This release adds 15 new exploits for a total of 64 new modules since version 3.5.1. All editions of Metasploit now include Post Exploitation modules that provide local exploits and additional data gathering capabilities.


Metasploit Express and Metasploit Pro users benefit from the Project Activity Report and Global Search capabilities now available in the user interface. Metasploit Pro users now have access to the new Pro Console, PCI Report, and Asset Tagging features. The full release notes for the open source framework can be found online here  

Wednesday, February 16, 2011

PenTBox v1.4

PenTBox is a Security Suite with programs like Password Crackers, Denial of Service testing tools like DoS and DDoS, Secure Password Generators, Honeypots and much more.Pentbox is destined to test security and stability of networks.

Tools included in PenTBox
Base64 encoder y decoder,
Digest for MD5,
SHA1,
SHA256 and SHA512,
Port scanner,
TCP DoS,
TCP AutoDoS,
SYN DoS,
Honeypot,
L33t Sp3@k Converter 

PenTBox is programmed in Ruby so ruby is required, and oriented to GNU/Linux systems compatible with Windows, MacOS and more.

Tutorial for PenTBox

1.Download PentBox and un tar
2. We are using windows box , simply run exe and choose from three options.
3. And your ready to attack  or audit. Nothing much to think or relay on.
Download PentBox Here

Pentbox is simple yet powerful .Feature i liked most is simple honeypot :) 

PenTBox v1.4

PenTBox is a Security Suite with programs like Password Crackers, Denial of Service testing tools like DoS and DDoS, Secure Password Generators, Honeypots and much more.Pentbox is destined to test security and stability of networks.

Tools included in PenTBox
Base64 encoder y decoder,
Digest for MD5,
SHA1,
SHA256 and SHA512,
Port scanner,
TCP DoS,
TCP AutoDoS,
SYN DoS,
Honeypot,
L33t Sp3@k Converter 

PenTBox is programmed in Ruby so ruby is required, and oriented to GNU/Linux systems compatible with Windows, MacOS and more.

Tutorial for PenTBox

1.Download PentBox and un tar
2. We are using windows box , simply run exe and choose from three options.
3. And your ready to attack  or audit. Nothing much to think or relay on.
Download PentBox Here

Pentbox is simple yet powerful .Feature i liked most is simple honeypot :) 

Wednesday, February 9, 2011

WordPress Releases Security Hardening Update

The WordPress project has announced the releases of WordPress 3.0.5. Dubbed as a security hardening release it is an essential update for those with any untrusted user accounts, but it also comes with other important security enhancements and hardening for all WordPress installations.
Two cross site scripting bugs have been squashed:
  • Properly encode title used in Quick/Bulk Edit, and offer additional sanitization to various fields. Affects users of the Author or Contributor role.
  • Preserve tag escaping in the tags meta box. Affects users of the Author or Contributor role.
Also included in 3.0.5 are two security enhancements one of which improves the security of any plugins which were not properly leveraging the WordPress security API.
All WordPress administrators are encouraged to upgrade to this latest version. You can update automatically from the Dashboard > Updates menu in your site’s admin area or download 3.0.5 directly

WordPress Releases Security Hardening Update

The WordPress project has announced the releases of WordPress 3.0.5. Dubbed as a security hardening release it is an essential update for those with any untrusted user accounts, but it also comes with other important security enhancements and hardening for all WordPress installations.
Two cross site scripting bugs have been squashed:
  • Properly encode title used in Quick/Bulk Edit, and offer additional sanitization to various fields. Affects users of the Author or Contributor role.
  • Preserve tag escaping in the tags meta box. Affects users of the Author or Contributor role.
Also included in 3.0.5 are two security enhancements one of which improves the security of any plugins which were not properly leveraging the WordPress security API.
All WordPress administrators are encouraged to upgrade to this latest version. You can update automatically from the Dashboard > Updates menu in your site’s admin area or download 3.0.5 directly

Wednesday, January 26, 2011

Facebook unveils security tools after Zuckerberg's page hacked

Facebook today announced two new security measures -- wider use of HTTPS and the introduction of "social authentication" -- less than 24 hours after the Facebook page of company founder Mark Zuckerberg was defaced by a hacker.

A blog post by Facebook's Alex Rice ties the security announcement to Friday being "Data Privacy Day," but the press and bloggers are having a high time connecting the news and Zuckerberg's victimization, whether or not there is actually any connection.

The first new security measure involves expanding the use of HTTPS -- Hypertext Transfer Protocol Secure -- beyond password exchanges.

Rice writes: "Starting today we'll provide you with the ability to experience Facebook entirely over HTTPS. You should consider enabling this option if you frequently use Facebook from public Internet access points found at coffee shops, airports, libraries or schools. The option will exist as part of our advanced security features, which you can find in the 'Account Security' section of the Account Settings page."

The second measure is a captcha-like authentication mechanism that instead of relying on illegible printed words employs photographs of a Facebook user's own friends.
Rice continues: "Instead of showing you a traditional captcha on Facebook, one of the ways we may help verify your identity is through social authentication. We will show you a few pictures of your friends and ask you to name the person in those photos. Hackers halfway across the world might know your password, but they don't know who your friends are."
Meanwhile, Facebook has remained officially mum regarding yesterday's apparent hacking incident that saw someone insert a message onto Zuckerberg's Facebook fan page, which has attracted 2.8 million Facebook users. While it was removed relatively quickly, some 1,800 of those users managed to "like" the page and more than 400 left comments beforehand. The message read:
"Let the hacking begin: If facebook needs money, instead of going to the banks, why doesn't Facebook let its users invest in Facebook in a social way? Why not transform Facebook into a 'social business' the way Nobel Price [sic] winner Muhammad Yunus described it? #hackercup2011"

As of this writing, Zuckerberg's page remains disabled.

Facebook unveils security tools after Zuckerberg's page hacked

Facebook today announced two new security measures -- wider use of HTTPS and the introduction of "social authentication" -- less than 24 hours after the Facebook page of company founder Mark Zuckerberg was defaced by a hacker.

A blog post by Facebook's Alex Rice ties the security announcement to Friday being "Data Privacy Day," but the press and bloggers are having a high time connecting the news and Zuckerberg's victimization, whether or not there is actually any connection.

The first new security measure involves expanding the use of HTTPS -- Hypertext Transfer Protocol Secure -- beyond password exchanges.

Rice writes: "Starting today we'll provide you with the ability to experience Facebook entirely over HTTPS. You should consider enabling this option if you frequently use Facebook from public Internet access points found at coffee shops, airports, libraries or schools. The option will exist as part of our advanced security features, which you can find in the 'Account Security' section of the Account Settings page."

The second measure is a captcha-like authentication mechanism that instead of relying on illegible printed words employs photographs of a Facebook user's own friends.
Rice continues: "Instead of showing you a traditional captcha on Facebook, one of the ways we may help verify your identity is through social authentication. We will show you a few pictures of your friends and ask you to name the person in those photos. Hackers halfway across the world might know your password, but they don't know who your friends are."
Meanwhile, Facebook has remained officially mum regarding yesterday's apparent hacking incident that saw someone insert a message onto Zuckerberg's Facebook fan page, which has attracted 2.8 million Facebook users. While it was removed relatively quickly, some 1,800 of those users managed to "like" the page and more than 400 left comments beforehand. The message read:
"Let the hacking begin: If facebook needs money, instead of going to the banks, why doesn't Facebook let its users invest in Facebook in a social way? Why not transform Facebook into a 'social business' the way Nobel Price [sic] winner Muhammad Yunus described it? #hackercup2011"

As of this writing, Zuckerberg's page remains disabled.

Saturday, January 22, 2011

WIKILEAKS HIRING HACKERS

Hey Niggas , Wondering While u read, Everything is truth, As u r seeing it..Believe..! We all have been known that WIKILEAKS has Tored the Fake face of America, And America Tryin To DDOS the Wikileaks And Successfully have done it..!! now www.wikileaks.org has been moved to mirror.wikileaks.org,
“JULIAN ASSANGE IS THE ONE MAN ARMY I GOTTTA SAY” Wikileaks has Showcased all the Drama of United States




Few Revealled Stuffs by WIKILEAKS:
1. IRAQ WAR LOGS
2. Calling tha Bessst World leaders in a NICK NAME.
3. Intruded in all governments Personal Stuff.
4. Spying on all Countries activites
5. SRILANKA WAR LOGS AGAINST Tamilian

Like all the Secrets has been revelaed With facts and Proffs,

Wikileaks Officialy Said Still they are having 2.5 Laks Of Confidential Notes From U.S Embassey
Hilary Clinton also warned there should not be Any post Regarding About one Secrets, If IT Happpens, Will be taken Series Account Leads to immediate action, (Ho HILARY am jus Askin Do u think Julian Assange(WIKILEAKS TEAM) India Or Wat…Watever u Say, To Nodding up Head Right and left)
This is WIKILEAKS..
Lets See Wat the steps Has taken Still So Far..
This Case has Been Movved To F.B.I , With Few Hired Hackers And Security Proff They DDosed And Main Site Has Been Shut Down…!! But Mirror Site (Backup Site) is still Active Upon now ..!!




( EVERYDNS.NET ) Wikileaks Has been hosted by this Provider F.B.I Forced to remove the Registration Entries..And Finally they Acted Upon..!
Now WIKILEAKS Has Come up With 729 Websites , Like( Replication in tha ROBOT Movie,If u have Seen tha Climax of tha movie u can understand it better)..So Now its hard for FBI To Identify tha Targeted Server Because Each Server From Different Location they hav hosted , And Wikileaks Are Looking to Take it 7000 Websites..!! And Hell Ya..!! NO WAY TO FIND…




And Here are the 729 Websites , Now Wikileaks CABLE Datas are available..! This Information is Strictly Confidential And Have Got Permission to Publish In Hackersbay.in

wikileaks.as50620.net wikileaks.tard.is ipv6 freeus.jsdev.org
wikileaks.enzym.su freeus.jsdev.org wikileaks.cellue.de
wikileaks.kafe-in.net wl.opsec.eu ipv6 wl.donatepl0x.com
wikileaks.challet.eu wikileaks.kister.org wl.gernox.de
wikileaks.morningtime.com wikileaks.renout.nl wikileaks.fdn.fr
wikileaks.gonte.se wikileaks.kaptenkong.se
wikileaksmirror.proxelsus-hosting.de ipv6 leaks.gooby.org
wikileaks.dubronetwork.fr ipv6 wikileaks.perry.ch wikileaks.sbr.im
wikileaks.u0d.de
wikileaks.81-89-98-125.blue.kundencontro...
www.fuckip.de wikileaks.psytek.net wl.mrkva.eu wikileaks.joworld.net
www.wlmirror.com wikileaks.chiquitico.org wikileaks.rout0r.org
www.gruiiik.org wikileaks.adhelis.com wikileaks.high-color.de
wikileaks.holarse-linuxgaming.de wl.alfeldr.de wikileaks.jikan.fr
wikileaks.huissoud.ch wikileaks.geekview.be wikileaks.fs-cdn.net
wikileaks.burnzone.de wikileaks.dysternis.de wikileaks.nulset.net
wikileaks.franslundberg.com wikileaks.krkr.eu ipv6 wl.yoltie.net
wikileaks.gnourt.org wikileaks.theunfamiliar.co.uk wikileaks.zeitkunst.org
wikileaks.aelmans.eu wikileaks.serverius.net wikileaks.synssans.nl
wl.ernstchan.net wikileaks.yasaw.net zwartemarktplaats.com
wikileaks.dena-design.de wikileaks.zone84.net wikileaks.subastas-xxx.com
wikileaks.iuwt.fr wikileaks.fernandoramirez.com.ar wikileaks.chmod.fi
wlmirror.wildeboer.net www.wikileaks.freelists.com.au leaked.rndm.ath.cx
wikileaks.splichy.cz wleaks.3sge.pulsedmedia.com
wleaks.hellfire.pulsedmedia.com wikileaks.palisades-berlin.de
wikileaks.razor1911.com wikileaks.dokansoft.com.ar
wikileaks.thinkfurther.de wikileaks.trankil.info wikileaks.gonte2.nu
leaks.stumcomie.com wikileaks.timburke.org wikileaks.ehcdev.com
wikileaks.zurk.org wikileaks.myscripts24.de wikileaks.breit.ws
wikileaks.emilts.com wikileaks.ruicruz.pt wikileaks.now-pages.com
wikileaks.ego-world.org wikileaks.nerdpol.org ipv6 cablegate.r3blog.nl ipv6
wikileaks.footboot.net www.wikileakz.eu wikileaks.realprogrammer.org
wikileaks.the-secret-world.info wikileaks.superjoesoftware.com
wikileaks.rtjuette.de wikileaks.rustigereigers.nl mirror1.wikileaks.lu
mirror2.wikileaks.lu wikileaks.emptyflask.net internaluse.net
wikileaks.r00t.la wikileaks.cordover.id.au brd.mcbf.net
wikileaks.merciful.nl wikileaks.spurious.biz wikileaks.1407.org
wl.datendetektei.de ipv6 wikileaks.mollar.me azow.selb.us
wikileaks.furdev.org wikileaks.datkan.net ipv6 wikileaks.nortemagnetico.es
wikileaks.threefingers.ca wikileaks.brenne.nu ipv6 www.anontalk.com
wikileaks.hutonline.nl vm8157.vps.tagadab.com nl1.wikileaksmirror.nl
wikileaks.noomad.org wikileaks.xcplanet.com www.wikileaks.nw-ds.com
wikileaks.infinium.org.uk wikileaks.piratskasit.cz peoplerule.info
wikileaks.sirobert.com wikileaks.solvare.se wikileaks.marktaff.com
wikileaks.hmaks.com im.wikileak.im wikileaks.aamjanata.com
www.wikigoteo.dialetheia.net wikileaks.dft-labs.eu
wikileaks.julietvanree.com wikileaks.argenton.ch wikileaks.i0i.co
wikileaks.lionelwood.com wikileaks.antifan.de ipv6 wasiutynski.net
wikileaks.diedx.nl wikileaks.chram.net wikil3aks.dyndns.org
wikileaks.encgmail.com wikileaks.yoerin.nl wikileaks.mcpond.co.nz
wikileaks.siwhine.org wikileaks.schroth.cx wikileaks.delight.ch
wikileaks.moochm.de wikileaks.syncaddict.net www.hallitus.info
info.patourie-systems.com wikileaks.softic.cz wikileaks.redhog.org
wikileaks.brokenbydesign.org wikileaks.nisd.dk wikileaks.sentientrobot.net
wikileaks.kronoss.org wikileaks.s4ku.com wikileaks.glembotzky.com
wikileaks.nperfection.com wikileaks.laquadrature.net
wikileaks.legrandsoir.info wikileaks.artwww.net wikileaks.39mm.net
leaks.uaqv.com wikileaks.krtek.net www.emilts.com leaks.3nglish.co.uk
wikileaks.explain-it.org wikileaks.dunnewind.net wl.fcharlier.net
wikileaks.poete.eu.org wikileaks.datenscheibe.org wikileaks.kapitein.org
www.wikileaks.djity.net wikileaks.nodemaster.de wikileaks.listepik.net
wikileaks.explain-it.org wikileaks.sedrati-dinet.net wikileaks.rigacci.org
wikileaks.ratm.ch wikileaks.tonbnc.fr cablegate.sentientrobot.net
wikileaks.ist-bremer.de wikileaks.spinrise.com wikileaks.rothnet.org
wikileaks.webtito.be ipv6 wikileaks.lainconscienciadepablo.net
wikileaks.g33kthug.co.uk wikileaks.b166er.net
wikileaksmirror.matstace.me.uk 87.106.58.253 wikileaks.virii.lu
wikileaks.junkle.org leaks.iamfos.co wikileaks.wass-media.com
wikileaks.karlsen.co wikileaks.lupine.me.uk ipv6 wikileaks.webprofiles.org
wikileaks.azatoth.net wl.unbloggbar.org santocristo.info
wikileaks.back2hack.cc wikileaks.supercrapule.com wl.treymassingill.com
wikileaks.poliisi.mobi wikileaks.karlsen.co wikileaks.rickfalkvinge.se
wikileaks.amette.eu wikileaks.batsh.it wikileaks.freei.me
wikileaks.chsdl.de last.to wikileaks.iheartfreedom.ca
wikileaks.rackstack.com wikileaks.serverlicious.org wikileaks.excds.se
wikileaks.under.ch leaks.kooll.info wikileaks.nldla.com
cablegate.dyndns.info wikileaks.afturgurluk.org wikileaks.phasebook.net
wikileaks.emquadat.com wikileaks3.no-ip.org wikileaks.hermans.net
wikileaks.urli.eu wikileaks.laotracarboneria.net wikileaks.datapusher.net
wleaks.shellmix.com wikileaks.citizen-boycott.org wikileaks.in-edv.de
wl.hor.de wl.rekursion.ch naixt-genne.com wikileaks.aircraftdispatch.net
wikileaks.cimeterre.info wikileaks.2qt.us wikileaks.rhgnet.de
wikileaks.crypton-technologies.net wikileaks.xgstatic.fr
wikileaks.medienfuzzis.com wl.creative-guerillas.com wikileaks.philpep.org
ipv6 wikileaks.para-dice.de wikileaks.outcast.no wikileaks.bandsal.at ipv6
wikileaks.concretedonkey.cz.cc wikileaks.oualid.net
wikileaks.webterrorist.net wl.22web.net wikileaks.deepdata.de
wikileaks.theano.de wikileaks.buzzworkers.com wikileaks.electric-castle.net
wikileaks.caseid.org wikileaks.luchaspopulares.org wikileaks.paysen.net
wikileaks.atpolitics.com wikileaks.otnf.tk wikileaks.nslu2-info.de
leaks.letsneverdie.net wikileaks.yasaw.net wikileaks.atpolitics.com mhym.de
www.wikileaks.videoteppista.net wikileaks.deutero.org wikileaks.grokia.se
wikileaks.tamcore.eu wikileaks.youfailed.de wikileaks.stephaneerard.fr
wikileaks.jotocorp.com wikileaks.canariaswireless.net
wikileaks.thearksakura.com wikileaks.org.org wikileaks.thefrackin.info
wikileaks.maero.dk wikileaks.metrogeek.fr wikileaks.simplaza.net
gouv.delation.org wikileaks.fellr.net wikileaks.mindfreakonline.de
wl.dixon.pl wikileaks.zombix.pcriot.com wikileaks.wkellner.com wl.thj.no
wikileaks.sodom.se wikileaks.macventure.de wikileaks.damn1337.de
wikileaks.bitciple.com wl-mirror.sokoll.com wikileaks.224charenton.net
help.majestan.com wikileaks.giggsey.com wl.kallix.net ipv6
wikileaks.unknowntruth.net wl.kaizer.se wikileaks.legalsutra.org
wikileaks.kitara.nl wikileaks.kyak106.com wikileaks.marpeck.net
wikileaks.leech.it wikileaks.pamphleteer.de wikileaks.return0.de
wikileaks.0x04.com wikileaks.mirror.jfet.org wikileaks.nerdhero.org
wikileaks.3ofcoins.net wikileaks.g0rn.com wikileaks.chpwn.com
wikileaks.fuck.cc wikileaks.hoppipolla.net wikileaks.slackdev.com
wikileaks.openmafia.org wikileaks.paper.st wikileaks.efremigio.es
wikileaks.zanooda.com wikileaks.wtfstfu.org wikileaks.freedomofspee.ch
www.elajt.info wikileaks.chuso.net wikileaks.letras.net wikileak.eicat.ca
wleaks.fryking.se wikileaks.0xff.it wikileaks.apileofbytes.com
wikileaks.revspace.nl leaks.curaj.tv wikileaks.mumu.cz wikileaks.kassala.de
wikileaks.mairipa.com wikileaks.crome.us wikileaks.chpwn.com
wikileaks.waixan.se wikileaks.k-ribou.com wikileaks.stasi.fi
wikileaks.milchi.de wl.kollegstufe.org leaks.freudian.sl wikileaks.laez.nl
wikileaks.dexite.de 74.63.248.219 wl.ownage4u.nl wikileaks.peer7.de
wikileaks.infinityloop.es wikileaks.orfeu.es wikileaks.myke.us
wikileaks.noova.de ipv6 wikileaks.leckerbits.com wikileaks.jikbag.net
wikileaks.pesqair.com wikileaks.nicolbolas.org ipv6 wikileaks.vixns.net
wikileaks.byteserv.de wikileaks.zro.co wikileaks.popcnt.org
wikileaks.acm.jhu.edu raubmordkopiert.ws wikileaks.adoutte.com
wikileaks.iodev.org wikileaks.ludost.net wikileaks.roethof.net ipv6
wikileaks.thespinlight.com wikileaks.apathie.net wl.mimamau.de
www.wikileaks.ufone.de wikileaks.mooo.se wikileaks.neofosis.com
wikileaks.eglin.net kileaks.byethost6.com www.mistermikileaks.com
wikileaks.pwnt.nl majjj.com wikileaks.antoniojperez.info
wikileaks.ig33k.com wikileaks.extensity.co.nz wikileaks.rudemusic.net
wikileaks.adoutte.com dgmx2k.dyndns.org:800 wl.fuldaecho.de
wikileaks.nc23.de www.wikileaks-backup.com wikileaks.bynoob.com
wl.mrblue.name wikileaks.martindv.es mirror.friendsofwikileaks.org.uk
wikileaks.disknode.org wikileaks.adundo.com wikileaks.lazzurs.net
wikileaks.deathserv.net wikileaks.tollofsen.se wikileaks.brokenco.de
wikileaks.buckyslan.com wikileaks.moell.us wikileaks.classcast.de
wikileaks.datenwelten.de www.priv.us wikileaks.neopt.org
wikileaks.samhargreaves.eu www.finngaria.de wikileaks.skvorsmalt.cz
wikileaks.neurd.org wlmirror.cosego.com leaks.boerdy.net
wikileaks.gundam.eu ipv6 novgorod.zunedevwiki.org ipv6 wikileaks.biz.tm
wikileaks.k4hosting.com wl.i2pbote.net leaks.underrun.org
wikileaks.simleb.cc wl.stefanpopp.de wikileaks.tejero.ca
www.keepinformationfree.com whatever.grillcheeze.com wikileaks.olivu.com
wikileaks.jieji.org wikileaks.zakulisa.org wlm.flooble.net
wikileaks.eondream.com www.shamanhouse.com wikileaks.galama.net
wikileaks.eondream.com wikileaks.goodlifebikes.ca wl.newscenterx.de
wikileaks.kofuke.org ipv6 wikileaks.xr3.cc dev.quadodo.net
wikileaks.cybertroops.com wikileaks.yacy.info wikileaks.anarka.nl
wikileaks.happyforever.com wikileaks.data-get.org wikileaks.humanpets.com
wikileaks.spectle.com wikileaks.hellopal.biz wleaks.verymad.net
whitenetdownloads.com WL.sanvicentemedia.com
wikileaks.lotek.org wikileaks.profithost.net wikileaksmirror.eu
wikileaks.chronzz.co wikiconstitution.info wikileaks.tinychan.org
wikileaks.holy.jp leaks.no.net www.wikileaks.angelbeast.org
www.wikileaks.angelbeast.org wikileaks.drewhavard.com wikileaks.keladi.org
wikileaks.awardspace.us wikijm.com wikileaks.pandas.es
wikileaks.mustashwax.com wikileaks2.info wikileaks.artwww.net
wikileaks.oneeyedman.net wikileaks.openconnector.net wikileaks.jordanroy.net
wikileaks.crazzy.se wikileaks.moo2ah.com wl.udderweb.com
www2181u.sakura.ne.jp wikileaks.blackwire.com wikileaks.rlsjrnl.info
wikileaked.jamestheawesome.kicks-ass.net wikileaks-in.ganesh.me 80.70.1.168
wikileaks.luotettu.net wikileaks.xakep.name wikileaks.jejaring.org
wikileaks.mahut.sk wl2.gernox.de wikileaks.mine-server.info
wikileaks.revoleaks.com bonsainetz.de www.spacemission.org
wikileaks.media.pl wikileaks.imrof.li wikileaks.hoper.dnsalias.net
wikileaks.escism.net wikileaks.lelapinblanc.eu wikileaks.tryptamine.net
wikileaks.piratenpartei-nrw.de wikileaks.cancamusa.net wikileaks.skarta.net
wikileaks.is-back.de wikileaks.radiopark.biz ipv6 wikileaks.nexiom.net
wikileaks.matschbirne.com www.extremesocial.biz wikileaks.blokovi.com
wikileaks.mooselook.de wikileaks.minibofh.org wikileaks.lengua.fr
wlmirror.riepernet.org wikileaks.aamjanata.com wikileaks.joevr.org
wikileaks.toile-libre.org wikileaks.parano.me wikileaks.slite.org
wikileaks.zvdk.nl wikileaks.picturesbyphilipk.de wikileaks.hostingjuice.com
wikileaks.editia.info wikileaks.renout.nl wikileaks.phoeney.de
wikileaks.msga.se wikileaks.infotubo.com wikileaks.adzi.net www.example.sk
wikileaks.wazong.de RealnoeBlinDelo.com
wikileaks.redandblack.cz ipv6 wikileaks.matschbirne.com wikileaks.aadnoy.no
wikileaks.erfassungsschutz.net wikileaks.aleph-0.net
wikileaks.oliverbaron.com wikileaks.vyus.de wikileaks.ladstaetter.at
wikileaks.willjones.eu wikileaks.anti-hack.net wikileaks3.piratenpartij.nl
wikileaks.ninanoe.net wikileaks.g0tweb.com 74.207.247.66
wikileaks.schuijff.com wikileaks.venix.eu wikileaks.iqaida.de
fremont.ca.us.wikileaks-mirror.com wikileaks.version2.nl
newark.nj.us.wikileaks-mirror.com london.uk.eu.wikileaks-mirror.com
dallas.tx.us.wikileaks-mirror.com zurich.ch.wikileaks-mirror.com
wikileaks.zici.fr wikileaks.tunny.ch wikileaks.boneputra.net
wikileaks.breit.ws wikileaks.weltgehirnmaschine.de wikileaks.csbnet.se
wikileaks.digital-revolution.at wl.dyndns-wiki.com wikileaks.nijhofnet.nl
ipv6 leaks.mooninhabitants.org wikileaks.ralforolf.com
wikileaks.pancake-pirates.org wl.farhad.su 93.90.28.65 wl.it.cx
wikileaks.lickmychip.com wikileaks.kimori.org wikileaks.beispieldomain.org
wikileaks.topdownmedia.nl wikileaks.webpagearts.com wikileaks.noreply.to
wl.openbotnet.eu wikileaks.univers-libre.net wikileaks.queralt.me
wikileaks.loutre.ch gatw.nl wikileaks.yourhero.de
wikileaks.disruptive.org.uk wl.scottymeuk.co.uk wikileaks.interblag.org
wikileaks.euridies.com wl.farhad.su wikileaks.jesolo-wants-adsl-back.info
wikileaks.ansible.fr wikileaks.violetsky.ch
wikileaks.dieinternetprofis.info wikileaks.daphne-dionys.com
wlmirror.dyndns.org whistleblower.futtta.be wikileaks.beraldoleal.com
newfagscanttriforce.com wikileaks.xen.no wikileaks.trylle.no
wikileaks.groissgroissgroiss.com wikileaks.nervsoft.com.ar
wikileaks.facenews.ru wikileaks.orientanet.es wikileaks.my-niap.org
wikileaks.phpdata.org wikileaks.nekochan.ch wklks.dyndns.org
wikileaks.uenota.org.ua wikileaks.4574.co.uk wikileaks.silverbullion.jp
wikileaks.gentlehost.net wikileaks.gonades.org wkl.fdumas.fr
wikileaks.gvoice.eu wikileaks.wiki-mirror.de wikileaks.socketubs.net
wikileaks.network-13.com wikileaks.sety.cz wikileaks.uruknet.com
wikileaks.brechi.com beatriceask.se wikileaks.uenota.org.ua
cablegate.dev-null.biz wikileaks.aditam.org wikileaks.bitplay.ru
wl.razor1911.com wlmirror.hopto.org:8000 wikileaks.mserverz.de
wikileaks.mazej.net:8080 wikileaks.com.hr wikileaks.bcweb.co.uk
wikileaks.weis.tk cablegate.technoaddict.fr wikileaks.jsphoto.at
wikileaks.africanaristocrat.com wikileaks.walgemoed.net
wikileaks.michaelkesler.info wikil.dyndns.org wikileaks.equal.cluenet.org
ipv6 wikileaks.bennyjacobs.nl wikileaks.kor.de
wikileaks.creativereasons.co.uk wikileaks.2114.su wikileaks.blazor.org
wl.shathor.com wikileaks.arulns.com wikileaks.fuxter.ru wiki.arrr.tv
wikileaks.synful.us wikileaks.nodehost.co.uk wikileaks.pod.cvut.cz
wikileaks.ihide.in wikileaks.nukezone-cnd.com wikileaks.key-server.de
wikileaks.silenceisdefeat.com wikileaks.reezer.org wikileaks.evilsocket.net
wikileaks.u35.dk wikileaks.felixbecker.name wikileaks.3g.de
wikileaks.tbotcotw.com wikileaks.b0x.lv wikileaks.sekil.fr
wikileaks.ebsserver.nl www.mirrorleaks.com partyboy.me
wikileaks.dashavoo.com 178.77.79.170 wikileaks.runlevel3.org
wikileaks.txapelbeltz.net wikileaks.av3s.net wikileaks.soft-creation.de
wikileaks.foetusproducts.com leaks.hw.is wikileaks.kiney.de
wikileaks.prismation.com wikileaks.brunogola.com.br
wikileaks.spiltirsdag.dk wikileaks.gehostet.de wikileaks.dennix.eu
wlm.hor.de iwikileaks.co.cc ewikileaks.co.cc wikileaks.sebastianbartsch.eu
wikileaks.bodji.net leaks.freecooki.es wikileaks.ecobytes.net
wikileaks.rolamasao.org cablegate.dyndns-remote.com
wikileaks.karimhossen.fr wikileaks.hlubina.com the-loser.net
wikileaks.tancee.com wl-tdl.ath.cx wikileaks.kermsware.net
wikileaks.kutxa.homeunix.org geheimnisse.taegli.ch www.swisswikileaks.ch
wikileaks.scratchbook.ch wikileaks.extranet.ee wikileaks.event-lan.net
wikileaks.bosna-i-hercegovina.info december.freez.in ipv6
wikileaks.mein-le.de wikileaks.mretc.net wikileaks.i-caramba.de
wikileaks.uwe.gd wikileaks.co.nl wikileaks.robsayers.com
wikileaks.i-caramba.de wikileaks.otherreality.net ipv6
wikileaks.hostalis.net wikileaks.maketo.se wikileaks.sharea.tk
wkleak.tartiflettes.com wikileaks.varchar.nl wikileaks.anavallasuiza.com
wikileaks.plixup.fr wikileaks.imrof.li freedomisimportant.org
wleaks.ddsd.de wikileaks.archive-one.us wikileaks.delovayakolbasa.ru
wikileaks.german-radio.net wikileaks.rootssh.net wikileaks.itos.pl
wikileaks.hackerheaven.org ipv6 wl.paranoidsecurity.nl
wikileaks.jugendverein.nl wikileaks.redcube.nl www.pucawo.net
wikileaks.neodox.org wikileaks.besthost.nl wikileaks.hinin.fr
wikileaks.WhoTheFox.com
wikileaks.capitanruby.es wikileaks.rorbuilder.info wikileaks.ce.tc
109.109.225.178 www.netur.net wleak.de ipv6 wikileaks.insultant.nl ipv6
wikileaks.eldaria.net wikileaks.dennix.eu wikileaks.spacedigital.eu
wikileaks.vanwoudt.com wikileaks.ypanema.de wikileaks.mindfarming.de
wikileaks.feh.name wikileaks.a-dit.fr wikileaks.jcowboy.org
wikileaks.diario-geek.com


-- Wikileaks Hiring Hackers Security Proffessional To Manage their Site,ur Original Information is Handled With tighten security Wen registering Domain For u On tha behalf of wikileaks, Your Job is to receive the Documents and Keeeps Postin on it as it Comes, Owner Can be a single person , Security Geek , Corporation , Security Consultant Firm….E.t.c
For More regarding Visit tha Main ..(Mirror sire) Site Of Wikileaks.org

ENJOY THA UPDATES WITH US…

Thursday, January 20, 2011

Verisign and responsible disclosure

In a recent post on his company blog, Verisign's vice president of marketing Tim Callan commented on the disclosure of our MD5 collision attack:

Here is the Scene Follow,




VeriSign did not receive any of [the] information ahead of the actual presentation, rendering it impossible for us to begin work on mitigating this issue prior to this morning.

I feel that this statement is inaccurate. Not only did we contact Verisign before our presentation to let them know about our research, we also strongly advised them to stop using MD5 as soon as possible and were given a chance to review their mitigation plans. I hope that Tim Callan's post is a result of a simple miscommunication between the technical people at Verisign their marketing department.

To help clarify this issue, in this post I will provide some background information about the disclosure of our work, as well as the exact timeline of our communication with the affected certificate authorities.
Protecting Internet users

From the very beginning of this project, all members of our team agreed that we needed to disclose this vulnerability without putting any users at risk. There were two main goals we set out to achieve: first, to prevent our rogue CA certificate from being abused; and second, to ensure that nobody else can repeat this attack before the affected CAs get a chance to fix the problem.

We took the following steps to prevent abuse of our rogue CA certificate:

* We did not release the private key for our rogue CA.
* We set the expiration date of the rogue CA certificate to August 2004, ensuring that even if the private key falls into the wrong hands, it will be useless against people who have their system date set correctly.
* We contacted the major browser vendors (Microsoft and Mozilla) to offer them a chance to explicitly blacklist our certificate if they felt that the past expiration date is not effective enough.

To make sure that our work could not be repeated by malicious attackers, we did not release the MD5 collision finding software necessary to do the attack. In addition, we chose to delay the publication of the improved collision finding techniques we had to develop for this project. Our team was confident that the R&D investment required to repeat our attack without access to this information would be prohibitive and the affected CAs would have enough time to stop using MD5 before the attack could be repeated.
Notifying the affected certificate authorities

Since we had already taken steps to ensure that the attack could not be easily repeated, notifying the affected certificate authorities before our presentation was not required in order to protect Internet users. A more important consideration was to ensure that we could present our work at the Chaos Computer Congress without interference. In the last year we have seen multiple cases in which companies have used legal threats in an attempt to silence security researchers and prevent the release of information that exposes their security failures. The most prominent examples include the lawsuit against Dutch researchers who showed fatal security flaws in the MIFARE transit cards and the restraining order that led to the cancelation of a talk about vulnerabilities in the fare collection system of the Boston subway.

Since the affected CAs did not have a significant track record of responding to public security vulnerabiltiies in their systems, we could not be confident that they wouldn't overreact and attempt to stop or delay our presentation through legal or other means. It was this feeling of uncertainty that led to our decision to avoid direct contact with them and to obtain Non-Disclosure Agreements from the browser vendors we contacted.

Recognizing the significance of the issue, Microsoft offered to act as a intermediary and contact the affected CAs on our behalf without revealing our names or the date of our presentation. Their proposal was reviewed by our team as well as our lawyers and on Dec 23 we agreed to go ahead with it:

Date: Tue, 23 Dec 2008 05:21:07 -0500
From: Alexander Sotirov
To: Microsoft Security Response Center

All of the team members agreed with the proposed plan, you can go ahead and
contact Verisign. Thanks for the help with this issue.

Here are the details that you can reveal to Verisign:

1) point them to the 2007 paper that describes the generation of colliding x509
certificates: http://www.win.tue.nl/hashclash/TargetCollidingCertificates/

2) tell them that Microsoft has been made aware that this crypto attack has been
improved and some practical limitations have been worked out, allowing the
successful generation of colliding x509 certificates signed by real
certificate authorities which still use MD5

3) tell them that RapidSSL and FreeSSL (also owned by Geotrust) use MD5 and
are vulnerable to this attack

4) encourage them to move to SHA-1 for all new certificates asap

5) it is important to stress that this attack is a generic attack against
CAs that use MD5 and not specifically targeting Verisign. They have a
good PR opportunity to react quickly and fix the bug before other CAs
They don't want to be the _last_ CA that uses MD5 :-)

If they request additional information from us, please pass the request along
and we'll try to help with what we can. You can call me directly at
XXX-XXX-XXXX if rapid response is required. We would be happy to chat with
Verisign directly on Dec 30, but we'd like to avoid direct contact until then.

The same day Microsoft contacted Verisign and informed them about our research. Verisign understood the severity of the issue and began working on it:

From: Microsoft Security Response Center
To: Alexander Sotirov
Date: Tue, 23 Dec 2008 13:18:09 -0800

We spoke to Verisign this morning, and essentially used your last e-mail as
a script to introduce them to the issue. We also passed along the roots they
own which you identified as affected, and they are reviewing their next steps
right now. They understood the severity of the issue and are taking it
seriously. At this point in time they did not have any further requests for
information.

They were however surprised by the ssl123 certificate: they claim these are
all issued using sha1. The ip address you listed for that certificate is no
longer live, and the hostname in the CN is using another Verisign certificate.
Would you mind if I pass along the subject and issuer information for them to
progress their validation?

I was happy to help Verisign by providing extra information about the SSL123 certificate in question. I also gave Microsoft permission to contact the other affected CA:

Date: Tue, 23 Dec 2008 19:38:09 -0500
From: Alexander Sotirov
To: Microsoft Security Response Center

> They were however surprised by the ssl123 certificate: they claim these are
> all issued using sha1. The ip address you listed for that certificate is no
> longer live, and the hostname in the CN is using another Verisign
> certificate. Would you mind if I pass along the subject and issuer
> information for them to progress their validation?

I have the original cert from that website. I've attached a zip file with all 5
Thawte MD5 certs that I found in the wild, including the SSL123 one. It's a
bit disconcerning that the CAs themselves don't know what algorithms they are
using.

You can give Verisign these certs, I collected them from public websites so
they are not secret in any way.

> The RSA root you listed is in fact also owned by Verisign, so they are
> investigating that one as well. There is one other root which belongs to
> another company, being Chosen Security/TC TrustCenter AG. We tentatively have
> a call scheduled with them tomorrow morning at 8 AM PST. If you can confirm
> that we can communicate the same information to them, this would be
> excellent.

Yes, you can communicate the same information to them.

On Dec 24, Microsoft requested permission to release more information to the CAs:

From: Microsoft Security Response Center
To: Alexander Sotirov
Date: Wed, 24 Dec 2008 09:09:15 -0800

One of the two certificate authorities got back to us and stated they will be
changing their engineering efforts to SHA1 within a *very short* timeframe. We
are literally talking days/weeks here. This is still going to be after your
presentation date. However, they are asking us specifically whether this
timeframe will be acceptable.

We cannot answer any questions on this for now - we are only the "voice box" in
between here. I do feel you should be giving them at least some nod in the
direction that they will still not make it in time, but also that this is not
very critical.

Could I have your permission to release the following statement to them:

"Hi [name],

The finder informed us they will likely take this issue public prior to [your
proposed switch date]. However, he wanted us to convey to you that they will
only be demonstrating that the generation of an “evil twin” certificate is
possible. They will not disclose their collision seeking algorithm, nor will
they be releasing any Proof of Concept code. Given the significant amount of
cryptographic research involved, they feel that their results will not be
repeatable for at least some time. They do plan on releasing a full research
paper on their method, but this will definitely be released much later than
your proposed switch time.

As such they don't feel that making this change will directly affect your
customers. They do think the level of responsiveness you are showing would be a
positive PR opportunity for your organization."

As this statement essentially conveys your plans and opinion, please feel free
to propose any other one with your team or make changes where you deem
necessary.

I promptly agreed to the proposed statement, with some minor edits:

From: Alexander Sotirov
To: Microsoft Security Response Center
Date: Wed, 24 Dec 2008 14:04:40 -0500

> "Hi [name],
>
> The finder informed us they will likely take this issue public prior to [your
> proposed switch date]. However, he wanted us to convey to you that they will
> only be demonstrating that the generation of an “evil twin” certificate is
> possible. They will not disclose their collision seeking algorithm, nor will
> they be releasing any Proof of Concept code. Given the significant amount of

make this "...releasing the software that implements the collision generation."

> cryptographic research involved, they feel that their results will not be
> repeatable for at least some time. They do plan on releasing a full research
> paper on their method, but this will definitely be released much later than
> your proposed switch time.

add "They will wait until all CAs have completed the move to SHA-1 before publishing
the details necessary to repeat the attack."

> As such they don't feel that making this change will directly affect your
> customers. They do think the level of responsiveness you are showing would be
> a positive PR opportunity for your organization."

I agree with this statement. You can share it with all affected CAs.

Alex

On Dec 29, Verisign confirmed that they are planning to stop using MD5 by the end of January.

From: Microsoft Security Response Center
To: Alexander Sotirov
Date: Mon, 29 Dec 2008 13:45:25 -0800

Hi Alexander,

Here is more feedback and contact information from Verisign:

"The SSL123 certs using MD5 are through a legacy reseller platform we are in
the process of EOL'ing. We do still have resellers using it so will need to
make updates to that platform as well.

We are working on making system changes to stop using MD5. They won't all be in
place by January 5th, but will be by the end of January. From what I am reading
below, the key thing seems to be that we are taking measures to stop using MD5
in the short term - so our plan to have all system changes in place by the end
of January should be Ok. Would you agree?

As far as contacts, from a technical point of view they can contact me. My
information, including cell is below. From a PR standpoint, the best person to
contact is Tim Callan - his email address is xxxxxxxx@verisign.com and direct
line is XXX-XXX-XXXX and cell is XXX-XXX-XXXX. An alternative contact for PR if
you can't reach Tim is Tina Hou (xxxxxxxx@verisign.com). She reports directly
to Tim.

Jay Schiavo
xxxxxxxx@verisign.com
Direct: XXX.XXX.XXXX
Mobile: XXX.XXX.XXXX"

Only 5 hours after our presentation, Verisign stopped using MD5 for all new RapidSSL certificates, successfully eliminating this vulnerability.

Cryptographic algorithms can become broken overnight, so it is important for CAs to demonstrate the ability to react quickly to such issues. I'm happy with the reponse from Verisign and the other affected CAs. Based on our experience with them, I would not hesitate to work with them directly on any vulnerabilties I might discover in the future.


This Symbolically tells..!! "SECURITY IS ZERO"

Verisign and responsible disclosure

In a recent post on his company blog, Verisign's vice president of marketing Tim Callan commented on the disclosure of our MD5 collision attack:

Here is the Scene Follow,




VeriSign did not receive any of [the] information ahead of the actual presentation, rendering it impossible for us to begin work on mitigating this issue prior to this morning.

I feel that this statement is inaccurate. Not only did we contact Verisign before our presentation to let them know about our research, we also strongly advised them to stop using MD5 as soon as possible and were given a chance to review their mitigation plans. I hope that Tim Callan's post is a result of a simple miscommunication between the technical people at Verisign their marketing department.

To help clarify this issue, in this post I will provide some background information about the disclosure of our work, as well as the exact timeline of our communication with the affected certificate authorities.
Protecting Internet users

From the very beginning of this project, all members of our team agreed that we needed to disclose this vulnerability without putting any users at risk. There were two main goals we set out to achieve: first, to prevent our rogue CA certificate from being abused; and second, to ensure that nobody else can repeat this attack before the affected CAs get a chance to fix the problem.

We took the following steps to prevent abuse of our rogue CA certificate:

* We did not release the private key for our rogue CA.
* We set the expiration date of the rogue CA certificate to August 2004, ensuring that even if the private key falls into the wrong hands, it will be useless against people who have their system date set correctly.
* We contacted the major browser vendors (Microsoft and Mozilla) to offer them a chance to explicitly blacklist our certificate if they felt that the past expiration date is not effective enough.

To make sure that our work could not be repeated by malicious attackers, we did not release the MD5 collision finding software necessary to do the attack. In addition, we chose to delay the publication of the improved collision finding techniques we had to develop for this project. Our team was confident that the R&D investment required to repeat our attack without access to this information would be prohibitive and the affected CAs would have enough time to stop using MD5 before the attack could be repeated.
Notifying the affected certificate authorities

Since we had already taken steps to ensure that the attack could not be easily repeated, notifying the affected certificate authorities before our presentation was not required in order to protect Internet users. A more important consideration was to ensure that we could present our work at the Chaos Computer Congress without interference. In the last year we have seen multiple cases in which companies have used legal threats in an attempt to silence security researchers and prevent the release of information that exposes their security failures. The most prominent examples include the lawsuit against Dutch researchers who showed fatal security flaws in the MIFARE transit cards and the restraining order that led to the cancelation of a talk about vulnerabilities in the fare collection system of the Boston subway.

Since the affected CAs did not have a significant track record of responding to public security vulnerabiltiies in their systems, we could not be confident that they wouldn't overreact and attempt to stop or delay our presentation through legal or other means. It was this feeling of uncertainty that led to our decision to avoid direct contact with them and to obtain Non-Disclosure Agreements from the browser vendors we contacted.

Recognizing the significance of the issue, Microsoft offered to act as a intermediary and contact the affected CAs on our behalf without revealing our names or the date of our presentation. Their proposal was reviewed by our team as well as our lawyers and on Dec 23 we agreed to go ahead with it:

Date: Tue, 23 Dec 2008 05:21:07 -0500
From: Alexander Sotirov
To: Microsoft Security Response Center

All of the team members agreed with the proposed plan, you can go ahead and
contact Verisign. Thanks for the help with this issue.

Here are the details that you can reveal to Verisign:

1) point them to the 2007 paper that describes the generation of colliding x509
certificates: http://www.win.tue.nl/hashclash/TargetCollidingCertificates/

2) tell them that Microsoft has been made aware that this crypto attack has been
improved and some practical limitations have been worked out, allowing the
successful generation of colliding x509 certificates signed by real
certificate authorities which still use MD5

3) tell them that RapidSSL and FreeSSL (also owned by Geotrust) use MD5 and
are vulnerable to this attack

4) encourage them to move to SHA-1 for all new certificates asap

5) it is important to stress that this attack is a generic attack against
CAs that use MD5 and not specifically targeting Verisign. They have a
good PR opportunity to react quickly and fix the bug before other CAs
They don't want to be the _last_ CA that uses MD5 :-)

If they request additional information from us, please pass the request along
and we'll try to help with what we can. You can call me directly at
XXX-XXX-XXXX if rapid response is required. We would be happy to chat with
Verisign directly on Dec 30, but we'd like to avoid direct contact until then.

The same day Microsoft contacted Verisign and informed them about our research. Verisign understood the severity of the issue and began working on it:

From: Microsoft Security Response Center
To: Alexander Sotirov
Date: Tue, 23 Dec 2008 13:18:09 -0800

We spoke to Verisign this morning, and essentially used your last e-mail as
a script to introduce them to the issue. We also passed along the roots they
own which you identified as affected, and they are reviewing their next steps
right now. They understood the severity of the issue and are taking it
seriously. At this point in time they did not have any further requests for
information.

They were however surprised by the ssl123 certificate: they claim these are
all issued using sha1. The ip address you listed for that certificate is no
longer live, and the hostname in the CN is using another Verisign certificate.
Would you mind if I pass along the subject and issuer information for them to
progress their validation?

I was happy to help Verisign by providing extra information about the SSL123 certificate in question. I also gave Microsoft permission to contact the other affected CA:

Date: Tue, 23 Dec 2008 19:38:09 -0500
From: Alexander Sotirov
To: Microsoft Security Response Center

> They were however surprised by the ssl123 certificate: they claim these are
> all issued using sha1. The ip address you listed for that certificate is no
> longer live, and the hostname in the CN is using another Verisign
> certificate. Would you mind if I pass along the subject and issuer
> information for them to progress their validation?

I have the original cert from that website. I've attached a zip file with all 5
Thawte MD5 certs that I found in the wild, including the SSL123 one. It's a
bit disconcerning that the CAs themselves don't know what algorithms they are
using.

You can give Verisign these certs, I collected them from public websites so
they are not secret in any way.

> The RSA root you listed is in fact also owned by Verisign, so they are
> investigating that one as well. There is one other root which belongs to
> another company, being Chosen Security/TC TrustCenter AG. We tentatively have
> a call scheduled with them tomorrow morning at 8 AM PST. If you can confirm
> that we can communicate the same information to them, this would be
> excellent.

Yes, you can communicate the same information to them.

On Dec 24, Microsoft requested permission to release more information to the CAs:

From: Microsoft Security Response Center
To: Alexander Sotirov
Date: Wed, 24 Dec 2008 09:09:15 -0800

One of the two certificate authorities got back to us and stated they will be
changing their engineering efforts to SHA1 within a *very short* timeframe. We
are literally talking days/weeks here. This is still going to be after your
presentation date. However, they are asking us specifically whether this
timeframe will be acceptable.

We cannot answer any questions on this for now - we are only the "voice box" in
between here. I do feel you should be giving them at least some nod in the
direction that they will still not make it in time, but also that this is not
very critical.

Could I have your permission to release the following statement to them:

"Hi [name],

The finder informed us they will likely take this issue public prior to [your
proposed switch date]. However, he wanted us to convey to you that they will
only be demonstrating that the generation of an “evil twin” certificate is
possible. They will not disclose their collision seeking algorithm, nor will
they be releasing any Proof of Concept code. Given the significant amount of
cryptographic research involved, they feel that their results will not be
repeatable for at least some time. They do plan on releasing a full research
paper on their method, but this will definitely be released much later than
your proposed switch time.

As such they don't feel that making this change will directly affect your
customers. They do think the level of responsiveness you are showing would be a
positive PR opportunity for your organization."

As this statement essentially conveys your plans and opinion, please feel free
to propose any other one with your team or make changes where you deem
necessary.

I promptly agreed to the proposed statement, with some minor edits:

From: Alexander Sotirov
To: Microsoft Security Response Center
Date: Wed, 24 Dec 2008 14:04:40 -0500

> "Hi [name],
>
> The finder informed us they will likely take this issue public prior to [your
> proposed switch date]. However, he wanted us to convey to you that they will
> only be demonstrating that the generation of an “evil twin” certificate is
> possible. They will not disclose their collision seeking algorithm, nor will
> they be releasing any Proof of Concept code. Given the significant amount of

make this "...releasing the software that implements the collision generation."

> cryptographic research involved, they feel that their results will not be
> repeatable for at least some time. They do plan on releasing a full research
> paper on their method, but this will definitely be released much later than
> your proposed switch time.

add "They will wait until all CAs have completed the move to SHA-1 before publishing
the details necessary to repeat the attack."

> As such they don't feel that making this change will directly affect your
> customers. They do think the level of responsiveness you are showing would be
> a positive PR opportunity for your organization."

I agree with this statement. You can share it with all affected CAs.

Alex

On Dec 29, Verisign confirmed that they are planning to stop using MD5 by the end of January.

From: Microsoft Security Response Center
To: Alexander Sotirov
Date: Mon, 29 Dec 2008 13:45:25 -0800

Hi Alexander,

Here is more feedback and contact information from Verisign:

"The SSL123 certs using MD5 are through a legacy reseller platform we are in
the process of EOL'ing. We do still have resellers using it so will need to
make updates to that platform as well.

We are working on making system changes to stop using MD5. They won't all be in
place by January 5th, but will be by the end of January. From what I am reading
below, the key thing seems to be that we are taking measures to stop using MD5
in the short term - so our plan to have all system changes in place by the end
of January should be Ok. Would you agree?

As far as contacts, from a technical point of view they can contact me. My
information, including cell is below. From a PR standpoint, the best person to
contact is Tim Callan - his email address is xxxxxxxx@verisign.com and direct
line is XXX-XXX-XXXX and cell is XXX-XXX-XXXX. An alternative contact for PR if
you can't reach Tim is Tina Hou (xxxxxxxx@verisign.com). She reports directly
to Tim.

Jay Schiavo
xxxxxxxx@verisign.com
Direct: XXX.XXX.XXXX
Mobile: XXX.XXX.XXXX"

Only 5 hours after our presentation, Verisign stopped using MD5 for all new RapidSSL certificates, successfully eliminating this vulnerability.

Cryptographic algorithms can become broken overnight, so it is important for CAs to demonstrate the ability to react quickly to such issues. I'm happy with the reponse from Verisign and the other affected CAs. Based on our experience with them, I would not hesitate to work with them directly on any vulnerabilties I might discover in the future.


This Symbolically tells..!! "SECURITY IS ZERO"

Sunday, January 16, 2011

Geinimi, Sophisticated New Android Trojan Found in Wild

The Threat:
A new Trojan affecting Android devices has recently emerged in China. Dubbed “Geinimi” based on its first known incarnation, this Trojan can compromise a significant amount of personal data on a user’s phone and send it to remote servers. The most sophisticated Android malware we’ve seen to date, Geinimi is also the first Android malware in the wild that displays botnet-like capabilities. Once the malware is installed on a user’s phone, it has the potential to receive commands from a remote server that allow the owner of that server to control the phone.


Geinimi is effectively being “grafted” onto repackaged versions of legitimate applications, primarily games, and distributed in third-party Chinese Android app markets. The affected applications request extensive permissions over and above the set that is requested by their legitimate original versions. Though the intent of this Trojan  isn’t entirely clear, the possibilities for intent range from a malicious ad-network to an attempt to create an Android botnet.
Lookout has already delivered an update for its Android users to protect them against known instances of the Trojan. If you are already a Lookout user (free or premium), you are protected and no action is needed.
How it Works:
When a host application containing Geinimi is launched on a user’s phone, the Trojan runs in the background and collects significant information that can compromise a user’s privacy. The specific information it collects includes location coordinates and unique identifiers for the device (IMEI) and SIM card (IMSI). At five minute intervals, Geinimi attempts to connect to a remote server using one of ten embedded domain names. A subset of the domain names includes www.widifu.com, www.udaore.com, www.frijd.com, www.islpast.com and www.piajesj.com. If it connects, Geinimi transmits collected device information to the remote server.

Though we have seen Geinimi communicate with a live server and transmit device data, we have yet to observe a fully operational control server sending commands back to the Trojan. Our analysis of Geinimi’s code is ongoing but we have evidence of the following capabilities:
  • Send location coordinates (fine location)
  • Send device identifiers (IMEI and IMSI)
  • Download and prompt the user to install an app
  • Prompt the user to uninstall an app
  • Enumerate and send a list of installed apps to the server
While Geinimi can remotely initiate an app to be downloaded or uninstalled on a phone, a user still needs to confirm the installation or uninstallation.
Geinimi’s author(s) have raised the sophistication bar significantly over and above previously observed Android malware by employing techniques to obfuscate its activities. In addition to using an off-the-shelf bytecode obfuscator, significant chunks of command-and-control data are encrypted. While the techniques were easily identified and failed to thwart analysis, they did substantially increase the level of effort required to analyze the malware. The Lookout Security team is continuing to analyze capabilities of new and existing Geinimi variants and will provide more information as we uncover it.
Who is affected?
Currently we only have evidence that Geinimi is distributed through third-party Chinese app stores. To download an app from a third-party app store, Android users need to enable the installation of apps from “Unknown sources” (often called “sideloading”). Geinimi could be packaged into applications for Android phones in other geographic regions. We have not seen any applications compromised by the Geinimi Trojan in the official Google Android Market.

There are a number of applications—typically games—we have seen repackaged with the Geinimi Trojan and posted in Chinese app stores, including Monkey Jump 2, Sex Positions, President vs. Aliens, City Defense and Baseball Superstars 2010. It is important to remember that even though there are instances of the games repackaged with the Trojan, the original versions available in the official Google Android Market have not been affected. As the Lookout team finds more variants of the Geinimi Trojan grafted onto legitimate applications, we’ll provide timely updates.
As stated above, Lookout has already delivered an update for its Android users to protect them against known instances of the Trojan.

How to Stay Safe:
  • Only download applications from trusted sources, such as reputable application markets. Remember to look at the developer name, reviews, and star ratings.
  • Always check the permissions an app requests. Use common sense to ensure that the permissions an app requests match the features the app provides.
  • Be aware that unusual behavior on your phone could be a sign that your phone is infected. Unusual behaviors include: unknown applications being installed without your knowledge, SMS messages being automatically sent to unknown recipients, or phone calls automatically being placed without you initiating them.
  • Download a mobile security app for your phone that scans every app you download. Lookout users automatically receive protection against this Trojan.
With the discovery of this new malware, it is more important than ever to pay attention to what you’re downloading. Stay alert and ensure that you trust every app you download. Stay tuned for more details on this threat.

Geinimi, Sophisticated New Android Trojan Found in Wild

The Threat:
A new Trojan affecting Android devices has recently emerged in China. Dubbed “Geinimi” based on its first known incarnation, this Trojan can compromise a significant amount of personal data on a user’s phone and send it to remote servers. The most sophisticated Android malware we’ve seen to date, Geinimi is also the first Android malware in the wild that displays botnet-like capabilities. Once the malware is installed on a user’s phone, it has the potential to receive commands from a remote server that allow the owner of that server to control the phone.


Geinimi is effectively being “grafted” onto repackaged versions of legitimate applications, primarily games, and distributed in third-party Chinese Android app markets. The affected applications request extensive permissions over and above the set that is requested by their legitimate original versions. Though the intent of this Trojan  isn’t entirely clear, the possibilities for intent range from a malicious ad-network to an attempt to create an Android botnet.
Lookout has already delivered an update for its Android users to protect them against known instances of the Trojan. If you are already a Lookout user (free or premium), you are protected and no action is needed.
How it Works:
When a host application containing Geinimi is launched on a user’s phone, the Trojan runs in the background and collects significant information that can compromise a user’s privacy. The specific information it collects includes location coordinates and unique identifiers for the device (IMEI) and SIM card (IMSI). At five minute intervals, Geinimi attempts to connect to a remote server using one of ten embedded domain names. A subset of the domain names includes www.widifu.com, www.udaore.com, www.frijd.com, www.islpast.com and www.piajesj.com. If it connects, Geinimi transmits collected device information to the remote server.

Though we have seen Geinimi communicate with a live server and transmit device data, we have yet to observe a fully operational control server sending commands back to the Trojan. Our analysis of Geinimi’s code is ongoing but we have evidence of the following capabilities:
  • Send location coordinates (fine location)
  • Send device identifiers (IMEI and IMSI)
  • Download and prompt the user to install an app
  • Prompt the user to uninstall an app
  • Enumerate and send a list of installed apps to the server
While Geinimi can remotely initiate an app to be downloaded or uninstalled on a phone, a user still needs to confirm the installation or uninstallation.
Geinimi’s author(s) have raised the sophistication bar significantly over and above previously observed Android malware by employing techniques to obfuscate its activities. In addition to using an off-the-shelf bytecode obfuscator, significant chunks of command-and-control data are encrypted. While the techniques were easily identified and failed to thwart analysis, they did substantially increase the level of effort required to analyze the malware. The Lookout Security team is continuing to analyze capabilities of new and existing Geinimi variants and will provide more information as we uncover it.
Who is affected?
Currently we only have evidence that Geinimi is distributed through third-party Chinese app stores. To download an app from a third-party app store, Android users need to enable the installation of apps from “Unknown sources” (often called “sideloading”). Geinimi could be packaged into applications for Android phones in other geographic regions. We have not seen any applications compromised by the Geinimi Trojan in the official Google Android Market.

There are a number of applications—typically games—we have seen repackaged with the Geinimi Trojan and posted in Chinese app stores, including Monkey Jump 2, Sex Positions, President vs. Aliens, City Defense and Baseball Superstars 2010. It is important to remember that even though there are instances of the games repackaged with the Trojan, the original versions available in the official Google Android Market have not been affected. As the Lookout team finds more variants of the Geinimi Trojan grafted onto legitimate applications, we’ll provide timely updates.
As stated above, Lookout has already delivered an update for its Android users to protect them against known instances of the Trojan.

How to Stay Safe:
  • Only download applications from trusted sources, such as reputable application markets. Remember to look at the developer name, reviews, and star ratings.
  • Always check the permissions an app requests. Use common sense to ensure that the permissions an app requests match the features the app provides.
  • Be aware that unusual behavior on your phone could be a sign that your phone is infected. Unusual behaviors include: unknown applications being installed without your knowledge, SMS messages being automatically sent to unknown recipients, or phone calls automatically being placed without you initiating them.
  • Download a mobile security app for your phone that scans every app you download. Lookout users automatically receive protection against this Trojan.
With the discovery of this new malware, it is more important than ever to pay attention to what you’re downloading. Stay alert and ensure that you trust every app you download. Stay tuned for more details on this threat.