MITM, almost: Redux

Apparently one of my OpenWRT boxes still uses OpenDNS. I was checking my Godaddy account then a Mozilla Firefox security error popped up. Note the https at the end of the host.


I didn't accept the certificate since I was already logged in. Unfortunately it didn't happen again so I was not able to verify. Was it a one time or erratic glitch? I'm not very sure who is at fault here, Godaddy or OpenDNS.

Somebody else experienced this and he asked Godaddy customer support. The CS response:

Thank you for contacting Online Support. We are sorry for any confusion with this process. You should be using the latest version of your web browser, as well as any new patches for these. We cannot control any errors that appear on browsers or any local security settings. However, the latest patches, web browser versions, etc. should rid these errors on your browsing.

Please let us know if we may be of further assistance.
Sincerely,
Ben P.
Online Support

The response was not satisfying to say the least but this is possibly a Mozilla Firefox bug. Replicating it is pretty hard so reporting will be a pain in the ass.

ICC stack-security-check

Recently I've been playing with the Intel C++/C Compiler. Code produced by the compiler reportedly are optimized better than GCC's. I'd say it's overrated and only gives perceived speed increase for common use.

I noticed that by default it produces AT&T assembly instead of Intel. Anyway, I'm more interested in its security feature.

$ icc -help
...
-fstack-security-check
              enable overflow security checks
...

A sample C program I used.

int 
main(int argc,char *argv[]) {
  char buffer[256];
  strcpy(buffer,argv[1]);
  return 0;
}

This is the vanilla assembly output of the program above.

push   ebp
mov    ebp,esp
sub    esp,0x3
and    esp,0xfffffff8
add    esp,0x4
sub    esp,0x108
add    esp,0x0
lea    eax,[ebp-0x100]
mov    DWORD PTR [esp],eax
mov    eax,DWORD PTR [ebp+0xc]
mov    eax,DWORD PTR [eax+0x4]
mov    DWORD PTR [esp+0x4],eax
call   804ddd0 <strcpy>
add    esp,0x8
xor    eax,eax
leave
ret

Looking at the produced assembly output of -fstack-security-check, it looks very similar to Stack Smashing Protector (SSP).

[chunk 1]
<         sub    esp,0x108
---
>         sub    esp,0x10c
>         mov    eax,__intel_security_cookie
>         mov    eax,DWORD PTR [ebp-0x4]
[chunk 2]
<         lea    eax,[ebp-0x100]
---
>         lea    eax,[ebp-0x104]
[chunk 3]
>         mov    eax,DWORD PTR [ebp-0x4]
>         call   __intel_security_check_cookie

__intel_security_cookie is a 32-bit canary from DS e.g. ds:0x080bc00c. Just like SSP it checks the canary before returning.

./dumbsoft `ruby -e 'puts "B"*512'`
Error:  Buffer overrun occurred, forced exit
Aborted

In case you didn't know, GCC has similar features.

DDoS progress

The Gala Coral Group reported that last year their gambling sites got hit by a 10Gb DDoS attack. The Information Security Officer spoke at the recently concluded e-Crime Congress 2008.

I'm not sure of the exaggerations but an interesting part is:

Attackers disguised the build up of traffic from up to 30,000 PC and Apple Mac botnet computers during the attack by analysing and reproducing the browsing habits of the sites' typical users.

Windows PCs no longer has the monopoly on botnet herds. The attackers also took the trouble into making it hard to defend against.

It sure is hard to separate the attacks if everything looks like legitimate access. Their firewall also proved to be worthless:

More worrying, during a second attack the botnet blocked attempts by the websites to stop them using a port firewall while continuing sending out data to carry on the attack.

Putting up a firewall during a big DDoS attack is useless even a stateless one. You need to work with your upstream provider to mitigate these attacks and since everything looks like legit, $DEITY help you.

Resistance is futile.

Recycle

Easily recycle thousands of compromised boxes using these easy steps

1. Search for commonly used defacer messages
2. Pick a defaced site
3. Find out how they got in
4. Patch the entrance (optional)
5. Repeat

Because of forgotten web applications lying around web directories not updated those steps can be very effective. Some defacements can go undetected for many years. If someone can create or edit files in web directories specially a php script, a shell's a whiff away.

