https://arstechnica.com/gadgets/2021/03/rookie-coding-mistake-prior-to-gab-hack-came-from-sites-cto/ Skip to main content * Biz & IT * Tech * Science * Policy * Cars * Gaming & Culture * Store * Forums Subscribe [ ] Close Navigate * Store * Subscribe * Videos * Features * Reviews * RSS Feeds * Mobile Site * About Ars * Staff Directory * Contact Us * Advertise with Ars * Reprints Filter by topic * Biz & IT * Tech * Science * Policy * Cars * Gaming & Culture * Store * Forums Settings Front page layout Grid List Site theme Black on white White on black Sign in Comment activity Sign up or login to join the discussions! [ ] [ ] [Submit] [ ] Stay logged in | Having trouble? Sign up to comment and more Sign up REVISIONIST HISTORY -- Rookie coding mistake prior to Gab hack came from site's CTO Site executive introduces, then removes, insecure code, then hides the evidence. Dan Goodin - Mar 2, 2021 7:11 pm UTC Rookie coding mistake prior to Gab hack came from site's CTO Enlarge Gab.com reader comments 139 with 82 posters participating, including story author Share this story * Share on Facebook * Share on Twitter * Share on Reddit Over the weekend, word emerged that a hacker breached far-right social media website Gab and downloaded 70 gigabytes of data by exploiting a garden-variety security flaw known as an SQL injection. A quick review of Gab's open source code shows that the critical vulnerability--or at least one very much like it--was introduced by the company's chief technology officer. Further Reading Trump's is one of 15,000 Gab accounts that just got hacked The change, which in the parlance of software development is known as a "git commit," was made sometime in February from the account of Fosco Marotto, a former Facebook software engineer who in November became Gab's CTO. On Monday, Gab removed the git commit from its website. Below is an image showing the February software change, as shown from a site that provides saved commit snapshots. [marotto-git-commit] Archive.vn The commit shows a software developer using the name Fosco Marotto introducing precisely the type of rookie mistake that could lead to the kind of breach reported this weekend. Specifically, line 23 strips the code of "reject" and "filter," which are API functions that implement a programming idiom that protects against SQL injection attacks. Developers: Sanitize user input This idiom allows programmers to compose an SQL query in a safe way that "sanitizes" the inputs that website visitors enter into search boxes and other web fields to ensure that any malicious commands are stripped out before the text is passed to backend servers. In their place, the developer added a call to the Rails function that contains the "find_by_sql" method, which accepts unsanitized inputs directly in a query string. Rails is a widely used website development toolkit. "Sadly Rails documentation doesn't warn you about this pitfall, but if you know anything at all about using SQL databases in web applications, you'd have heard of SQL injection, and it's not hard to come across warnings that find_by_sql method is not safe," Dmitry Borodaenko, a former production engineer at Facebook who brought the commit to my attention wrote in an email. "It is not 100% confirmed that this is the vulnerability that was used in the Gab data breach, but it definitely could have been, and this code change is reverted in the most recent commit that was present in their GitLab repository before they took it offline." Advertisement Ironically, Fosco in 2012 warned fellow programmers to use parameterized queries to prevent SQL injection vulnerabilities. Marotto didn't respond to an email seeking comment for this post. Attempts to contact Gab directly didn't succeed. Revisionist history Besides the commit raising questions about Gab's process for developing secure code, the social media site is also facing criticism for removing the commits from its website. Critics say the move violates terms of the Affero General Public License, which governs Gab's reuse of Mastodon, an open source software package for hosting social networking platforms. Critics say the removal violates terms that require forked source code be directly linked from the site. The requirements are intended to provide transparency and to allow other open source developers to benefit from the work of their peers at Gab. Gab had long provided commits at https://code.gab.com/. Then, on Monday, the site suddenly removed all commits--including the ones that created and then fixed the critical SQL injection vulnerability. In their place, Gab provided source code in the form of a Zip archive file that was protected by the password "JesusChristIsKingTrumpWonTheElection" (minus the quotation marks). Representatives from the Mastodon project didn't immediately respond to an email asking if they shared the critics' concerns. Besides questions about secure coding and license compliance, the Gab git commits also appear to show company developers struggling to fix their vulnerable code. The image below shows someone using the username "developer" trying unsuccessfully to fully fix the code containing the SQL injection vulnerability. [developer-change] Thread participants respond by sarcastically pointing out the difficulty the developer seemed to be having. sorry, not telling where the SQLi still is, maybe you should call an exorcist to figure it out XDDDDDD pic.twitter.com/R4h0wNkoLg -- crash override (@donk_enby) March 1, 2021 Gab's security breach and behind-the-scenes handling of code before and after the incident provide a case study for developers on how not to maintain the security and code transparency of a website. The lesson is all the more weighty given that the submission used the account of Gab's CTO, who among all people should have known better. Promoted Comments * Kuro san Ars Centurion et Subscriptor jump to post One thing the article misses is that, in addition to it being bad practice, every code static analysis tool in existence will tell you that writing SQL like that is a Really Bad Idea(tm). Our CI pipeline will even reject the code outright and refuse to merge it. Meaning that even if one of our devs managed to overlook the glaring security flaw, the system itself would prevent it. So Gab either didn't have any SAST tools at all, or intentionally chose to ignore their feedback. 206 posts | registered 4/5/2006 * cerberusTI Ars Praefectus et Subscriptor jump to post dangoodin wrote: mehj wrote: Just a quick note - "reject" and "filter" operations missing are not the problem in the listed code - they're Ruby methods designed to operate on collections of data, and don't intrinsically protect against SQL injection. The actual problem in the listed code is the use of string interpolation to construct the query, rather than using query parameterization. I'm struggling to find a way to explain this that's understandable to nonprogrammers and won't make experienced programmers wince. Can anyone suggest a simple way I can do better? SQL is code. It is run by an interpreter. The programmers in this case let the user directly supply code to run, by copying it into their SQL program and running it. That has predictable consequences if you have any malicious users. Parameters mean you replace certain parts with ? (or a name), then run the program. You then provide data to the running program, and as it is input and not code, it is safe and cannot execute. 4382 posts | registered 12/15/2000 reader comments 139 with 82 posters participating, including story author Share this story * Share on Facebook * Share on Twitter * Share on Reddit Dan Goodin Dan is the Security Editor at Ars Technica, which he joined in 2012 after working for The Register, the Associated Press, Bloomberg News, and other publications. Email dan.goodin@arstechnica.com // Twitter @dangoodin001 Advertisement You must login or create an account to comment. Channel Ars Technica - Previous story Next story - Related Stories Sponsored Stories Powered by Today on Ars * Store * Subscribe * About Us * RSS Feeds * View Mobile Site * Contact Us * Staff * Advertise with us * Reprints Newsletter Signup Join the Ars Orbital Transmission mailing list to get weekly updates delivered to your inbox. Sign me up - CNMN Collection WIRED Media Group (c) 2021 Conde Nast. All rights reserved. Use of and/or registration on any portion of this site constitutes acceptance of our User Agreement (updated 1/1/20) and Privacy Policy and Cookie Statement (updated 1/1 /20) and Ars Technica Addendum (effective 8/21/2018). Ars may earn compensation on sales from links on this site. Read our affiliate link policy. Your California Privacy Rights | Do Not Sell My Personal Information The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of Conde Nast. Ad Choices