HOST HEADER INJECTION

HOST HEADER INJECTION

Most of the common web servers are configured in the form of the same server to host many web applications with the same IP address this type of configuration is the reason for the Host Header issues. Here we are going to deal with the host header injection attack in various forms, its impact and mitigation.

CONTENTS:

1. HOST HEADER ISSUES
2. RISK
3. HOW ATTACKERS UTILIZE HOST HEADER ATTACK
4. WHY HOST HEADER HAPPEN
5. HOW TO FIND HOST HEADER ISSUES
6. PHASES OF HOST HEADER ISSUES
7. IMPACT OF HOST HEADER ISSUES
8. MITIGATIONS FOR HOST HEADER ATTACK
9. CONCLUSION

HOST HEADER ISSUES:

An attacker can manually divert the code to produce the hacker desired output simply by editing the host header. Most probably web servers are configured to pass the host header to the first virtual host in the list without proper reorganisation, So It is possible to send the HTTP requests with arbitrary host headers to the first virtual host. In that case, if we specify an invalid Host means the web server process it and pass the invalid host header to the first virtual host in the list.

An attacker can modify the host name by giving a fake web page or a vulnerable website and deliver it to the user and fraud the users.

Example:

The result will redirect the user to the attacker’s website by simply modifying the host header

RISK:

Most probably many websites use the values provided in the user input field and uses it afterwards without an improper input validation. Commonly this will not have that much impact on the application, but in some cases, if the application accepts the host header, the risk lays there. There may occur,

• URL redirection problems.
• Username and password credentials may be theft.
• Financial loss may happen in Finance sectors.

HOW ATTACKERS UTILIZE HOST HEADER ATTACK:

The exploitation is based on the logic of the web application. If the application does not use the user input value, then there is no risk. But the host header attack is considered as a serious issue at the time of resetting our password. When we are resetting our forgotten password, or we change our password for our privacy, the web application generates a link dynamically there it uses the host header provided in the request. In this scenario, the hacker uses this header for their evil cause. The hackers use some social engineering and phishing attacks for getting the link. So, the developer should realise the importance of the host header attack.

WHY HOST HEADER HAPPEN:

It is an injection type of attack that done on the HTTP headers.

• HTTP headers are dynamically generated based on the input of the user. User inputs can be edited or spoof by attackers. It is accessible by everyone.
• Any website that does not correctly validate or verify the HTTP Host headers.

HOW TO FIND HOST HEADER ISSUES:

Verify the header of the request. Inject other domain in the header field and check the response in the browser.

PHASES OF HOST HEADER ISSUES:

1. WEB CACHE POISONING WITH SINGLE HOST HEADER:

Web cache poisoning is a kind of technique used by a hacker to manipulate a web cache that serves a poisoned content for those who requests that webpage. For this attack, the hacker needs to poison a caching proxy run by the website itself, or content delivery networks (CND’s), or other caching mechanisms are carried out between the client and the server. In this scenario where caching is enabled, A hacker will potentially embed a remote URL as the base-URL for any website. This scenario then causes other users who request the site will be redirected unknowingly. Thus if an application fails to prevent the user from using the X-Forwarded-Host header, it will effectively override the Host header. The cache will serve the poisoned content to everyone those who request the webpage without the knowledge of the victim.

EXAMPLE:

 

2. X-FORWARDED HOST HEADER:

Host header injection is mitigated by preventing the tampering of Host header. It means if any request is made with tampered host header, the application responds with an error message like “404 Not Found”. Another way to pass arbitrary Host headers is to use the X-Forwarded-Host header. In some configurations, this header will rewrite the value of the Host header. Therefore it’s possible to make the following request.

EXAMPLE:

3. WEB POISONING WITH MULTIPLE HOST HEADERS:

It is one of the forms of web cache poisoning attack. It is similar to that of the web cache poisoning using the single header. The only difference is that in this type is that it use multiple headers more than one to the users those who request the website. By tampering with the header, it is possible. The web cache will deliver the wrong content to the user with their knowledge.

EXAMPLE:

GET / HTTP/1.1

Host: www.example.com

Host: www.evil.com

