I am an independent developer and OSCP certified penetration tester. I focus on Ruby and Ruby on Rails development, and on penetration testing, code auditing and exploit development.
I usually help business to find security issues before the bad guys do to prevent any negative business impact.

I try to contribute to open source projects as much as I can. You can view all my contributions on my Github profile but here is a gist of them:

Latest Blog Post

27 Aug 2021 . rails . console1984 bypass Comments

Basecamp released a new gem recently, which is intended to be an extension to the Rails console to protect sensitive accesses and make them auditable. When they first mentioned it more than a year ago, I was sceptical about how would they make this work, and it looks like I was right, they even mention on their Readme the following:

console1984 uses Ruby to add several protection mechanisms. However, because Ruby is highly dynamic, it’s technically possible to circumvent most of these controls if you know what you are doing. We have made an effort to prevent such attempts, but if your organization needs bullet-proof protection against malicious actors using the console, you should consider additional security measures.

I thought I will give a try to come up a way to bypass the auditing and it only took a few minutes of looking at the source code and fooling around in a console. After I figured out how are they storing the audit records, I figured I will just delete the records from the database with Console1984::Session.last.commands.destroy_all, but that raised an exception: Console1984::Errors::ForbiddenCommand. I checked the sourcecode and noticed that they defined a list of auditable table names, so I just overrode that in the console:

  module Console1984
   module ProtectedAuditableTables
     def auditable_tables_regexp

After this, Console1984::Session.last.commands.destroy_all runs with no error, but I noticed that my session is still flagged as sensitive, so I fixed that with Console1984::Session.last.sensitive_accesses.destroy_all I am sure there are a lot of other ways to circumvent the protection, and I would strongly advise against using this gem in any project, because it gives a false sense of security and doesn’t prevent any developer to access whatever they want in case they have access to a production console.

29 August 2021 Update v0.1.5 fixed the above issue, but I still found and reported another way to bypass the protection. You can get a low level database connection and wipe your session if want to:

# if you need to get the database connection config: ActiveRecord::Base.send(:resolve_config_for_connection, :development)
conn = PG::Connection.open(:dbname => 'rails_edge_development')
conn.exec "delete from console1984_sessions"

View more posts


  • October 2019 – July 2020

    Engineering Manager at Silverfin

  • July 2018 – October 2019

    Ruby Developer at Silverfin

  • August 2017 – July 2018

    Lead Developer at Narrative Forum Limited

  • April 2016 – August 2017

    Senior Ruby Developer at Podomatic

  • February 2015 – April 2016

    Ruby Consultant

  • May 2014 - February 2015

    Senior Ruby Developer at MWR Infosecurity

  • September 2012 – May 2014

    Freelance Ruby Developer

  • September 2010 - February 2012

    Senior Developer at Clockwork Marketing and Direct Mail Ltd

  • September 2009 - September 2010

    Freelance PHP Developer

  • October 2008 - September 2009

    Web Developer at Clockwork Marketing and Direct Mail Ltd


Send me an email if you would like me to code for you or if you want me to penetration test your application or network!