University user account management at its best...



  • I though I'd share a WTF moment I recently ran across.

    All our university's dorms have wired internet access. User access is granted on the basis of MAC adresses, with managed switches preventing spoofing (every room has just one RJ45 slot). Some years ago, we had a centralized database where the dorm admins were required to enter the user data. That database went down for some reason or other (before my time) with no immediate replacement, just one that was promised to us Soon(tm).

    Well, after some month of wide open access to everyone, every dorm began to roll out their own solution - our own dorm now has a nice GUI, iptables rules which run flawlessly and other clever things the old solution couldn't do.

    Recently, the new database finally has been delivered. Apart from the db structure being a WTF in itself, it sports a web administration interface based on PHP which has to be installed on every router and is reachable only over a high port. It also has to be run as root.

    Now, the writer of said interface obviously wanted some kind of centralized updating mechanism so he could change things without having to update each and every router out there manually. You could do some kind of rsync. You could do git on a cron job.

    You could use the include feature of PHP to pull in remote files on another server. Still not that bad, though.

    However, you could also base the target of the include on the GET part of a HTTP request. Unsanitized, of course.



  • @Rhywden said:

    However, you could also base the target of the include on the GET part of a HTTP request. Unsanitized, of course.

    As in: now anyone can execute arbitrary PHP-code via a http parameter? Neat. Time to block your neighbour's access...



  • @TGV said:

    @Rhywden said:

    However, you could also base the target of the include on the GET part of a HTTP request. Unsanitized, of course.

    As in: now anyone can execute arbitrary PHP-code via a http parameter? Neat. Time to block your neighbour's access...

     

    Or add a default static route to a rickroll site, or if you're sadistic use lemon party instead.



  • Stories like this beg the question "Why?". Like, "Why did that seem like a good idea?" Assuming the code author was a rational, logical human being, and made their decisions purposefully and deliberately (like we're supposed to assume poets choose their words purposefully and deliberately), FUCKING HELL WHY???

    (BTW, I almost reported this one as abuse, just because...)



  • @SuperJames74 said:

    Stories like this beg the question "Why?". Like, "Why did that seem like a good idea?" Assuming the code author was a rational, logical human being, and made their decisions purposefully and deliberately (like we're supposed to assume poets choose their words purposefully and deliberately), FUCKING HELL WHY???

    (BTW, I almost reported this one as abuse, just because...)

     

    It's rational, it's just the infamous Works On My Machine(tm) type of rationality. Obviously the guy that designed the database is the only remotely computer-literate being in the whole dorm, so no one ever would get the idea of examine something as complicated and arcane as URL query parameters...



  • We don't have any level 2 security. So I can have any IP I want from a /16. :3
    The downside is: my dorm (~200 rooms) are connected by a 'last mile solution'. Which is a hardly reliable 120 MBit/s WLAN, across pretty much a whole mile.



  • This reminds me of my university days. This was some years ago and the dorms didn't have phone/net access, they had to go to the labs, but non-on-campus students could dial into the 28.8k modems for network access. These modems never connected at more than 24k for me, even though my commercial ISP always connected at 33600 (33.6k modem). But anyway, every student had a "web site" area that one edited/uploaded files via a web interface. This web interface presented a select box with the list of html files in your web directory. I remember there being no escaping on the html: so if you had a </textarea> in your page it would truncate. There was also no server-side checking of the post parameters, so of course there was a directory traversal "opportunity" there. If one made their own HTML page and replaced the <select> with <input> and tried to "edit" say "../" it would show a list of the directory entries of the directory above your own area.

    Long story short, someone I knew managed to traverse the directory and come down into /etc or something and found a very interesting file. it was a ~6MB text file containing every student's username, student number, name, email address, a few other things and PASSWORD, in plain text. They had a home-grown "single sign on" system that used this file to authenticate everyone for "online" services: at that point pretty much only the labs, the modems, the above web area, the proxy server to access real web sites and the place to check grades. I don't remember if there was an opportunity to cause real damage to someone's account, though there was enough information to impersonate them quite successfully. The poxy proxy only allowed a quota of about 2 or 5 MB per week so this file became very valuable: simply use a different student's username/password for more quota. Even the "test" usernames had quota, though using them could have been our downfall. "Who is Mr Test Test?"

    It did take 6+ months for IT security to catch on! Because we uncovered their massive WTF and kept it quiet we didn't get into big trouble. They then posted a letter to every student telling them that their password will be force-ably changed.

    I had wondered why it always took overnight to change your password. This has all changed since I left and they have gotten rid of these systems and now use PeopleSoft or some crap, with better authentication systems.



  • Short follow-up: We just discovered that the SQL-Database containing all students' data pertaining to web access indeed has user accounts, each dorm has a different one. To boot, those accounts are only allowed to use views.



    However, the PHP script doesn't use the authentication script provided, instead skipping it for a hardcoded master password. Which gives full access to the database up to and including "DROP Table".



    I haven't yet looked at the hashing function of the passwords but if those are sufficiently weak, one could brute force the hash and get the password. Which then would allow to wreak havoc upon that particular student since the web forms for signing up and dropping out of lessons and exams are also protected by that same password. Dropping out of university however, that function is protected by a PIN/TAN solution.



    Additional WTFs:

    several "function1() function2() funtcion3()" throughout the code.

    Large swathes of uncommented code

    Including of files like "incl.inc" and "incl.php"

    Includes may also contain only html, no PHP at all

    Four different functions of doing SQL statements, all opening a new connection to the database without closing it.

    Wild mixture of camel case and underscore function and variables.

    A full page of global variables.



  • @Rhywden said:

    I haven't yet looked at the hashing function of the passwords but if those are sufficiently weak, one could brute force the hash and get the password.
     

    If you know the algo and can get a rainbow table, it's going to be a matter of minutes to obtain all valid passwords without brute forcing.

    Unless they're salted, in which case you have nothing at all.



  • Next up: Shell execution vulnerability, SQL insertion vulnerability, SNMP header injection vulnerability.



    I wonder if this guy got anything right



  • @Zemm said:

    Long story short, someone I knew managed to traverse the directory and come down into /etc or something and found a very interesting file. it was a ~6MB text file containing every student's username, student number, name, email address, a few other things and PASSWORD, in plain text.
    I have seen this before, at a university/HS campus where I studied. (Note: In Mexico, most High Schools are actually part of a university, and in some cases the "High School" actually shares the same classrooms with the college section. Thus my High School days were spent in a full-fledged University Campus. Oh, the days....)

    When I entered High School back in 1996, I was given a randomly-generated password that couldn't be changed in any of the UNIX systems. I had originally assumed that this was for security-related purposes, mostly to avoid idiot students from using "password" or "penis" as their "secure" password. By the time I was in 4th semester, the truth came out.

    Some curious hacker managed to deduce one of the admin's password (teachers and staff were allowed to set their own passwords) and checked his homedir. There was an interesting series of files called "1", "2", "3", etc. and he saw that the files were pretty large. He cat's one of 'em  and finds:

    [code] 707071 Fdk2Skd56 708071 EwsdFDxa4 [/code]

    Geeze, those look like student IDs. He then tries to login with one of em... and succeeds. The admins didn't let the students change their password because they had a convenient list of unencrypted passwords to access 'em at any time! Seems like some sysadmins were unaware of "su", but oh well.

    This isn't the best WTF yet.

    The same group of sysadmins that had the genious (sic) idea of compiling this big-ass list also thought of automating the process of searching for someone's password. So there was also a special "accounts" login which would bring up a simple script asking for student ID, and would spit out the user's password.

    The password for this "über-special" account was a variation on the sooper-sekrit word "password". Actually, it was the UNIX command for changing passwords with one letter missing. The can of worms was opened, and suddenly a lot of people had either the big-ass password file list, or were using the dumbfounded "accounts" login.

    Some of us were immune to this, thanks to us being able to change our own passwords during a small timeframe when the yppasswd daemon was running (this was the sysadmin's way to block students from changing passwords: shutting down the yppasswd daemon.) The admins eventually found out that their "accounts" login had been compromised and shut it down (not hard to notice when you have a zillion logins as "accounts"), but the text files were still circulating among miscerants long after I had graduated.



  • Okay, I've got some more updates. The guy responsible for the mess has had time to update his stuff. These two snippets show what he came up with, PHP in both cases:



    #1

    if ($_GET['ip'] && $_GET['pass']=='gehaim') {

    $userip = $_GET['ip'];

    echo "!!!!!";

    }

    $x="/usr/sbin/arp -n ".$userip."|grep ".$userip."|cut -d"r" -f2|cut -d" " -f4";

    global $echtmac;

    $echtmac=$x;



    #2

    $qstring = "SELECT uid FROM user ORDER BY uid DESC";

    $row=abfrage($qstring,1);

    $uid=$row[0]+1;

    $d=$d."UiD: ".$uid."
    ";

    $vname=$_POST[vorname];

    $name=$_POST[nachname];



    $qstring='insert into user(vname,name,hnr,zimmer,mail,tel2,account,uni,

    unote, org,uid,nachricht)

    '."Values ('$_POST[vorname]' , '$_POST[nachname]'

    , '$_POST[hausnummer]', '$_POST[zimmernummer]', '$_POST[email]', '$_POST[telefon]'

    , '$_POST[account]', '$_POST[uni]', '$ztext' ,'$orgid','$uid','$num_nachricht' )";

    $result= einfuegen($qstring,1);



  •  Maybe it was a university assignment to pass the "Introduction to Java" class. But the guy didn't know any Java. Not that he knows any PHP for that matter.



  •  i18n variable names are the best thing.


Log in to reply