Dynadot .com transfer sale, only $10.12 with coupon code DYNA12, available while supplies last, ends October 31, 2026.

My thoughts about hacking... [Part 1]

SpaceshipSpaceship
SpaceshipSpaceship
SpaceshipSpaceship
Watch

DomainReseller

Rocket ManVIP Member
Impact
21
Is security really that critical? If so, why are some of the largest software companies providing such a bad example for the rest of the industry? Why would someone want to target my website? Why is security often overlooked?

These are all common questions that arise on a daily basis within the online industry. The rest of this article will provide some detailed answers, along with practical examples and true scenarios.

I've spoken with numerous hackers over the past short while. I can't count the number of times I've heard the line "Ignorant site owners deserve to be hacked". In my opinion, that's like claiming that cars without alarms deserve to be stolen, or homes without alarm systems deserve to be burglarized. It's not just wrong - it's illegal.

Security risks and vulnerabilities affect the entire online industry. When a single website is hacked, there are usually multiple other victims. This is most commonly seen with widely distributed software. A potential attacker has the ability to install the software on a test environment, locate the vulnerabilities, then attack random victims even before anyone else is aware of the potential exploits. Once a vulnerability is located, the attacker simply needs to search for other environments using the same software, and within minutes there are hundreds, often thousands of potential victims.

Typically, in the race to market, software providers are encouraged to release their products as soon as the applications are usable. Critical development procedures are often overlooked or intentionally bypassed. One such miss is an application vulnerability assessment. Although the product may be usable, the effects of a vulnerable application could be severe.

Sadly, nobody is "off limits" when it comes to hacking. Most hackers feel safe committing online crime, since the online industry has evolved much faster than the security industry. Many applications are not created with the intent to recognize hacking attempts. Some hackers view their actions as a competition - Who can attack the most valuable website? Who can exploit the most user databases? In many cases, these attacks are bragged about within the hacker's immediate network. The competitive nature of these hacking groups has become so severe, there have been reports of attacks between competing organizations.

You might ask, "If I use industry standards, won't my environment be secure?". The short answer: no, but it helps. Hackers are not restricted by industry standards. Most security companies only implement new standards once at least one victim is reported. This often gives hackers plenty of time to locate other vulnerable environments, and before long, the number of victims can increase rapidly. Hackers are some of the most innovative individuals within the online industry. The most logical way to combat them is to use similar methodology for security purposes.

---

Source: http://igosh.org/forums/showthread.php?t=544

Written by Matt Tanenbaum
International Group of Online Security Help
http://www.iGosh.org/
June 7, 2008
 
2
•••
The views expressed on this page by users and staff are their own, not those of NamePros.
GoDaddyGoDaddy
For those of you, who have never been a victim of hacking, you don't know how it feels.

I have a disability advocacy website that is under attack hourly.
My site cost have increased x 50.

I have zero respect for those that glorify hackers activities
 
0
•••
Honestly.. I think hacking is completely and utterly over rated, any person with even half the skills needed to hack properly, would not waste there time doing so (at least on us commoners with nothing worth hacking), and would sooner earn a decent living ethical hacking or security testing.

With regards web server hacking in particular, exploits / sql injection and the likes are primarily performed by script kiddies, can be of little concequence and I'd like to hope that 99.9% of all scripts are secure nowadays.

This leaves us with the 2 most concerning attacks:
a: brute force password attacks (on web apps, databases, ssh/telnet)
b: denial of service attacks

in reverse order..
b: what you gonna do? seriously if you're server is being attacked by a botnet of circa 25k machines, just ride it out and pick up the pieces; however 99.9% of the time your ISP will be covered against this with flood protection :)

a: get yourself v secure passwords; and keep all your valuable ports closed (ssh/mysql etc), or at least on private or alternative ip addresses.

all in though, the biggest risk?
"remember password" in your browser; /hackers/ like to find the easiest way in, and get the most control possible - most of the time this is simply sitting at your pc for 5 minutes while your not there.

ps:
if it's that sensitive or mission critical; why put it on a public server??
 
0
•••
blacknet said:
With regards web server hacking in particular, exploits / sql injection and the likes are primarily performed by script kiddies, can be of little concequence and I'd like to hope that 99.9% of all scripts are secure nowadays.

SQL injection having little consequence? I take it you are not aware that the the best possible scenario for the webmaster is that the data in the DB is tainted. The worst case scenario is that the SQL injection gives the hacker a chance to take over the server (and yes this can happen, usually by exploiting a vulnerability in the sql server).

Regarding most scripts being secure nowadays. Even if you made the most secure script in the world but was using a piece of software that is vulnerable then the server can be hacked. If for example you use php and you wrote the most secure php code, if 1 of the functions you use has a vulnerability or PHP itself has a vulnerability then you can be exploited. Just tae a look through the update logs of PHP and you will see MANY bug fixes, PHP 5 itself was susceptable to a buffer overflow.