4. PASSWORD RESET POISONING:

 The significant impact of Host header attack lies in the password resetting functionality. The most common scenario of this attack the hacker generates a secret token and sends a mail that has a link that contains the mysterious symbol of the hacker. The hacker urges the user to make use of his link, and to requests, a password reset link which redirects the user to him. In this case, if the web application makes use of this host header value when composing with the reset link and when the user clicks the poisoned reset link in the mail, then the user will become a victim to the hacker. The attacker will obtain the password reset token and make use of his password for his destructive purposes.

EXAMPLE:

 

IMPACT OF HOST HEADER ISSUES:

1. A hacker can modify the legitimate host header with a wrong host in the request, and it poisons the cache of the web application server and the proxy. It has nothing to do with the browser. When the authorised user tries to access the host, but still the cache of the web server is poisoned with the hacker’s domain that redirects the licensed user to the domain of the hacker.
2. If the host headers are used for writing links without a proper HTML encoding, there may be a possibility for Cross-site
3. Access to the internal
4. HTML INJECTION also can be done.

MITIGATIONS FOR HOST HEADER ATTACK:

• Proper sanitation of input values.
• Proper verification of the request that it came from the original target host or not.
• Mitigate the Host header attack in Apache and Nginx by creating a dummy virtual host that catches all requests from unrecognised Host headers.
• Whitelist the trusted domains at the initial phase of the web application.
• Respective Mapping of the domains that received in the host header of each HTTP request with itself.
• Use secure server configuration.
• Disable the support for the X-Forwarded-Host header option.

CONCLUSION:

Many application developers did not realise that the HTTP host header is accessible and controlled by all user. In an application security perspective, the input given by the user is always deceivable, and it is unsafe to trust. So, a web developer should consider host header issues as a dangerous thing not to and neglect it; we should find the impacts caused by the host header and follow the mitigation to safeguard ourselves.

We Briskinfosec is Center for Cyber Security Excellence passionate to protect you from all application security threats on your budget. Talk to our experts contact@briskinfosec.com

AUTHOR

Alex Daniel Raj

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

follow me @https://www.linkedin.com/in/alex-daniel-raj-xavier-b77869145/

RED HAWK VERSION 2.0.0

RED HAWK VERSION 2.0.0

ABOUT  THE  TOOL :

RED HAWK is one of the best information gathering and vulnerability assessment tool. It is written in  PHP language. It allows the pen tester to perform numerous scans by merely selecting the type of scan he wants. It reduces the time consumption of every security professional during penetration testing by providing overall scans and displays the output for the specific scans in a convenient manner.

FEATURES :

• It does some Basic Scan like
  1. Title of the Target site.
  2. IP Address of the Target site.
  3. To Discover the Web Server of the Target site.
  4. TO Discover the CMS.
  5. To Discover the Cloudflare.
  6. It includes robots.txt Scanner
• IT performs the WHOIS LOOKUP of the Target site.
• Look for the GEO-IP of the Target site.
• It is also providing Banner Grabbing facility.
• It also performs the DNS Lookup.
• It provides Nmap Port Scan.
• Sub-Domain Scanner
  1. SUBDOMAINS of the target site.
  2. IP ADDRESS of the target site.
• GET REVERSE IP-ADDRESS LOOKUP & DISCOVERING CMS
  1. Hostname of the target site.
  2. IP Address of the target site.
  3. CMS Tracing.
• Error Based SQL Scanning of the Target
• Bloggers View NEW
  1. HTTP Response Code
  2. Site Title
  3. Domain Authority of the target site
  4.  Links Extractor of the target site
  5. Link Grabber of the target site.
• WordPress Scan NEW
  1. Sensitive Files Crawling
  2. Version Detection
  3. Version Vulnerability Scanner
• Crawler
• MX Lookup NEW

 INSTALLATION :

STEP 1: We have to clone the RED HAWK tool from GITHUB.

root# git clone https://github.com/Tuhinshubhra/RED_HAWK

Fig-1

STEP 2: We have to Parse into the RED HAWK tool folder and list it view the installation file.

root# cd  RED_HAWK

root#~/RED_HAWK# ls

Fig-2

STEP 3: PHP is an inbuilt function in the OS so install it.

Root # PHP  rhawk.php

Fig-3

