Security Misconfiguration

Sunday, 12 August 2018

Security Mis-configuration
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date

Server configuration problems
> Unpatched security flaws in the server software
> Server software flaws or misconfiguration that permit directory listing and directory traversal attacks
> Unnecessary default, backup, or sample files, including scripts, applications, configuration files, and web pages
> Improper file and directory permissions
> Unnecessary services enabled, including content management and remote administration
> Default accounts with their default passwords
> Administrative or debugging functions that are enabled or accessible
> Overly informative error messages (more details in the error handling section)
> Misconfigured SSL certificates and encryption settings
> Use of self-signed certificates to achieve authentication and man-in-the-middle protection
> Use of default certificates
> Improper authentication with external systems

All about => Insecure-direct-object-references
Critical Vulnerability => Sql-injection-attack-and-defense-notes

** Do security hardening
1) Configuring all security mechanisms
2) Turning off all unused services
3) Setting up roles, permissions, and accounts, including disabling all default accounts or changing their passwords
4) Logging and alerts
5) Monitoring the latest security vulnerabilities published
6) Applying the latest security patches
8) Updating the security configuration guideline
9) Regular vulnerability scanning from both internal and external perspectives
10) Regular internal reviews of the server’s security configuration as compared to your configuration guide
11) Regular status reports to upper management documenting overall security posture

Security Misconfiguration Cases
Case 1 :
Your application relies on a powerful framework like Struts or Spring. XSS flaws are found in these framework components you rely on. An update is released to fix these flaws but you don’t update your libraries. Until you do, attackers can easily find and exploit these flaws in your app.

Case 2 :
The app server admin console is automatically installed and not removed. Default accounts aren’t changed. Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over

Case 3 :
Directory listing is not disabled on your server. Attacker discovers she can simply list directories to find any file. Attacker finds and downloads all your compiled Java classes, which attackers reverse engineers to get all your custom code. Attacker then finds a serious access control flaw in your application.

Case 4 :
App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers love the extra information error messages provide.

All about => Insecure-direct-object-references
Critical Vulnerability => Sql-injection-attack-and-defense-notes

Exploit  1:
We can try out as many options as we can think of. All we need to find the URL of config file and we all know developers follow kind of naming convention for config files. It can be anything that is listed below. It is usually done by BRUTE force technique.


Exploit 2: 
Error Handling

There are quite a few different ways to handle errors in ASP.NET MVC and Web API, whether through error handlers, filters and overrides, as well as granular application of error handling at the action or controller level. But, very likely you have experienced those edge cases where some exception has managed to bubble up past your custom control gates unhandled and you have experienced a error message

Exploit 3:
URL redirection

Insecure Direct Object References

Insecure Direct Object References
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.

Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object.

For Example

All About Cross Site Scripting => Click on me :)
Learn about => Security-misconfiguration
Know about Critical Vulnerability => SQL Injection Click on me :)

1) Avoid exposing your private object references to users whenever possible, such as primary keys or filenames
2) Validate any private object references extensively with an "accept known good" approach
3) Verify authorization to all referenced objects

Insecure Direct Object References cases
Case 1: 
The value of a parameter is used directly to retrieve a database record

String query = "SELECT * FROM table WHERE cartID=" + cartID;

Case 2: 
Sometimes leads to Directory traversal or Path traversal
Many file operations are intended to take place within a restricted directory. By using special elements such as ".." and "/" separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the "../" sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as "/usr/local/bin", which may also be useful in accessing unexpected files. This is referred to as absolute path traversal.
In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated file name to widen the scope of attack. For example, the software may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.

../../../etc/passwd in part of linux

Directory Traversal

Assume a web application allows for a file to be rendered to a user that is stored on the local machine. If the application isn't verifying what files should be accessed, an attacker can request other files on the file system and those will also be displayed.

For instance, if the attacker notices the URL:
The attacker could modify the file parameter using a directory traversal attack. He modifies the URL to:**../../../etc/shadow**
Upon doing this the /etc/shadow file is returned and rendered by file.jsp demonstrating the page is susceptible to a directory traversal attack.

All About Cross Site Scripting => Click on me :)
Learn about => Security-misconfiguration

IMP =>
Exploiting Insecure Direct Object References, attackers can bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object ( i.e. by modifying the user account)

Exploit 1 :
Is there is URL is redirecting on parameter ID in a URL string to access the information of other users)
attacker can change the ID by predicting and and may redirect to another person account

Exploit 2 :
IF something is coming in directory
attacker can change the path and lead to LFI or path traversal or directory traversal
for example