Security Boulevard

Disclaimer 1: This blog post is on a new and still under development toolset in John the Ripper. Results depict the state of the toolset as-is and may not reflect changes made as the toolset evolves.

Disclaimer 2: I really need to run some actual tests and password cracking sessions using this attack, but I'm splitting that analysis up into a separate blog post. Basically I have enough forgotten drafts sitting in my blogger account that I didn't want to add another one by trying to "finish" this post before hitting publish. So stay tuned for new posts if you want to see how effective this attack really is.

Introduction:

It's been about 15 years since I last wrote about John the Ripper's Markov based Incremental mode attacks [Link] [Link 2]. 15 years is a long time! A lot of work has been done applying Markov based attacks to password cracking sessions, ranging from the OMEN approach to Neural Network based password crackers. That's why I was so excited to see a new proof of concept (PoC) enhancement of JtR's Incremental mode that was just published by JtR's original creator SolarDesigner.

The name of this enhancement is likely going to change over time. Originally it was described in an e-mail thread as "Markov phrases". That's not a bad descriptor, but doesn't really get to the heart of the current PoC. Therefore in this blog post I'm going to call this attack after the new script SolarDesigner released (tokenize.pl) and just refer to it as a "Tokenizer Attack". I think this  gets closer to conveying how the underlying enhancement differs from the original Incremental attack which the tokenizer attack is built on.

The next question of course is "What does this new enhancement do?" To take a step back, what make Markov attacks "Markovian" is they represent the conditional probability of tokens appearing together. For example, if you see the letter 'q' in an English word, the next letter is very likely to be a 'u'. How far you look ahead to apply this probability is measured by the "order" of the Markov chain. So the above example would describe a first-order Markov process. If we extended this and said that given a 'q' and then a 'u', the next most likely character would be a 'e', now we are talking about a second-order Markov process. Where this starts to play out compared to a first-order process is that 'qu' -> 'e' with a high probability but the highest probability next character for the substring 'tu' might be 'r'.  Therefore the highest probable letter following a 'u' might change based on the letter before the 'u' Basically the order represents the "memory" of the Markov chain. It can remember X previous tokens of the string it is generating.

The reason I bring this up is that JtR's Incremental mode works with trigraphs which "roughly" can be represented by second-order Markov processes. I use "roughly" since like most Markov implementations, Incremental mode contains nuances and differences from the abstract/academic definition of Markov based processes. Those nuances aren't super important for this current investigation/blog-post so I'm going to gloss over them for now.

One interesting area of research is implementing "variable order" Markov processes. Aka some particularly likely substrings might be created by a third/fourth/fifth/sixth order Markov process, but other less likely transitions might be implemented in a lower order (first/second) Markov process. As an example of that, if you were using a second order Markov chain the initial letters 'or' might generate a next letter of 'k' with a high probability, but if you take a larger step back and see the earlier letters are 'passwor' then the next letter will almost certainly be a 'd' instead. Based on this, it's tempting to "apply the largest memory possible" to your Markov processes. The limiting factor though is if you extend things out too much you run into overtraining issues, not being able to generate substrings not seen in the training data, and general implementation issues (the size of your Markov grammar explodes). So being able to dynamically switch how much memory/state you are keeping track of can be very helpful when generating password guesses. While more research is needed, this is my current theory why the CMU Neural Network Markov based attacks [Link] outperform other Markov implementations. I strongly suspect the Neural Network makes use of a variable order Markov process when generating guesses.

That's a lot of words/background to say that JtR's Tokenizer attack can be thought of as a way to incorporate variable length Markov orders into JtR's current Incremental mode attack. It does this by identifying certain likely substrings (aka "tokens") and then replacing them in the training set with a "placeholder" character. So for example the likely substring "love" might be replaced with the hex value of x15. This would normally be an unprintable character in ASCII (NAK), but it allows JtR's normal Incremental mode charset to be trained using these replacements. The resulting Incremental charset will have probability information for generating the character "x15" (NAK) as part of a password guess. Now (NAK) isn't actually part of a real password (unless the user did something really cool). This means when running a password cracking session, you'll need to then apply an External mode to translate these guesses back into the full ASCII text outputs. For example the guess "I(x15)MyWife" would be translated by the External mode into "IloveMyWife" which can then be fed into a real password cracking session.