STEP 4: RED_HAWK is installed. Then specify the Target site to scan.

Fig-4

STEP 5: Then specify the Connection that the Target site is Running on.

Fig-5

STEP 6: Then specify the Type of Scan to be performed on the Target Site.

Fig-6

STEP 7: For Basic Recon Scan select 0 from the list of actions.

Action Panel Fig-7

STEP 8: For GEO-IP LOOK UP select option 2 from the list of actions in above image (Fig-7).

Fig-8

STEP 9: For WHOISLOOK UP select option 1 from the list of actions in the action panel image (Fig-7).

Fig-9

STEP 10: For MX LOOKUP select option 13 from the list of actions in action panel image (Fig-7).

Fig-10

STEP 11: For Banner Grabbing select option 3 from the list of actions in action panel (Fig-7).

Fig-11

RED_HAWK is one of the best information gathering tools it fetches the information efficiently and delivers it to the Security Professional.  A lot of further up gradation and modification are made in this tool and make it more enhanced way.

AUTHOR

Alex Daniel Raj

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

follow me @https://www.linkedin.com/in/alex-daniel-raj-xavier-b77869145/

ANDROID MANIFEST FILE ANALYSIS

ANDROID MANIFEST FILE ANALYSIS

ANDROID MANIFEST File can be obtained by extracting any.APK Files and this file contains the several information’s about the device needs to run the app, and it also includes the information about the component of the applications such as services, content providers, activities and broadcast receivers etc.

It also contains the protected information for an application like

1.1     PERMISSION LEVEL ACCESS

It includes the list of information’s that imply the hardware features it’s available in user feature, user permissions

For example, the code in user features available in the manifest file

1. < uses - permissionandroid: name = "string"

2. android: maxSdkVersion = "integer"/ >

1.2     USER PERMISSION:

Specifies system permission that the user must grant to run the app correctly. The user grants permissions when the application is installed (on devices running Android 5.1 and lower) or while the app is running (on devices running Android 6.0 and higher)

For more information’s about the user permissions, you can check on to the “android. Manifest. Permission” to process over the list of permissions that you wish to be enabled

It can be permission defined by the application with the  <permission> element;
one can set one of the standard features (such as "android.permission.CAMERA" 
or "android.permission.READ_CONTACTS") etc.

1.3     ANDROID API INFORMATION:

The API Level expressed by an application will be compared with the given Android version API level is a single integer, and it can vary based on different Android OS version. Here it’s been assigned to based on the minimum, targeted and maximum SDK version and they are based on the developer choice on based on their app requirements.

<uses-sdk android:minSdkVersion="integer"
           android:targetSdkVersion="integer"
           android:maxSdkVersion="integer" />

1.4     APP PERMISSIONS:

APP Permission is used to protect the privacy of the Android user and android apps must request permission to access sensitive user data are like SMS and CONTACTS and also other certain features like (CAMERA, INTERNET and WIFI) etc.

Permission request for any kinds of APP is assigned in the manifest file which is an APK file, and you can see in your day-to-day activities like code for the user permission to send SMS in the manifest file as shown below:

1. < manifest xmlns: android = "http://schemas.android.com/apk/res/android."

2. package= "com.example.snappyyapp" >

       < uses - permission android: name = "android.permission.SEND_SMS" / >

       < application... >      ...
   
       < /application> </manifest >

If an app has a typical kind of information, then the lower level of permissions can be used, but if your app contains any sensitive level of information’s then you have to assign the above code for the security purpose

APP PERMISSIONS:

In the above figure tells about the various permissions that have generally been allocated to an app and here I have checked the different authorities that have used for the cliq app.In this list of options you can enable the required option which you need to set the app permission by default and once you select any one of this option than later it will not ask for any user permission

If you did not enable any permissions over here, then it will ask for the app permissions every time like the diagram as follows.

DEFAULT APP PERMISSIONS:

This is the various levels of permissions that are available in manifest file and also on your smartphones.

1.5     ANDROID VULNERABILITY ANALYSIS:

Vulnerability analysis in android can be done by analysing the manifest file, and once you deobfuscated the code, you can manually examine the code to check the vulnerabilities. Many vulnerabilities can occur on the manifest file, and here I have explained some vulnerable code for your reference and what are the various options that can lead to the vulnerabilities

