# http://blog.abiss.gr/mgogoulos/feed/entries/atom 2009-01-10T06:53:15-08:00 Apache Roller (incubating) http://blog.abiss.gr/mgogoulos/entry/middle_east_protesters_deface_us Middle East protesters deface US Army and Nato websites markos 2009-01-10T06:48:32-08:00 2009-01-10T06:53:15-08:00 <p>On Thursday 8 Jan, Turkish cracker &quot;Agd_Scorp&quot; <b>defaced the US Army website</b> mdw.army.mil <b>and NATO Parliament</b> www.nato-pa.int, by putting messages in support of the Intifada and protesting against the recent Israeli attacks in Palestine that have resulted in the death of more than 800 of Palestinians so far.</p><p>Zone-h has screenshots taken after the defacements <a href="http://www.zone-h.org/component/option,com_mirrorwrp/Itemid,160/id,8497283/%20">here</a> and <a href="http://www.zone-h.org/component/option,com_mirrorwrp/Itemid,0/id,8497867/%20">here</a>.</p><p><img hspace="0" vspace="0" border="0" align="baseline" src="http://blog.abiss.gr/mgogoulos/resource/es-intifada390.jpg" /><br /></p><p> From what we can read on <a href="http://www.zone-h.org/content/view/15003/1/">zone-h.org</a>, Windows 2003 was the Operating System of the server hosting the domains, while the attacker exploited some Sql Injection flaws (on the ASP application powering the websites) for the break-in. <br /></p><p>Two days after the incident, mdw.army.mil seems inaccessible, as you can see on the screenshot.&nbsp; </p><p>It is interesting what we read on <a href="http://www.securityfocus.com/brief/884">securityfocus</a> for the story. &quot;Last week, several sources reported that thousands of Web sites may have been defaced by Palestinian sympathizers. Still, this is nothing on the scale of Georgia or even more recently with the (online) attacks on Kasparov&quot; <br /></p><p>&nbsp;</p><p>&nbsp;</p><p><img hspace="0" vspace="0" border="0" align="baseline" src="http://blog.abiss.gr/mgogoulos/resource/army.mil.jpg" alt="army.mil down" /></p> http://blog.abiss.gr/mgogoulos/entry/domain_hijacking_and_other_malicious Domain hijacking and other malicious activities with Gmail markos 2008-11-26T03:12:49-08:00 2008-11-26T03:12:49-08:00 <p>&nbsp;<img vspace="0" hspace="0" border="0" align="baseline" alt="google logo" src="http://blog.abiss.gr/mgogoulos/resource/gmaillogo.png" /></p><p>A few months ago I read on <a href="http://www.gnucitizen.org/" title="http://www.gnucitizen.org/">Gnucitizen</a> about the <a href="http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/" title="http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/">Gmail CSRF</a> and that was what I think one of the first really big cases of a <a href="http://www.cgisecurity.com/articles/csrf-faq.shtml" title="http://www.cgisecurity.com/articles/csrf-faq.shtml">CSRF</a> attack that became publicly known. Although Google has fixed this issue, it seems there's a new bug somehow similar to that one, and there's some great coverage on the issue at <a href="http://www.readwriteweb.com/archives/gmail_exploit_may_aid_domain_h.php" title="http://www.readwriteweb.com/archives/gmail_exploit_may_aid_domain_h.php">readwriteweb</a></p><p>The story behind this, amongst others contains the story of <b>shocked</b> <b>site owners</b>, getting their domain names <b>hijacked</b> by a malicious group, that asks for a fee (a few 00's dollars) in order to give them their domains back! Nasty.</p><p><b>CSRF</b> is a so called <font color="#ff0005">'Web 2.0 vulnerability'</font>, without this meaning that CSRF attacks didn't take place a few years ago. It is an emerging threat, <font color="#60ff0f">not as well known and understood</font> at the moment, as the different sorts of Injections, like SQL Injection, or Cross Site Scripting, still it is getting a lot of publicity as we hear more and more about <a href="http://webappsec.org/projects/whid/byclass_class_attack_method_value_cross_site_request_forgery_(csrf).shtml" title="http://webappsec.org/projects/whid/byclass_class_attack_method_value_cross_site_request_forgery_(csrf).shtml">high profile incidents</a> .</p><p> I'm not going to dive deep into CSRF attacks, as the <a href="http://en.wikipedia.org/wiki/Cross-site_request_forgery" title="http://en.wikipedia.org/wiki/Cross-site_request_forgery">Wikipedia article</a> explains very well the whole thing. In a few words, <i>&quot;It is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts.&quot;</i> <font color="#57ff00">This attack class exploits the trust a site has for a particular user.</font> Since the user is authenticated, any command issued during his sessions is supposed to be valid. So the problem is on the server side, still the user has a problem if a site is vulnerable to CSRF!<br /></p>The story with Gmail and CSRF goes like this: <br /><p>a) while logged on to Gmail, a person who owns a domain name and it's contact details are associated to this email address, visits a site that contains malicious code against Gmail</p><p>b) since the Gmail user is logged on Gmail, and Gmail is vulnerable to CSRF, the malicious code is executed, that adds a filter on the user's account. Gmail filters are rules to be executed, say for example that each email should be forwarded to address xxx@yyy.com. In this case, a filter is set to forward emails on the malicious guy's email address</p><p>c) since paying a close look every now and then on what are your filters isn't very usual (at least for most users, now), it is unlike that the user will notice the difference. </p><p>d) during this time, the malicious person collects the user's emails and monitors sensitive information being sent. <br />He can also use the password reset utilities on the domain registrant, change the password and hijack the domain. <br /><br /><img width="556" vspace="0" hspace="0" height="110" border="0" align="baseline" alt="adding filters to gmail" src="http://blog.abiss.gr/mgogoulos/resource/gmail_add_filters.png" /></p><p>&nbsp;adding filters to Gmail (Settings-&gt;Filters-&gt;Create a filter) <br /></p><p>&nbsp;<img vspace="0" hspace="0" border="0" align="baseline" alt="available filters on Gmail (plus malicious ones)" src="http://blog.abiss.gr/mgogoulos/resource/gmail-domain-stealing-2.png" /></p><p>filters of a domain hijack victim, with added filters (image from <a href="http://www.makeuseof.com/tag/breaking-gmail-security-flaw-more-domains-get-stollen" title="http://www.makeuseof.com/tag/breaking-gmail-security-flaw-more-domains-get-stollen">readwriteweb.com</a>)</p><p><br />Take a moment and think the damage if your email account is compromised. This might result in a far greater loss than physical disasters, eg your hard drive crashing! Not in the case you are a plain user, exchanging mesages with friends and partners, but if your email account is the <font color="#ff0000">gateway for online banking systems</font>, <font color="#ff0000">paypal</font>, or other systems, or for a <font color="#ff5500">domain registrar</font>, as in the scenario we are discussing.<br /><br /><b>What you can do about that</b></p><p>Google has <a href="http://googleonlinesecurity.blogspot.com/2008/11/gmail-security-and-recent-phishing.html" title="http://googleonlinesecurity.blogspot.com/2008/11/gmail-security-and-recent-phishing.html">fixed</a> this vulnerability, however it's good to keep in mind some small things, cause similar scenarios might appear in future. <br /><br />1) If you use Gmail, check your filters and make sure there's no filters added by others (Settings-&gt;Filters) <br /><br />2) Change your reset passwords/answers. Seriously. <b>Don't allow yourself to get owned because someone reset your password by answering the question 'What's your favorite puppy'.</b>&nbsp; (this also aplies to ALL web based email, like yahoo, hotmail etc). <br /><br />3) While logged on Gmail, don't visit malicious/questionable sites.<br /><br />4) Use https://mail.google.com instead of http://mail.google.com (notice the s). Thus all of your session is encrypted (HTTPS), rather than only when you login as it happens with HTTP. <br /><br />&nbsp;What's really important to remember is in CSRF, or XSS, or other types of attacks, we tend to <b>underestimate</b> the number of web sites/applications that are vulnerable. Also, as users we can't do many things to avoid these attacks (since they are server side), <b>just be informed and suspicious :)</b><br /><br />If this sounds interesting to you, check out <a title="http://geekcondition.com/2008/11/23/gmail-security-flaw-proof-of-concept/" href="http://geekcondition.com/2008/11/23/gmail-security-flaw-proof-of-concept/">geekcondition</a>, featuring some great coverage on the issue.</p><p><a href="http://www.gnucitizen.org/" title="http://www.gnucitizen.org/">Gnucitizen</a> (what an awesome name!) is an IT security Think Tank, having produced amazing papers and coverage for many issues in the field of IT security. Moreover, the policy they've been following for publicizing vulnerabilities seems very responsive (they even prompt others to inform the vendor for a problem, let the vendor fix it and then publicize it, rather than just publicize it once discovered). </p> http://blog.abiss.gr/mgogoulos/entry/fuzzing_finding_vulnerabilities_in_software Fuzzing: Finding vulnerabilities in Software markos 2008-10-09T03:31:36-07:00 2008-10-09T03:31:36-07:00 <p> <b>Fuzzing</b> is a well known term amongst security people, because of the buzz created around last few years and the impressive results it has given.</p><p> According to the Wikipedia <a title="Fuzz_testing" href="http://en.wikipedia.org/wiki/Fuzz_testing">article</a>,&nbsp; <i>Fuzzing is a technique for testing software, by providing random data as input and monitoring if the program will fail -by crashing or consuming high system resources.</i> If this happens, this means there are defects to correct. <br /><br />As it is quoted on the wikipedia entry, <b>Unexpected input causes unexpected results</b>. In fuzzing, you are somehow creating <font color="#0058ff"><b>'rough clients'</b></font>, that send input a normal client wouldn't. </p><p>&nbsp;</p><img hspace="0" vspace="0" border="0" align="baseline" alt="A fuzzing taxonomy" src="http://blog.abiss.gr/mgogoulos/resource/fuzz.png" /><br /><br /> <p> <b>Fuzzing</b> is a well known term amongst security people, because of the buzz created around last few years and the impressive results it has given.</p><p> According to the Wikipedia <a title="Fuzz_testing" href="http://en.wikipedia.org/wiki/Fuzz_testing">article</a>,&nbsp; <i>Fuzzing is a technique for testing software, by providing random data as input and monitoring if the program will fail -by crashing or consuming high system resources.</i> If this happens, this means there are defects to correct. <br /><br />As it is quoted on the wikipedia entry, <b>Unexpected input causes unexpected results</b>. In fuzzing, you are somehow creating <font color="#0058ff"><b>'rough clients'</b></font>, that send input a normal client wouldn't. </p><p>&nbsp;</p><p><img hspace="0" vspace="0" border="0" align="baseline" alt="A fuzzing taxonomy" src="http://blog.abiss.gr/mgogoulos/resource/fuzz.png" /><br /><br />There are fuzzing frameworks and programs that create &quot;rough clients&quot; for almost everything, including<br /></p><ul><li>operating system kernels (eg test syscalls)</li><li>file formats (eg pdf, doc, images, sound, video)</li><li>executables</li><li>network daemons (eg fuzz apache, IIS, Vmware Server)</li><li>network protocols (eg tcp/ip)</li><li>command utilities arguments</li><li>device drivers (eg Wifi cards)</li><li>web application</li><li>misc (COM Object Interfaces)</li><li>whatever_else_you_might_imagine</li></ul><p><br /><font color="#ff0000"><i>Fuzzing is an unbelievable technique for testing software, meaning that you have to see it yourself to believe that it actually works :)</i></font><br /><br />This is something I have read several times but only had the chance to see in front of my eyes some months ago, when I was encouraged to create a prototype for a python module fuzzer. The fuzzer would try to call all classes and functions of a python module, with random arguments (such as None, False, big integers, or big strings) after it had found out the number of arguments a function needs. This was a rough prototype, very specialized to one thing (fuzzing python modules) and was created/used for two days, yet it resulted in the discovery of some tenths of segmentation faults in well known python modules, including GUI toolkits, as <a title="Bugs in wxwidgets" href="http://trac.wxwidgets.org/search?q=mgogoulos">wxwidgets</a> , Scientific software <a href="http://scipy.org/scipy/scipy/search?q=mgogoulos&amp;wiki=on&amp;changeset=on&amp;ticket=on" title="Bugs in scipy">scipy</a> and <a href="http://pygame.motherhamster.org/bugzilla/show_bug.cgi?id=20" title="Bugs in pygame">pygame</a> .<br /></p><p>&nbsp;All of the above are python modules written in C, that's why they result in python crashing with segmentation fault -python modules can be written in many programming languages, including C.<br />&nbsp;<br /></p><h1>How it all started<br /></h1><p>Fuzz testing was developed at the University of Wisconsin-Madison in 1988/89 by Professor <a title="fuzz" href="http://pages.cs.wisc.edu/%7Ebart/fuzz/">Barton Miller</a> , that created the legendary program fuzz, that would send random data to Unix command line utilities. <b>Surprisingly, most of the programs and command line utilities he tested resulted in segmentation fault or heavy resources usage!</b><br /></p><p>One great presentation about fuzzing was written by Ilja van Sprundel and is <a title="Ilja van Sprundel on fuzzing" href="http://events.ccc.de/congress/2005/fahrplan/attachments/683-slides_fuzzing.pdf">here</a>. Another epic presentation is <a title="The art of File Format Fuzzing" href="www.blackhat.com/presentations/bh-usa-05/bh-us-05-sutton.pdf">The Art of <i>File Format Fuzzing. </i></a>Neat!</p><p>&nbsp;A good <a title="fuzzing-software" href="http://www.fuzzing.org/fuzzing-software">list of fuzzing software</a> can be found in the page made for the book Fuzzing: Brute Force Vulnerability Discovery. This is one of the two mainstream books that focus 100% on fuzzing, at least to my knowledge. The other book is Open Source Fuzzing Tools by Noam Rathaus and Gadi Evron.<br /></p>Amongst other fuzzers I would like to mention <a title="fusil" href="http://fusil.hachoir.org/trac">fusil</a>, due to the fact that it seems to be more actively developed, than other more famous fuzzers. Fusil is a powerful fuzzing framework that has many ways to create and detect a program crash and the framework comes with available fuzzing projects, such as those for fuzzing ClamAV, Firefox, mplayer, php.<br /><p>As any fuzzing project that respects itself, fusil contains a <a title="Crash List" href="http://fusil.hachoir.org/trac/wiki/CrashList">crash list</a>&nbsp;, aka a page with programs crashed using the framework/tool! If you look at the related lists for other fuzzers, like SPIKE, Peach or zzuf you'll realize that most of the high profile servers, programs or protocols have been crashed one or several times and bugs were found with fuzzing software!<br /><br />As a fuzzing framework, fusil is MUCH harder to use that a fuzzing program that targets a single entity (protocol or program). I would really like to write a GUI or web front-end for fusil, to facilitate the process of using fusil. I have contacted the author which was very kind and helpful, so at the near future I shall start working on this - time is the enemy here. <br /><br />Another great fuzzer software is <a title="zzuf" href="http://caca.zoy.org/wiki/zzuf">zzuf</a>, that makes it easy to test a program, you just run zzuf with a few arguments and the program you want to fuzz (eg Internet Explorer). See the rest for yourself!</p><p>Zzuf and a few other fuzzers are straightforward and easy to use, however fuzzing isn't by far a plug n play area. Most of the times deep knowledge of the file format/program/protocol that is going to be tested is needed in the case of serious vulnerability testing with fuzzing. <br /></p>Above all, have fun!<br /><br /><br /><br />&nbsp;