postmodern_mod3

Title got a little cut off. Should mention the new recon engine (ronin-recon) and the new local Web UI (ronin-app).

"but the ecosystem is the biggest problem by promoting magic."

This argument isn't entirely true anymore. The Ruby ecosystem has mostly moved away from meta-programming, and embraced classical OOP. Rubyists now tend to avoid `method_missing` and `const_missing` when possible, and abandoned the craze of making everything a DSL. The most meta-programming that Rubyists still use on a regular basis is defining `self.included` on modules in order to inject other modules. Also, Rubyists have embraced API documentation, such as YARD, in order to document and communicate any "magic" that might exist or occur.

There is a significant anti-Ruby sentiment in the tech industry right now, especially in certain fields like InfoSec, that is being pushed by a very vocal subset of the community. Whenever they see Ruby come up, they will try pushing the meme that Ruby is dead/dying/irrelevant and cite TIOBE; despite Ruby developers continuing to release new libraries, frameworks, and tooling. Or they will claim no popular websites use Ruby; apparently GitHub, LinkedIn, and AirBnB are not popular enough? Or claim MetaSploit is the only security tool written in Ruby; off the top of my head I can think of BeFF, CeWL, Evil-WinRM, and Ronin. Or claim no company uses or supports Ruby; GitHub, Shopify, Stripe all use and support Ruby. Or they will derail any positive discussion about Ruby into some intractable debate about Static vs Dynamic Typing, GC, interpretive languages, etc; even though many of the arguments against Ruby can equally be applied to Python, and yet there's no similar criticism of Python. It's really annoying and inconsistent.

Even Haskell has exceptions. Even with Strong Typing and Functional Programming, things can go wrong, like network issues or your hard drive fills up.

Recently there was a news story about how a typo in a US military address (.mil) caused top secret emails to accidentally be sent to a similar Mali address (.ml). This blog post shows how to find all valid TLD typos using a little bit of Ruby and the ronin-support library.

There is not a Python equivalent to Ronin as a whole, to my knowledge. There are however Python libraries that provide some of the features of Ronin. For example, pwntools can be used for packing binary data and generating shellcode for exploits, however it is more of a library instead of an exploit framework (frameworks run 3rd party code and manage the control flow) and has a fairly minimal API when compared to Ronin's many libraries. There are also dozens of bespoke Python exploit "frameworks" on GitHub, but none of them that I've seen support installing 3rd party repositories of exploits. The scope of Ronin is much bigger than just an exploit framework or vulnerability scanner. YMMV

It might still be. The original metasploit developers had a habit of vendoring all of their dependencies to create a mono-repo that "just worked" (tm), even after Bundler was created, which beefed up their SLoC count. Plus there's lots of miscellaneous supporting code that was added for various past exploits. However, while some see "largest Ruby codebase" as bragging rights, wise Software Engineers will see that as a liability to be avoided.

One minor note:

Crystal achieved basic Windows support as of 2021/11/18. https://github.com/crystal-lang/crystal/issues/5430

As of Crystal 1.5.0, Windows support is basically there. https://crystal-lang.org/2022/07/06/1.5.0-released.html

However, Crystal aims to support the lowest common denominator between POSIX and Windows, so not all of the Windows standard APIs are supported out-of-the-box. Other Windows specific libraries will need to be created specifically for Windows users/developers.

How so? Go does not prevent you from writing a monolith. Furthermore, Go does not actually require that you check the err return value of functions.

You can write "complected" monoliths in any language. You can also write SOAs in any language. If you need native performance, Crystal is a better option, as it provides much of the same syntax, semantics, and stdlib as Ruby, but with Strong Typing. Go is a bit too simple.

- tooling: there is a VS Code plugin for Crystal (https://marketplace.visualstudio.com/items?itemName=crystal-...). There is also syntax highlighting for most popular editors, if you prefer a text-editor to a fully-loaded IDE.

- no multi threading: Crystal has lightweight green threads for lightweight concurrency. However, Crystal does have experimental native multi-threading guarded by a compiler flag. The ultimate goal is to have multiple native threads each running multiple green threads for maximum concurrency. Currently, with just green threads, Crystal is competitive with Go or Rust wrt throughput. You can checkout benchmarks on crystal-lang.org or search Google for "Go vs Crystal benchmark" blog posts.

- no real support: Manas Tech is the corporate sponsor for Crystal (https://manas.tech/projects/crystal/) and employs many of the core developers; the project also accepts donations on Open Collective. There is a crystal-lang IRC channel, Gitter, Discord, Discourse forum, sub-reddit, and even a "Matrix" channel where developers frequently ask and answer questions.

- still immature: a 1.0.0 version is a significant milestone for any project. Companies are already running Crystal in production, which was discussed during the Raw Crystal 2020 virtual-conference (videos on YouTube).

- API breakage: Crystal 1.0.0 was released to stabilize the API (SemVer)

If you are looking for a minimal alternative to RVM, you should also checkout chruby (https://github.com/postmodern/chruby#readme). It's only ~90 LoC, supports bash/zsh, optionally supports auto-switching of Rubies, and doesn't install obtrusive bin-stubs.

Took a while to write a new blog post. Still, CVE-2013-0333 relies on the same YAML deserialization technique as CVE-2013-0156, so all the previous information is still relevant.

and write-up for those who are interested in the technical details: http://ronin-ruby.github.com/blog/2013/01/28/new-rails-poc.h...

Not unless nginx/apache routes the request directly to public/. There will definitely be more code-paths to YAML.load, but so far ActionDispatch::Http::Parameters has been the entry point.

@benmmurphy seems to be the only one who knows how to get RCE via Syck (1.8.x YAML parser). https://twitter.com/benmmurphy/status/296025302986014720

Bonus points if you exfiltrate config/initializers/secret_token.rb.

Maybe graph the rate of vulnerabilities discovered vs. LoC/files added?

It's safer to only use vulnerability counts as a metric for how interesting software is to security researchers.

YAML does not allow execution of arbitrary Ruby code. Some YAML types allow specifying a custom class, which the Psych YAML parser (default in Ruby 1.9) will call the initialize or []= methods. If you can find a class that eventually evals() input passed to initialize or []=, then you win. http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html

What if I told you that there is a new web framework similar to Rails, called Fortran on Fails. It has zero vulnerabilities reported against it, ergo it must be 100% secure.

> Similar projects with a similar user base, like Django, don't have vulnerabilities of this severity with this frequency.

Not all Django vulnerabilities have been discovered or reported yet. Just because no one has found or reported a vulnerability, doesn't mean that it it doesn't exist.

Here you go: https://gist.github.com/4660248

Vulnerability counts are misleading metric for security. They do not include the vulnerabilities which have not yet been discovered or created.

Checkout the lengthy write-up for the original vulnerability. http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html

Proof-of-Concept exploit: https://gist.github.com/4660248

Charlie Somerville has already released his PoC. http://charlie.bz/blog/rails-3.2.10-remote-code-execution

You should release your PoC(s) as well.

Proof-of-Concept Exploits for CVE-2013-0156 and CVE-2013-0155 are here:

rails_rce.rb (https://gist.github.com/4499206)

rails_sqli.rb (https://gist.github.com/4499032)

rails_dos.rb (https://gist.github.com/4499017)

rails_jsonq.rb (https://gist.github.com/4499030)