Garuda CBT — Security Teardown

The Install controller is never disabled after installation completes, and createAdmin() carries no authentication guard. Anyone, without logging in, can POST a new account into the admin group of a live instance — then simply log in with it. The shipped check_installer() guard exists only on index(), not on the methods that actually matter.

Total application takeover: manage teachers and students, read and edit every grade and report card, export the exam bank with its answers, download database backups — and with GBT-003, arbitrary SQL and code execution. No credentials, no victim interaction.

Lock the installer after installation (lock file or an INSTALLED constant) and reject createAdmin, createApp, createSetting, and checkDatabase once an admin exists — the guard belongs on every method, not just the landing page.

checkDatabase() takes POSTed connection values, string-replaces them into a PHP config template, and rewrites application/config/database.php — the very file the install guide instructs you to chmod 777. The xss_clean filter blocks obvious calls like system( and eval(, but the blacklist is trivially sidestepped: popen() plus stream_get_contents() executes commands just as happily. One request writes the payload; the next request includes it.

OS command execution as the web-server user, without authentication. Reverse shells, config reads, persistence — and because the installation flow itself demands a writable config, the vulnerable condition is the default state of real deployments.

Lock the installer (see GBT-001); stop interpolating raw strings into executable PHP — validate inputs strictly (a hostname belongs to [a-zA-Z0-9.:-]) and write values with var_export(); after install, restore sane permissions and remove the installer.

The Update controller ships with no authentication guard. Its methods decrypt an incoming POST payload and feed it straight into mysqli::multi_query() — stacked queries on command. The catch is supposed to be that payloads are encrypted; but the encryption key is hardcoded in the public repository, identical on every installation. I re-implemented the CI3 HKDF-SHA512 key derivation offline, forged valid encrypted payloads, and the server executed the SQL inside them. With the DB user's FILE privilege, SELECT ... INTO OUTFILE then wrote a PHP webshell into the webroot — full chain, from public repo to RCE.

Dump the entire database — password hashes, student records, exam banks, answers, grades. Insert admin users, alter or drop any table. Where the DB user holds the FILE privilege (common on shared hosting), a webshell lands in the webroot. This is the maximum-severity finding of the audit: CVSS 10.0, verified end to end.

Mandatory admin guard and update-state nonce on every Update method; a random per-installation encryption key generated at install time; validate the payload's JSON schema against a whitelist instead of concatenating into multi_query; deny FILE privilege to the application's DB user and set a strict secure_file_priv.

The kelas GET parameter passes through xss_clean — which is not SQL escaping — and is concatenated directly into a LIKE clause inside the WHERE string. A student-level session (the lowest role in the system) can close the quote, balance the parentheses, comment out the remainder, and drive a timing oracle: SLEEP(4) is answered in four seconds, SLEEP(0) instantly. Character-by-character extraction follows.

Any student can extract the whole database through automated blind retrieval: credential hashes, personal data of classmates and teachers, exam banks with answers. Verbose SQL errors (GBT-008) make the mapping easier.

Query Builder binding — where("a.kepada LIKE", "%$kelas%") — or prepared statements; never concatenate input into a WHERE string. Audit every get_where() call that interpolates a variable.

Same sink pattern, different door: the report-book controller passes tp (academic year) and smt (semester) into model lookups that build get_where() clauses by raw concatenation. One AND SLEEP(4)# in the tp parameter holds the response for four seconds. The identical pattern repeats across several other controllers — one sink, many routes.

The same class of full-database extraction as GBT-004, reachable by any authenticated role that can open the report book.

Parameter binding in getTahunById() and getSemesterById() plus an audit of every caller; treat this as one systemic fix, not two tickets.

Three state-changing endpoints — saveMateri, uploadfile, deletefile — are excluded from CSRF protection to keep an AJAX progress bar simple. A page controlled by the attacker can therefore drive a logged-in teacher's browser to upload files, and worse: saveMateri processes material content as HTML, decodes every base64 <img> data URI, and writes it to disk with the file extension taken from the attacker-controlled MIME type. application/php sails through as a .php file — a webshell, stored and served.

One visit to a booby-trapped page while logged in as a teacher or admin hands the attacker a PHP webshell on the server — RCE with a single victim click. deletefile doubles as arbitrary material-file deletion.

Remove all three URIs from csrf_exclude_uris and make the handlers CSRF-compatible (token via AJAX header); never derive file extensions from client-controlled MIME types — whitelist image extensions and force img_*.jpg|png; disable PHP execution inside uploads/ as mandatory defense in depth.

The announcement text field is saved without an XSS filter and rendered back with raw <?= ?> output — no html_escape in sight. A posted <script> tag survives all the way to the announcement wall, where every role in the school reads it.

Script execution in every viewer's browser — admin, teacher, student. Cookie theft is blunted by HttpOnly, but UI actions on behalf of victims, defacement, and phishing all remain on the table.

html_escape() at output; if rich text is genuinely required, sanitize server-side with an HTML purifier rather than trusting the input.

Three enablers in one finding. The encryption key is hardcoded in the public repo — the same value on every installation, and the direct key to forging GBT-003 payloads. ENVIRONMENT ships as development, so db_debug renders full SQL errors — error numbers, file paths, model lines — straight to the user. And the install guide instructs chmod 777 on database.php, leaving GBT-002's door standing open on real deployments.

Not a direct breach on its own, but it multiplies every other finding: forged crypto, verbose recon, and a writable config are the load-bearing walls of the Critical chain.

Generate a random encryption key during installation; ship ENVIRONMENT=production as the default; rewrite the install instructions with sane permissions.

Static-review findings that did not need dynamic proof: a Compare dev utility that can create and drop tables without authentication (dangerous wherever its DB groups exist); Dbmanager::hapusBackup() deleting files without basename() validation; the blanket input->post(..., false) pattern disabling XSS filtering on content fields across controllers; a non-HttpOnly csrf_cookie; and client-controlled max-size on uploads.

Each is a hardening gap rather than a demonstrated breach — but together they sketch an application where security was never part of the build loop.

Remove dev utilities from production releases; basename() plus a whitelist in backup deletion; re-enable filtering on content fields with output-side encoding; server-side upload size limits.