Organizations spend 32.4% of security budgets on code security, yet only 44% of developers follow secrets management best practices. Get the full insights in our 2024 report.
The post Voice of Practitioners 2024 appeared first on Security Boulevard.
Within today’s quickly transforming threat context, security operations centers (SOCs) need robust tools to detect, analyze, and respond to threats efficiently. ReversingLabs’ integration with Microsoft Sentinel, a cloud-native Security Information and Event Management (SIEM) solution, empowers SOCs with advanced threat intelligence and file enrichment capabilities. This blog post explores how these integrations enhance security operations and streamline incident response.
The post Enhancing Security Operations with ReversingLabs and MicrosoftSentinel Integrations appeared first on Security Boulevard.
Open banking has revolutionized the financial services industry, allowing customers to share their financial data with third-party providers through secure APIs (Application Programming Interfaces). While this has opened up new avenues for innovation, it also brings significant security risks. Securing APIs in open banking is essential to protect sensitive financial data and maintain customer trust. […]
The post Why Does Every Retailer Need Penetration Testing to Ensure Customer Safety? first appeared on StrongBox IT.
The post Why Does Every Retailer Need Penetration Testing to Ensure Customer Safety? appeared first on Security Boulevard.
Generative AI, often abbreviated as GenAI, is undoubtedly here to stay. The power to generate humanlike text, images, code, and...
The post 5 Steps to Assess the Cyber and Privacy Risk of Generative AI appeared first on Symmetry Systems.
The post 5 Steps to Assess the Cyber and Privacy Risk of Generative AI appeared first on 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: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:
Example output of running the training session on one million training passwords:
3) Update John the Ripper's Config FileBelow 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:
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.
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!
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 ThreatsAt 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:
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 DangerousIn 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 ExposedOne 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:
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:
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.
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.
