Hint #1: Take a good look at the dumpData function and to the login mechanism.
Hint #2: The script seems to be resistant to SQL injection, but the database is cleared every 5 minutes. Maybe we can do something with that?
Hint #3: Timing seems to be the key here.
If you look at the PHP code it seems the developer protected the code against SQL injection, thus it would be pretty hard to fool the login system. There are no exploitable functions in the code (such as unserialize or passing commands etc.), but there is something funky going on. The database gets cleared every 5 minutes. But since the admin needs to login, it automatically creates the admin account after the database was cleared.
Since the script checks at login of the SQL query returns more than 0 rows we might as well try to create more than one record in the database. You can do this by spamming login attempts to the webservice and if you post at the exact moment where the database gets cleared but the natas28 user is not automatically added yet you can create your own natas28 user (creating two records of the same user). It seems the database clearing and creation of the natas28 user is not in one transaction but has some delay between them.
After this you can login with your own created natas28 user (and given password) to call the dumpData function which will prints all rows of that given user (which also indicated this attack since you otherwise always had to print only one record).