Openware: Program info

In-Scope Vulnerabilities

We are interested in the following vulnerabilities:

• Business logic issues
• Payments manipulation
• Remote code execution (RCE)
• Database vulnerability, SQLi
• File inclusions (Local & Remote)
• Access Control Issues (IDOR, Privilege Escalation, etc)
• Leakage of sensitive information
• Server-Side Request Forgery (SSRF)
• Other vulnerability with a clear potential loss

Out-of-Scope Vulnerabilities

Vulnerabilities found in out of scope resources are unlikely to be rewarded unless they present a serious business risk (at our sole discretion). In general, the following vulnerabilities do not correspond to the severity threshold:

• Vulnerabilities in third-party applications
• Best practices concerns
• Recently (less than 30 days) disclosed 0day vulnerabilities
• Vulnerabilities affecting users of outdated browsers or platforms
• Social engineering, phishing, physical, or other fraud activities
• Publicly accessible login panels without proof of exploitation
• Reports that state that software is out of date/vulnerable without a proof of concept
• Vulnerabilities involving active content such as web browser add-ons
• Most brute-forcing issues without clear impact
• Denial of service
• Theoretical issues
• Moderately Sensitive Information Disclosure
• Spam (sms, email, etc)
• Missing HTTP security headers
• Infrastructure vulnerabilities, including:
• Certificates/TLS/SSL related issues
• DNS issues (i.e. MX records, SPF records, DMARC records, etc.)
• Server configuration issues (i.e., open ports, TLS, etc.)
• Open redirects
• Session fixation
• User account enumeration
• Clickjacking/Tapjacking and issues only exploitable through clickjacking/tap jacking
• Descriptive error messages (e.g. Stack Traces, application or server errors)
• Self-XSS that cannot be used to exploit other users
• Login & Logout CSRF
• Weak Captcha/Captcha Bypass
• Lack of Secure and HTTPOnly cookie flags
• Username/email enumeration via Login/Forgot Password Page error messages
• CSRF in forms that are available to anonymous users (e.g. the contact form)
• OPTIONS/TRACE HTTP method enabled
• Host header issues without proof-of-concept demonstrating the vulnerability
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
• Content Spoofing without embedded links/HTML
• Reflected File Download (RFD)
• Mixed HTTP Content
• HTTPS Mixed Content Scripts
• DoS/DDoS issues
• Manipulation with Password Reset Token
• MitM and local attacks

Previous audit results(out-of-scope)

1. OTG-CONFIG-006- Test HTTP Methods

RFC 2616 (which describes HTTP version 1.1 which is the standard today) defines the following eight methods:

• HEAD
• GET
• POST
• PUT
• DELETE
• TRACE
• OPTIONS
• CONNECT Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users.

2. OTG-SESS-002- Testing for Cookies attributes If an attacker were able to acquire a session token (for example, by exploiting a cross site scripting vulnerability or by sniffing an unencrypted session), then they could use this cookie to hijack a valid session. Second, there is the option Secure which does not allow the cookie to be sent over a plain HTTP connection. It can only be sent over HTTPS. This makes sense only if the entire application is available over HTTPS and should be used that way only

Business impact: It gives the hacker the possibility to get the value of the cookie unencrypted and to create idea about cookies information

3. OTG-SESS-003 -Testing for Session Fixation In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session. In our case we were able to export cookies to another machine, and after accessing the system from that other machine, we were logged into the application without authentication. As a result, we were able to hijack the session.

Business impact It is possible to perform hijacking of an authenticated user’s session. As the application doesn’t suffer from XSS (see also below), this issue is not high profile.

4. OTG-BUSLOGIC-001-Test Business Logic Data Validation At URL /wallets , at “Add new withdrawal address” all parameters “does not validate properly inputs according to a logic. At URL POST /api/v2/barong/resource/profiles back-end parameter “dob” is allowing inputs beside the standard ones. At back-end parameter is allowing inputs beside the standard ones. POST /api/v2/barong/resource/documents as shown the picture below .

Business impact: The front end and the backend of the application should be verifying and validating that the data it has, is using and is passing along is logically valid. Even if the user provides valid data to an application the business logic may make the application behave differently depending on data or circumstances.

5. OTG-BUSLOGIC-009-Test Upload of Malicious Files Many application’s business processes allow for the upload of data/information. We regularly check the validity and security of text but accepting files can introduce even more risk. To reduce the risk we may only accept certain file extensions, but attackers are able to encapsulate malicious code into inert file types. Testing for malicious files verifies that the application/system is able to correctly protect against attackers uploading malicious files. In my case I was able to upload double file extension. POST /api/v2/barong/resource/documents

Business impact: This can compromise the whole server and give to hacker full access to it and databases.

6. OTG-CLIENT-009- Testing for Clickjacking “Clickjacking” (which is a subset of “UI redressing”) is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different to what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting with seemingly harmless web pages. A Clickjacking attack uses seemingly innocuous features of HTML and JavaScript to force the victim to perform undesired actions, such as clicking a button that appears to perform another operation. This is a “client side” security issue that affects a variety of browsers and platforms. In our case we did it by simulating with burpsuite.

Business impact: Hackers can manipulate genuine users to click on unwanted URL resulting in unwanted results.

7. A3-Sensitive Data Exposure (Top 10 findings) Sensitive Data Exposure occurs when an application does not adequately protect sensitive information.

Business impact A hacker gains valuable information for further attacks.

• Avoid using web application scanners for automatic vulnerability searching which generates massive traffic
• Make every effort not to damage or restrict the availability of products, services or infrastructure
• Avoid compromising any personal data, interruption or degradation of any service
• Don’t access or modify other user data, localize all tests to your accounts
• Perform testing only within the scope
• Don’t exploit any DoS/DDoS vulnerabilities, social engineering attacks or spam
• Don’t spam forms or account creation flows using automated scanners
• In case you find chain vulnerabilities we’ll pay only for vulnerability with the highest severity.
• Don’t break any law and stay in the defined scope
• Any details of found vulnerabilities must not be communicated to anyone who is not a HackenProof Team or an authorized employee of this Company without appropriate permission