For example this guy does not even know his host got pwned in March 2006. I think he's very busy with his new kid.

Outdated or not, the insecure web application (phpGraphy) which was used to gain entry has a below average security track record.

• 0.9.13a - Fixed a security bug related to vulnerability in PHP itself
• 0.9.12 - Fixed security bug introduced in 0.9.9
• 0.9.12 - Fixed security bugs introduced in 0.9.12-rc1
• 0.9.11-rc1 - Fixed security bug related to internal security levels
• 0.9.9a - Fixed little security bug with random pic function
• 0.9.5 - Some html "security" holes fixed
• 0.9.4 - Bugfixed security level system

MITM, almost

Yesterday I wanted to check my bank balance. Clicked on the my bank's ebanking interface but I was presented to what looks like a self-signed certificate warning. Not a good sign as this means a possible MITM. For comparison the self-signed certificate is here. A legit certificate from the bank is here.

I proceed to accept the self-signed certificate to see if it's really a MITM. To my disappointment it was not. Actually it's a Squirrelmail installation at 125.212.46.13 which has a self-signed certificate. A bad practice nonetheless.



Must be a typo in one of their nameservers as 125.212.46.18 is the correct host. Normal response should be:



At first I suspected it was a MITM because 125.212.46.13 is an old CentOS 4.x installation with PHP 4.3.9 and Apache 2.0.52. Probably compromised I said to myself, along with an A record it makes a good MITM host. Apparently the mis-configured nameserver is 210.14.7.216.

.

As of today 125.212.46.13 is dropping connections but 210.14.7.216 still is returning it as an A record for ebanking.unionbankph.com.

Holes

A week ago the OpenBSD 4.2 errata page have been updated with two fixes or vulnerabilities, depending on who you ask. In case you are not aware, OpenBSD doesn't have formal or official security advisories. You have to check the errata page for security vulnerabilities.

• 008: RELIABILITY FIX: February 25, 2008 All architectures
  Malformed IPv6 routing headers can cause a kernel panic.


• 007: RELIABILITY FIX: February 22, 2008 All architectures
  Incorrect assumptions in tcp_respond can lead to a kernel panic.

I wonder if arbitrary code execution is possible for these bugs. Those entries reminded me of a 4.0 errata entry:

• 010: SECURITY FIX: March 7, 2007 All architectures
  2nd revision, March 17, 2007
  Incorrect mbuf handling for ICMP6 packets.

Started as a RELIABILITY FIX until Core Security took a jab at it. They provided a POC and forced OpenBSD to revise the errata. It's troubling that a remote crash is not considered a security vulnerability in OpenBSD.

On March 16, 2007 an update was done to the famous one liner that glazed the project's homepage.

Alfredo Ortega of Core Security presented to Defcon 15 the details of the exploitation. Read the paper and the slides. I reckon entry 008 is the third remote vulnerability that Core Security was talking about.

In the presentation you will see they disabled W^X through extension of the kernel CS (Code Segment) selector. This shows the lack of protection done to kernel memory unlike what PaX provides to the Linux kernel. Expected, as PaX predates W^X and is obviously based on it.

Later this year we will possibly see a OpenBSD feature similar to KERNEXEC. Besides the latest PF code I don't see any advantage using OpenBSD anymore. Even NetBSD is catching up and may even be better with its security features.

I bet before the end of the year it will be three remote holes in the default install.

Violent Upgrade Cycle

A RedHat fan visited the NASA Telescience Lab to check out the RHEL and Fedora Core installations. One of the pictures caught my attention.

If it ain't broke, don't upgrade it, right? Actually one of the guys in the lab told me they are in the process of upgrading to Fedora 8 and playing with 9 alpha.

This machine is possibly http://countdown.ksc.nasa.gov/. I'm not sure what's their policy for upgrades. This is one of those install and forget setups. I can deduce that no major updates happened after installation.

I reckon the installation happened around July 15, 2005 to August 25, 2005 where at least a kernel update was done, that's why the kernel is kernel-2.6.12-1.1398 and not 2.6.11 which is the Fedora Core 4 default. You will also notice that Apache is still at version 2.0.54.

If this is the norm at that lab we can assume that the other machines are under the same upgrade cycle. The machine looks like it does not perform any critical task and contain any important data. Possible entry points like this is all it takes to fully compromise a network.