Right-Click Actions Based On Software Versions

[xpelican]

Hello, and first of all a big thank you for developing Sparta. I love this tool, think the idea is spot-on and you have a great base here to make the ultimate 'semi-automated" pentesting tool, and while I'm learning Python, I figured this would be the perfect project to hopefully contribute to so I can give back a little to the community while I learn.

One enhancement I think would be of great benefit to Sparta is to make certain actions available based on detected software versions. Obviously, I don't expect anyone to go through every version of every software available and create actions for them, my question here is more about how to make it happen - and add functionality bit by bit once we know the best way to do it.

For instance, this exploit works for OpenSSH versions below 7.7. The idea is, if Sparta detects an SSH service name to be "OpenSSH", and its version to be below "7.7", we could add an action to let the user choose running this exploit against it.

Currently, I understand how to add custom actions by modifying the sparta.conf file, but it seems that there, it's only possible to add actions based on service types and nothing more specific. So for instance it allows you to assign actions for "ssh", but doesn't let you specify "openssh", or "openssh < 7.7", and so on.

Have you considered this before? If you have, do you have a recommended way of going about doing this?

One way I thought of was to write an entirely separate program that sparta can call on upon detecting services, that would run separate nmap scans to get the version number again, then do further actions based on that information to perform the kind of functions I mentioned. However I'd much rather implement the functionality into Sparta directly, if possible.

Any ideas? Thanks in advance!

[st3r30byt3]

Hi. First of all, sorry for the huge delay in responding.

We have thought about before and feel it's a great idea. It would entail significant work since it would effectively turns SPARTA more into a vulnerability scanner rather than just focusing on scanning and enumeration. This is not a bad thing, just difficult to pull off for 2 people with full time jobs and little time. :)

In fact, one idea was to integrate with Nessus too so that you could import Nessus and SPARTA could do the "manual" verifications for some of the issues identified. This is all possible but it would require significant changes to the GUI and some refactoring to make the code more modular and easier to change / contribute to.

Since you can customise everything, we cannot be sure that the nmap port scan will include -sV (for versions) but if it is used, then the information will be in the database and thus can be queried.

Running tools/exploits based on versions would be great. We would fully support the idea of implementing this into SPARTA.

I'd be happy to discuss this further. Hit me up on NetSec mattermost if you want. Same nickname.

Thanks!

[xpelican]

Hello, I'll apologize right back for my own delay :) I was busy with some IRL stuff, still am, but hopefully I'll have some more free time in two weeks.

I'll definitely hit you up, for now I just wanted to say how happy I am to hear you're open to this idea, and let you know I will be chasing this. I believe in Sparta big time, and with your guidance regarding how the code works, I'm hopeful we can make this happen. It's gonna be great. I'm thankful you guys didn't abandon this project all these years.

For others reading this, don't worry - I'll try to document the work I do as much as possible for collaborations. Surely I'll need all the help we can get.

Thanks again, and talk to you soon on NetSec.

[xpelican]

