Feeds:
Posts
Comments

Posts Tagged ‘Ethical Hacking’

Session Hijacking

Session hijacking is the act of taking control of a user session after successfully obtaining or generating an authentication session ID. Session hijacking involves an attacker using captured, brute forced or reverse-engineered session IDs to seize control of a legitimate user’s Web application session while that session is still in progress.

Types of Session Hijacking

There are two types of session hijacking attacks:

Active: In an active attack, an attacker finds an active session and takes over

Passive: With passive attack, an attacker hijacks a session, but sits back, and watches and records all the traffic that is being sent forth.

Session Hijacking Attacks:

Attackers’ use several session hijacking attacks to gain access to user sessions on a server, the most common of these attacks are listed below:

  • Session Prediction
  • Session Sidejacking
  • Session Fixation
  • Cross Site Scripting
  • Using Proxy Servers
  • Physical Access to Server

Defending Against Session Hijacking

Since session hijacking is where the attacker steals a user’s Session Identifier, to prevent this attack, we would need to prevent the user’s Session Identifier. There are several things we can do to help to prevent this attack:

  1. Use Secure Connections (Achieved through Secure Socket Layer(SSL) – as much as possible, since SSL creates an encrypted connection between the client and server, any data the attacker steals during this transfer would be useless to them. However, SSL does not fully secure against this attack, and hackers can still use session hijacking even over HTTPS.
  2. Regenerate user’s session identifier often, therefore, even though the attacker may manage to steal a user’s session identifier, when it is regenerated, the Session Identifier he stole would be useless.
  3. You can implement an IP Address Check to match a user’s Session Identifier to his/her IP Address. However this may have its limitations.
  4. Another method is to use HTTP only cookies, these are cookies that claim to be inaccessible from the DOM, However, some hackers have claimed to gain access to HTTP only cookies through the dom. HTTP only cookies would still make it harder to gain access to cookies using most of the session hijacking attacks. However if session Sidejacking is used, These cookies can easily be stolen from over a LAN network. Session Sidejacking is spoofing cookies over a LAN network,

 

Advertisements

Read Full Post »

What is SQL Injection?

sqlinjection

The most common type of hack attack seen these days, however, involves SQL injection. Attackers including hacktivists favor SQL injection attacks because they allow attackers to “inject” their own commands into databases.

When databases aren’t configured to properly screen inputs for signs of attack, attackers have an easy-to-use, remote technique for obtaining any information stored by the database. The specially crafted user data tricks the application into executing unintended commands or changing data.

SQL Injection allows an attacker to create, read, update, alter, or delete data stored in the back-end database. In its most common form, a SQL Injection attack gives access to sensitive information such as social security numbers, credit card number or other financial data.

What is a SQL Injection Attack?

A SQL Injection attack is a form of attack that comes from user input that has not been checked to see that it is valid. The objective is to fool the database system into running malicious code that will reveal sensitive information or otherwise compromise the server.

There are four main categories of SQL Injection attacks against databases

  1. SQL Manipulation: manipulation is process of modifying the SQL statements by using various operations such as UNION .Another way for implementing SQL Injection using SQL Manipulation method is by changing the where clause of the SQL statement to get different results.
  2. Code Injection: Code injection is process of inserting new SQL statements or database commands into the vulnerable SQL statement. One of the code injection attacks is to append a SQL Server EXECUTE command to the vulnerable SQL statement. This type of attack is only possible when multiple SQL statements per database request are supported.
  3. Function Call Injection: Function call injection is process of inserting various database function calls into a vulnerable SQL statement. These function calls could be making operating system calls or manipulate data in the database.
  4. Buffer Overflows: Buffer overflow is caused by using function call injection. For most of the commercial and open source databases, patches are available. This type of attack is possible when the server is un-patched

How to prevent SQL injection attacks?

An attacker uses SQL injection to manipulate a site’s Web-based interfaces and force the database to execute undesirable SQL code, enabling data manipulation and spreading malware. Organizations must not only build defenses and practice secure coding best practices, but also develop an in-depth understanding of how SQL injection attacks work and how the threat has evolved — the earlier SQL injection attacks didn’t have the vulnerability detection capabilities of contemporary attacks — as well as learn how to find, isolate and address webpages infected with malware on a website.

Defending Against SQL Injection Attacks

The good news is that there actually is a lot that web site owners can do to defend against SQL injection attacks. Although there is no such thing as a 100 percent guarantee in network security, formidable obstacles can be placed in the path of SQL injection attempts.

1. Comprehensive data sanitation.

Web sites must filter all user input. Ideally, user data should be filtered for context. For example, e-mail addresses should be filtered to allow only the characters allowed in an e-mail address, phone numbers should be filtered to allow only the characters allowed in a phone number, and so on.

2. Use a web application firewall.

A popular example is the free, open source module ModSecurity which is available for Apache, Microsoft IIS, and nginx web servers. ModSecurity provides a sophisticated and ever-evolving set of rules to filter potentially dangerous web requests. Its SQL injection defenses can catch most attempts to sneak SQL through web channels.

3. Limit database privileges by context.

Create multiple database user accounts with the minimum levels of privilege for their usage environment. For example, the code behind a login page should query the database using an account limited only to the relevant  credentials table. This way, a breach through this channel cannot be leveraged to compromise the entire database.

4. Avoid constructing SQL queries with user input. 

Even data sanitation routines can be flawed. Ideally, using SQL variable binding with prepared statements or stored procedures is much safer than constructing full queries.

Any one of these defenses significantly reduces the chances of a successful SQL injection attack. Implementing all four is a best practice that will provide an extremely high degree of protection. Despite its widespread use, your web site does not have to be SQL injection’s next victim.

Read Full Post »

Web Application Security

How do you handle your web application testing, vulnerability scans, test data and related security assessment reports? I’ve found that this is something that doesn’t get a lot of attention in web application security circles but is still impactful to the business. It’s actually kind of ironic that those of us working in IT and security often forget about what’s at stake if web vulnerability information were to fall into the wrong hands. I should know – I used to take it too lightly and many others still do.

The thing is, everything from passwords to SQL injection requests to hard-coded encryption keys – practically anything imaginable related to web security flaws – is contained in the following files, screenshots and reports:

  • Web vulnerability scan files (the raw data such as .wvs files in Acunetix Web Vulnerability Scanner)
  • Web vulnerability scanner reports (i.e. PDF and HTML files)
  • Screenshots of exploits
  • Proxy log files
  • Username and password dictionaries
  • Final web application testing reports containing specific findings and methods of exploitation

The risk is increased when all of this information is scattered about on multiple systems – especially once it makes its way to unencrypted laptops and data backups, third-party email systems and under-protected mobile devices (and trust me, it will). Even hard copies of web application testing reports can create business risks. I see those being tossed around to third parties quite often like it’s no big deal at all.

In the end, you’re not going to have complete control of the information resulted from your web application testing. You’ll have to trust people to do the right things. Unfortunately, that’s where businesses often get themselves into trouble. Thus the cycle of information security and managing risks continues.

Read Full Post »

PTMFOG0000001190

Advantages of using AcuSensor Technology

  • Ability to provide more information about the vulnerability, such as source code line number, stack trace, affected SQL query.
  • Allows you to locate and fix the vulnerability faster because of the ability to provide more information about the vulnerability, such as source code line number, stack trace, affected SQL query, etc.
  • Significantly reduces false positives when scanning a website because it understands the behavior of the web application better.
  • Can alert you of web application configuration problems which could result in a vulnerable application or expose sensitive information. E.g. If ‘custom errors’ are enabled in .NET, this could expose sensitive application details to a malicious user.
  • It can advise you how to better secure your web application and web server settings, e.g. if write access is enabled on the web server.
  • Detects many more SQL injection vulnerabilities. Previously SQL injection vulnerabilities could only be found if database errors were reported or via other common techniques.
  • Ability to detect SQL Injection vulnerabilities in all SQL statements, including in SQL INSERT statements. With a black box scanner such SQL injection vulnerabilities cannot be found.
  • Ability to know about all the files present and accessible through the web server. If an attacker will gain access to the website and create a backdoor file in the application directory, the file will be found and scanned when using the AcuSensor Technology and you will be alerted.
  • AcuSensor Technology is able to intercept all web application inputs and build a comprehensive list with all possible inputs in the website and test them.
  • No need to write URL rewrite rules when scanning web applications which use search engine friendly URL’s! Using the AcuSensor Technology the scanner is able to rewrite SEO URL’s on the fly.
  • Ability to test for arbitrary file creation and deletion vulnerabilities. E.g. Through a vulnerable script a malicious user can create a file in the web application directory and execute it to have privileged access, or delete sensitive web application files.
  • Ability to test for email injection. E.g. A malicious user may append additional information such as a list or recipients or additional information to the message body to a vulnerable web form, to spam a large number of recipients anonymously.
  • Ability to test for file upload forms vulnerabilities. E.g. A malicious user can bypass file upload form validation checks and upload a malicious file and execute it.
  • Unlike other vulnerabilities reported in typical scans, a vulnerability reported by the AcuSensor Technology contains much more detailed information. It can contain details such as source code line number, POST variable value, stack trace, affected SQL query etc. A vulnerability reported by the AcuSensor Technology, will be marked with ‘(AS)’ in the title.

Read Full Post »

Ensure-your-Website-Security

Is the exploitation of web vulnerabilities worth the trouble? Does it create unnecessary risks that should be avoided? Why exploit flaws anyway? This is not a black and white circumstance. Every situation is unique. But here’s what I know. The exploitation of web security flaws such as Cross-Site Scripting, SQL injection and Cross-Site request forgery is arguably the most valuable part of my assessments. Web exploitation can provide actual data, screenshots and other evidence which are great for getting management, developer and user buy-in on the issues. Otherwise, you may simply be running scans and making dangerous assumptions about what can or cannot be taken advantage of.

In many situations, all it takes is exploiting one missing web server patch, one SQL injection flaw or cracking a set of web passwords to show that problems exist in the respective areas. You may not need to exploit every flaw on every system to demonstrate what’s weak and what can happen. For certain projects, exploiting every single flaw on every single page could take too long and cost too much.

You have to ask yourself what’s really needed? What’s the ultimate goal of your security assessment? Is it to find some basic issues running basic scans or is it to completely vet a website or application and show exactly what can happen when things go awry? There is a ton of value in web exploitation…if it meshes with the overall project goals.

Vulnerability “exploitation” seems like a bad word that’s going to leak data, crash servers and cause business continuity problems but it really doesn’t have to. I’ve found that exploitation of web flaws is actually less risky than running the actual scans themselves. Interestingly, I’ve never had a problem running web exploits but automated scans have certainly created issues. Then again, unless the specific requirements call for it, I only run exploits that are not designed to create denial of service conditions. Your situation may be different.

In the end, if a web exploit (or even a scan) knocks over an application or its associated server(s), that may be a good indicator that you need to look even deeper. In the interest of minimizing problems, some people will just pretend the server or application doesn’t exist and leave it be. Sure, the problems are minimized but the security flaws are still there! Two wrongs don’t make a right.

For some people – especially IT auditors or compliance managers – exploitation of web flaws may be new territory. That’s fine. I just encourage people to really think things through when scoping web security assessments projects. Know all the facts and the possible outcomes and then dig in as deeply as possible. That’s the only way you’re going to find the flaws that matter and get people on your side to do something about them.

Read Full Post »

As many as 70% of web sites have vulnerabilities that could lead to the theft of sensitive corporate data such as credit card information and customer lists.
Hackers are concentrating their efforts on web-based applications – shopping carts, forms, login pages, dynamic content, etc. Accessible 24/7 from anywhere in the world, insecure web applications provide easy access to backend corporate databases.
Firewalls, SSL and locked-down servers are futile against web application hacking!
Web application attacks, launched on port 80/443, go straight through the firewall, past operating system and network level security, and right into the heart of your application and corporate data. Tailor-made web applications are often insufficiently tested, have undiscovered vulnerabilities and are therefore easy prey for hackers.

acunetix-overview
Acunetix – a worldwide leader in web application security
Acunetix has pioneered the web application security scanning technology: Its engineers have focused on web security as early as 1997 and developed an engineering lead in website analysis and vulnerability detection.
Acunetix Web Vulnerability Scanner includes many innovative features:

AcuSensor Technology

  • An automatic client script analyser allowing for security testing of Ajax and Web 2.0 applications
  • Industries’ most advanced and in-depth SQL injection and Cross site scripting testing
  • Advanced penetration testing tools, such as the HTTP Editor and the HTTP Fuzzer
  • Visual macro recorder makes testing web forms and password protected areas easy
  • Support for pages with CAPTHCA, single sign-on and Two Factor authentication mechanisms
  • Extensive reporting facilities including VISA PCI compliance reports
  • Multi-threaded and lightning fast scanner crawls hundreds of thousands of pages with ease
  • Intelligent crawler detects web server type and application language
  • Acunetix crawls and analyzes websites including flash content, SOAP and AJAX
  • Port scans a web server and runs security checks against network services running on the server

Read Full Post »