Lazy Hacker

Analysis: During the analysis, it was observed that the application was generating an inadequate cookie path attribute for the authentication cookie which was used for maintaining the user's session. Please refer to the below-provided evidence and proof of concept. Impact: Cookie Path attributes specify the validity of the cookie to a specific URL. The cookies can be easily stolen from the insecure/incorrect URL path if the path attribute is not set properly. The path attribute is used with the domain attribute to provide more security. If the path attribute is set to "/myapp", the cookie will only be sent to the specified domain on the web server. An attacker may steal the cookies from a malicious URL if the cookie path is insecurely/inadequately specified. This may lead to various attacks such as session hijacking, session replay, etc. Recommendation: ·  Set the cookie path attribute specific to “/myapp/”. ·  Apply proper validation to the cookie path attribute.

Analysis: During the analysis, it was observed that the application was vulnerable to Host Header Injection as when the host header was changed to something outside the target domain (ie. Demo.testfire.net), it was accepted and was  used to generate links, import scripts, etc. Impact: Attack vectors are somewhat limited, but depend on how the host header is used by the back-end application code. If code references the hostname used in the URL such as password reset pages, an attacker could spoof the host header of the request in order to trick the application to forwarding the password reset email to the attacker’s domain instead, etc. Other attack vectors may also be possible through manipulation of hyperlinks or other misc. code that relies on the host/domain of the request. Recommendation: To fix this, the application should reject anything that doesn't match the target domain. Then Request.ServerVariables("Server_Name") should only ever contain valid values As an addi

Analysis: During the analysis, it was observed that the application allowed users to upload malicious files to the server. Please refer to the below-provided evidence and proof of concept. Impact: An attacker can upload a malicious file that can lead to Remote Code Execution and thereby can take over the entire web application. The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, client-side attacks, or simple defacement.   Recommendation: ·  It is recommended to restrict file types accepted for upload. ·  Validate the file extension and Content-Type of the file on the server side. ·  Only allow certain files to be uploaded. ·  Use a whitelist approach instead of a blacklist. ·  Change the permissions on the upload folder so the files within it are not executable. If possible, rename the files that are uploaded.

Analysis: During the analysis, it was observed that there was functionality to export the data in a CSV file and this functionality was affected by the CSV injection vulnerability, also known as Formulae Injection. We could execute a malicious command. Impact: Successful exploitation will allow an attacker to execute arbitrary code with the privilege of a currently logged-in user of the system, causing serious damage to the victim’s system like an entire partition can be wiped out or create backdoors as well for later access. Also, an attacker can steal sensitive information from CSV files. Recommendation: We recommend that it is always a good practice not to trust user inputs. Also, for the successful execution of the formula, the attacker will have to use the ‘-‘ , ‘=’ , '@', and the pipe (|) is used to execute the binary in the excel software. Hence, it is strongly recommended to whitelist the input and not allow ‘- ‘, ‘|’ , ‘+’, '@', and  ‘=’  to mitigate this vulne

Analysis: During the analysis, it was observed that multiple logins for the same user from different systems/browsers were allowed. Please refer to the below-provided evidence: Impact: An attacker who has compromised the credentials of a user may login from another computer using these credentials. If simultaneous logins are disallowed, such an action would alert the genuine user of the application to misuse his/her credentials. Recommendation: It is recommended that when a user logged into an application, the user should not be permitted to open a different type of browser (or use another computer) to log in again until his first session has ended.

Analysis: During the analysis, It was observed that the application didn’t validate the user-provided inputs. Please refer to the below-provided evidence:   Impact: When an application does not validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application. This will lead to parts of the system receiving unintended input, which may result in stored XSS, altered control flow, arbitrary control of a resource, or arbitrary code execution. Recommendation: It is recommended to implement use input sanitization and validate the same on both,  the client side and the server side.

Analysis: During Analysis, it was observed that the password policy for user accounts was not implemented properly. Due to this users can create a one-character password. Also, it was observed that users can use an old password for “ Change Password Functionality ”. Please refer to the below-provided proof of concept and evidence: Impact: Weak passwords can be guessed by malicious users or can be brute forced using a username and password combination. Recommendation: The following solutions are recommended to implement a strong password policy: • Password length must be minimum 8 characters. • Password must contain characters from the following four categories:    (i)   At least one upper case letter: (A – Z)    (ii)  At least one lower case letter: (a - z)    (iii) At least one number: (0 - 9)    (iv)  At least one Special Characters: !# $ % & ' ( ) * + , - . / : ; < = > ? @ • Password history should be maintained in order not to allow the usage of the same password agai

