INFO5995 · Security Investigation

SafeCampus Connect
Security Investigation

Five evidence-based findings from static and dynamic APK analysis

Tutorial 16 Activity 6 Semester 2, 2026

Team Mutaz_INFO5995_Activity16_6
Yawen Yang · Huachen Wang · Wanling Guo · Yiqin Sun · Haidi Sun

← → navigate · N speaker notes · F fullscreen

System and threat model

What the application trusts, stores and exposes

Protected assets

Campus alerts, support requests and sync data
Login state and locally stored profile data
Recovery workflow and hidden service-panel state

Trust boundaries

Android client to the HTTPS backend
User input to client-side security decisions
External applications to exported activities

Realistic attackers

A network attacker on the same Wi-Fi
An unauthenticated user with the APK
A malicious application on the same device

F1 · Network trust

F2 · Local login

F3 · Error output

F4 · Recovery code

F5 · Exported activity

Finding 1 · Highest confirmed risk

TLS server authentication is completely bypassed

checkServerTrusted(...) {
  // no certificate validation
}

hostnameVerifier = (host, session) -> true;

fetchCampusAlerts()
submitSupportRequest()
fetchSyncEnvelope()

1

Attacker presents any certificate

The custom trust manager accepts it.

2

Hostname mismatch is ignored

The verifier returns true for every host.

3

Traffic can be read or changed

Alerts, support requests and sync data share the path.

ConfirmedThe trust-all logic is present and used by three workflows.

LimitThe packaged endpoint is invalid, so no live MITM was demonstrated.

FixUse platform certificate and hostname validation. Add pinning only if operationally justified.

Finding 2 · Demo-context risk

Credentials and authentication decisions live in the APK

Embedded values

student
Connect2026!

1

APK exposes the credentials

Anyone who receives the APK can recover constants from the client.

2

Login is checked locally

No server-issued session proves the user identity.

3

Local state opens the dashboard

The demo login continues to work without a network connection.

Evidence boundary: the assignment supplied these teaching credentials and the data is fictional. This demonstrates an unsafe production design, not an undisclosed bypass of the classroom build.

Finding 3 · Information disclosure

A failed login reveals internal authentication details

AUTH_DEBUG_ERROR endpoint: /api/v1/auth/login realm: campus_identity host: 10.0.2.15 service account: auth_api_user exception: InvalidCredentialException

Security impact

An unauthenticated user gains endpoint names, network structure, a service-account identifier and implementation detail that can guide later reconnaissance.

Technical fix

Return a generic login failure to the user. Send diagnostic detail to protected logs with access control and retention limits.

This finding does not reveal a password or establish backend access. Its confirmed impact is reconnaissance.

Finding 4 · Predictable recovery code

Public inputs determine the recovery code offline

Student ID and dateSCU-2026-1842
2026-09-11

=

Generated valueRC-014261

Root cause

ReferenceCalculator combines yyDDD, the student ID characters and Java hash arithmetic. It uses no server secret, secure randomness or one-time state.

Attack path

An attacker obtains or guesses a student ID, extracts the algorithm from the APK, and computes the same value without intercepting email or SMS.

Mitigation

Generate a random server token, store only its digest, bind it to one request, enforce expiry and single use, and rate-limit attempts.

Verification: the same input always produced the same code. Moving the date to 2026-09-12 produced RC-086614. No redemption path was present in the APK, so account takeover remains conditional on an external service accepting this value.

Finding 5 · Local access-control bypass

An exported activity unlocks the hidden service panel

1 · External app

Sends an explicit intent to the exported MainActivity.

2 · Crafted extra

Places a Base64 value in profile_bundle.

3 · Client comparison

The decoded text matches svc:lantern:42.

4 · Persistent state

workspace_state=true reveals the hidden panel.

Demonstrated impact

A malicious application can bypass the intended navigation flow and persist access to the hidden panel.

Limitation

The investigation did not establish that the panel performs privileged backend operations.

Fix

Set the activity to exported=false unless required. Remove Base64 authorization and enforce authenticated server-side checks.

Overall security assessment

Priorities, evidence boundaries and the common root cause

F1TLS authentication bypassTop priority

F5Exported activity access bypassConfirmed

F4Predictable recovery codeConditional

F3Internal error disclosureRecon

F2Embedded demo credentialsDemo risk

What the evidence confirms

Trust-all TLS logic, deterministic code generation, unauthenticated diagnostic output, local credential checks and an exported intent path.

What remains unproven

A live backend MITM, recovery-code redemption, real account takeover and privileged server actions from the hidden panel.

Most findings arise because the client makes or stores security decisions that an attacker can inspect or influence. Move identity, recovery and authorization decisions to a trusted server boundary.