blacknet said:
in reverse order..
b: what you gonna do? seriously if you're server is being attacked by a botnet of circa 25k machines, just ride it out and pick up the pieces; however 99.9% of the time your ISP will be covered against this with flood protection :)

Even the dns root servers cannot cope when being attacked with a DDos attack so what are the chances that joe bloggs webhost has an ISP that wil have such protection.

I have had a server attacked so much that the server didnt only have problems with the excessive connection attempts it also had a problem because the size of the iptables file, the server could no longer handle it. In this instance all that could be done was to turn the server off until the attack was over (and it started again a couple of wees later however a smaller attack that time)


blacknet said:
a: get yourself v secure passwords; and keep all your valuable ports closed (ssh/mysql etc), or at least on private or alternative ip addresses.

If you want to be able to access mySQL or SSH from an external machine (and of course SSH is generally accessed externally) you cannot close the port. You can go into stealth mode or something like that (which would help against port scanners) but you cannot close the port.
 
0
•••
There are many methods which can be implemented to reduce the severity of DDoS attacks. One of the applications that we have developed (still officially pre-release) is intended to recognize DoS and DDoS attacks. The application uses fewer resources than a successful DoS or DDoS attack, and simply blocks the data from being transmitted.

A practical example of the way the script works:

Imagine an image upload script. If the script is configured to only detect invalid files AFTER the file is uploaded, your system is wasting resources. Rather than receiving the file, checking the file, then deleting the file (which uses CPU, ram, bandwidth, and more), the script can be configured to detect the invalid file prior to the upload.

Similar methods can be used to reduce the severity of certain types of flood attacks. There are still certain attacks which cannot be secured against, for example:

A TCP flood from multiple remote systems. An attack like this is intended to overload the remote system by simply initiating an excessive number of connection acknowledgments, rather than actually sending large packets to the remote server. Due to the attack method, there is no data to deny.

An example of this:

Imagine a party - Each guest is only allowed to take 1 piece of cake. If there are only 50 guests, the cake will probably last throughout the entire party. If I bring 200 friends and they each take a piece of cake, there probably won't be any left within a short period of time.

The attack described above is similar - Nobody individually is taking more than the allowed quantity, but if too many people take the allowed quantity, the cake wouldn't last (or the server would crash).

In regards to securing SSH:

There are quite a few ways to secure SSH. One of the most recommended actions is to disallow untrusted users from accessing SSH (for example, hosting companies should not allow shared and reseller clients to use SSH, even in a restricted environment). Allowing restricted access to SSH is like handing someone a gun, but no bullets. All the user has to do is find bullets, and before you know it, he's a potential killer.

Some creative ways to secure SSH include:

-Requiring users to verify login attempts via email (sent to an off-site email address)
-Disabling standard root access (only allow root logins via authorized "su" user swap attempts)
-Logging all access attempts on a 3rd party server, with instant email notification
-Do not use the default SSH port

Enabling standard root login or using a standard SSH port provides the attacker with at least 50% of the information required to access the system. If the authorized root user is not standard, the attacker not only needs to guess the password, but also needs to discover the username. The same applies to the port - Allowing SSH access via port 22 (or other standard ports) provides the attacker with more information than he needs to know.

Brute force protection methods are highly recommended to block multiple invalid login attempts. Attackers often use automated scripts to brute force applications. Allowing an infinite number of login attempts per IP address or IP range enables the attacker to continue attempting to guess your password until the password is discovered. If no logging methods are enabled, the server administrator probably won't recognize the attack until it's too late.
 
0
•••
I think, people should be care themselves, thought there are quite loopholes. Similarly one of the biggest organization that controls the online industry, got controlled by "netdevilz" proved that there are some loopholes, or there are still ways that exist, ,may be leaking a important information by getting paid under the table?? may be?
 
0
•••
maniacbits:

One of the major issues with large organizations is the amount of information that is provided to the public. There was a news article recently stating that Microsoft purposely installed backdoors with Vista, enabling law enforcement agencies to access systems for criminal investigation. This raised quite a few concerns, because there is always the possibility that the backdoor will be exploited for the wrong reasons.

Other than the scenario described above, there are many other motivations behind illegal hacking. There are quite a few ongoing situations where an individual or company hires a black hat hacker to perform some dirty work against a competitor. Additionally, as stated in my initial post, malicious hacking is often considered a competitive sport between hackers.
 
0
•••
Keep up the good work Domain Reller

Looking forward to Part II

Cheers
Corey
 
0
•••
CatchedCatched

We're social

Escrow.com
Spaceship
Escrowly
CryptoExchange.com
Domain Recover
AIVikings
Catchy
  • The sidebar remains visible by scrolling at a speed relative to the page’s height.
Back