While I can certainly dive more into the details of the tokenizer attack, this intro is already too long. So lets instead look at how to run it!

References:

• Post by SolarDesigner announcing the release of the tokenize.pl script: [Link]
• John the Ripper Bleeding Edge: [Link]

Configuring The Attack: 1) Update JtR Bleeding Edge:

• The new code, (including tokenize.pl) is available in the newest version of JtR Bleeding Jumbo.
• To make use of it, clone the gihub repository and make sure you are on the "bleeding-jumbo" branch which is the default. [Link]
• (Optional) Rebuild JtR from source.
• This is optional since the new code "should" work with older versions of JtR. But you might want to rebuild JtR to be on the safe side.

2) Create a Custom Incremental .CHR File:

• Run the new tokenize.pl script on your training passwords. 

• Notes:
• Save the full output of this tool, as you'll need to run the Sed command to parse/tokenize your trianing set, and you'll need to paste the External "Untokenize" script to your john.conf file. Both of these steps will be described later

• Example:
• ./tokenize.pl TRAINING_PASSWORDS.txt

Example output when training on one million passwords from RockYou. You may note that the results are slightly different than when SolarDesigner trained on the full RockYou list:

• Re-run the sed script on the training set to generate a custom training file.

• Example:
• cat TRAINING_PASSWORDS.txt | sed {{REALLY LONG SED COMMAND}} > new_training.txt
• Closer to Real Example:
• cat TRAINING_PASSWORDS.txt | sed 's/1234/\x10/; s/love/\x15/; s/2345/\x1b/; s/3456/\x93/; s/ilov/\xe5/; s/123/\x6/; s/234/\x89/; s/ove/\x8c/; s/lov/\x90/; s/345/\x96/; s/456/\xa4/; s/and/\xb2/; s/mar/\xc1/; s/ell/\xd9/; s/199/\xdf/; s/ang/\xe0/; s/200/\xe7/; s/ter/\xe9/; s/198/\xee/; s/man/\xf4/; s/ari/\xfb/; s/an/\x1/; s/er/\x2/; s/12/\x3/; s/ar/\x4/; s/in/\x5/; s/23/\x7/; s/ma/\x8/; s/on/\x9/; s/el/\xb/; s/lo/\xc/; s/ri/\xe/; s/le/\xf/; s/al/\x11/; s/la/\x12/; s/li/\x13/; s/en/\x14/; s/ra/\x16/; s/es/\x17/; s/re/\x18/; s/19/\x19/; s/il/\x1a/; s/na/\x1c/; s/ha/\x1d/; s/am/\x1e/; s/ie/\x1f/; s/11/\x7f/; s/ch/\x80/; s/10/\x81/; s/00/\x82/; s/te/\x83/; s/ve/\x84/; s/as/\x85/; s/ne/\x86/; s/ll/\x87/; s/or/\x88/; s/ta/\x8a/; s/st/\x8b/; s/is/\x8d/; s/01/\x8e/; s/ro/\x8f/; s/20/\x91/; s/ni/\x92/; s/at/\x94/; s/34/\x95/; s/45/\x97/; s/it/\x98/; s/08/\x99/; s/mi/\x9a/; s/ca/\x9b/; s/ic/\x9c/; s/da/\x9d/; s/he/\x9e/; s/21/\x9f/; s/nd/\xa0/; s/me/\xa1/; s/ng/\xa2/; s/mo/\xa3/; s/ba/\xa5/; s/sa/\xa6/; s/ti/\xa7/; s/56/\xa8/; s/sh/\xa9/; s/ea/\xaa/; s/ia/\xab/; s/ol/\xac/; s/se/\xad/; s/ov/\xae/; s/be/\xaf/; s/de/\xb0/; s/co/\xb1/; s/ss/\xb3/; s/99/\xb4/; s/to/\xb5/; s/22/\xb6/; s/oo/\xb7/; s/02/\xb8/; s/ke/\xb9/; s/ee/\xba/; s/ho/\xbb/; s/ey/\xbc/; s/ck/\xbd/; s/ab/\xbe/; s/et/\xbf/; s/ad/\xc0/; s/13/\xc2/; s/07/\xc3/; s/pa/\xc4/; s/09/\xc5/; s/06/\xc6/; s/ki/\xc7/; s/98/\xc8/; s/hi/\xc9/; s/th/\xca/; s/05/\xcb/; s/14/\xcc/; s/25/\xcd/; s/ay/\xce/; s/ce/\xcf/; s/89/\xd0/; s/ac/\xd1/; s/os/\xd2/; s/ge/\xd3/; s/03/\xd4/; s/ka/\xd5/; s/ja/\xd6/; s/bo/\xd7/; s/do/\xd8/; s/04/\xda/; s/e1/\xdb/; s/nn/\xdc/; s/em/\xdd/; s/31/\xde/; s/15/\xe1/; s/18/\xe2/; s/ir/\xe3/; s/91/\xe4/; s/om/\xe6/; s/90/\xe8/; s/30/\xea/; s/nt/\xeb/; s/di/\xec/; s/si/\xed/; s/ou/\xef/; s/un/\xf0/; s/24/\xf1/; s/us/\xf2/; s/88/\xf3/; s/ai/\xf5/; s/78/\xf6/; s/y1/\xf7/; s/so/\xf8/; s/pe/\xf9/; s/ot/\xfa/; s/ga/\xfc/; s/ly/\xfd/; s/16/\xfe/; s/ed/\xff/'  > new_training.txt