Analysis: During the analysis, it was observed that the application didn’t implement cache control directives properly in its response headers because of which the browser was storing sensitive internal pages in its cache. Please refer to the below-provided evidence  and proof of concept: Impact: This vulnerability can be exploited by an attacker having access to the victim's computer by browsing the cached pages. After getting access to sensitive information, the attacker can misuse the information. Recommendation: It is recommended to implement all Cache-Control directives properly. The following solutions are recommended to fix the vulnerability: I. Multiple mechanisms, including HTTP headers and Meta tags, should be used to ensure that the pages containing sensitive information are not cached by user's browsers. II. Authenticated pages should be marked with all the variants of the no-cache tag to prevent someone from using the browser's back button to access the history

Analysis: During the analysis, it was observed that the X-Frame-Options header was not implemented on the application. Due to this an attacker could load the application in an iframe and lure a victim to enter sensitive information. Please refer to the below-provided evidence: Impact: An attacker could perform malicious activities on behalf of a user (victim) without his/her knowledge simply by luring the victim to click on a malicious or attacker controller page containing invisible iframe of the vulnerable applications. This vulnerability can be chained with other vulnerabilities besides stealing sensitive information. Recommendation: I t is recommended to add a DENY and SAMEORIGIN HTTP header in the “X-Frame-Options” in the HTTP response of the application, which will prevent the site from loading inside an Iframe in modern browsers.

Analysis: During the analysis, it was observed that no anti-automation mechanism was implemented on the “Registration” functionality due to which numbers of request for user registration could be submitted by using automation tools or scripts. Please refer to the below provided proof of concept and evidences. Impact: An attacker could use automated tools for submitting the Registration form with the random data. A malicious user could potentially execute thousands of requests in seconds and consume the resources like the application server and the database. Recommendation: It is recommended to implement a captcha to prevent automated scripts from flooding the application and the captcha should be unique each time. The captcha should be validated on the server side. References: https://www.wpbeginner.com/plugins/how-to-add-captcha-in-wordpress-login-and-registration-form/ https://www.pixelemu.com/documentation/wordpress-tutorials/captcha-on-wordpress-website

Analysis: During the analysis, it was observed that servers were vulnerable to SWEET32 vulnerability, due to use of weak 64-bit ciphers. Please refer to the below-mentioned evidence. Impact: Ciphers that use 3DES are prone to attacks, where an attacker who can cause enough cryptographic collisions can recover a stored session cookie or other sensitive information using malicious JavaScript. Recommendation: It is recommended to stop the use of all 64-bit block ciphers. Alternatively, place limitations on the number of requests that can be processed over the same TLS connection to mitigate this vulnerability.

