thesp0nge/dawnscanner

Dawn is a static analysis security scanner for ruby written web applications. It supports Sinatra, Padrino and Ruby on Rails frameworks.

Dawnscanner - The raising security scanner for ruby web applications

dawn is a source code scanner designed to review your web applications for security issues.

The tool is able to scan web applications written in Ruby and it supports all major MVC (Model View Controller) frameworks, out of the box:

• Ruby on Rails
• Sinatra
• Padrino

---

---

dawn version 2.0 has 680+ security checks loaded in its knowledge base which is weekly updated from the National Vulnerability Database by NIST.

A brief "how it works"

When you run dawn on your code it parses your project Gemfile.lock looking for the gems used and it tries to detect the ruby interpreter version you are using or you declared in your ruby version management tool you like most (RVM, rbenv, ...).

Then the tool tries to detect the MVC framework your web application uses and it applies the security check accordingly. There checks designed to match rails application or checks that are appliable to any ruby code.

dawn can also understand the code in your views and to backtrack sinks to spot cross site scripting and sql injections introduced by the code you actually wrote (in the project roadmap this is the code most of the future development effort will be focused on).

dawn security scan result is a list of vulnerabilities with some mitigation actions you want to follow in order to build a stronger web application.

Installation

You can install latest dawn version, fetching it from Rubygems by typing:

$ gem install dawnscanner

After that, you need to download the knowledge base from Github and unpack the archive to $HOME/dawnscanner/kb directory.

A typical kb directory layout is similar to this:

$ ll ~/dawnscanner/kb
total 56K
drwxr-xr-x 2 thesp0nge users  28K 29 mar 18.27 bulletin
drwxr-xr-x 2 thesp0nge users   72  7 lug  2021 generic_check
-rw-r--r-- 1 thesp0nge users   65 29 mar 17.06 kb.yaml
-rw-r--r-- 1 thesp0nge users   74 29 mar 17.06 kb.yaml.sig
drwxr-xr-x 2 thesp0nge users 4,0K  7 lug  2021 owasp_ror_cheatsheet

The knowledge base is structured this way:

• bulletin is the folder where all CVE downloaded from NIST are stored.
• generic_check is the folder with all custom checks for your code
• owasp_ror_cheatsheet is for the Owasp Ruby on Rails cheatsheet recomendations

Usage

Starting from version 2.0, the tool uses subcommands to start specific tasks, each of them with specific help messages.

Scanning a project

The scan subcommand tells dawn to scan the specified target for security issues.

$ dawn scan target

At the moment results are available in text format only and they are stored in a directory named with the scan timestamp, under $HOME/dawnscanner/results/target, where target is the name of the application being analyzed.

Querying the knowledge base

Is it possible, with the kb subcommand, to query the knowledge base.

dawn kb find                        # Searches the knowledge base for a given vulnerability
dawn kb help [COMMAND]              # Describe subcommands or one specific subcommand
dawn kb lint                        # Checks knowledge base content for correcteness
dawn kb list gem_name[gem_version]  # List all security issues affecting a gem passed as argument (the version string is optional).
dawn kb status                      # Checks the status of the knowledge base
dawn kb unpack                      # Unpacks security checks in KB library path

Useful links

Twitter profile: @dawnscanner Github repository: https://github.com/thesp0nge/dawnscanner

Support us

Feedbacks are great and we really love to hear your voice.

If you're a proud dawn user, if you find it useful, if you integrated it in your release process and if you want to openly support the project you can put your reference here. Just open an issue with a statement saying how do you feel the tool and your company logo if any.

Thank you.

Thanks to

saten: first issue posted about a typo in the README

presidentbeef: for his outstanding work that inspired me creating dawn and for double check comparison matrix. Issue #2 is yours :)

marinerJB: for misc bug reports and further ideas

Matteo: for ideas on API and their usage with github.com hooks

LICENSE

Copyright (c) 2013-2023 Paolo Perego [email protected]

MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

dawnscanner's Issues

MVC && Ruby deprecation warning

Add a check against deprecated ruby / MVC gems version

Move core check ruby classes to Core namespace

No rake task dawn

$ ruby -v
ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-linux]
$ bundle -v
Bundler version 1.5.2
$ bundle exec rake --version
rake, version 10.1.1
$ bundle show codesake-dawn
/home/xxx/.rvm/gems/ruby-2.1.0@xxx/gems/codesake-dawn-1.0.2
$ cat /home/xxx/.rvm/gems/ruby-2.1.0\@xxx/gems/codesake-dawn-1.0.2/lib/tasks/dawn.rake 
desc 'Execute codesake-dawn on the current directory'
task :dawn do
  system "dawn ."