I've added you on NetSec, but will also be logging my progress on this thread so others can keep track, and hopefully if they're interested, help me out. (I sure do need it, I'm a noob with Python remember)

So first off, just to further clarify my goal here a little:

The goal is to build SPARTA up into an efficient semi-automated pentesting suite, to save the user time from writing commands, by utilizing input/output redirection. I'm not trying to turn it into a fully-automated scanner, but more into something that will parse output from commands and recommend other relevant commands based on what the previous command's output was. Use it more as a reminder of pentesting flow, and as a shortcut for carrying variables over from command to command to save testers time in typing out commands and placing variables like IPs into them - which is already what Sparta is for, we're just talking about extending that functionality here.

So to go with the previous example, say if you found an OpenSSH service below version 7.7, you have the right-click option reminded to you that you could try the exploit for that. If you do decide to try that, you get relevant commands readily written, saving you from having to remember these all the time. It's so you can feed output from your Nmap directly into your input with following commands. When you have Sparta open up a terminal to run this command, the command will be written down, but not executed, so you can check it out yourself and then run it as you like, making necessary edits if needed before running. As per usual, some commands will always be auto-executed upon detection of certain services, a functionality Sparta already posesses.

Imagine something like that - if we built a GUI-based application that could keep pentesting activities all in one place as a session and organized like that, who wouldn't use it? Sparta has the right stuff to make this happen -it's really a work of genius IMO. Right now, it's already pretty good; lets you parse & combine output from nmap scans, filters out the relevant info, while (with a few tweaks) letting you view the whole scan too if you need to, lets you run some commands based on the info found off these scans - It just needs a little extra push to make it into something truly amazing, a constantly-developing platform more akin to Metasploit.

If we can develop a modular infrastructure that lets users add new functionality in a "if encountered output X, recommend command Y" , we can steadily grow this into something fantastic. Any time new scripts, vulnerabilities or methodologies get discovered, someone could go in and write some rules to add that functionality into Sparta's arsenal.

Sorry for the wall of text, but it was an optional read so I went all out. Starting with the next post here I'll start logging my findings, and bit by bit move towards this goal hopefully. Once again, I greatly appreciate any help from others, as I really don't know what I'm doing :)

[xpelican]

So to start with, I'm mapping out the program flow to make things less intimidating what with all the files and functions that make up Sparta.

Under the root directory, there are some dirs you can ignore right off the bat:

images
scripts
wordlists

These are pretty straightforward, they only include external tools / resources that can be easily added to. The rest is really what Sparta runs under the hood. So let's look at some of them:

---

app/

auxiliary.py
This is a big one, and one that's imported by almost all others. It's mostly a collection of modules to be called upon by other modules. Things like checking for SSL on web services, clearing screens, setting table view properties. It also includes some sanitization / validation functions, such as making sure given strings are all lowercase, do not include whitespaces, and so on.

hostmodels.py / processmodels.py / scriptmodels.py / servicemodels.py
These seem to display information about hosts, processes, scripts and services. They talk to the QtCore and are responsible for sorting, how tables etc are arranged

logic.py
This is another big one, and is responsible for many things:

• Creation & deletion of temporary working files for each session.
• Talks to the Database and runs checks for preconditions that have to exist for later functions to be considered eligible, pulls / overwrites information from/to the DB,
• Toggles the display status of running / stopped / killed processes under the processes window.
• Has some functions about nmap importing operations that I haven't figured out yet

settings.py

• Reads & Writes application settings in sparta.conf
• Creates default sparta.conf file if it's missing
• Defines functions for importing settings from config file

---

controller/
controller.py
As the documentation put it, "the controller interfaces between the GUI and the logic" and does a LOT of things, but is more of a middleman - almost everything it does is relayed to some other module found in other files - controller just orchestrates how these modules from various areas like GUI, logic etc. work together:

• Initialization operations that happen when you launch the program / create a new session
• Sets up progaram objects that can be called to incur operations
• Imports settings from the sparta.conf file
• Creating / loading / saving projects
• Adding new hosts to scope
• Context menus and relevant actions for hosts & ports --> this is going to be relevant to our purposes
• Updating left, right & bottom panels with information pulled from DB
• Creating / killing tracking processes, displaying them, tracking PIDs --> Relevant
• Parsing nmap output for actionable ports
• Probably more that I missed

---

parsers/

Responsible for parsing nmap XML files, and where most of the magic happens. Originally written by "yunshu" and modified by the Sparta authors to integrate with Sparta, these also introduce a very badly needed aggregation function for nmap scans - FYI the only other "accepted" way of aggregating nmap scans like this is to use Zenmap, which is a pain and not exactly programmatically usable.

From what I understand, the functions that parse the nmap XMLs located in the parsers/Service.py Already have the capability to get the "product" & "version" information and store it in the product and version variables.

---

ui/
Obviously, UI stuff. Will get to these later.