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/