• Convert the new_training.txt file to a John the Ripper potfile format

• Reason: Currently JtR's Incremental mode character sets can only be trained from cracked passwords in a potfile. You can't just give it a set of raw plaintext passwords.
• Enhancement: You can totally combine this step with the previous one by piping the output of the original Sed command into this second one. I'm keeping these steps separate for now since my recommendation is going to be to update the tokenizer.pl script to incorporate this step into the Sed command it generates. Basically I'm hopeful I can just delete this step in the future
• Example: 
• cat new_training.txt | sed 's/^/:/' > training.pot

• Run the JtR Incremental mode training program on the new training file.

• Flags:
• --make-charset= : the filename here is the name of the Incremental character file you want to create. Warning: It will overwrite existing files!
• --pot- : In this example, this is the potfile to read in training passwords from. In "normal' usage this is the file where your cracked passwords will be stored.

• Example:
• john --make-charset=tokenize.chr --pot=training.pot

Example output of running the training session on one million training passwords:

3) Update John the Ripper's Config File

• Add the following to John the Ripper's "john.conf" config file
• New Values:
• [Incremental:Tokenize]
• File = $JOHN/tokenize.chr
• Notes:
• If you save your Incremental character file as "custom.chr" you can use the default custom Incremental mode that is already including in John.conf instead
• Feel free to update the name of this attack (in this example it's "Tokenize") to whatever identifier you want to use.
• Add the "Untokenize External Mode" config generated when you ran tokenize.pl to your john.conf
• Notes:
• I don't think there are many restrictions where you paste this in, as long as it is not in the middle of another configuration item or at the very end.

Below is a screenshot of me running the tokenize.pl script again, with the External mode section highlighted.

Next is a screenshot of me pasting the resulting External mode into my John the Ripper config file.

Running The Attack:

To run the attack, you can use the following commands in addition to your normal attack commands:

• Arguments:

• --incremental=Tokenize : You can set this to be whatever name you specified in your john.conf file to use the .chr file you generated with tokenize.pl

• --external=untokenize : This calls the external mode to convert the tokenized output of the Incremental mode attack into a normal password guess

• Example:

• ./john --incremental=tokenize --external=untokenize --stdout

Here is a screenshot comparing the first 25(ish) guesses generated by both the new Tokenize attack and the default JtR Incremental attack. It's interesting to note that the default Incremental attack seems to start off stronger with more likely passwords. What's important though is longer password cracking sessions, which I'll investigate in future tests.

Conclusion: The next step will be to run some actual tests. The experiments SolarDesigner ran seemed to imply a significant improvement when running the tokenize attack over the first two billion guesses compared to a standard Incremental attack. This assumes you run these attacks after cracking the "common" passwords first using a more traditional wordlist attack. I'm having to restrain myself from speculating about the results of future tests that I'm planning on running (better to just run them), but hopefully this blog post is helpful for anyone else who also wants to experiment with this new attack. It's a cool attack and a neat approach so I'm looking forward to seeing how it evolves going forward.

The post Running JtR’s Tokenizer Attack appeared first on Security Boulevard.

NSFOCUS Showcases Two Groundbreaking Topics at SAS 2024: An In-Depth Analysis of the DarkCasino APT Group and the Evolution of New Botnets. SANTA CLARA, Calif., October 30, 2024 – The 17th Security Analyst Summit (SAS), a premier global event focused on cybersecurity, recently concluded in Bali, Indonesia, where NSFOCUS was invited to participate. As the […]

The post NSFOCUS Showcases Two Groundbreaking Topics at SAS 2024 appeared first on NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks..

The post NSFOCUS Showcases Two Groundbreaking Topics at SAS 2024 appeared first on Security Boulevard.

The post How Security Automation Platforms Streamline SOC Operations appeared first on AI-enhanced Security Automation.

The post How Security Automation Platforms Streamline SOC Operations appeared first on Security Boulevard.

If you process credit card payments, you need to prioritize security. One way to guarantee this safety is by complying with Payment Card Industry (PCI) Data Security Standards (DSS).

The post PCI DSS Self-Assessment Questionnaires: Choosing the Right Type appeared first on Security Boulevard.

If your business processes credit card transactions, it needs to meet the Payment Card Industry (PCI) Data Security Standards (DSS).

The post PCI DSS Compliance Levels and Requirements: A Complete Guide appeared first on Security Boulevard.

Although not a new concept, Operational Relay Box (ORB) networks—often referred to as "covert," "mesh," or "obfuscated" networks—are...

The post An Introduction to Operational Relay Box (ORB) Networks – Unpatched, Forgotten, and Obscured appeared first on Security Boulevard.

Modern apps require hundreds of secrets to function (API keys, cloud credentials, etc.). However, poor management of these secrets can expose sensitive information publicly or to malicious actors.

The post What Is Secrets Management? Best Practices and Challenges appeared first on Security Boulevard.

4 min read The new WIF support capability enables access without having to manage secrets.

The post Aembit Introduces Google Workload Identity Federation Support appeared first on Aembit.

The post Aembit Introduces Google Workload Identity Federation Support appeared first on Security Boulevard.

Handling large volumes of sensitive data in testing environments is challenging. You need to protect customer information, financial records, and other confidential data without compromising security or violating regulations. At the same time, you have to keep data relationships intact and make sure testing accurately reflects real-world scenarios. The risks multiply when data moves between […]

The post Test Data Management Best Practices: Handling Sensitive Data Across Multiple Databases first appeared on Accutive Security.

The post Test Data Management Best Practices: Handling Sensitive Data Across Multiple Databases appeared first on Security Boulevard.

Authors/Presenters:Chloé Messdaghi, Kasimir Shulz

Our sincere appreciation to DEF CON, and the Presenters/Authors for publishing their timely DEF CON 32 erudite content. Originating from the conference’s events located at the Las Vegas Convention Center; and via the organizations YouTube channel.

Permalink

The post DEF CON 32 – AppSec Village – Got 99 Problems But Prompt Injection Ain’t Watermelon appeared first on Security Boulevard.

via the inimitable Daniel Stori at Turnoff.US!

Permalink

The post Daniel Stori’s Turnoff.US: ‘Security Engineer Interview’ appeared first on Security Boulevard.

In the wake of Cisco’s recent data breach involving exposed API tokens - amongst other sensitive information -  the cybersecurity community is reminded once again of the significant risks associated with unsecured APIs. Though Cisco has asserted that the damage was limited to a public-facing environment, such breaches demand a more cautious evaluation. Exposing sensitive information like API tokens, credentials, and even source code can have broader security implications than initially apparent. These compromises, even in ostensibly low-risk environments, can act as gateways for attackers to launch more sophisticated intrusions.

Similarly, Deloitte experienced a breach perpetrated by the same actor, issuing reassuring statements about the extent of the impact. However, both cases illustrate a critical truth: even if the compromised systems are "public-facing," the exposure of sensitive materials creates dangerous opportunities for attackers.

Why Even Minor Breaches Are Major Threats

At first glance, it may seem that breaches involving public-facing environments aren’t as severe as those involving highly sensitive internal systems. However, the real danger lies in what attackers can do with the seemingly minor details uncovered in these intrusions. In the case of the Cisco breach, the exposed API tokens offer more than just access to the breached system itself—they can serve as stepping stones to deeper, more sensitive areas of a network.

Here’s why this is so concerning:

• Exposed Source Code: When source code is exposed, attackers can scrutinize it for security vulnerabilities. These vulnerabilities can then be leveraged in more targeted attacks on other systems, applications, or even other organizations using similar codebases.
• Hardcoded Credentials and API Tokens: These are especially dangerous as they provide attackers direct access to sensitive resources and data. With valid tokens, hackers can bypass traditional security barriers and authenticate as legitimate users, allowing them to navigate undetected in systems they weren’t meant to access.
• Seemingly Harmless Data: Information like Jira tickets or internal documents may appear insignificant, but they can offer valuable intelligence. Attackers can use this information to build more effective phishing campaigns or gain insights into how an organization operates, helping them tailor attacks for higher success rates.

Pivotal Points for Attackers

One of the main problems with breaches like Cisco’s is that they create openings for attackers to escalate their attacks. What starts as a minor exposure can quickly lead to a full-scale data breach if attackers use the information they’ve accessed to exploit vulnerabilities elsewhere.

This is why the Cisco incident—and others like it—underscore the urgent need for strong API security measures, even in environments considered to be less critical or public-facing. Attackers thrive on exploiting seemingly minor oversights, and by the time an organization realizes the full impact of the breach, the damage can be severe.

Why Exposed API Tokens Are So Dangerous

In the case of API tokens, the security implications are especially grave. API tokens grant authorized access to systems and services, but when exposed, they provide attackers with the same level of access. Whether the system is public-facing or not, these tokens can allow unauthorized users to retrieve sensitive data, execute unauthorized transactions, or even manipulate systems. Attackers can pivot from these compromised environments to more sensitive ones, potentially gaining access to mission-critical assets.

Common Ways Sensitive Data Gets Exposed

One of the critical questions raised by incidents like the Cisco breach is: How do sensitive pieces of information like source code, credentials, and API tokens end up on public-facing sites? Some common factors include:

• Misconfigurations: Inadequate access control settings during deployment or changes in system architecture can lead to the exposure of sensitive information that should be kept private.
• Human Error: Simple mistakes, like hardcoding credentials in code or accidentally uploading sensitive files to public repositories, can leave data exposed.
• Inadequate Security Testing: Without thorough testing before deploying systems, organizations may fail to catch vulnerabilities or misconfigurations that leave data exposed.
• Third-party Services: Integrations with third-party platforms or services can sometimes unintentionally expose data if those services are compromised or not properly secured.

Mitigating API Security Risks Requires a Multi-Layered Approach

The key lesson from breaches like these is that securing APIs must be a top priority for all organizations. Here are some ways to reduce the risk:

• Enforce Strict Access Controls: Ensure that APIs are only accessible to authenticated and authorized users. Use robust authentication mechanisms like OAuth or API gateways with strict access policies.
• Promote Secure Coding Practices: Secure coding practices can prevent developers from hardcoding credentials or leaving other vulnerabilities in the codebase.
• Security Testing and Posture Governance: Conduct thorough security testing of your APIs before deployment, and establish posture governance standards to monitor and enforce security controls.
• Secrets Management: Implement secure secrets management solutions that allow API keys, tokens, and credentials to be stored and accessed securely, reducing the likelihood of exposure.
• Continuous Monitoring: Use continuous monitoring and threat detection tools to identify any unauthorized access or suspicious behavior in real-time. This ensures that threats can be addressed before they escalate into full-blown breaches.
• Regular Security Assessments: Organizations should routinely assess their security posture through audits, vulnerability scans, and penetration tests to identify and address potential gaps.

Proactive API Security

The Cisco breach is a stark reminder that even seemingly insignificant vulnerabilities can be leveraged for much larger attacks. Public-facing systems must be treated with the same level of security as internal environments, especially when they house sensitive information like API tokens or credentials. Organizations need to take a proactive approach to API security, ensuring that all APIs, regardless of their exposure level, are adequately protected.

By implementing strong authentication, maintaining a comprehensive API inventory, securing secrets, and continuously monitoring for threats, organizations can safeguard their systems against breaches like the one experienced by Cisco. Ultimately, taking a holistic and forward-looking approach to API security is critical to protecting an organization's most valuable assets.

Salt Security delivers comprehensive API protection, helping businesses identify vulnerabilities, prevent attacks, and secure sensitive data. Salt’s platform uses AI-infused behavioral analysis to automatically detect and block API threats in real time - safeguarding against data leakage, fraud and abuse.

Salt Security empowers organizations to confidently secure their APIs, reduce their attack surface, ensure proper API posture governance and mitigate risks -  even in complex, modern environments. Learn how today.

The post Lessons from the Cisco Data Breach—The Importance of Comprehensive API Security appeared first on Security Boulevard.

Dimon’s dollars (not yours): No, Chase Bank isn’t going to let you cash bad checks. It’s fraud—no matter what X and TikTok tell you.

The post TikTok ‘Infinite Money Glitch’ — Idiots Chased by JPMorgan appeared first on Security Boulevard.

Authors/Presenters:Cassie Crossley

Our sincere appreciation to DEF CON, and the Presenters/Authors for publishing their timely DEF CON 32 erudite content. Originating from the conference’s events located at the Las Vegas Convention Center; and via the organizations YouTube channel.

Permalink

The post DEF CON 32 – AppSec Village – The Missing Link – How We Collect And Leverage SBOMs appeared first on Security Boulevard.

Starlink encountered a high-profile outage in April that caused service to go down for several hours. The reason was an expired digital certificate. Digital certificates have emerged as the currency of digital trust in the hyper-connected world of today. These electronic credentials enable devices to recognize, trust and interoperate with each other. The certificates keep..

The post DigiCert – It’s a Matter of Trust appeared first on Security Boulevard.

Securing IT infrastructure is a continual journey for every security team. A resilient infrastructure enables organizations to not only defend against modern cyber threats but also to quickly recover from attacks or system failures. Building and maintaining such an infrastructure is an iterative and predictable process that relies on solid foundations in asset management, change management, integrity baselining, system hardening, and effective change detection and rollback capabilities. Here's a step-by-step guide to help you chart a secure and resilient IT infrastructure strategy.

The post How to Achieve a Secure and Resilient IT Infrastructure in 6 Steps appeared first on Security Boulevard.

Announcing an exclusive partnership between Mend.io and HeroDevs to provide support for deprecated packages.

The post Mend.io & HeroDevs Partnership: Eliminate Risks in Deprecated Package appeared first on Security Boulevard.

The digital certificate lifecycle is undergoing significant changes, with a push towards shorter validity periods for SSL/TLS certificates. Currently, the lifespan of certificates is about 398 days, but companies like Google and Apple are advocating for much shorter terms, with Apple proposing to reduce lifespans to just 45 days by 2027. This shift aims to enhance security by limiting the time a compromised key can be exploited, but it poses challenges for IT teams accustomed to longer renewal periods. Organizations must prepare for this transition by adopting automated certificate management solutions to manage the increased administrative burden effectively.

The post Preparing for the future: Apple’s 45-Day certificate lifespan proposal appeared first on Security Boulevard.

Leading information and communication technology provider is now offering an AI/ML-powered threat detection and response platform and services across Italy, Spain and DACH regions. Milan, Italy and Westford, MA, USA – Seceon, the pioneer of the first cybersecurity platform that augments and automates security operations services with an AI/ ML-powered aiSIEM, aiXDR platform, announces a

The post Exprivia Partners With Seceon to Offer Seceon’s Cybersecurity Platform and Exprivia Cybersecurity Services Powered by Seceon appeared first on Seceon Inc.

The post Exprivia Partners With Seceon to Offer Seceon’s Cybersecurity Platform and Exprivia Cybersecurity Services Powered by Seceon appeared first on Security Boulevard.

Modern vehicles are essentially computers on wheels, with interconnected software-enabled systems such as advanced driver assistance systems (ADAS), keyless entry, onboard diagnostics, infotainment, and battery management functions. Many of these components support internet connectivity for over-the-air (OTA) software updates, remote access, and real-time monitoring.

The post Connected car security: Software complexity creates bumps in the road appeared first on Security Boulevard.