Campus Network Security Assessment

Note: Certain credentials, internal IP addresses, and personal identifiers have been redacted from this publication for responsible disclosure.

Research Overview

This research involved a passive security assessment of a campus Wi-Fi environment, focusing on the student network’s captive portal, client isolation, and exposed services.

Target

IIMS College Student WiFi Network Subnet: 10.200.x.x/21 Gateway: 10.200.30.x (Ubiquiti UniFi)

Research Objective

To document the network’s security posture, identify weaknesses in authentication and segmentation, and demonstrate potential attack vectors without exploiting them against third parties.

Methodology

The research employed:

• Passive reconnaissance — ARP table analysis, service discovery (Bonjour/mDNS)
• Network mapping — Nmap scanning of gateway and discovered devices
• Traffic analysis — tcpdump capture of HTTP requests (own credentials only)
• DNS probing — Testing resolution before authentication
• Tunnel testing — DNS tunneling proof-of-concept (own VPS only)
• Service enumeration — Identifying exposed services on student devices

Technical Analysis

Captive Portal Authentication

The login form at http://iims.edu/login uses:

Finding	Detail
Protocol	HTTP only — no HTTPS redirection
Password hashing	MD5 with hardcoded salt in JavaScript
Salt location	Visible in client-side code, same for all users
Replay protection	None — hash itself acts as credential

Evidence:

<form name="login" action="http://iims.edu/login" method="post">

document.sendin.password.value = hexMD5(
    '\253' + document.login.password.value +
    '\072\223\222…[redacted]'
);

Client Isolation — None

The network has zero client isolation:

• 138–250+ devices visible in ARP table at any time
• All devices on single broadcast domain
• Direct device-to-device communication possible

Service Discovery

Bonjour/mDNS broadcasts exposed:

Service	Device
AirPlay	Multiple MacBooks (19+ identified by name)
VNC	Student MacBook Air
SMB	Student MacBook Air
KDE Connect	Linux desktop
RAOP	Multiple devices

Infrastructure Devices

IP	Device	Open Ports
10.200.24.x	MikroTik Router	DNS (53), MySQL (3306)
10.200.24.x	MikroTik Router	DNS (53)
10.200.25.x	Windows Server IIS 10.0	HTTP (80)
10.100.250.x	Mail/DNS Server	SMTP (25), DNS (53)

SMTP Server Exposure

The mail server on the internal network accepted unauthenticated connections from the student network:

220 SMTP ESMTP ready
250-SMTP Hello test [10.200.30.x]
250-STARTTLS
250 HELP

This allows spoofed internal emails and potential phishing from trusted infrastructure.

DNS Tunneling Proof-of-Concept

DNS resolution worked before authentication. A DNS tunnel (iodine) was successfully established though throughput was limited by the campus DNS infrastructure.

Key Findings

Finding	Severity
HTTP portal exposes credentials	Critical
No client isolation	Critical
MD5 + hardcoded salt	High
Credential replay possible	High
SMTP open to student network	High
mDNS exposes user identities	Medium-High
Infrastructure on student subnet	Medium
DNS tunneling possible	Low-Medium

Security Impact

Any device on the student WiFi can passively capture login credentials using standard tools. The lack of client isolation allows direct attacks between students. The exposed SMTP server enables phishing from what appears to be trusted campus infrastructure.

Recommendations

1. Enable HTTPS for the captive portal immediately
2. Enable client isolation on the student SSID in UniFi controller
3. Replace MD5 with server-side bcrypt/Argon2 with per-user salts
4. Add CSRF tokens to login form
5. Require SMTP authentication from student network
6. Move infrastructure devices to management VLAN

Disclosure

All testing was limited to passive reconnaissance and the assessor’s own devices and accounts. No third-party credentials were captured, cracked, or replayed. No exploitation of discovered services was attempted.