Slashdot Mirror

Let's read the article and see what that headline really means.

Litchfield took a look at just over 1 million randomly generated Internet Protocol [IP] addresses, checking them to see if he could access them on the IP ports reserved for Microsoft SQL Server or Oracle's database.

He found 157 SQL servers and 53 Oracle servers.

He found open ports on just over 200 servers, which correspond to the ports used by two popular database servers. That's all. The article doesn't say that he actually connected to them, confirmed that there were real databases running there, or even identified the owners. He found two hundred open ports out of a million randomly chosen addresses on the Internet. But "0.02% of Internet Connected Computers May Or May Not Be Running Database Software" just isn't the kind of headline that grabs attention.

Unless there is a lot more detail, preferably from someone who isn't in the business of selling firewalls for databases, then you'll have to forgive me for not being terribly concerned about this revelation.

"In the fast-moving world of software security it pays to have allies you can trust. Government, business and software vendors all turn to the global expertise of NGSSoftware for the protection they need. You can rely on us too... "

If the system has no hard disk, explain me where your hypothetical, urban legendary, hypervisor rootkit would reside? I seriously hope you're not implying the BIOS hold enough room to contain an hypervisor rootkit (come take a look at an hypervisor like Xen to see what I'm talking about).

Many PCI cards contain an expansion ROM that holds additional code required to initialise the card during execution of the system BIOS. This code is also responsible for carrying out the device-specific self-test and hooking required interrupts. The presence of an expansion ROM is determined via the Expansion ROM Base Address Register within the PCI function's Configuration Header.

It is worth noting that the expansion ROM does not necessarily hold x86 code nor does it have to contain a single ROM image. The code type field within the ROM data structure within the image specifies the presence of x86 code or OpenBoot interpretive code (documented in the Open Firmware standard).

The expansion ROM is stored on either an EPROM, or more commonly on an EEPROM. EPROMs require that the chip is removed from the card and erased via exposing it to strong ultraviolet light before it can be reprogrammed. EEPROMs, however, can be erased electrically, in-circuit, thus the card need not be removed from the system and can be re-flashed from the operating system.

In order to perform this, the user must have the SeTcbPrivilege and call the undocumented Native API function, NtSetInformationProcess with a process information class of ProcessUserModeIOPL. Once the user can perform unrestricted I/O, they can potentially re-flash the card without having to load a driver.

This raises the possibility of (1) a remote attack that yields LocalSystem privilege (such as the server service vulnerability patched in update MS06-040) being used to deploy a malicious expansion ROM, (2) a browser exploit, that, if the user is running under the administrative context, obtains SeTcbPrivilege and re-flashes a card.

Try these papers, you dip:

http://www.blackhat.com/presentations/bh-federal-0 6/BH-Fed-06-Heasman.pdf

http://www.ngssoftware.com/research/papers/Impleme nting_And_Detecting_A_PCI_Rootkit.pdf

Also, TFA links off to the Invisible Things website which DOES mention BIOS rootkits.

I have been tinkering with the methods in this PDF ..

http://www.ngssoftware.com/papers/StoppingAutomate dAttackTools.pdf

Specifically I have been testing out the Token Appending method, it looks like it might be a good method to try.

I've set it so that the token is a SHA1 hash of todays date, client browser string and a text string of my choosing, so basically this token with change daily for recurring visitors and be fairly unique to each visitor (you can just throw more unique qualifiers at it if needed).

It does rely on javascript in the client browser but most have that enabled anyway and it is an easier method for the end user than the Captcha method. Of course you could use both and really help keep the bots away.

Read this: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=op enoffice

Note that 2.0.3 fixes (at least) 3 flaws, one of which involves a buffer overflow that happens when you open any kind of openoffice document: http://www.ngssoftware.com/advisories/high-risk-vu lnerability-in-the-openoffice-suite/

Now, this doesn't mean OpenOffice security is bad, or that it's good, it just means that OpenOffice is subject to exactly the same kinds of security issues that happen whenever a complex app parses a complex data format. To pretend that it's somehow magically immune to this class of problem because of open source pixie dust is utter rubbish. Read the code.

I came accross this PDF a while ago, and though it was very informative, even providing examples of a few injection ways I hadn't thought before. Their White Papers section is overall pretty good, should be kept in your bookmarks for one of those slow news day.

I came accross this PDF a while ago, and though it was very informative, even providing examples of a few injection ways I hadn't thought before. Their White Papers section is overall pretty good, should be kept in your bookmarks for one of those slow news day.

TFA also states that "People who distribute networking vulnerability scanning tools such as Nmap or Nessus could also be caught up in part (b), Clayton warned.". A quick reading of section 41 seems to bear that out. As author and maintainer of the Nmap Security Scanner, I am more than a little concerned.

I'm certainly not going to let anything as silly as some U.K. law stop me from distributing Nmap, but I also don't want to become like Dmitry Skylarov the next time I give a presentation in England. And even if (as I would expect) the rest of the world ignores this, it could have a chilling effect on important security tools and research from U.K. citizens. Think of all the good research and tools that David Litchfield from London (NGS Software) has brought us. And my London friend Hoobie brought us the free Brutus password cracker, which appears to be prohibited by this bill.

The good news is that this is just a proposal. So I would join the chorus in urging our British friends to make their voice heard against this silly bill.

-Fyodor
Insecure.Org

Well that only accounts for part of phishing emails. However just like some people aren't as bright, or as educated in detecting fake emails, there are phishes who aren't as bright as disguising their fake email. Part of the problem is companies not bothering to make things easier for customers.

For example, when just logged into ebay a moment ago it directed me to a page with a contest where i could $500! The link to enter looks like this:
http://srx.main.ebayrtm.com/clk?%5Bmore junk]
So one could go register ebayrts.com or something similar and send some fake emails saying you could win $500! and direct people to a fake log in page. Now a majority of people would probably be suspicious and not fall for it but we know #1 ebay sends email to it's members about promotions, #2 ebay doesn't always use the same domain name. One could follow the advice you lay out and still fall for the email.

Example 2: How about paypal, they send out an email when someone sends you money. Scammer sends email saying you just received $153.21. The link in the email is https://www.paypal.us/com/cgi-bin/webscr?cmd=_acco unt where the real papal link is https://www.paypal.com/us/cgi-bin/webscr?cmd=_acco unt. (Note Paypal.us is registered by someone in Poland and is currently used for ad squatting) Once again you just have to fall for the simple url and enter your account info. It's not so simple as hey look some 12.34.56.78 is asking me to enter my credit card info.

Real life used examples from Millersmiles.uk, an archive of phishing emails.
http://www.millersmiles.co.uk/report/2661
http://www.millersmiles.co.uk/report/2681
http://www.millersmiles.co.uk/report/2678

Those examples are not going to work 100% of the time and still aren't undetectable but it just requires one lapse where you can easily fall victim. There seems to be a sort of apathy when it come to actually educating people. Most shrug and say it's their own fault for being scammed while companies continue to provide scammers with more ways to fool people. There is a good paper on host naming and url practices in pdf form at: http://www.ngssoftware.com/papers/NISR-BestPractic esInHostURLNaming.pdf
I would imagine phishing schemes would be less effective with just a marginal effort of education end users and following and sound practice by the company.

<<
If theres anything sophisticated enough to bypass this level of paranoia then it can damn well have my credit card number and I'll gladly send spam for them.
>>

This may very well astonish you, but such sophisticated infection mechanisms already exist and have already been demonstrated. See this rootkit concept overwriting your BIOS to create a permanent backdoor.

Note: removing the CMOS battery will not destroy this rootkit because the CMOS battery erases the NVRAM, not the BIOS flash chip. The only known way to recover from a BIOS rootkit is to reflash your BIOS... but what if the rootkit is intelligent and tries to re-corrupt the new image being flashed ? This is a possibility. In this case your only option is to physically change the flash chip with a known good one. And don't forget that a modern computer has a lot of flash chips that can theoretically be infected: hard disk firmware, video card BIOS, DVD drive firmware, etc.

The latest Microsoft compilers do implement canaries to check for buffer overflows, and DEP too.

There are still exploits for them though

http://www.ngssoftware.com/papers/defeating-w2k3-s tack-protection.pdf

The per process cookie isn't write protected, and exception handlers can be located on the heap.

Adobe Acrobat Reader... can be extended using the XML Forms Data Format or XFDF... XFDF files... are rendered automatically on downloaded [sic] when using applications such as Internet Explorer... When parsing an XFDF document the Adobe Reader suffers from a classic stack based buffer overflow vulnerability... On contacting Adobe, they confirmed that the current version is no longer vulnerable and NGSSoftware urgently advises users of Adobe Reader to upgrade.

Actually, I think it is just a matter of basics.
For a thorough treatment, this is as good as any I've found and far better than most: MSSQL-UDP Analysis