1.5.1      BACKUP MODE ENABLED:

The name usually describes the automatic enabling of the backup data. The backup mode allows backup option as the attacker can take the backup of your data as well as he can also steel some sensitive information’s present in your applications making it a vulnerable. According to the security purpose and by default the google drive is the default destination of the app backup’s and the backup option code available in the manifest file as follows

1. < application…android: allow Backup = ”true” > < /app>

 Prevention: Backup mode should be set false to prevent this kind of attacks

1.5.2      DEBUG MODE:

The debug mode defines that whether the applications are debuggable or not. Also, when the debug is enabled the attacker can gather plenty of information. In  Staging environment when the app is not in production state, it can be set as true, and once it moves to the final stage for execution it should be set as false, it’s a one of the critical vulnerability which leads anyone to capture sensitive information’s of an applications

Debug code available on manifest file

1. < application android: debuggable = "false"< /application>

1.5.3      APP COMPONENT VULNERABILITY:

The app component vulnerabilities mainly describe the components present in the manifest file like activity, services, Content provider or Broadcast receiver and they can be either private or public the exported attribute in each component declaration in the manifest file defines that the component is private or public

If the component is public it can be exported to the other apps, if the component is private then it cannot be exported, by exporting option the attacker can export any information’s from the application and this kind of export options depends upon the applications and the severity level of this vulnerability may vary upon the application

1. android: exported = "true">

2. < intent-filter> < /intent-filter> < /service>... < /manifest>

3. < manifest xmlns: android = "http://schemas.android.com/apk/res/android"

4. package= "com.example.testapps.test1" > ... < service android: name = ".MailListenerService

5. android: enabled = ""

Prevention:

• If an application has an exported option, then it should have a permission function for each file that is to be exported

1.6     CONCLUSION:

It is one of the ways to analyse the Android manifest file and by this blog the information about the permission access, backup and debug mode analysis can be done.

Reference Links:

• https://developer.android.com/guide/topics/manifest/uses-feature-element
• https://www.oreilly.com/library/view/application-security-for/9781449322250/ch04.html
• https://blog.devknox.io/what-is-android-allowbackup-how-it-affects-your-app/

AUTHOR

Ram Kumar

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

follow me @https://www.linkedin.com/in/ram-kumar-3439b511a/

NIST CYBERSECURITY FRAMEWORK 1.1

NIST CYBERSECURITY FRAMEWORK 1.1

INTRODUCTION

The Framework 1.1  offers an agile way to address cybersecurity, including cybersecurity’s effect on physical, cyber, and people dimensions. It applies to organisations relying on technology, whether their cybersecurity focus is primarily on Information Technology (IT), Industrial Control Systems (ICS), Cyber-Physical Systems (CPS), or connected devices more generally, including the Internet of Things (IoT). The Framework 1.1 can enhance the organisations in addressing cybersecurity as affects the privacy of other data. Additionally, the Framework’s 1.1 outcomes serve as targets for workforce development and evolution activities.

The Framework 1.1 is not a one-size-fits-all method to manage cybersecurity risk for critical infrastructure. Organizations will continue to have static risks with different threats and vulnerabilities, and also with risk tolerances. They also will vary in how they customise practices described in the Framework 1.1. Organizations can determine activities that are important to critical service delivery and can prioritise investments to maximise the impact of each dollar spent. The Framework 1.1 is aiming to reduce the risk and better managing cybersecurity threats.

The Framework 1.1 is a living document and will continue to be updated and improved as the industry responds to implementation. NIST will continue coordinating with the private sector and government agencies at all levels. As the Framework 1.1 is placed into higher practice, additional lessons learned will be integrated into future versions. It will ensure the Framework 1.1 which meets the needs of infrastructure owners and operators in a critical environment of new threats and also the solutions.

USAGE OF FRAMEWORK 1.1

An organisation can use the Framework 1.1 as a critical part of its systematic process for identifying, assessing, and managing cybersecurity risk. The Framework is not used to replace existing methods, but companies can use its current method, and that can overlap it onto the Framework 1.1 to determine loopholes in its current cybersecurity risk approach. The Framework 1.1 can be used as a cybersecurity risk management tool; an organisation can identify activities that are most central to critical service delivery and prioritise expenditures to maximise the impact of the investment.