Analysis: During the analysis, we discovered that the servers supported weak RC4 ciphers. Please refer to the below-provided evidence: Impact: The RC4 cipher is flawed in its generation of a pseudo-random stream of bytes so that a wide variety of small biases are introduced into the stream, decreasing its randomness.  If plaintext is repeatedly encrypted (e.g., HTTP cookies), and an attacker can obtain many (i.e., tens of millions) cipher texts, the attacker may be able to derive the plaintext. Recommendation: It is recommended to reconfigure the affected application, if possible, to avoid the use of RC4 ciphers. Consider using TLS 1.2 with AES-GCM suites subject to browser and web server support. Disable SSL RC4 in Windows 1.Open “regedit” from the command line 2.Browse to the following key: 3. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128] "Enabled"=dword:00000000 4.[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Se

Analysis: During the analysis, it was observed that the remote host supports RSA_EXPORT cipher suites with keys less than or equal to 512 bits. Please refer to the below-provided evidence: Impact: An attacker can factor a 512-bit RSA modulus in a short amount of time. A man-in-the-middle attacker may be able to downgrade the session to use EXPORT_RSA cipher suites (e.g. CVE-2015-0204). Thus, it is recommended to remove support for weak cipher suites. Recommendation: It is recommended to reconfigure the service to remove support for EXPORT_RSA cipher suites.

Analysis: During the analysis, it was observed that the remote host is affected by a man-in-the-middle (MitM) information disclosure vulnerability known as POODLE. The vulnerability is due to the way SSL 3.0 handles padding bytes when decrypting messages encrypted using block ciphers in cipher block chaining (CBC) mode. Please refer to the below-provided evidence: Impact: The POODLE attack can be used against any system or application that supports SSL 3.0 with CBC mode ciphers. This affects most current browsers and websites, but also includes any software that either reference a vulnerable SSL/TLS library (e.g. OpenSSL) or implements the SSL/TLS protocol suite itself. By exploiting this vulnerability in a likely web-based scenario, an attacker can gain access to sensitive data passed within the encrypted web session, such as passwords, cookies and other authentication tokens that can then be used to gain more complete access to a website (impersonating that user, accessing database c

Analysis: During the analysis, it was observed that the above-mentioned remote service accepts connections encrypted using SSL 2.0 and/or SSL 3.0. Please refer to the below-provided evidence: Impact: It is recommended to disable SSL 2.0 and 3.0. and implement TLS 1.2 or higher with strongly approved cipher suites. Recommendation: These versions of SSL are affected by several cryptographic flaws. An attacker can exploit these flaws to conduct man-in-the-middle attacks or to decrypt communications between the affected service and clients. NIST has determined that SSL 3.0 is no longer acceptable for secure communications. As of the date of enforcement found in PCI DSS v3.1, any version of SSL will not meet the PCI SSC'S definition of 'strong cryptography.

Analysis: During the analysis, it was observed that the certificates sent by the remote host have a key that is shorter than 2048 bits. According to industry standards set by the Certification Authority/Browser (CA/B) Forum, certificates issued after January 1, 2014 must be at least 2048 bits. Please refer to the below-provided evidence: Impact: As computer power increases, anything less than 2048-bit certificates are at risk of being compromised by hackers with sophisticated processing capabilities. Some browser SSL implementations may reject keys less than 2048 bits after January 1, 2014. Additionally, some SSL certificate vendors may revoke certificates less than 2048 bits before January 1, 2014. Recommendation: It is recommended to replace the certificate in the chain with the RSA key less than 2048 bits in length with a longer key, and reissue any certificates signed by the old certificate.

Analysis: During analysis, it was observed that the SSL certificate was signed using the cryptographically weak algorithm SHA1. Please refer to the below-provided evidence: Impact: These signature algorithms are known to be vulnerable to collision attacks. A determined attacker may be able to leverage this weakness to generate another certificate with the same digital signature which could allow the attacker to masquerade as the affected service. Recommendation: It is recommended that the certificate should not be signed using weak hashing algorithms (e.g. MD2, MD4, MD5, or SHA1). It's recommended that the certificate should be signed using a strong hashing algorithm like SHS-256

Analysis: During the analysis, it was observed that the mentioned application was deployed over an unencrypted protocol (i.e. HTTP). Due to this user credentials are transmitted in plain text over the network.  Please refer to the below-provided evidence. Impact: When the transport layer is not encrypted, all communication between the website and the server is sent in clear text which leaves it open to interception, injection, and redirection (also known as a man-in-the-middle/MITM attack).  An attacker may passively intercept the communication, giving them access to any sensitive data that is being transmitted such as usernames and passwords. An attacker may also actively inject/remove content from the communication, allowing the attacker to forge and omit information, inject malicious scripting, or cause the client to access remote untrusted content.  An attacker may also redirect the communication in such a way that the website and client are no longer communicating with each other,

Analysis: During the analysis, it was observed that the mentioned application was not validating the user-provided input and directly included that input within the immediate HTTP response in an unsafe way. Please refer to the below-provided evidence or proof of concept: Provide your screenshot here with the steps Impact: If an attacker can control a script that is executed in the victim's browser, then an attacker can execute arbitrary JavaScript in the victim's browser, redirect a victim to a malicious website, hijack user session, keylogging, completely compromise that user, view any information that user is able to view, etc. Recommendation: It is strongly recommended to implement the following mitigations: • Encode all fields when displaying them in the browser • Ensure that user input is properly sanitized especially in the case of special characters • Ensure that cookie properties (such as HttpOnly) and security headers (such as Strict-Transport-Security, X-Frame-Options