## SOAP Credentials Security Analysis - Summary

### ✅ What We've Proven

**1. Credentials Are Hardcoded in APK**
- Location: `com/purolator/mobileapp/utils/security/X.java` line 77
- Account: `ef7475ef70b44f4687158fbbb9ff3f47:|HXY2).6` (Base64: `ZWY3NDc1ZWY3MGI0NGY0Njg3MTU4ZmJiYjlmZjNmNDc6fEhYWTIpLjY=`)
- Credit Card: `000b94d6601f4c96ba75d84433 17a2a9:xyA}FWoD` (Base64: `MDAwYjk0ZDY2MDFmNGM5NmJhNzVkODQ0MzMxN2EyYTk6eHlBfUZXb0Q=`)
- Extracted via: Standard APK decompilation (JADX)

**2. Credentials Are Used for Financial Operations**
- Usage: `PurolatorApplication.java` line 301
- Operations:
  - `paymentCreateShipment` - Create billable shipments
  - `voidShipment` - Cancel existing shipments
- Endpoint: `https://webservices.purolator.com/EWS/v2/Shipping/ShippingService.asmx`
- Format: HTTP Basic Auth header

**3. Platform Purpose Identified**
Per PMA/EWS team:
- Credit Card credential: First tariff estimate
- Account credential: Guest estimate + corporate shipping platform
- Platform model: Like ShipStation/2Ship
- Corporate customers: Stryker, J&J, NCR ship through app
- Account registration: Via API Portal

**4. Bypass Successfully Implemented**
- Root detection: BYPASSED ✅
- Emulator detection: BYPASSED ✅
- Frida detection: BYPASSED ✅
- App runs normally on rooted Genymotion emulator
- SOAP interceptor ready to capture traffic

### 🔒 Security Implications

**Risk Level: MEDIUM-HIGH**

**Why It's a Concern:**
1. **Extractability**: Any attacker with basic reverse engineering skills can extract credentials
2. **Permanence**: Basic Auth credentials don't expire
3. **Scope**: Platform-wide credentials (not per-user or per-device)
4. **Operations**: Used for financial operations (create/void shipments)
5. **No Session Security**: Basic Auth provides no per-session validation

**Why Direct Exploitation May Be Limited:**
1. **Server-Side Validation**: Likely requires valid account numbers from API Portal
2. **Client Certificates**: POC failed with AWS Sig v4 error (suggests additional auth)
3. **Rate Limiting**: Likely in place for estimate endpoints
4. **Account Isolation**: Cannot modify shipment data (per team)

**Attack Scenario:**
1. Attacker extracts credentials from APK ✅ (proven)
2. Attacker obtains corporate account numbers (social engineering, breach)
3. Attacker implements AWS Sig v4 signing or uses captured TLS session
4. Attacker uses credentials + valid account to:
   - Create fraudulent shipments
   - Void legitimate shipments
   - Generate shipping labels
   - Abuse tariff estimate system

### 📋 Recommended Actions

**Immediate (PMA/EWS Team Testing)**
- [ ] Verify rate limiting on estimate endpoints
- [ ] Confirm account number validation (credentials alone insufficient)
- [ ] Review logging for suspicious patterns
- [ ] Test if credentials work without valid API Portal registration
- [ ] Verify corporate customer data isolation

**Short-Term (0-3 months)**
- [ ] Move credentials to Firebase Remote Config (rotation without app update)
- [ ] Implement device fingerprinting validation
- [ ] Add SafetyNet/Play Integrity attestation
- [ ] Enable comprehensive API usage logging

**Long-Term (3-6 months)**
- [ ] Replace Basic Auth with OAuth 2.0 Client Credentials Flow
- [ ] Implement device-specific tokens
- [ ] Add per-session validation
- [ ] Integrate with API Gateway for device attestation

### 📊 Current Status

**Tracking API Vulnerability**: ✅ **CONFIRMED - HIGH RISK**
- Token: `EJdhN2UPqA2ZC0otPdTee5JtzN1yeKHr5S0HpTxJ`
- Direct exploitation proven
- Information disclosure of any tracking number

**SOAP Credentials Vulnerability**: ✅ **CONFIRMED - MEDIUM RISK**
- Credentials: Extracted and decoded
- Usage: Traced through code
- Direct exploitation: Blocked by server-side validation
- Security concern: Credentials are extractable and permanent

### 🎯 Next Steps for Complete Analysis

**Option A: Capture Live Traffic** (if needed)
1. Login with valid corporate account
2. Create or void shipment
3. Capture SOAP request with interceptor
4. Document actual headers sent

**Option B: Focus on Tracking API** (already proven)
1. Document tracking information disclosure
2. Test data export capabilities
3. Demonstrate privacy implications

**Option C: Report Current Findings** (sufficient evidence)
1. Credentials are hardcoded (proven)
2. Used for financial operations (proven)
3. Extractable by any attacker (proven)
4. Recommend rotation + architectural changes

### 💡 Key Takeaway

Even though direct exploitation may be limited by server-side controls, **the fundamental security issue remains**: platform credentials are hardcoded in a publicly distributed APK and can be extracted by any attacker with basic skills. This violates security best practices regardless of additional protective layers.