It is designed to complement cybersecurity operations. It can serve as the foundation for a new cybersecurity program or a mechanism for improving an existing application. The Framework  1.1 provides a means of articulating cybersecurity requirements to business partners and customers and can help identify gaps in an organisation’s cybersecurity practices.

The Framework 1.1 can be applied throughout the lifecycle phases of the plan, design, build/buy, deploy, operate, and decommission. The planning phase begins the cycle of any system and lays the groundwork for everything that follows. Overarching cybersecurity considerations should be declared and described as clearly as possible. The plan should be recognized that those requirements are to evolve during the remainder of the life cycle.

CYBERSECURITY USAGE FRAMEWORK 1.1

CONCLUSION

The Cybersecurity Framework 1.1 is intended to reduce risk by improving the management of cyber security risk to organisational objectives. Ideally, organisations using the Framework 1.1 will be able to measure and assign values to their risk along with the cost and benefits of steps taken to decrease risk to proper levels. The better an organisation can estimate its risk, costs, and advantages of cybersecurity strategies and actions, the more rational, useful, and valuable its cybersecurity approach and investments will be.

Over time, self-assessment and measurement should improve decision making about investment priorities. For example, measuring – or at least robustly characterising – aspects of an organisation’s cybersecurity state and trends over time can enable that organisation to understand and convey meaningful risk information to dependents, suppliers, buyers, and other parties. An organisation can accomplish this internally or by seeking a third-party assessment. If done correctly and with an appreciation of limitations, these measurements can provide a basis for healthy trusted relationships, both inside and outside of an organisation.

REFERENCE:

https://www.nist.gov/cyberframework

https://www.us-cert.gov/ccubedvp/cybersecurity-framework

AUTHOR

Dharmesh B

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

https://www.linkedin.com/in/dharmeshbaskaran/

INTRODUCTION & CHANGES IN PCI-DSS v3.2

INTRODUCTION & CHANGES IN PCI-DSS V3.2

The Payment Card Industry Data Security Standard (PCI- DSS) was developed to follow the policy and standards of cardholder data security which consistent data security measures globally. PCI- DSS provides a minimum of technical and operational requirements to protect data of the cardholders. PCI -DSS applies to all operation which involved in payment card processing of cardholder data.

The below describes the changes in PCI-DSS v3.2 from version 3.1.

AREAS EMPHASISED IN V3.2:

• CHANGE MANAGEMENT PROCESS:

  • The Change Management Process is done to perform the secure changes during the process based on the business requirement.

• ADMINISTRATIVE ACCESSING:

  • The Administrative privilege is given only to the single user were the particular can gain the read, write and execute access to the changes in the environment.

• INCIDENT RESPONSE:

  • Incident response is nothing but when there is an issue raised in the environment the action is taken based on the severity of the problems.

• E-COMMERCE – A-EP ENVIRONMENTS:

  • the “Expected Testing” column is based on the testing procedures in the PCI DSS and provides a high-level description of the types of testing activities should be performed to verify that a requirement has met.

SAQ VERSION	# QUESTIONS V3.1	# QUESTIONS V3.2	DIFFERENCE
SAQ D-SP	347	369	+22
SAQ D-MER	326	331	+5
SAQ C	139	162	+23
SAQ A-EP	139	193	+54
SAQ B-IP	83	84	+1
SAQ C-VT	73	80	+7
SAQ B	41	41	0
SAQ P2PE-HW	35	33	-2
SAQ A	14	22	+8

MASKING THE PAN NUMBER

• DISPLAYING THE PRIMARY ACCOUNT NUMBER

  • First six and last four digits of PAN can be displayed based on the current requirement.

For a legitimate business need the pan number must be encrypted. Follow Requirement 3.3 for further reference.

CHANGE CONTROL

• CHANGES IN CHANGE CONTROL IN V3.2

  • Maintain proper documentation when any change control issued.
  • Implement all the necessary control in all the new and existing systems or devices.
  • Change control processes must include verification of PCI DSS requirements impacted by a (significant) change. Fallow Requirement 6.4.6 which is effective from Feb 1, 2018.

