A hacker recently obtained unauthorised access to the IP telephony 
(VoIP) system of a Perth business, making 11,000 calls costing over 
$120,000, according to the Western Australian police.

The calls were made over a period of 46 hours, the police said, and the 
business only became aware of the imposition when it received an invoice 
from its service provider.

Thieves have always targeted PBX systems by finding numbers used for 
remote calling — for mobile employees or those requiring international 
call access outside of business hours — to make calls at the company's 
expense.

This has in the past been exploited for uses such as routing calls made 
on cheap international phone cards, according to Pure Hacking senior 
security consultant Chris Gatford.

However, police said they were more concerned with the increasing number 
of occurrences such as that in Perth where the thieves gained access to 
users' VoIP network. They have issued a warning to small businesses to 
ramp up their VoIP security.

A noted security analyst has proposed a new twist on the traditional denial of service model where attackers purposefully inflate the bills of cloud service users until they can no longer afford service.

Christofer Hoff, the Chief Security Architect at Unisys, has recently been discussing the concept of an Economic Denial of Sustainability on his blog. Put simply, it is an attack against the billing model that underlies the cost of providing a service with the goal of bankrupting the service itself. Before we go into why EDoS is a threat, and one that is separate from DDoS, we have to understand how companies turn dollars into bytes, which they hopefully turn back into dollars.

The operations team at a company does two things. They buy hardware, and they pay people to keep the hardware and its software from falling over. The cost of the boxes and the pipe installation is known as Capital Expenditures, or CAPEX, while the cost of electricity, bandwidth, and the tireless individuals who maintain the systems all hours of the day is the Operational Expenditures, or OPEX. Traditionally all dotcom’s had a chunk of CAPEX for systems and then a team of people (your OPEX) to maintain the systems. If you wanted to grow as a company, you had to buy more boxes and more people to maintain them.

This is why CIOs, including the competent ones, are all hot and bothered by Cloud Computing. They can delete the CAPEX sheet from their books and then only consider the OPEX side. All of their budgets are worked out based upon how many dollars they make off of each byte shoveled, and if they can guarantee that they pay less to shovel a byte than they charge for each byte shoveled, you have reached stage 3: profit. These equations even hold true if you have some flash of legitimate traffic that wants your service. Sure, your cloud system bill goes up for the month, but you are making more money off of the traffic, so everyone is happy.

What happens when you introduce DDoS to the equation? In the traditional model where you buy your own boxes and you have your own maintenance staff, a DDoS attack saturates everything you have and starves your legitimate customers of data. Your bandwidth provider is also used to seeing DDoS attacks and has technical strategies, like Arbor Networks systems, in place to limit the damage. The result is you lose out on servicing your customers and face an increased bandwidth bill for the month.

The story is a little different in the Cloud world. Organizations will shift their budget from the CAPEX column over to the OPEX column, and find out that their initial cost is far lower. The variance from quarter to quarter will be higher, but hey, traffic varies from quarter to quarter. When a lightweight, under the radar, DDoS hits the cloud service, the service can elastically scale to meet the worthless demand. This time, in the absence of any self-throttling components, namely the capacity of your services, the result is a massive spike in billing without the commensurate increase in revenue derived from the traffic. Rather than losing money on unserviced customers, you end up overpaying for servicing the non-existent shadow customers of the DoS.

EDoS, like DDoS, is not an insurmountable problem. The billing models that underlie cloud services may not be mature enough to properly account for an EDoS like attack. I am sure they will all be straightened out in time, but there will probably be a business or two that fails in the meantime because their unwarranted usage spike causes them to go deeply into the red.

source

Everybody who has read a paper on SQL injection has seen the ‘OR 1=1’ example (or the similar ‘ OR ‘’=’). It is the classic method for bypassing authentication when an application does not sanitize user input before using it in SQL queries.

I think it is somewhat overused. Often I see pentesters throwing this kind of string into each input field, hoping to trigger an SQL injection or some kind of error. Some tools which test for SQL injection (for example Nessus) also do it.

So why do I think it’s bad? Well, because it can have a major impact on the query that’s executed and has the potential to break things. Production systems are often the target of pentests and we should try not to break those.

Unless you have the source code to the application, you can’t know exactly what happens with your input string. Most people assume they are injecting into SELECT statements, but of course, applications also use DELETE, UPDATE and INSERT, which modify the database. Let me give you a real life example, we once cam e across an application which did this ($articleID comes from user input):

‘SELECT title,text,hitcount FROM articles WHERE id=’ + $articleID

A prime target for SQL injection! But a little further in the code something else happens:

‘UPDATE articles SET hitcount=’ + $hitcount+1 ‘ WHERE id=’ + $articleID

So the application first retrieves the title,text and hitcount for a certain article from the database, all is well here, the only thing that happens if we enter ‘OR 1=1’ after the articleID is that the application will receive all articles from the database and will most likely pick the first one.

The next statement is a different story, as the application tries to change something. It has retrieved the ‘hitcount’ for the article in the previous query (the hitcount being the number of times the article has been viewed) and uses it in a different query, to update the hit counter with a new view. Our articleID is used again as well, but in this case the resulting query becomes something like:

UPDATE articles SET hitcount=1338 WHERE articleID=1234 OR 1=1

This will set the hitcount to 1338, but instead for just just article 1234, it changes it for all articles in the table, not what we intended to do! Of course this is in most cases a relatively harmless scenario (and an example of lousy software engineering), but had our articleID been used in a DELETE statement, all articles would have been deleted from the table.

