The first FLOSSHack workshop will be held on July 1st, 2012 from noon to 4pm at Free Geek. The workshop's target will be the Ushahidi platform. An overview of the FLOSSHack workflow can be found on the "FLOSSHack for Participants" page. The primary organizers for this event are Timothy D. Morgan and Wil Clouser.
- 1 Getting Started
- 2 Joining Remotely
- 3 Competition Notes
- 4 Ideas for Attacks
- 5 Suggested Tools
- 6 Other Tips
- 7 Prize Winners
- 8 Findings
- 8.1 Issue #1: SQL injection in admin area reports editing
- 8.2 Issue #2: TBA
- 8.3 Issue #3: Admin User Hijacking
- 8.4 Issue #4: Lack of Authentication in Checkin API
- 8.5 Issue #5: TBA
- 8.6 Issue #6: TBA
- 8.7 Issue #7: TBA
- 8.8 Issue #8: TBA
- 8.9 Issue #9: Lack of authentication report submission
- 8.10 Issue #10: Lack of authentication in deleting email messages
- 8.11 Issue #11: Potential stored XSS via member name
- 8.12 Issue #12: SQL Injection in MY_Countries_Api_Object.php
- 8.13 Issue #13: TBA
- 8.14 Issue #14: TBA
- 8.15 Issue #15: TBA
- 8.16 Issue #16: Multiple SQL Injection Vulnerabilities
- 8.17 Issue #17: TBA
- 8.18 Issue #18: TBA
If you want to check out the code separately from the VM, the version of the source code for audit is the latest commit on the master branch. This can be obtained with:
git clone -b master git://github.com/ushahidi/Ushahidi_Web.git
Once the workshop begins, a Google+ Hangout will be created that remote participants may join. To receive an invite, please email
tim . morgan |at|
owasp . org with your Google email address/ID. In addition to Hangouts, the session will be streamed live on YouTube. A URL will be posted here later today for accessing that feed.
UPDATE: Google Hangouts turned out to be too complicated. Please join us instead on IRC. Network: freenode / Channel: #flosshack
You are welcome to start looking for vulnerabilities right now. If you do find any vulnerabilities in the application prior to the workshop, please email them to
tim . morgan |at|
owasp . org. That way you get credit for them if you're the first to find a given flaw. At the end of the workshop, there will be prizes for both finding the "best" vulnerability and for finding the most vulnerabilities. Also, be sure to keep any flaws you find under wraps so that way Ushahidi has some time to correct everything before they are made public.
Ideas for Attacks
The application is designed to gather information about events from the general public and combine them into useful statistical and geographic reports. The following attack scenarios seem relevant (not all-inclusive):
- Cross-site Scripting (XSS): plenty of places to enter data and have it displayed later by other users. Reflected attacks also interesting
- SQL Injection: Using PHP with a MySQL database
- Authorization: supports user-defined roles. These roles can be configured with various sets of built-in access rights as well as an access level feature designed for controlling access to custom forms. Certainly any bypass of this privilege system would be interesting. Try setting up accounts with different privilege levels and see if you can get around any restrictions.
- File uploads: several forms allow file uploads of various types. These are frequently vectors for a variety of attacks, including directory traversal, uploads of executable content (like .php scripts within the web root), XSS via filenames and content, HTTP header injection via file names, and other content-type/file extension shenanigans.
- Privacy concerns: in some deployments, the application is used to gather reports of civil/human rights violations by governments and other entities. If you see a flaw in the application that could leak reporters' identities, this could be devastating for these deployments
- Software deployment: The provided VM is distinctly not security-hardened, so if you see a problem in the web server, database, or filesystem configuration, it may not be very relevant. However, if you find something along these lines and you find that the instructions in the Installation Guide would cause this same problem to come up for normal users, then it is definitely worth noting.
- The provided VM image apparently does not have PHP's GD imaging library packages installed. You'll want to install the
php5-gdpackage. This may cause a packaging conflict with the underlying GD library, but you can resolve it by installing the
libgd2-xpmversion of the GD library. After doing this, then restart PHP with:
- You may find it helpful to turn on PHP error reporting to immediately see in the UI when certain errors could be exploitable. To do this, edit the
/etc/php5/fpm/php.inifile, add the following line, and then restart PHP:
display_errors = On
Good luck and happy hunting!
FLOSSHack One was a great success, particularly in how many issues were identified in such a short period of time. This speaks largely to the quality of skills participants brought to the event and the help from Ushahidi developers who supported us through the process. The following findings were identified, many of which have already been fixed in a new software release on August 1. Here we include details about what the flaws were and how they could have been exploited, for educational benefit.
Issue #1: SQL injection in admin area reports editing
credit: Timothy D. Morgan
Issue #2: TBA
Issue #3: Admin User Hijacking
credit: Wil Clouser
- Load /installer/basic_summary.php
- Click through the prompts filling out any data you want. Intercept all requests. Remove any Location headers in the server responses before they hit your browser. It might take a few trips through the wizard to get all the variables into your $_SESSION but by the end I didn't even need to intercept Location.
- /installer/basic_admin_pass.php will reset the administrative password in the database.
- Log in with your new admin account using the password in step 3.
The best idea would be to remove the installation files when installation is complete. The super fast fix (and worth auditing the rest of the site) is to call die() after any Location headers. That way if the client ignores the header they can't load the rest of the page.
Issue #4: Lack of Authentication in Checkin API
credit: Kees Cook
There appears to be no authentication of users beyond knowing a given account's email address and name. This allows unauthenticated API users to create comments on arbitrary incidents as arbitrary users:
curl -d task=comments -d action=add -d firstname.lastname@example.org \ -d comment_author=Administrator -d incident_id=2 \ -d comment_description=comment_description-Data2 \ 'http://localhost/api'
Also anyone can delete arbitrary comments:
curl -d task=comments -d action=delete -d comment_id=2 'http://localhost/api'
The approve and spam actions have a bug that blocks anyone from being able to use those functions ("a" != "approve"), but if that was fixed, then anyone could also query pending comment and approve (or spam) them (if auto-approve was disabled):
curl -d task=comments -d by=pending 'http://localhost/api' ... curl -d task=comments -d action=approve -d comment_id=200 'http://localhost/api'
curl -d task=comments -d action=spam -d comment_id=200 'http://localhost/api'
Issue #5: TBA
Issue #6: TBA
Issue #7: TBA
Issue #8: TBA
Issue #9: Lack of authentication report submission
credit: Kees Cook
There appears to be no authentication for adding reports, so an unauthenticated user can report as an user by specifying person_email in the POST via reports::save_personal_info().
Issue #10: Lack of authentication in deleting email messages
credit: Dennison Williams
There is no authentication for this action. The functionality for this is located in: application/libraries/api/MY_Email_Api_Object.php line 134
Issue #11: Potential stored XSS via member name
credit: Amy K. Farrell
Storing a "Full Name" with HTML special characters is possible and will result in at least one page, the public profile, including these characters unencoded on output. The application does perform blacklist-style HTML filtering of the entered content, but it is likely that there is some way to get around it.
To fix, encode these values properly using HTML entities. Also consider rejecting entered names that include unreasonable characters.
Issue #12: SQL Injection in MY_Countries_Api_Object.php
credit: Kees Cook
The countries API does not perform any parameterized SQL queries, so multiple "by" codes will trigger it. Note the injected "KABOOM":
curl -d task=countries -d by=countryiso -d iso="us' KABOOM" 'http://localhost/api'
ERROR: Database error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'KABOOM' ORDER by id DESC LIMIT 0, 20' at line 3 - SELECT id, iso, country as `name`, capital FROM `country` WHERE iso='us' KABOOM' ORDER by id DESC LIMIT 0, 20
Issue #13: TBA
Issue #14: TBA
Issue #15: TBA
Issue #16: Multiple SQL Injection Vulnerabilities
$request is a plain Array that is populated elsewhere in:
https://github.com/Ushahidi/Ushahidi_Web/blob/master/application/controllers/admin/messages.php line 81 https://github.com/Ushahidi/Ushahidi_Web/blob/master/application/controllers/admin/messages/reporters.php line 54 https://github.com/Ushahidi/Ushahidi_Web/blob/master/application/libraries/api/MY_Incidents_Api_Object.php line 191
Location_Model::get_locations (application/models/location.php line 44) never escapes column or value in:
https://github.com/Ushahidi/Ushahidi_Web/blob/master/application/libraries/api/MY_Locations_Api_Object.php line 50 https://github.com/Ushahidi/Ushahidi_Web/blob/master/application/libraries/api/MY_Locations_Api_Object.php line 68
$user_email is not accepted and is passed request['email'] on line 303 in: