A Puzzlement...
Perhaps I'm getting old and unimaginative - but I just don't get it...
About a month and a half ago, I published a diary called "What's In A Name." In that diary, I discussed an interesting "hack," where additional names were added to DNS zone information as part of what appears to be an SEO (search engine optimization) scam.
Over the past month, I've seen several web app RFI (remote file inclusion) attacks that have been using "target files" hosted on machines with names like blogger.com.victimdomain.com or img.youtube.com.victimdomain.com. A little digging shows that these names also appear to have been added to DNS zones without the knowledge or permission of their owners. As in the first set of these I found, those names point to a completely different machine (in fact, in a different country) that has nothing at all to do with the main domain.
So, what's the point of using one of these names? What does this sort of obfuscation gain someone doing RFI attacks?
I'd love to hear some theories, because honestly... I'm stumped.
Tom Liston
ISC Handler
Senior Security Analyst, InGuardians, Inc.
twitter: tliston
P.S.: The folks at the web hosting company that I talked with were less than helpful. The contents of DNS were "confidential" and they could only respond to a "client complaint." So I'm left trying to explain to some poor, clueless, mom and pop outfit that they need to contact their web host and complain about something called "DNS." Lovely.
I keep hearing horror stories about how organizations treat people who contact them regarding security issues. Please make sure that *your* organization truly works with anyone who reports an incident. It's the frickin' holidays, after all...
UPDATE: B-I-N-G-O! Both @web007 and @jjarmoc on Twitter came up with the answer... and made me kick myself for not looking more closely at how these machine names were being used in the RFI attack. The attack is intended to satisfy a poorly written domain name matching "filter" for allowed remote includes in the script being attacked... in this case, timthumb.php. Thank you, thank you, thank you! And, if you're using timthumb.php, you need to make sure you're using the latest version. Also, @jjarmoc correctly points out that this isn't really an RFI attack... the malicious code is actually uploaded and executed - but the end result is the same.
It's Cyber Monday - Click Here!
Wait - What? Click Here?
It appears that our spamming friends are taking advantage of the Cyber Monday phenomena, and trying to phish us into clicking links in the hope of getting that awesome deal on a watch, camera, tablet or laptop.
While there certainly are great deals and reputable vendors, my personal "spam / phish" email count is 8 so far today (and it's just 9am here in sunny Ontario, Canada). Emails that appear to be from a reputable vendor, but in order to actually get that great deal, yes, you guessed it - click here ! The link that they want me to click of course does not belong to the vendor that the email appears to come from.
In roughly half the cases, it's close enough to fool lots of people. The other links are obfuscated in hex, so they don't look like anything unless you click them. Of the illegitimate sites, most of them I've looked at are distributing malware, but really they could be anything - with the count rising by the hour, who has time to check them all out?
There are some good deals out there today, but please, shop responsibly! Check that link out before you click!
===============
Rob VandenBrink
Metafore
Pentesters LOVE VOIP Gateways !
As someone who does vulnerability assessments, you always hope your clients are doing a good job with their security infrastructure. Theoretically, the perfect assessment is "we didn't find any problems, here's a list of our tests, and here's a list of things you're doing right". In practice, though, that *never* happens.'
Also in real life, there's that private (or vocal) "WOOT" moment that you have when you find a clear path from the internet to the crown jewels. I can start anticipating that moment when I see a VOIP gateway in the rack - these allow remote VOIP sessions (either from a handset or a laptop) to connect to the PBX, through a proxy. VOIP vendors (all of them) sell these appliances as "Firewalls", and usually they have the word "Firewall" in the product name.
I had a recent assessment, where we found that the VOIP gateway was based on Fedora 7, with all server defaults taken. Yes, that includes installing an Apache webserver, a DNS server and a Mail server. All unnecessary, all exploitable (given the vintage). Not only that, but they enabled packet forwarding and SNMP, so that not only did the unit forward packets from the internet to inside resources, it also advertised that fact through default SNMP community strings, along with the internal subnets themselves ! Oh, and source routing was enabled - - sort of a pen-test trifecta !
In another engagement, we found a gateway from a different vendor, based on BSD (good start), but with a similar litany of issues:
- SNMP enabled on the exterior interface
- Default snmp community string
- Routing enabled
- Internal interfaces and internal routes listed via snmp
- Source routing enabled
- Oh, and the admin interface (with vendor default credentials) was facing the internet - not that we needed that, it was already open!
- an expired, self signed certificate.
- To top it all off, when you got to the admin interface, the you were looking at the word "Firewall" in the product name ! (yea, that made me smile too)
Not having actually seen the unit, I asked the client to check to see if it might have been hooked up backwards (with the private interface on the internet side) - alas, that was not the case, the "hardened" interface had these issues !
It's still *extremely* common to see voicemail servers based on SCO Unix or Windows 2000 (Windows NT4 in a recent assessment ! ). One vendor in particular still has a production, new-off-the-shelf voicemail server based on Win2k.
Mind you, all of the appliances had been in the rack for a number of years - the current crop of these devices are not nearly as open as some of the older ones. But that's actually part of the problem - people seem to consider Voice systems (PBXs and ancillary equipment) as "appliances" - somehow different than Windows or Linux servers. Which as you've probably guessed, is not wise - they *are* Windows or Linux servers! They need to be patched updated, monitored and included in every process that your internal, dmz and perimeter servers see.
Even today, we see organizations trust appliances from vendors that don't place security at the fore. Then once they are installed, they are promptly ignored, sometimes for years. Anymore, if it has an ethernet jack, you should be asking security questions before it gets plugged in. And those security questions should be asked again, at least once or twice a year in the form of an audit, assessment or pentest.
Anyway, all I can say is - when I'm looking for vulnerabilities, I LOVE (ok, I really really like) VOIP gateways !
... but you knew I'd be saying that !
==============
Rob VandenBrink
Metafore
Comments