In September of 2007, I wrote “The truth about viruses” and pointed out how the ubiquitous danger of viruses exists largely because of negligence. When the vulnerabilities that common viruses exploit never get fixed, and those viruses are only guarded against in a case-by-case manner using signatures-based and heuristic detection systems, new viruses that will bypass detection and still affect your computer can be created by the hundreds and thousands with minimal effort. In short, much of the reason for the ubiquitous threat of viruses is a tendency of software vendors to ignore virus-exploitable vulnerabilities, and expect antivirus vendors to pick up the slack.This is not a problem particular to viruses. In fact, a good antivirus application can protect you from viruses reasonably well most of the time. Those of us who deal with security issues professionally, or even regularly as a hobby, are understandably leery of the idea of being “reasonably well protected” from something “most of the time.” Still, it’s obvious that antivirus software is not a complete failure as a Band-Aid over a sucking chest wound.

The same problem exists outside of virus-exploitable vulnerabilities, however, and is not nearly so well addressed. As Gregg Keizer reports in “Top security suites fail exploit tests,” integrated security suites for desktop computers fare much worse across the range of threats against which they’re expected to protect you.

I’ve prepared a couple of simple bar graphs to give you an idea how much they protect you against virus threats and active attacks. I cut the number of compared vendors down to 10 in each case, because that’s the number of vendors that overlapped in the two shootouts. In both graphs, I will use the color green to show threat coverage that exceeds 50%, yellow to show threat coverage that exceeds 25% up to 50%, and red to show threat coverage no higher than 25%. In both graphs, they’re ranked from best performing vendor to worst performing.

The first example is from the June 2008 Virus.gr antivirus software shootout, and in each case where a single vendor had more than one product in the shootout, I counted only the best-performing product:

Antivirus Performance by Vendor

The second example is from Secunia’s [PDF] October 2008 Internet Security Suite test:

Security Suite Performance by Vendor

An antivirus application is expected to do well at protecting against viruses. While I wouldn’t consider anything lower than, say, 98% coverage to qualify as doing sufficiently “well” to satisfy me personally, at least nobody came in under the 50% wire.

An integrated Internet Security Suite is expected to protect one against active threats; it should include effective firewall, rootkit detection, active vulnerability defense, and at least some rudimentary kind of real-time intrusion detection. Sadly, one might have noticed I didn’t get to use my virtual yellow highlighter at all in that security suite graph. Everything came in below 25%. Even though the best was significantly better than second place for the vulnerability prooofs of concept that made up the testing gauntlet, it was nowhere near good enough to even bother.

The problem here is multifarious. A few key points include the following:

• Notice that there isn’t much relationship between who were the best performers on one graph and who were the best on the other. A lesson to take from this fact is the idea that maybe companies that are good at one thing aren’t necessarily good at another. The best performer on the AV graph was tied for third worst on the security suite graph; the best performer on the security suite graph was fourth worst on the AV graph. The fact some vendor seems to do well at AV in no way suggests you should entrust that vendor’s software with all your security software needs.
• As pointed out in Secunia’s test results document, vulnerability defense coverage is abysmal in every case — more so in some cases than in others. When corporate software vendors do not quickly and effectively patch vulnerabilities (which is almost always the case) and users do not test and apply security patches in a timely manner (which is usually the case), vendors for security software should definitely look into picking up some of the slack. Can you imagine the marketing benefits if you were the only vendor to achieve more than 50% coverage in Secunia’s test — especially with second place, an order of magnitude better than third, scoring less than half as well as you?
• Security software vendors shouldn’t even have a vulnerability defense market to target. Software vendors should be patching vulnerabilities more quickly than security software vendors can develop active defenses for them, and software update systems should be designed to make it at least as easy to find and apply patches without breaking functionality as to fail to update. This is a huge challenge for closed source software vendors, of course, but that doesn’t mean it’s not a challenge that needs to be met.

I can offer three simple pieces of advice, if you want effective defense, one to deal with each of the above problems:

• Build your defenses a piece at a time, selecting the best security options for each part of the whole. Don’t trust a single vendor to get everything right, because, frankly, it probably won’t.
• Track vulnerabilities yourself. Choose software that offers good mechanisms for doing so, and protect yourself to the best of your ability.
• Make your software selections at least in part based on good vulnerability response time (and don’t fall into the trap of simply counting discovered vulnerabilities).

source

I lost the login to my old account and it's not sending to my email, I may have used a different email than usual though, I don't know if it's my email or the servers here that are messed up, it's probably my fault.

Anyhow, I haven't been here for a long time and wanted to come post. Dan and myself decided we were going to try our hand at web design which would be nothing new considering that's what we've been doing for the longest time. The only difference is we did it for our own projects, we never really thought about doing it for other people.

One day I pointed out to him how much money this guy I know made with his local mom and pop web design company. After a brief discussion we decided if they can do it, why can't we? Well, Naples Web Design was born.

Obviously the main service we plan on offering is web design, but we also want to offer other stuff too. Everything form MySQL and programming to PPC management. I really feel like if we can compete in the national arena, we should be just fine in the local one, wouldn't you think?

So that's it, that's what I came to say. I'll definitely post again after we get our first client! Wish us luck!

P.S. if the admins have time, feel free to email me about my password. If not, doesn't really matter I suppose seeing as how I got a new account.

UPDATE: We got our very first client and I wanted to give them a shout out! Naples Blinds FTW!