πŸ”’
theB10G
  • ⁉️Welcome/whoami
  • πŸ‘¨β€πŸ”¬Malware Analyst for a day
  • πŸ“§Spooky Scammers (Back for the holidays)
  • πŸ’°Hacking the Scammers
  • πŸ’°Systematic Destruction (Hacking the Scammers pt. 2)
  • πŸ€΅β€β™‚οΈSQL Injection in Security Cleared Job Site
  • ↩️XSS Security Policy Bypass
  • πŸ“ŠCraft CMS Unauthenticated SQLi via GraphQL
  • πŸ₯MISI Hack the Building 2.0 Hospital Edition
  • πŸ“”Booked v2.5.5/LabArchives Scheduler Vulnerability
  • πŸ΄β€β˜ οΈCTF Writ3ups
  • πŸͺ–ARCENT Best Cyber Warrior 2023
  • πŸ’΅Bounty Hunter Writeup
  • πŸͺ„Previse Writeup
  • πŸ‘ΎeJPT certification Review
  • πŸ”₯Sauna Writeup
  • πŸƒβ€β™‚οΈActive Writeup
  • 🚘Driver Writeup
  • ❌Trick Writeup
  • πŸ“ŠGraphQL Query Authentication Bypass Vuln
  • πŸ•ΈοΈeWPT Certification Review
  • β˜€οΈ2022 DOE Cyberforce Competition
  • ⛏️Data Mining CVEs and Exploits
  • πŸ’»eCPPTv2 Certification Review
  • Breaking GraphQL Presentation
  • Springshare LibApps Stored XSS
Powered by GitBook
On this page

Was this helpful?

SQL Injection in Security Cleared Job Site

Error-Based SQL Injection in Security Cleared Job Site

PreviousSystematic Destruction (Hacking the Scammers pt. 2)NextXSS Security Policy Bypass

Last updated 1 year ago

Was this helpful?

A few months back I was on a security cleared job site, one of the top two, and found an interesting endpoint when just using the site as normal. This was a PHP endpoint that when a semi-colon was entered had a very verbose error. How interesting...

Now looking at this we can see that it is surprisingly simple to inject into this query. In order to prove that this was a vulnerability before submitting it to the site maintainers I used the verbose errors to show the tables in the database and get a count on users to make sure it was the active database.

Here is a snippet of this:

Database: <cleared out>
[120 tables]
+-------------------------------------+
| jb_404_page_manager |
| jb_action_log |
| jb_addresses |
| jb_admin_users |
| jb_agent |
| jb_agent_keyword |
| jb_api_keys |
| jb_api_log |
| jb_applicants_activity |
| jb_applicants_feedback |
| jb_applicants_msg_templates |
| jb_applicants_notes |
| jb_apply_job_log |
| jb_banned_ips |
| jb_banners |
| jb_bd_access |
| jb_bd_log |
| jb_bd_services |
| jb_bd_services_menu |
| jb_bd_users |
| jb_billing |
| jb_billing_combo |
| jb_billing_hidden |
| jb_billing_history |
| jb_censor |
| jb_countries |
| jb_coupons |
| jb_covers |
| jb_decline_reasons |
| jb_deleted |
| jb_device_tokens |
| jb_email_themes |
| jb_emails |
| jb_employers |
| jb_employers_old |
| jb_failed_login_attempts |
| jb_feed_error_log |
| jb_feed_import_session |
| jb_feed_xml_base |
| jb_feed_xml_mappings |
| jb_feed_xml_mappings_values |
| jb_form_modifiers |
| jb_form_modifiers_files |
| jb_job_coordinates |
| jb_job_fair |
... <continued>

Count of users:

[x] [INFO] fetching SQL SELECT statement query output: 'SELECT COUNT(*) FROM jb_users WHERE
password IS NOT NULL'
[x] [INFO] retrieved: '320461'
SELECT COUNT(*) FROM jb_users WHERE password IS NOT NULL: '320461'

Wow, over 320k users, all of whom are presumably security cleared professionals. This was a huge security risk and I immediately reached out to the website administrators with my findings. It took a few weeks but eventually got in contact and they remediated the issue.

The main impact from this was the exposure of all these security cleared professional's personal and job information, resumes, messages between employers and recruits, internal employer messages and notes on applicants, API keys, password hashes for each user, admin user passwords, and much more. Thankfully this has been patched and won't fall into the hands of any bad actors anytime soon.

πŸ€΅β€β™‚οΈ
The verbose error returned