Domain: red-database-security.com
Stories and comments across the archive that link to red-database-security.com.
Comments · 7
-
As do I (programmatically online for decades)
Via programming, database-wise (client-server largely since 1995 online professionally) that travels over the public internet, & yes, has to resolve out domain-hosts names + travels over various ports online... middleware too!
For example, some defaults for online communications as well as "internal/local LAN":
SQLServer = 1433/1434, MySQL = 3306, DB/2 + others too, & those are just defaults ports, yes, that could be changed, mind you + for instance do more...
E.G.-> Look @ what can be done with Oracle products here -> Oracle = http://www.red-database-security.com/whitepaper/oracle_default_ports.html
Fact is - A lot of that today gets done by SQL online via websites/webservers in communication with HTML & browsers, etc./et al but, my point's to show CUSTOM PROGRAMS HAVE USED THE PUBLIC NET FOR AGES TOO... & not just HTML & database access for they - banks even use it!).
APK
P.S.=> In fact? Heh - I have such a program I've written up here running right now, continuously, every 15 minutes written in PyThon 2.7x that hits sites, files, webpages too on a couple, to fill the very HOSTS file I speak of here... & it's not a browser, but it has the sites it actually goes to HARDCODED in my HOSTS file, which means no hosts-domain name resolution time is ever taken to talk to they that's slower than local access which is SSD zero ms practically fast here off a 4gb Gigabyte IRAM DDR-2 SSD that holds my HOSTS file + the files cached too!
(Thus - It's not SLOWER on that op either, because of HOSTS files having its sites hardcoded init, such as DNS servers are, & potentially downed or worse in THIS case, for security, DNS-poisoned/misdirected (but I use the "best in the business" on those, if not for hardcoded sites, in Norton DNS, Open DNS, Scrub IT DNS (all heavily security oriented vs. malware too))... apk
-
Re:With all due respect
The XSS mentioned requires the use of phishing techniques...
To you and everybody else who keeps thinking this somehow discredits the article:- The only reason he needed to "phish" was that this site had a maxlength on the relevant textbox. Other sites won't. Many sites can be directly exploited. The phishing in this case shows that maxlength is not an adequate security mechanism (duh), not that phishing is required in general to exploit sites.
Moreover, I'm pretty sure that if he was a bit more clever, or a bit lucky, he could have skipped that too. We don't know what site he was working on, but I wouldn't be surprised that he could have written an exploit that sent out code that used Javascript to strip off the maxlength parameter, loaded in his exploit code, and then proceeded onward, all without user intervention. - Have you not been reading the news? Phishing works all the time! If you have a large enough site, the odds of at least one of your users falling for it approaches 100%. If you're basing your security on "not being phished", it's not even worth calling "security".
Thirdly, is simple abuse of a poorly designed web application.
Your average web application is poorly designed. I've found XSS in commercial apps, but they do tend to converge on security. Eventually. But even names as prestigious as Oracle have had XSS flaws.
The problem is that all of these flaws are of a kind; if you don't escape your user's input correctly when sending it back into the user's HTML page, it's a good guess that you also send the user's values into the database unescaped, or that you'll happily run uploaded PHP content unescaped. It's really all the same error, so they tend to all show up at once. And they do, often.
Pointing out that XSS can only be done on poorly designed sites is really a tautology. The fact is, there's a lot of them, and I hope this article will open some eyes about how serious that poor design can be. - The only reason he needed to "phish" was that this site had a maxlength on the relevant textbox. Other sites won't. Many sites can be directly exploited. The phishing in this case shows that maxlength is not an adequate security mechanism (duh), not that phishing is required in general to exploit sites.
-
logon trigger aa blocked by Google?
In the article by red database security it's stated that Google has allready blocked the Full Disclosure mailing list article refering to the sploit, and a request to it, "http://www.google.de/search?hl=en&q=startc0GtJBi
1 +full-disclosure&btnI=I%27m+Feeling+Lucky", results in a message by google stating "We're sorry... but we can't process your request right now. A computer virus ...", but if you change the request, eliminating the "hl=en" parameter you get the Full Disclosure mailing list article, thus making the source of the exploit easily accessible, perhaps should google find a way to better to block articles they don't want be accessible by their search engines. -
Re:Comparison of MySQL, PostgreSQL, Oracle, MS SQL
MS SQL Server:
... Troubled security history.
Nice and objective. Not.
At least Microsoft deals with it's security issues promptly. Unlike, say, Oracle. -
Re:Deparment of Homepage Security
This is bullshit.
Oracle does _not_ take vulnerabilites seriously. I agree that the oracle database is extremely complex, and the implications of bugs is enormous, but it's not inherently complex. Because of this, claiming that they don't release patches because it's complex is bullshit. Oracle does not need to be as complex as it is.
First, the complexity:
I've been running Oracle just as long as I've been running both Mysql and Postgres (I know what you're saying - oh, he's one of those guys:)), and I know that the features oracle offers can exist without all of the useless bloat oracle tacks on. Mysql can replicate, instantly, to who knows how many databases. Oracle Dataguard is limited to 9. I can restore databases in seconds using postgres, oracle takes all damn day. Mainly because you have to have your ducks in a row with: Arch files, redo files, tnsnames, listener files, spfiles, pfiles, oratab, oracle home, etc. Oracle databases are extemely difficult to get running on a different system. Even exports (exp/imp - what _should be similiar to an sql dump) don't work across OSs. Oracle offers no native sql dump command, instead you have to figure out how to get TORA working. Oracle offers sqlplus, an old, broken command line client that requires unsightly scripting to even start the database.
Oracles documentation is very similiar to their product: Disconnected. Nothing fits. Everything (kind of) works, but noone knows how to put it together, save the people who killed what must be hundreds of thousands of brain cells by doing it by trial and error. Oracle requires java, and lots of it. Oracle requires an oracle database to monitor other oracle databases. It's wise to put this on a seperate installation/box. Doesn't seem to make a lot of sense. Now I have twice as many exploitable boxes, not to mention more to backup, administer, etc. Oracle requires an insane amount of diskspace compared to other databases.
I'm not arguing for mysql/postgres vs. oracle - I'm just trying to say that Oracle does NOT need all of the bloat it currently has. The company could stand to do a complete rewrite of it.
Now, the security:
Here's a perfect example of what I mean:
http://www.red-database-security.com/advisory/publ ished_alerts.html
The first 6 vulnerabilites are 600(!!!) days old!
Here's a perfect example of their lack of motivation.
http://packetstormsecurity.nl/0507-advisories/Orac le9R2-unpatched.txt
Basically, a vulnerability was disclosed months ago, and oracle fixed 10.x in July's update, but completed ignored 9.x. To quote TFA:
'We contacted Oracle about this issue and Oracle
confirmed it, when we asked why there is no fix
for 9iR2, Oracle said:
"Our development teams neglected to do the backports.
We are working on creating those backports now."'
Leaving production systems unpatched until October! (Assuming oracle doesn't 'neglect' to do it again.
In short, quit reading the marketing bullshit and wake up. -
Re:But that's true, at least for extensive vulns
The problem is, a few of the recently-released ones had lag times measured in *years*. Oracle can whine all they like about unrealistic deadlines from researchers, but a few years is far too long to sit on something.
My reference for the years comment:
http://www.red-database-security.com/advisory/publ ished_alerts.html
They waited over 600 days for Oracle to patch some vulns. There's no excuse for that. -
Re:I wonder...
"That was true a few years ago, but its rarely the case these days. Once you contact the correct people at the vendor they generally move fairly quickly to resolve the issue."
That turns out to not be the case. On the server side, Red Database reports several vulnerabilites upatched by Oracle for over 600 days, at least one unpatched for over 700 days, etc. http://www.red-database-security.com/advisory/publ ished_alerts.html
In userland, Microsoft Internet Explorer is famous for long-standing open vulnerabilities. No point in going into that one at Slashdot.
It once took me more than a year to get HP to admit to a problem in HP-UX 11i. As of January, they still hadn't completely accepted the fact, and had only a partial fix in place.
I'd be surprised if this trend didn't continue. Software complexity is the culprit. Not only does it make flaws far more likely, but patches which really do fix the problem, without introducing others, become progressively more difficult to create and test.
Has anyone here seen software as a whole growing *simpler* with time? I didn't think so.
It's just the general nature of things. Marketing departments in commercial software shops have to keep adding bullet points to get people to buy the latest revision. Things are a bit better in the OSS world, where this sort of thing typically happens as a result of feature requests from users, not marketers. But there too, complexity only grows, albeit not as quickly.
The fix(es)? Well, like any security guy, I have my opinions. But that's way too much to cover in a Slashdot post.