HIGH-RISK VULNERABILITY MANAGEMENT

• INTEGRATE VULNERABILITIES INTO THE RISK ASSESSMENT PROCESS

  • Ensure all “high risk” vulnerabilities must be addressed for internal scans and resolved.
  • By the vulnerability ranking as per Requirement 6.1 and 6.2 in PCI-DSS scope.
  • After resolving the vulnerabilities ensure the risk has been cleared by rescanning.

REMOTE ADMINISTRATOR ACCESS TO CDE

• ANY NON-CONSOLE ADMINISTRATOR ACCESS TO CDE

  • All the non-console access into CDE for personnel with administrative access must implement the multi-factor authentication.
  • The current requirement for multi-factor authentication for remote access to CDE for personnel with administrative access still applies according to the PCI-DSS scope.
  • Fallow PCI-DSS scope 8.3.1 and 8.3.2 mandatorily from Jan 31, 2018.

RESOURCE

• Refer the following document for the PCI-DSS scope.
• LINK: pcisecuritystandards.org/document_library?category=pcidss

AUTHOR

Dharmesh B

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

https://www.linkedin.com/in/dharmeshbaskaran/

SSRF (SERVER SIDE REQUEST FORGERY)

SSRF (SERVER SIDE REQUEST FORGERY)

INTRODUCTION

Server-Side Request Forgery (SSRF) refers to an attack wherein an attacker can send a crafted request from a vulnerable web application. SSRF is mainly used to target internal systems behind WAF (web application firewall) that are unreachable to an attacker from the external network. Additionally, it’s also possible for an attacker to mark SSRF to access services from the same server that is listening on the loopback interface address called (127.0.0.1).

Typically, Server Side Request Forgery (SSRF) occurs when a web application is making a request, where an attacker has full or partial control of the claim that is sent. A typical example is when an attacker can control all or part of the URL to which the web application makes a request to some third-party services, and here I have captured the parameter of file= URL, and I tried to perform this server-side forgery attack

tried to perform this server-side forgery attack

In the above figure, the perpetrator forges a request for a fund transfer website, and he embeds it into the visitor site. when the visitor logs the website for the transaction and clicks the perpetrator created a link, it redirects to Perpetrator site, and the amount is transferred to his account

SSRF IMPACTS:

By this attack, an attacker can gather information about ports, IP addresses, Remote code execution and it also discovers the IP addresses of servers running behind a reverse proxy etc.

For Example, I have tried SSRF attack on a testing site for your reference

Vulnerable site: http://testphp.vulnweb.com/

POC 1:

In Burp Suite I have checked for some different redirection parameter other than URL=, and in the search field I have tried with various parameters and using this parameter of file= and here I have captured the request of the particular path and sent it to the repeater

POC 2:

Request Captured from the search file in the repeater and here in file feed a .jpg file is available, now I removed the file and entered a third party URL on file Redirected URL: https://www.expressvpn

POC 3:

Once I click on Go to capture response the response is changed to expessvpn.com, and you can see the IP of the testphp.vulnweb.com, but in render page, you can see the expressvpn.com site gets loaded as follows.

POC 4:

PREVENTION FROM SSRF:

• Generic error messages should be displayed to every client as unhandled responses might end up revealing sensitive information or data leakage about the server when any other raw response or different parameter is used.
• URL schemas other than HTTP and HTTPS should be blacklisted. Instead, these two mentioned protocols should be whitelisted thereby not allowing different schemas which are not in use like file:///, direct://, feed://, touch://  and FTP:// which might prove to be dangerous for SSRF.

CONCLUSION:

Hence, the Server Side Request Forgery attack has been made from the server side and the required web page has been redirected to some other web pages and to prevent from such types of attacks allow only the particular subdomains of the required web page and whitelist the other web pages which they are not in use.

REFERENCE LINKS:

• https://dzone.com/articles/the-server-side-request-forgery-vulnerability-and
• https://medium.com/poka-techblog/server-side-request-forgery-ssrf-attacks-part-1-the-basics-a42ba5cc244a

AUTHOR

Ram Kumar

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

follow me @https://www.linkedin.com/in/ram-kumar-3439b511a/