end

But

$ bundle exec rake dawn
rake aborted!
Don't know how to build task 'dawn'
$ bundle exec rake -T|grep dawn
$

Dawn works, it's only the rake task that's missing.

$ dawn .
09:28:51 [*] dawn v1.0.2 is starting up
...

Owasp Ror Cheatsheet task also check commented lines

If run dawn on my rails app have an error on deploy.rb file:

[{:filename=>"./config/deploy.rb", :matches=>[{:match=>"# ask :branch, proc {git rev-parse --abbrev-ref HEAD.chomp }\n", :line=>3}]}

but is a commented line:

# ask :branch, proc {git rev-parse --abbrev-ref HEAD.chomp }

Introduce check dependency

CVE-2013-1655 introduces a security issue that depends on a particular gem only
when running a particular Ruby interpreter version. For such a reason in
BasicCheck class I introduced a ruby_version attribute as a String and a
is_vulnerable_ruby_version? method to match this thing.

CVE-2013-1821 introduces a security issue about the specific Ruby interpreter
version, therefore I introduced a new kind of security check, the
RubyVersionCheck. Since RubyVersionCheck includes also BasicCheck, it has 2
attributes (filled in engine.rb apply and apply_all methods that are almost
the same. The ruby_version and the detected_ruby that it is an hash.

This situation introduces a logical mess and the chances of having bugs in the
future are very high. So it must be possible to declare a complex security
check as a mixin of basic security checks, this way:

module Codesake
    module Dawn
        module Kb
      class MyVeryComplexSecurityCheck
        include ConditionalSecurityCheck # TODO: name check

        def initialize
          # since DependencyCheck and friends are module, I need to introduce
          # also a scaffolding class including that module so I can create an instance of
          # that.
          a_dependency_check = Codesake::Dawn::Kb::BasicDependencyCheck.new
          a_dependency_check.safe_dependencies = [{:name=>"puppet", :version=>['2.7.21', '3.1.1']}]

          a_ruby_version_check = Codesake::Dawn::Kb::BasicRubyVersionCheck.new
          a_ruby_version_check.safe_rubies = [{:version=>"1.9.3", :patchlevel=>"p392"}, {:version=>"2.0.0", :patchlevel=>"p195"}]

          super({
              :name=>"My very complex security check",
              :cvss=>"AV:N/AC:L/Au:N/C:P/I:P/A:P",
              :release_date => Date.new(2013, 5, 23),
              :cwe=>"20",
              :owasp=>"A9", 
              :applies=>["rails", "sinatra", "padrino"],
              :kind=>Codesake::Dawn::KnowledgeBase::CONDITIONAL_CHECK,
              # => there is no reason not to support multiple boolean operators
              # when checking security checks in the chain for their vuln? return value
              :condition=>:or, 
              :message=>message,
              :mitigation=>"Please upgrade puppet gem to a newer version",
              :aux_links=>["https://puppetlabs.com/security/cve/cve-2013-1655/"],
              :security_checks = [a_dependency_check, a_ruby_version_check]
          })
        end
      end
        end
    end
end

invalid byte sequence in UTF-8

Trying to use the scanner on Mac OS X (10.8) against my Sinatra app, however it does not get very far. It does work on another small project, but not my main large one. Looks like an encoding / parsing issue. Perhaps there should be some better handling in the pattern matcher.

[*] dawn v0.50 (C) 2013 - [email protected] is starting up at 10:11:04
10:11:05: scanning Lumen
10:11:05: sinatra vsinatra 1.3.3 detected
10:11:05: applying all security checks
/Users/jaybrown/.rvm/gems/ruby-1.9.3-p374@comp2/gems/codesake-dawn-0.50/lib/codesake/dawn/kb/pattern_match_check.rb:50:in `=~': invalid byte sequence in UTF-8 (ArgumentError)

Cryptic vulnerability report about "Owasp Ror Cheatsheet"

I'm getting this error when running dawn . in a Rails project:

11:52:14 [$] dawn: Owasp Ror Cheatsheet failed
11:52:14 [$] dawn: Description:
11:52:14 [$] dawn: Solution:
11:52:14 [!] dawn: Evidence:
11:52:14 [!] dawn: [{:filename=>"./config/initializers/devise.rb", :matches=>[{:match=>"  # given strategies, for example, `config.params_authenticatable = [:database]` will\n", :line=>48}, {:match=>"  # given strategies, for example, `config.http_authenticatable = [:token]` will\n", :line=>54}, {:match=>"  # passing :skip => :sessions to `devise_for` in your config/routes.rb\n", :line=>77}, {:match=>"  # Require the `devise-encryptable` gem when using anything other than bcrypt\n", :line=>210}, {:match=>"  # When using Devise inside an engine, let's call it `MyEngine`, and this engine\n", :line=>280}, {:match=>"  # The router that invoked `devise_for`, in the example above, would be:\n", :line=>286}]}, {:filename=>"./config/initializers/simple_form.rb", :matches=>[{:match=>"    # given input by passing: `f.input EXTENSION_NAME => false`.\n", :line=>11}, {:match=>"    # renaming `b.use` to `b.optional`.\n", :line=>13}, {:match=>"    # They are disabled unless you pass `f.input EXTENSION_NAME => :lookup`\n", :line=>24}, {:match=>"    # extensions by default, you can change `b.optional` to `b.use`.\n", :line=>27}]}]
11:52:14 [!] dawn: []
11:52:14 [!] dawn: []

I can't understand what the problem is about. Could both the solution and the evidence be improved with meaningful messages? Thanks in advance.

Multiple versions processing in 'is_vulnerable_version?' method

I knew that Rack had several vulnerabilities (http://www.cvedetails.com/vulnerability-list/vendor_id-12598/product_id-24629/Rack-Project-Rack.html), so I wanted to check for them. I created new CVE files based on your existing ones - completing the info as best I could (let me know if/how you want them added). I am using an older minor version (1.4.) and did not want to jump to the latest version (1.5.), but there is a fix for that version (1.4.5).

The problem I encountered is that the vulnerability check still flagged the gem even though I updated to one of the fix versions, just not the latest number. So I believe there is a flaw in your looping logic when multiple fix versions are available. Example list of fixes for Rack:

self.safe_dependencies = [{:name=>"rack", :version=>['1.1.6', '1.2.8', '1.3.10', '1.4.5', '1.5.2']}]

Perhaps you could sort the array of versions before processing the numbers. Then you may need to break out of the loop once a matching major + minor combo has been found, so it does not look for newer versions and report false positive.

          fixes.sort!.each do |fv|
            fixes_v_array = fv.split(".").map! { |n| n.to_i }
            # same major version
            if target_v_array[0] == fixes_v_array[0]
              # same minor version
              if target_v_array[1] == fixes_v_array[1]
                # previous patch version, so vulnerable
                if target_v_array[2] < fixes_v_array[2]
                  ret = true
                end
                # no need to look at other fix versions
                break
              end
              # same major but previous minor
              if target_v_array[1] < fixes_v_array[1]
                ret = true
              end
            end
          end

Add support for string version modifiers (like 'beta' or 'rc')

If you are using rails version 4.1.0.beta, you're not prompted for CVE-2014-0080 due to the fact Codesake::Dawn doesn't support string version modifiers.

We must support string version modifiers in some way.

Could not locate Gemfile (Bundler::GemfileNotFound) in MVC detection

During the MVC autodetection, dawn fails because bundler gem needs to be in the same directory of the Gemfile.lock (it must access also Gemfile).

No evidence on sensitive files check

In addition to not telling me what's wrong, shouldn't it not complain if my repo is not publicly accessible?

18:26:12 [!] dawn: Owasp Ror CheatSheet: Sensitive Files check failed
18:26:12 [$] dawn: Description: Many Ruby on Rails apps are open source and hosted on publicly available source code repositories. Whether that is the case or the code is committed to a corporate source control system, there are certain files that should be either excluded or carefully managed.
18:26:12 [$] dawn: Solution: Put sensitive files in your repository gitignore file
18:26:12 [$] dawn: Evidence:
18:26:12 [*] dawn is leaving

Add Cross Site Scripting detection

Create a task to check for new CVE in NVD website

cocaine version 0.3.2 is classified as vulnerable

See dawn's output here:

09:38:41 [!] dawn: Vulnerable cocaine gem version found: 0.3.2

But apparently only some versions >= 0.4 are actually vulnerable, see here:

The Cocaine gem 0.4.0 through 0.5.2 for Ruby allows context-dependent attackers to execute arbitrary commands via a crafted has object, related to recursive variable interpolation.

[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4457]

Unable to install codesake-dawn gem

I am not able to install codesake-dawn gem because of the dependency on multiple versions of "mime-types" gem.

grit requires mime-types (> 1.15)(mime type 2 will not work)
rest-client requires mime-types (>= 1.16)
mechanize requires mime-types (> 2.0)

I tried installing both version of the "mime-types" gem (1.25 and 2.2) then gem installed successfully but i am unable to run dawn,when try to run dawn I am getting following error
" `raise_if_conflicts': Unable to activate grit-2.5.0, because mime-types-2.2 conflicts with mime-types (~> 1.15) (Gem::LoadError)"

I am running ubuntu 13.10 and RVM with ruby 1.9.3 and ruby 2.1

Please let me know if there is any work around for this ?

should warn users of invalid combinations of rubygems/ruby

sunce the gem doesn't install in some cases (e.g. ruby 1.9.3 and rubygems 2.1.11) there should be a note saying "upgrade rubygems if XXX happens")

Add @rubysec vulnerability database integration using rake

CVE-2014-2322: Remote Command Injection in Arabic Prawn 0.0.1 Ruby Gem

Arabic Prawn Gem for Ruby contains a flaw in the ib/string_utf_support.rb file. The issue is due to the program failing to sanitize user input. This may allow a remote attacker to inject arbitrary commands.

Security Related Headers check failed, to fix or not to fix and how?

I run dawn on a Rails 4 project and got this

09:28:58 [$] dawn: Description: To set a header value, simply access the response.headers object as a hash inside your controller (often in a before/after_filter). Rails 4 provides the "default_headers" functionality that will automatically apply the values supplied. This works for most headers in almost all cases.
09:28:58 [$] dawn: Solution: Use response headers like X-Frame-Options, X-Content-Type-Options, X-XSS-Protection in your project.
...

I have no idea of what those headers are about so I googled for them and found https://coderwall.com/p/k7xlxa
Apparently they are already used by Rails 4. I checked a Rails 4 application of mine and got them in the response

X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff

So is Rails 4 already safe? If this is the case, should dawn still warn me about those headers?

I believe there is a more general problem. I'm not a security professional and there will be many people like me in the intended audience of dawn. I need either time to really understand why a vulnerabily is a vulnerabily or plain Ruby code to use in my projects to fix vulnerabilities. Falling back to the second option, the message "Use response headers like X-Frame-Options, X-Content-Type-Options, X-XSS-Protection in your project" is not so useful because I don't know how to use those headers (which values?) and where to put them (first guess, some callback in ActionController to set headers on all responses but I thought only 1 second about it.)

Github raw url has changed

Your installation instructions are now incorrect as Github has updated their URLs for direct raw links. The cert is now located at https://raw.githubusercontent.com/codesake/codesake-dawn/master/certs/paolo_at_codesake_dot_com.pem.

Session management check failed

I am using redis-store for sessions, but I still get this error:

18:26:12 [!] dawn: Owasp Ror CheatSheet: Session management check failed
18:26:12 [$] dawn: Description: By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.
18:26:12 [$] dawn: Solution: Use ActiveRecord or the ORM you love most to handle your code session_store. Add "Application.config.session_store :active_record_store" to your session_store.rb file.
18:26:12 [$] dawn: Evidence:
18:26:12 [$] dawn:  In your session_store.rb file you are not using ActiveRercord to store session data. This will let rails to use a cookie based session and it can expose your web application to a session replay attack.
18:26:12 [$] dawn:  {:filename=>"/Users/intinig/src/rgts/config/initializers/session_store.rb", :matches=>[]}

Adding CVE and RoR Cheatsheet tests

CVE-2014-1234
CVE-2014-1233
CVE-2013-5671
CVE-2013-4593
CVE-2013-4489
CVE-2013-4413
CVE-2013-2516
CVE-2013-2513
CVE-2013-2512
CVE-2013-1607
CVE-2013-0262
CVE-2013-0184
CVE-2013-0183
CVE-2012-6109
CVE-2011-5036
CVE-2007-6183
adding test for RoRCheatSheet_2
adding test for RoRCheatSheet_3
adding test for RoRCheatSheet_5
adding test for RoRCheatSheet_6
adding test for RoRCheatSheet_9
adding test for RoRCheatSheet_10
adding test for RoRCheatSheet_11
adding test for RoRCheatSheet_12
adding test for RoRCheatSheet_13
adding test for RoRCheatSheet_14
adding test for RoRCheatSheet_15
adding test for RoRCheatSheet_16

Should these two vulnerabilities be fixed in "rails new"?

1. Ran "rails new new-rails-app" (Rails is 4.1.0.beta1)
2. Added dawn gem to Gemfile and ran "bundle install".
3. Ran "cd new-rails-app ; dawn ." and got 2 vulnerabilities:

09:16:37 [*] dawn v1.0.2 is starting up
09:16:37 [$] dawn: scanning .
09:16:37 [$] dawn: rails v4.1.0.beta1 detected
09:16:37 [$] dawn: applying all security checks
09:16:37 [$] dawn: 146 security checks applied - 0 security checks skipped
09:16:37 [$] dawn: 2 vulnerabilities found

09:16:37 [!] dawn: Owasp Ror CheatSheet: Session management check failed
09:16:37 [$] dawn: Description: By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.
09:16:37 [$] dawn: Solution: Use ActiveRecord or the ORM you love most to handle your code session_store. Add "Application.config.session_store :active_record_store" to your session_store.rb file.
09:16:37 [$] dawn: Evidence:
09:16:37 [$] dawn:  In your session_store.rb file you are not using ActiveRercord to store session data. This will let rails to use a cookie based session and it can expose your web application to a session replay attack.
09:16:37 [$] dawn:  {:filename=>"./config/initializers/session_store.rb", :matches=>[]}

09:16:37 [!] dawn: Owasp Ror CheatSheet: Security Related Headers check failed
09:16:37 [$] dawn: Description: To set a header value, simply access the response.headers object as a hash inside your controller (often in a before/after_filter). Rails 4 provides the "default_headers" functionality that will automatically apply the values supplied. This works for most headers in almost all cases.
09:16:37 [$] dawn: Solution: Use response headers like X-Frame-Options, X-Content-Type-Options, X-XSS-Protection in your project.
09:16:37 [$] dawn: Evidence:
09:16:37 [$] dawn:  {:filename=>"./app/controllers/application_controller.rb", :matches=>[]}
09:16:37 [*] dawn is leaving

JSON output not valid

The text returned when using the "--output json" option is not valid JSON. Specifically, the keys are still using the Ruby symbols instead of quoted strings (e.g. :mvc=>"sinatra")

(Note: I find this site very helpful - http://jsonformatter.curiousconcept.com/)

Fix missing target error message

When dawn is executed with -r, -p or -s but without target directory an error message must be displayed and no MVC detection performed.

Thanks @riffraff for submitting

Documentation - List of security checks

Would be nice if people interested in trying out the gem could see a list of security checks provided to determine if they feel like it gives them some... well... security. If you agree, I'd be happy to fork and add this information to the readme if you can point me to where I could audit the code to see the different security checks.

Errno::ENOENT when .ruby-version is present in a project.

contents of test-project/.ruby-version:

ruby-2.1.1

$ dawn test-project
07:22:44 [*] dawn v1.1.0 is starting up
/Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/engine.rb:374:in `read': No such file or directory @ rb_sysopen - .ruby-version (Errno::ENOENT)
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/engine.rb:374:in `get_rvm_ruby_ver'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/engine.rb:140:in `get_ruby_version'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/engine.rb:155:in `set_target'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/engine.rb:67:in `initialize'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/rails.rb:10:in `initialize'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/core.rb:103:in `new'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/core.rb:103:in `block in detect_mvc'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/core.rb:102:in `each'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/core.rb:102:in `detect_mvc'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/bin/dawn:166:in `<top (required)>'
    from /Users/justin/.rbenv/versions/2.1.1/bin/dawn:23:in `load'
    from /Users/justin/.rbenv/versions/2.1.1/bin/dawn:23:in `<main>'

Refactor bin/dawn with new Reporting facilities

In order to support ascii table, we recently introduced a new Codesake::Dawn::Reporter class to handle all presentation stuff.

json report will be created soon with this class and it will be introduced report formats in html and csv

Also a plain text file will be used

ruby framework auto detect failed on Padrino

Ruby 2.0.0-p353
Padrino 0.11.4
Codesake-dawn 1.1.0

Just after gem install codesake-dawn, I try and start the gem for the first time:

bundle exec dawn -p .
18:41:20 [*] dawn v1.1.0 is starting up
18:41:20 [!] dawn: ruby framework auto detect failed. Please force if rails, sinatra or padrino with -r, -s or -p flags

typo in gem name in the readme

codesake_dawn should be codesake-dawn

New Codesake::Dawn::Core::LanguageCheck to be introduced

A new language check it will handle a ruby script as input and a ruby_parser line as unsafe pattern.

It will compile the ruby and look for the unsafe patterns

CVE-2014-2538: rack-ssl Gem for Ruby Error Message Reflected XSS

Omniauth OAuth2 confusion (CVE-2012-6134)

Not sure if this is an issue with your check and/or confusion wording in the CVE itself. The original issue was found on Sept. 8, and there is a fix in the OAuth2 code on Sept. 18 (omniauth/omniauth-oauth2#25). This resulted in v1.1.1 of the gem published on that same date. I do see that the primary CVE ticket says it affects 1.1.1 and below, which is what your scanner code looks for, but this gem site (https://gemnasium.com/gems/omniauth-oauth2) implies that it was actually fixed by 1.1.1.

So should the check be changed to ">= 1.1.1"?

Add priority and severity to BasicCheck

Findings must be stored in an ad hoc object with severity, message and remediation

CVE-2014-0036: rbovirt Gem for Ruby rest-client Missing SSL Certificate Validation MitM Spoofing Weakness

rbovirt Gem for Ruby contains a flaw related to certificate validation. The issue is due to the program failing to validate SSL certificates. This may allow an attacker with access to network traffic (e.g. MiTM, DNS cache poisoning) to spoof the SSL server via an arbitrary certificate that appears valid. Such an attack would allow for the interception of sensitive traffic, and potentially allow for the injection of content into the SSL stream.

Suggested HTML output

Here is some formatting that I applied to the console output after I pasted it into our wiki.

3 vulnerabilities found:

• CVE-2013-0175 failed
  • Description: multi_xml gem 0.5.2 for Ruby, as used in Grape before 0.2.6 and possibly other products, does not properly restrict casts of string values, which allows remote attackers to conduct object-injection attacks and execute arbitrary code, or cause a denial of service (memory and CPU consumption) involving nested XML entity references, by leveraging support for (1) YAML type conversion or (2) Symbol type conversion, a similar vulnerability to CVE-2013-0156.
  • Solution: Please upgrade multi_xml gem or grape gem
  • Evidence:
    • Vulnerable multi_xml gem version found: 0.5.1
• CVE-2013-0269 failed
  • Description: The JSON gem before 1.5.5, 1.6.x before 1.6.8, and 1.7.x before 1.7.7 for Ruby allows remote attackers to cause a denial of service (resource consumption) or bypass the mass assignment protection mechanism via a crafted JSON document that triggers the creation of arbitrary Ruby symbols or certain internal objects, as demonstrated by conducting a SQL injection attack against Ruby on Rails, aka "Unsafe Object Creation Vulnerability."
  • Solution: Please upgrade JSON gemto version 1.5.5, 1.6.8 or 1.7.7 or latest version available
  • Evidence:
    • Vulnerable json gem version found: 1.7.5
• CVE-2013-1821 failed
  • Description: lib/rexml/text.rb in the REXML parser in Ruby before 1.9.3-p392 and 2.0.0-p0 allows remote attackers to cause a denial of service (memory consumption and crash) via crafted text nodes in an XML document, aka an XML Entity Expansion (XEE) attack.
  • Solution: Please upgrade ruby interpreter to 1.9.3-p392 or 2.0.0-p195 or latest version available
  • Evidence:

<div>
    3 vulnerabilities found:</div>
<ul>
    <li>
        CVE-2013-0175 failed
        <ul>
            <li>
                <em>Description:</em> multi_xml gem 0.5.2 for Ruby, as used in Grape before 0.2.6 and possibly other products, does not properly restrict casts of string values, which allows remote attackers to conduct object-injection attacks and execute arbitrary code, or cause a denial of service (memory and CPU consumption) involving nested XML entity references, by leveraging support for (1) YAML type conversion or (2) Symbol type conversion, a similar vulnerability to CVE-2013-0156.</li>
            <li>
                <em>Solution:</em> <strong>Please upgrade multi_xml gem or grape gem</strong></li>
            <li>
                <em>Evidence:</em>
                <ul>
                    <li>
                        Vulnerable multi_xml gem version found: 0.5.1</li>
                </ul>
            </li>
        </ul>
    </li>
    <li>
        CVE-2013-0269 failed
        <ul>
            <li>
                <em>Description:</em> The JSON gem before 1.5.5, 1.6.x before 1.6.8, and 1.7.x before 1.7.7 for Ruby allows remote attackers to cause a denial of service (resource consumption) or bypass the mass assignment protection mechanism via a crafted JSON document that triggers the creation of arbitrary Ruby symbols or certain internal objects, as demonstrated by conducting a SQL injection attack against Ruby on Rails, aka &quot;Unsafe Object Creation Vulnerability.&quot;</li>
            <li>
                <em>Solution:</em> <strong>Please upgrade JSON gem to version 1.5.5, 1.6.8 or 1.7.7 or latest version available</strong></li>
            <li>
                <em>Evidence:</em>
                <ul>
                    <li>
                        Vulnerable json gem version found: 1.7.5</li>
                </ul>
            </li>
        </ul>
    </li>
    <li>
        CVE-2013-1821 failed
        <ul>
            <li>
                <em>Description:</em> lib/rexml/text.rb in the REXML parser in Ruby before 1.9.3-p392 and 2.0.0-p0 allows remote attackers to cause a denial of service (memory consumption and crash) via crafted text nodes in an XML document, aka an XML Entity Expansion (XEE) attack.</li>
            <li>
                <em>Solution:</em> <strong>Please upgrade ruby interpreter to 1.9.3-p392 or 2.0.0-p195 or latest version available</strong></li>
            <li>
                <em>Evidence:</em></li>
        </ul>
    </li>
</ul>

Ignore tags and vendor/bundle

Many developers install gems in vendor/bundle directory inside a Ruby on Rails application repository. Some also use ctags. Dawn currently scans both tags file and all files inside vendor/bundle. This leads to many duplicates and many errors found in gems.

Interesting situation is that Dawn reports vulnerabilities in itself if it's installed in vendor/bundle.

It would be nice if Dawn automatically ignores these or if there is an option to ignore certain files or directories, passed as flag or set in a configuration file.

Rails '3.2.13', simple little rails application

after installino I run bundle exec dawn -h
and the output was:

/Users/marinobonetti/.rvm/gems/ruby-2.0.0-p0@global/gems/codesake-commons-0.90.0/lib/codesake/commons/logging.rb:60:in helo': undefined methodcolor' for "09:01:04 [*] dawn v1.0.1 is starting up\n":String (NoMethodError)
from /Users/marinobonetti/.rvm/gems/ruby-2.0.0-p0@global/gems/codesake-dawn-1.0.1/bin/dawn:14:in <top (required)>' from /Users/marinobonetti/.rvm/gems/ruby-2.0.0-p0@global/bin/dawn:23:inload'
from /Users/marinobonetti/.rvm/gems/ruby-2.0.0-p0@global/bin/dawn:23:in `

'

Refactor Dependency check

All version related checks must be moved in an adhoc class

CVE-2014-0036: rbovirt Gem for Ruby rest-client Missing SSL Certificate Validation MitM Spoofing Weakness

rbovirt Gem for Ruby contains a flaw related to certificate validation. The issue is due to the program failing to validate SSL certificates. This may allow an attacker with access to network traffic (e.g. MiTM, DNS cache poisoning) to spoof the SSL server via an arbitrary certificate that appears valid. Such an attack would allow for the interception of sensitive traffic, and potentially allow for the injection of content into the SSL stream.

class_eval matching

Hi,
I have many Spree projects where is very common to create model decorators via class_eval().
Looks like dawn matches all of them because contain the "eval" word:

08:05:52 [$] dawn: Solution: Please refere to the Ruby on Rails cheatsheet available from owasp.org to mitigate this vulnerability
08:05:52 [!] dawn: Evidence:
08:05:52 [!] dawn: [{:filename=>"./app/models/spree/shipment_decorator.rb", :matches=>[{:match=>"Spree::Shipment.class_eval do\n", :line=>0}]}, {:filename=>"./app/models/spree/shipping_method_decorator.rb", :matches=>[{:match=>"Spree::ShippingMethod.class_eval do\n", :line=>0}]}
.......

is this intended?

Vulnerable rails gem version found: 4.1.0

Please add support for 4.1.0. Getting several "Vulnerable rails gem version found: 4.1.0" warnings.

ruby 2.1.0 problem

with 2.1.0 inside .ruby-version i get this error, works with any older ruby.
Note that ruby versioning has changed and can not have patchlevel: https://www.ruby-lang.org/en/news/2013/12/21/semantic-versioning-after-2-1-0/

21:33:08 [*] dawn v1.0.0 is starting up
21:33:08 [$] dawn: scanning .
21:33:08 [$] dawn: rails v3.2.16 detected
21:33:08 [$] dawn: applying all security checks
/Users/legion/.rvm/gems/ruby-2.1.0@thefantree/gems/codesake-dawn-1.0.0/lib/codesake/dawn/kb/ruby_version_check.rb:80:in `is_vulnerable_patchlevel?': undefined method `split' for nil:NilClass (NoMethodError)
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/gems/codesake-dawn-1.0.0/lib/codesake/dawn/kb/ruby_version_check.rb:30:in `vuln?'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/gems/codesake-dawn-1.0.0/lib/codesake/dawn/engine.rb:261:in `block in apply_all'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/gems/codesake-dawn-1.0.0/lib/codesake/dawn/engine.rb:249:in `each'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/gems/codesake-dawn-1.0.0/lib/codesake/dawn/engine.rb:249:in `apply_all'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/gems/codesake-dawn-1.0.0/bin/dawn:149:in `<top (required)>'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/bin/dawn:23:in `load'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/bin/dawn:23:in `<main>'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/bin/ruby_executable_hooks:15:in `eval'
    from /Users/legion/.rvm/gems/ruby-2.1.0@thefantree/bin/ruby_executable_hooks:15:in `<main>'

Add "Owasp Ror Cheatsheet" example to README file.

Can you add this example to the README with details on how to fix it?
I am getting this on the first two projects I installed the gem in.
Maybe break the Owasp Ror Cheatsheet up into more specific vulnerabilities.
Finally fix the "refere" typo.

10:44:13 [*] dawn v1.0.0 is starting up
10:44:14 [$] dawn: scanning .
10:44:14 [$] dawn: rails v4.1.0.beta1 detected
10:44:14 [$] dawn: applying all security checks
10:44:14 [$] dawn: 142 security checks applied - 0 security checks skipped
10:44:14 [$] dawn: 1 vulnerabilities found
10:44:14 [$] dawn: Owasp Ror Cheatsheet failed
10:44:14 [$] dawn: Description: This Cheatsheet intends to provide quick basic Ruby on Rails security tips for developers. It complements, augments or emphasizes points brought up in the rails security guide from rails core.  The Rails framework abstracts developers from quite a bit of tedious work and provides the means to accomplish complex tasks quickly and with ease. New developers, those unfamiliar with the inner-workings of Rails, likely need a basic set of guidelines to secure fundamental aspects of their application. The intended purpose of this doc is to be that guide.
10:44:14 [$] dawn: Solution: Please refere to the Ruby on Rails cheatsheet available from owasp.org to mitigate this vulnerability
10:44:14 [!] dawn: Evidence:**
10:44:14 [!] dawn: [{:filename=>"./config/environments/production.rb",  :matches=>[{:match=>"  # Add `rack-cache` to your Gemfile before enabling this.\n", :line=>17}]}]
10:44:14 [!] dawn: []
10:44:14 [!] dawn: []
10:44:14 [!] dawn: []
10:44:14 [*] dawn is leaving

Thanks

Redis session management considered insecure?

hi I have a project that's using redis for the session_store, and I'm getting this notified by dawn:

11:15:16 [!] dawn: Owasp Ror CheatSheet: Session management check failed
11:15:16 [$] dawn: Description: By default, Ruby on Rails uses a Cookie based session store. What that means is that unless you change something, the session will not expire on the server. That means that some default applications may be vulnerable to replay attacks. It also means that sensitive information should never be put in the session.
11:15:16 [$] dawn: Solution: Use ActiveRecord or the ORM you love most to handle your code session_store. Add "Application.config.session_store :active_record_store" to your session_store.rb file.
11:15:16 [$] dawn: Evidence:
11:15:16 [$] dawn:  In your session_store.rb file you are not using ActiveRercord to store session data. This will let rails to use a cookie based session and it can expose your web application to a session replay attack.

I think I don't need to fix this (in my code), right?

If redis store is actually safe I could try to contribute a patch to dawn :)

Brakeman comparison

Hi Paolo,

I'm very excited to see this project and wish you the best of luck. Now when people say "Does Brakeman work with Sinatra?" I can just point them to you :)

There are a couple things in the comparison I wanted to point out:

• Brakeman does support JSON output (-f json)
• Brakeman does warn on unescaped output of database values, which could be considered stored XSS if you want
• Brakeman warns if an application does not use protect_from_forgery, but it doesn't warn about vulnerable forms (e.g. those not using view helpers)
• There are a couple other similar projects you might consider adding

TypeError

$ dawn test-project/
/Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/core.rb:146:in `exist?': no implicit conversion of Fixnum into String (TypeError)
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/lib/codesake/dawn/core.rb:146:in `read_conf'
    from /Users/justin/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/codesake-dawn-1.1.0/bin/dawn:61:in `<top (required)>'
    from /Users/justin/.rbenv/versions/2.1.1/bin/dawn:23:in `load'
    from /Users/justin/.rbenv/versions/2.1.1/bin/dawn:23:in `<main>'

Support for Lotus MVC framework

Support for http://lotusrb.org/

Add check for CVE-2014-0080, 81 and 82

There are 3 brand new vulns affecting rails. They must ne added

JRuby

Does this tool support JRuby?