How to get started with writing an exploit

The real kung-fu behind exploit development isn't actually about which language you choose to build it, it's about your precise understanding of how an input is processed by the application you're debugging, and how to gain control by manipulating it. That's right, the keyword is "debugging." Your binjitsu (reverse-engineering) is where the real kung-fu is. However, if your goal isn't just about popping a calculator, but actually want to weaponize, to maintain, and to provide use in the practical world, you need a development framework. And this is where Metasploit comes in. It's a framework that's free and open-source, actively contributed by researchers around the world. So when you write a Metasploit exploit, you don't have to worry about people not having the same libraries the exploit needs, or the wrong version, or not having enough payloads for different pentesting scenarios to choose from, etc. The idea is all you need to do is focus on building that exploit, and nothing more.

Plan your module

Unlike writing a proof-of-concept, when you write a Metasploit module you need to think about how users might use it in the real world. Stealth is usually an important element to think about. Can your exploit achieve code execution without dropping a file? Can the input look more random so it's more difficult to detect? How about obfuscation? Is it generating unnecessary traffic? Can it be more stable without crashing the system so much, etc, etc.

Also, try to be precise about exploitable requirements. Usually, a bug is specific to a range of versions, or even builds. If you can't automatically check that, you need to at least mention it in the description somewhere. Some of your exploit's techniques might also be application-specific. For example, you can take advantage of a specific behavior in the application to generate heap allocations the way you want, but maybe it's more noisy in the newer version so that gives you some stability issues. Does it need a 3rd-party component to work that may not even be installed by everyone? Even if it is, is the component revised often that could make your exploit less reliable?

Know that in the real world, your exploit can break or fail in a lot of different ways. You should try to find out and fix it during the development and testing phase before learning the hard way.

Ranking

As you can see, reliability is important to Metasploit, and we try to be more friendly about this for the users. I know what you're thinking: "Well, if they're using the exploit they should understand how it works, so they know what they're getting themselves into." In the perfect world, yes. Knowing how a vulnerability works or how an exploit works will only benefit the user, but you see, we don't live in the perfect world. If you're in the middle of a penetration test, it's very unlikely to always find the time to recreate the vulnerable environment, strip the exploit to the most basic form to debug what's going on, and then do testing. Chances are you have a tight schedule to break into a large network, so you need to use your time carefully. Because of this, it's important to at least have a good description and good references for the module. And of course, a ranking system that can be trusted.

The Metasploit Framework has seven different rankings to indicate how good an exploit is:

• ExcellentRanking - The exploit will never crash the service. This is the case for SQL Injection, CMD execution, RFI, LFI, etc. No typical memory corruption exploits should be given this ranking unless there are extraordinary circumstances (WMF Escape()).
• GreatRanking - The exploit has a default target AND either auto-detects the appropriate target or uses an application-specific return address AFTER a version check.
• GoodRanking - The exploit has a default target and it is the "common case" for this type of software (English, Windows XP for a desktop app, 2003 for server, etc).
• NormalRanking - The exploit is otherwise reliable, but depends on a specific version and can't (or doesn't) reliably autodetect.
• AverageRanking - The exploit is generally unreliable or difficult to exploit.
• LowRanking - The exploit is nearly impossible to exploit (or under 50%) for common platforms.
• ManualRanking - The exploit is unstable or difficult to exploit and is basically a DoS. This ranking is also used when the module has no use unless specifically configured by the user (e.g.: php_eval).

Template

References