-
Posts
18785 -
Joined
-
Last visited
-
Days Won
738
Everything posted by Nytro
-
Vom publica detalii pe masura ce apar atat aici pe forum cat si pe site-ul conferintei: https://rstcon.com Evenimentul e mai mult ca reminder.
-
Am facut si event pe Facebook: https://www.facebook.com/events/326165868478475/
-
Partea mai complicata nu e cea in care se scrie un programel care face asta, ci aflarea unei metode simple de schimbare. Daca e vorba de outlook.com de exemplu, trebuie vazut cum se poate face login (sa nu fie vorba de un captcha acolo) cum se pastreaza sesiunea si ce request e necesar pentru schimbarea pozei. Daca se stiu aceste lucruri se poate face in 2 linii de bash cu curl si grep.
-
Stiu ca foloseam un tool (cred ca Secure CRT) pentru conectare pe portul serial si acces la shell astfel de dispozitive embedded, insa nu stiu cum s-ar putea face asta prin USB. Pentru portul serial vad ca exista si tool-uri pentru forwarding: http://www.serial-port-redirector.com/ dar la fel, nu stiu care e faza cu USB. Inteleg, nu prea mai gasesti nimic cu port serial direct. Da chiar, acel convertor USB nu expune portul acela ca fiind tot serial? Ma gandesc ca poate are un driver care emuleaza portul serial.
-
Lucram la CTF! Intre timp, asteptam propunerile de prezentari.
-
In general multe probleme apar de la concatenari de stringuri care ulterior sunt folosite in diverse actiuni, gen SQL query sau trimis intr-un request HTTP. E posibil sa se discute despre asta la RST Con
-
Security capabilities in Azure Kubernetes Service on Azure Stack HCI Azure Kubernetes Service on Azure Stack HCI (AKS-HCI) is an on-premises implementation of the popular Azure Kubernetes Service (AKS) orchestrator, which automates running containerized applications at scale. AKS on Azure Stack HCI enables developers and admins to deploy and manage Linux and Windows containerized apps on Azure Stack HCI. With AKS-HCI, enterprises can take advantage of consistent AKS experience across cloud and on-premises environments, extend to Azure with hybrid capabilities, run apps with confidence through built-in security, and use familiar tools to modernize Windows apps. For a more detailed overview of AKS-HCI capabilities, refer to this blog. One of the core strengths of AKS-HCI is using security-first approach. At Microsoft, we believe that leading with strong security posture is table stakes for an enterprise-grade offering. Our security roadmap is comprehensive, starting with a mindset of placing strong protection guardrails and bolstering that with industry-hardened threat detection, and remediation and recovery. The protection-related hardening is built into AKS-HCI. To bring threat detection and remediation, and we integrate with security management systems such as Azure Security Center. Figure 1. Securing AKS-HCI Deployment In this blog, we will describe the security capabilities in AKS-HCI. These security features are not available in the current public preview version, but these and more will be released in the lead-up to general availability. Secure image baseline and container protection Microsoft provides a secure baseline for Windows and Linux container host images and services the updates of those images to maintain consistency and standards. Figure 2. AKS-HCI implemented with hypervisor isolation AKS-HCI is designed such that every layer is secure. The container host is deployed as a virtual machine. Each tenant cluster runs on its dedicated set of container hosts and uses the same strong Hyper-V-based isolation used in Azure which provides the strong kernel isolation among the container hosts. In addition, AKS-HCI has multiple layers of protection built in. The first cluster to be bootstrapped is the management cluster, which is then used to bootstrap other tenant clusters. The container pods are run within Hyper-V virtual machines, enforcing strong isolation guarantees wherein the impact of a compromised container or pod is contained within the Hyper-V VM itself. Identity and access management (IAM) AKS-HCI integrates with Active Directory (AD), providing strong identity and facilitating seamless single sign-on (SSO) to manage the AKS-HCI environment and deploy the container workloads. Additionally, there is provision for Windows containerized application workloads to be bootstrapped with group Managed Service Account (gMSA) identity. gMSA is an AD-managed service account for which the passwords are automatically rotated. Secure communication and secrets Management Communication between the control plane components is protected by Transport Layer Security (TLS). AKS-HCI comes with zero-touch, out-of-the-box provisioning, and management of certificates for the infrastructure and Kubernetes built-in components. Additionally, the Kubernetes secrets are encrypted at rest using strong Advanced Encryption Standard (AES), with the ability to rotate the key encryption keys (KEK). Integration with Azure security assets AKS-HCI is integrated into the Microsoft security ecosystem, which allows extending Azure security constructs such as Azure Container Registry and Azure policies. In the future, integration with Azure assets like Azure Security Center will provide customers the ability to monitor for threats and offer pre- and post-runtime security assessments for both the infrastructure fabric and the Kubernetes cluster. This helps in monitoring for threats and keeping a strong security posture. Join us in this journey Security is a journey, not a destination. These are just some of the security features that we are working on and making generally available (GA) soon. AKS-HCI is going to be continually updated like a service. We will add more security features and continue to further harden the platform. Join us in this journey: we would love to hear feedback, experience, and insights on security. Be part of discussions in our Github repository. rahulverma Microsoft Sursa: https://techcommunity.microsoft.com/t5/azure-stack-blog/security-capabilities-in-azure-kubernetes-service-on-azure-stack/ba-p/1705759
-
Code Review 101 How to perform source code review to find vulnerabilities in web applications. Reviewing code is probably the best way to find vulnerabilities in a web application. It’s a lot faster than black-box testing, and it helps you learn how to program safely in the future by observing the mistakes of others. If you are interested in open-source software, auditing code is also a great way to get involved in the open-source community and help secure the tools you love. Here are a few tricks I’ve learned along the way to audit source code more effectively. Let me know if you have any additional tips for conducting source code reviews. How to look for bugsPermalink There are several ways to go about hunting for vulnerabilities in source code. Depending on how thorough you want to be, here are some approaches that you could take. The “I’ll take what I can get”Permalink The “I’ll take what I can get” approach works great if you don’t need extensive test coverage. This could be because you have very limited time to audit the application, or because you’re a bug bounty hunter who wants to maximize your bugs to time ROI. These techniques are fast and often leads to the discovery of some of the most severe vulnerabilities. Use Grep You can grep for specific functions, strings, keywords and coding patterns that are known to be dangerous. Examples include input() in Python and eval() in PHP. This is the quickest approach and can often lead to critical findings. Focus on the search for dangerous functions used on user-controlled data, as well as hardcoded credentials. 2. Recent fixes and patches You can also take a look at the most recent code fixes and security patches. Recent code change has not stood the test of time and is more likely to have bugs. Look at the protection mechanisms implemented and see if you can bypass them. Search for the program’s dependencies and see if any of them are outdated. The “Bug Spray”Permalink If you have more time, you can complement the above techniques with a more extensive source code review. However, instead of reading the entire code base line-by-line, here are a few strategies that you can take to maximize your efficiency. Important functions first When reading source code, focus on important functions such as authentication, password reset, state-changing actions and sensitive info reads. (What is the most important would depend on the application.) Then, review how these components interact with other functionality. Finally, audit other less sensitive parts of the application. 2. Follow user input Another approach is to follow the code that processes user input. User input such as HTTP request parameters, HTTP headers, HTTP request paths, database entries, file reads, and file uploads provide the entry points for attackers to exploit the application’s vulnerabilities. This can help find common vulnerabilities such as stored-XSS, SQL injections, shell uploads, and XXEs. Focusing on areas of code that deals with user input will provide a good starting point for reviewing where potential dangers might arise. Then, review how the user input gets processed, stored or transferred. Finally, see whether other parts of the application uses the previously processed user input. You might find that the same user input interacts differently with other components of the application. What to look forPermalink Now that we know how to look for bugs in source code, what exactly are we looking for? While a source code review can, potentially reveal most vulnerabilities hiding in an application, some are easier to find than others. In addition to looking for all common vulnerabilities that might be exploited by an attacker, you should also focus on bugs that are critical but hard to discover via other methods (like pen-testing or bug bounties). Hardcoded secrets and credentials: Hardcoded secrets such as API keys, encryption keys and database passwords can be easily discovered during a source code review. You can grep for keywords such as “key”, “secret”, “password”, “encrypt” or regex search for hex or base64 strings (depending on the key format in use). Use of dangerous functions and outdated dependencies: Unchecked use of dangerous functions and outdated dependencies are a huge source of bugs. Grep for specific functions for the language you are using and search through the dependency versions list to see if they are outdated. Developer comments, hidden debug functionalities, configuration files, and the .git directory: These are things that developers often forget about and they leave the application in a dangerous state. Developer comments can point out obvious programming mistakes, hidden debug functionalities often lead to privilege escalation, config files allow attackers to gather more information about your infrastructure and finally, an exposed .git directory allows attackers to reconstruct your source code. Hidden paths, deprecated endpoints, and endpoints in development: These are endpoints that users might not encounter when using the application normally. But if they work and they are discovered by an attacker, it can lead to vulnerabilities such as authentication bypass and sensitive information leak, depending on the exposed endpoint. Weak cryptography or hashing algorithms: This is an issue that is hard to find during a black-box test, but easy to spot when reviewing source code. Look for issues such as weak encryption keys, breakable encryption algorithms, and weak hashing algorithms. Grep for terms like ECB, MD4, and MD5. Missing security checks on user input and regex strength: Reviewing source code is a great way to find out what kind of security checks are missing. Read through the application’s documentation and test all the edge cases that you can think of. A great resource for what kind of edge cases that you should consider is PayloadsAllTheThings. Missing cookie flags: Look out for missing cookie flags such as httpOnly and secure. Unexpected behavior, conditionals, unnecessarily complex and verbose functions: Additionally, pay special attention to the application’s unexpected behavior, conditionals, and complex functions. These locations are where obscure bugs are often discovered. Sursa: https://vickieli.dev/hacking/code-review-101/
-
Hi! I'm a pentester and a bug bounty hunter who's learning everyday and sharing useful resources as I move along. Subscribe to my channel because I'll be sharing my knowledge in new videos regularly.
-
BLURtooth BLUR attacks BLURtooth (the BLUR attacks) exploits the lack of cross-transport key validation, allowing an attacker to bypass Bluetooth Classic and Bluetooth Low Energy security mechanisms. Bluetooth’s cross-transport key derivation (CTKD) is vulnerable to attacks enabling to attack Bluetooth Classic from Bluetooth Low Energy and vice versa. A remote attacker in Bluetooth range may impersonate, man-in-the-middle, and establish malicious sessions with arbitrary devices. Security Impact: device impersonation, man-in-the-middle, malicious session establishment with arbitrary devices Affected Devices: the attack is standard compliant, so all BT/BLE devices supporting CTKD are likely vulnerable; all our tested devices are vulnerable BLURtooth is tracked under CVE-2020-15802 Credit: Daniele Antonioli and Mathias Payer from École Polytechnique Fédérale de Lausanne (EPFL), Nils Ole Tippenhauer from Helmholtz Center for Information Security (CISPA), and Kasper Rasmussen from University of Oxford. Contacts at EPFL: Daniele Antonioli and Mathias Payer Summary Here, we provide more details about a set of novel and standard-compliant Bluetooth vulnerabilities affecting both Bluetooth Classic (BT) and Bluetooth Low Energy (BLE). The uncovered vulnerabilities affect a security mechanism called cross-transport key derivation (CTKD). CTKD is used to improve the usability of Bluetooth pairing by allowing to generate BT and BLE pairing keys just by pairing two devices either on BT or BLE (rather than pairing them two times). However, we find that CTKD introduces cross-transport security issues and that an attacker can abuse those issues to attack BT from BLE and vice versa. In particular, our attacks enable to impersonate, man-in-the-middle, and establish malicious sessions with arbitrary devices by abusing CTKD, while defeating all the security mechanisms put in place by BT and BLE. Our work is named BLURtooth and the related attacks are called BLUR attacks as they blur the security boundary between BT and BLE. The team behind this work consists of Daniele Antonioli and Mathias Payer from the HexHive group at École Polytechnique Fédérale de Lausanne (EPFL), Nils Ole Tippenhauer from Helmholtz Center for Information Security (CISPA), and Kasper Rasmussen from the University of Oxford. In the remainder of this document, we provide information on technical details, disclosure, impact, our proposed mitigation, the response from the Bluetooth SIG. Technical Details The Bluetooth standard includes two technologies Bluetooth Classic (BT) (also known as Bluetooth BR/EDR) and Bluetooth Low Energy (BLE). The majority of mobile devices, including laptops, smartphones, tablets, headphones, and smartwatches, support both and are defined as dual-mode Bluetooth devices. To securely use dual-mode devices over BT and BLE a user has to pair her devices two times, once for BT and once for BLE. As pairing the same device is considered user-unfriendly, in 2014, with the release of Bluetooth version 4.2, the Bluetooth standard introduced a security mechanism that allows a user to pair dual-mode Bluetooth devices once (either over BT or BLE) and then securely use them both over BT and BLE. This security mechanism is called cross-transport key derivation (CTKD), and, as the name implies, it enables deriving pairing keys across different transports (i.e. derive a BT pairing key from BLE and vice versa). Despite being a security-critical mechanism, CTKD is not part of the Bluetooth threat model and there are no security evaluations of CTKD. Those reasons motivated us to perform a security analysis of CTKD, resulting in our findings. In particular, CTKD is affected by 5 major issues (i.e. vulnerabilities) enabling an attacker to abuse Bluetooth roles, association, security modes, keys, and pairing states across BT and BLE. Such issues derive from the lack of a cross-transport threat model in the Bluetooth standard. The standard considers BT and BLE with separate threat models and security architectures while, through CTKD, opens avenues for cross-transport attacks (i.e., attacks that exploit BT by taking advantage of a vulnerability in BLE or vice versa). We demonstrate that the identified CTKD issues can be exploited by a remote attacker in Bluetooth range with the victims. In particular, the attacker can perform impersonation, man-in-the-middle, and malicious session establishment attacks while bypassing all the security mechanisms provided by BT and BLE (including Secure Connections or strong association). Those are very serious attacks that violate the security guarantees promised by Bluetooth. We confirmed the feasibility of our attacks by testing them on 13 common Bluetooth devices using 10 unique Bluetooth chips. All of them were vulnerable. You will find technical details about CTKD, our security analysis, a detailed discussion of the threads, a discussion, and potential mitigations in our BLURtooth preprint. Disclosure We discovered the vulnerability in March 2020 and responsibly disclosed our findings along with suggested countermeasures to the Bluetooth SIG in May 2020. We kept our findings private and the Bluetooth SIG publicly disclosed them, without informing us, on the 10th of September of 2020. Our work is assigned CVE-2020-15802. Impact The BLUR attacks are a significant threat for all Bluetooth users and the related vulnerabilities remain 0-days. Our claim is backed up by our experimental results where we successfully conducted impersonation, man-in-the-middle, and malicious sessions establishment attacks on 13 different devices. Our device sample include manufacturers such as Dell, Google, Lenovo, Samsung, and Sony, operating systems, such as Windows 10, Linux, and Android, and Bluetooth chip manufacturers such as Cypress, Qualcomm, Intel, Broadcom, and Cambridge Silicon Radio (CSR). Our Mitigations As part of our disclosure, we provided concrete fixes to combat the BLUR attacks. In particular, we recommended disabling the capability to overwrite keys via CTKD in certain circumstances, enforce strong association and Secure Connections and roles across BT and BLE, disable pairing over BT and/or BLE when not needed, and add user notifications in case of odd behaviors. Our fixes can be implemented at the standard level and do not require vendor-specific features. Response from the Bluetooth SIG At the time of writing, there are no deployed patches to address the BLUR attacks on actual devices. The Bluetooth SIG suggested that version 5.1 of the standard will contain guidelines to mitigate the BLUR attacks (e.g., disable key overwrites in certain circumstances as proposed in our countermeasures), but such guidelines are not (yet) public and we cannot comment on them. The Bluetooth SIG provides a public statement about BLURtooth and the BLUR attacks. Sursa: https://hexhive.epfl.ch/BLURtooth/
-
gitjacker Gitjacker downloads git repositories and extracts their contents from sites where the .git directory has been mistakenly uploaded. It will still manage to recover a significant portion of a repository even where directory listings are disabled. For educational/penetration testing use only. Installation curl -s "https://raw.githubusercontent.com/liamg/gitjacker/master/scripts/install.sh" | bash ...or grab a precompiled binary. You will need to have git installed to use Gitjacker. Sursa: https://github.com/liamg/gitjacker
-
Taking down the SSO, Account Takeover in the Websites of Kolesa due to Insecure JSONP Call Yasho Hello, this post is about how I could take-over any account of Kolesa’s websites using Single Sign-On. There was an insecure JSONP call which could break the security of the entire SSO mechanism. What is JSONP? JSONP is a method for sending JSON data to other domain. Can load an external JavaScript object Does not use the XMLHttpRequest object Less secure Bypassed SOP in browsers Example of JSONP request/response Single Sign-On Information gathering revealed that Kolesa websites use SSO, the authentication server was: https://id.kolesa.kz The websites used SSO were: https://market.kz https://krisha.kz https://kolesa.kz The general workflow of how SSO works: In this authentication model since a domain can not set an authentication cookie for the others, an authentication token should be transferred between the authentication server and other domains. Considering the orange box in the image above, each site should save a cookie after verifying the authentication token. In addition, authentication server also saves its cookie, so after a couple of HTTP requests I found the authentication cookie name for each Kolesa website: JSONP Call to Handle SSO The JSONP call is used for further authentications. If a user has already logged-in in any of three websites, a JSONP call is made to authenticate the user in. The reason for this action is the ease of implementation. Since the origins of domains are different, the Kolesa websites should have implemented the Cross Origin Resource Sharing to transfer the authentication, but they’ve decided to use JSONP to avoid CORS setup. The point is, once a user is logged in for examplekosela.kz, they have a ccid cookie in id.kolesa.kz, an authentication token to transfer the authentication, and a ssid cookie in kosela.kz. After that, if the user wants to log-in in the other websites, it happens by just a click, since id.kosela.kz has authentication cookie, it immediately generates authentication token and the user will have the corresponded authentication cookie on the website. Based on the picture above, phase 4 shows how the JSONP call is made and how the authentication token can be turned into authentication cookie in a domain. The cause of JSONP call: If the user has already been authenticated by id.kolesa.kz, the following response is expected: HTTP/1.1 200 OK Server: openresty/1.13.6.2 Date: Mon, 19 Aug 2019 16:43:26 GMT Content-Type: text/javascript;charset=UTF-8 Connection: close Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Backend-Server: auth-be3.alaps.kz.prod.bash.kz X-Bug-Bounty: Please report bugs and vulnerabilities to bugs@kolesa.kz Content-Security-Policy: frame-ancestors 'self' http://webvisor.com https://webvisor.com Strict-Transport-Security: max-age=31536000 Content-Length: 627window.xdm = { sess: { is_authenticated: 1, token: 'xG3ROFWcb7pnXSnMr8MkaBvH01pLlCHqn0sPt0PVL6BBWYdQPdvA31tBi6dLB5njv5jhMW3y/cGBMRB9LC/69zv867wweaDhkxX6arGVzYDy2q+J52nkOQJ+62rR9wLPYJGyEpNGWeOBSp12vugXZUPq2RA6FMptbNkGQpJFjAclXSzduj7wJJgAUONMj3mkkElM1nWmIllrl5zDEz6s7077E4ibx//BvnfZ9AIC/9b2PB+QzVKOnSzzcr9wSXqta9TEDHvjopqbUd4UE2xSMRSj/zxPQlCba5632hcIXnzZB3A8fvahvf2Hm5ssuC+cwuKU8pAdE/qcGQSJKdhpYXxntGkQiLdEAliyCq+fahS4itb6HlFH/+H20RsZA+cjyaF7ntnW5tYY31vxJXovrR3oinaj9YDSzoCZYMDYPJMdk+HuZhRuxxEl8abuNlGD0aCt2GCPV7GY0J9Ma7AcPw==' } };(function ($) { "use strict";$.xdm = window.xdm; }(jQuery)); As it’s been seen there is an object named sess containing the two properties named is_authenticated and token. This object is responsible to transfer authentication. At this moment the user has authentication token but not authentication cookie of the current website, so the second call is made: The JavaScript code: Vulnerable External JavaScript Object The question is, an arbitrary origin can extract the authentication token? of course, it can because the JSONP call bypasses the Same Origin Policy. The vulnerability found, account takeover by a single click The Exploitation Phase The scenario is simple: Setting up a page calling JSONP on behalf of any user Tricking authenticated user to visit our malicious website Sending authentication token by the user to our website logging-in as the victim and doing bad stuff The exploit code (client-side + server-side call): Here is the video POC: WRITTEN BY Yasho Sursa: https://medium.com/bugbountywriteup/taking-down-the-sso-account-takeover-in-3-websites-of-kolesa-due-to-insecure-jsonp-call-facd79732e45
-
White hat hacker infects smart coffee machine with ransowmare by Waqas on September 28th, 2020 IPVanish Avast security researcher reverse-engineered an IoT coffee machine to upload ransomware and mine Monero coin. Smart appliances have always remained a risky option for consumers, specifically when it comes to coffee machines. Back in 2015, Pen Test Partners researchers discovered security flaws in the first version of the Smarter iKettle brand of coffee machine with which they could recover its Wi-Fi encryption keys. Similar flaws were identified in the second version of this coffee machine, and now it appears that there are issues in its latest version as well. This should not come as surprise as in 2017 Hackread.com exclusively reported how a coffee machine infected a factory’s entire computer network with ransomware. Now, Martin Hron, a senior researcher at security firm Avast, hacked the iKettle coffee maker’s third version without compromising the network or router. Hron experimented on the £179 coffee machine to demonstrate that hacking an IoT device is possible without accessing unprotected routers. Coffee machine hacked with ransomware (Image: Avast) His experiment was quite successful as he had to pull the plug to stop the machine’s malfunctioning. Later he wrote about his findings in a blog post published on Sep 25, explaining that: “The threat to IoT devices is not just to access them via a weak router or exposure to the internet, but that an IoT device itself is vulnerable and can be easily owned without owning the network or the route.” Hron could access the coffee maker via a firmware update since unencrypted connection corresponded to its Android smartphone app. When he switched it on, the researcher noted that the machine served as a Wi-Fi access point facilitating an unsecured/unencrypted connection to the android app. After probing further, Hron learned that the firmware update mechanism was also unencrypted and didn’t involve any authentication process or code-signing. Then, Hron uploaded the app’s latest firmware version to a computer and performed reverse engineering with an interactive disassembler. Hron also took apart the appliance to identify the CPU installed inside. Initially, he tried to convert it into a cryptocurrency miner but found that the CPU wasn’t efficient enough. Coffee machine hacked to mine Monero coin (Image: Avast) 1 of 3 After obtaining the necessary details, Hron wrote a Python script, which replicated the machine’s update process. He also modified its firmware and script lines to make the machine malfunction and demand a ransom after connecting to a user’s home network. Watch how it happened: Video Player However, Hron clarified that it isn’t as easy to hack the coffee maker as it sounds to be. The hacker will have to remain within the machine’s Wi-Fi range. Still, it is concerning that smart appliances could be exploited in such a way. “With the pace of IoT explosion and a bad attitude to support, we are creating an army of abandoned vulnerable devices that can be misused for nefarious purposes such as network breaches, data leaks, ransomware attack, and DDoS,” Hron wrote. Sursa: https://www.hackread.com/white-hat-hacker-smart-coffee-machine-ransowmare/
-
- 1
-
-
Critical Information Disclosure on WP Courses plugin exposes private course videos and materials Today we’ve got an interesting story to share. A vulnerability in WP Courses caused our Java course to be publicly disclosed via the WordPress REST API. Let’s dive into the details and see what happened. WordPress REST API Since version 4.7 of WordPress, the REST API is a default feature. It can be found at URL endpoint /wp-json/wp/v2. It will serve all of your websites’ content in a JSON structure. That way, external services that want to read data from your website won’t have to scrape HTML pages made for human eyes. They just query the REST API. You may be aware of another method, providing similar services: xml-rpc. This entrypoint has been known for being vulnerable to brute-force attacks, and is suggested to be disabled in many articles. For reasons of backwards compatibility it’s still included with the newest version of WordPress. But efforts are made to have it replaced with the REST API, which doesn’t suffer from the same vulnerabilities. Still, we are dealing with an API, so we have: Increased attack surface An easier way for attackers to crawl content The vulnerable plugin: WP Courses We host our online course using WP Courses. This $79 plugin (a free version without support for payments is also available) allows you to define courses with lessons. Only when a user is registered to WordPress and has bought the product via WooCommerce, the contents of the lessons are shown. The plugin is correctly hiding the contents of the lesson for users who haven’t purchased the course. So far so good. What if we try to get the content via the REST API? WordPress is making it easy for us, by adding a <link rel="alternate"> tag to its pages. The link tag is pointing to the REST API endpoint Let’s have a look at what the REST API endpoint exposes. Its behavior is documented in the REST API Handbook of WordPress. It states the following about private content: The REST API is a developer-oriented feature of WordPress. It provides data access to the content of your site, and implements the same authentication restrictions — content that is public on your site is generally publicly accessible via the REST API, while private content, password-protected content, internal users, custom post types, and metadata is only available with authentication or if you specifically set it to be so. REST API Handbook However, when we browse to our lesson we get the full contents of the page, including the secret link to the course video. Course video URL leaked to unauthorized users To be clear, this was accessible to unauthenticated users. A registered account on our WordPress instance wasn’t even necessary. How is this possible? Root cause analysis In WordPress, there is a distinction between pages and posts. A page is content that stays relevant over time, whereas a post is like an article. This distinction has been there since the beginning of WordPress, and it is reflected in the REST API as well: page content can be fetched from /wp-json/wp/v2/pages, and posts from.. you guessed it right, /wp-json/wp/v2/posts. Apart from making it easier for attackers to parse content, there is nothing wrong with it being accessed using an API. It’s all public content anyways. Then why does ‘private’ material of WP Courses get displayed here? For WP Courses, a ‘page’ or a ‘post’ doesn’t really fit nicely the description of course content. They decided instead to create new post types, called ‘course’, ‘lesson’, and ‘teacher’. Consequently, their content is browsed via REST API endpoint /wp-json/wp/v2/course, /wp-json/wp/v2/lesson and /wp-json/wp/v2/teacher respectively. Creating new post types Defining new post types is done via the WordPress method register_post_type. As can be seen from the documentation, it takes an array of options. One of them is called ‘show_in_rest’: WordPress API documentation of the register_post_type function As you may have guessed by now, WP Courses had set this option expliclty to ‘true’, causing the contents to be accessible via the REST API. From the source code of WP Courses, we can see the ‘ show_in_rest’ attribute is set to true for the post type ‘lesson’ Setting this option to false solved the issue immediately. Preventing exposure of the content via the REST API Detection of the vulnerability We were alerted of the vulnerability by looking at log files. A number of different IP addresses were seen to download our course content, without purchasing the course first. We immediately suspected a breach at this point, but the method was yet unclear. The filenames of our videos are hard to guess, and it would take some kind of enumeration vulnerability to find out their paths. Pretty soon we found out that the /wp-json/ endpoint was queried more often than usual. It led us to eventually discover the content leak of WP courses via the REST API. Pirates in sight Before we could recover from the vulnerability, a number of people have downloaded our course material without paying for it. In other words, it was stolen by purposefully looking for a way to get access to the videos. In total 38 IPs have been tracked doing that. Many of them are residential IP addresses (both static and dynamic). Some others are business IP addresses or VPS hosted on Amazon, OVH, etc… We’ve seen peole from Myanmar, Mexico, Iran, Peru, Italy, The Netherlands, France, Israel, USA, India, Albania, Egypt, UK, Philippines, Ecuador, Madagascar, Belgium, Estonia, and a place falling under the British crown jurisdiction called “Isle of Man”. It appears one of the first using this trick was an IP from “Amazon Technologies Inc“. It also appears the content has been shared mainly via Telegram. Our course We feel it’s unfair not to pay for work that has cost us many hours to put together. We also understand you may not be able to afford it. Because of the breach and the enormous interest we got from the recent campagin on Twitter, we made the decision to try something different. From today, the course is available for the excellent price of what you think is fair. We urge you – including those who have obtained our course by illegal means – to have a good think about how much the course is worth to you. If this works out well, then we will be selling all future courses according to this price model. Obviously we cannot afford to do that if people pay the bare minimum. If we succeed, we can be the first ones with courses affordable to anyone around the world, regardless of purchasing power. So, we would like to invite all of you interested in becoming an expert on Java hacking to sign up for our course. We are still working on the website, but before end of today the course contents and materials will be back. We’d like to thank you in advance for the support, and let’s see if we can make this model work! Recovery Before we finish off, let’s spend a few words on how we recovered from the vulnerability. After we discovered the issue, we immediately contacted the developers of WP Courses (CVE to be announced). They were quick to fix as a patch was pushed the same evening, but the level of details provided was initially insufficient. We made WP Courses developers notice that people could have got confused from the information provided, as in the email above there was no mention this was a security issue. Customers could think version 2.0.28 was just a minor release and decide not to fix soon. As a consequence, all their private courses could have been stolen. The reaction to our considerations was the transmission of a new email and the release of a new version (2.0.29). Notification about the availability of a new version of WP Courses plugin On our side no customer data was leaked during the breach. User names, e-mail addresses and order information are not part of the WP courses plugin, and thus were not at risk. We assessed the use of the REST API, and disabled it as a preventative measure, even though there could be many legit use cases to keep it enabled. Of course we are not going to trust WP Courses plugin anymore . Our future courses are probably going to be hosted on other platforms. Stay tuned! Sursa: https://www.redtimmy.com/critical-information-disclosure-on-wp-courses-plugin-exposes-private-course-videos-and-materials/
-
Daca te descurci la partea de artificial intelligence/machine learning poti face un simplu web application firewall care "invata" request-uri valide pentru o aplicatie, apoi le poate bloca pe altele (care nu par in regula). Tema mi-a fost propusa acum x ani de catre profesorul meu coordonator de licenta dar nu ma pricepeam la asa ceva. Si am facut NetRipper
-
Orice ar folosi, teoretic, se poate. Practic, asta poate fi extrem de dificil si sa consume foarte mult timp (fara sa punem la socoteala skill-urile necesare). Doar daca cineva de pe forum are timp, eu pana termin cu RST Con nu prea o sa am timp.
-
Te referi la acele LPIC? Din cate am vazut eu cuprind multe lucruri si cred ca sunt si destul de recunoscute. Adica mi se par foarte OK.
-
Nu cred ca ai nevoie de VPN pentru bug bounty, te complici, nu o sa se ia nimeni de tine. Sunt multe servicii, ceva romanesc e RoTunneling al unui baiat de pe forum. Hidemyass (parca) am folosit in trecut pentru un engagement (la munca) si a fost ok.
-
Imi pare bine sa ma alatur comunitatii voastre!
Nytro replied to truffledog's topic in Bine ai venit
Bun venit, daca te putem ajuta cu ceva nu ezita sa intrebi. -
Partea cu acel Gigel care intra pe Zoom nu e chiar de joaca. Si se vede ca Romania nu este o tara atat de adaptata tehnologic cum se crede (vazand ca toti copii au smart phone-uri si stiu sa "isi bage" jocuri crackuite). Profesorii ar trebui sa stie si ei sa puna o parola la o conferinta de Zoom. E ok cand se intampla la clase mai mari dar daca e vorba de copii mai mici? Nu stii ce dubiosi pot sa apara.
-
OSWE/AWAE Preparation Jan 22, 2020 WebExploit Development Share on: updated Content AWAE1.5 OSWE Exam Preparation This post contains all trainings and tutorials that could be useful for offensive security’s OSWE certification. I will be updating the post during my lab and preparation for the exam. Course Syllabus: https://www.offensive-security.com/documentation/awae-syllabus.pdf Before registering for AWAE Lab: Get comfortable with python requests library Read Web Application Hacker’s handbook, again if you already did Get familiar with Burpsuite Get familiar with regex Get hands on with OWASP top 10 2017 Vulnerabilities Vulnerable Apps for practice on OWASP Portswigger WebSecAcademy Practice code review skills - OWASP SKF Before registering for the OSWE Exam: XSS to RCE AtMail Email Server Appliance 6.4 - Persistent Cross-Site Scripting Chaining XSS, CSRF to achieve RCE Code analysis to gaining RCE Magento 2.3.1: Unauthenticated Stored XSS to RCE Mybb 18.20 From Stored XSS to RCE Bypassing File Upload Restrictions: [Paper] File Upload Restrictions Bypass Shell the web - Methods of a Ninja Unrestricted File Upload Atlassian Crowd Pre-auth RCE Popcorn machine from HackTheBox Vault machine from HackTheBox Authentication Bypass to RCE ATutor 2.2.1 Authentication Bypass ATutor LMS password_reminder TOCTOU Authentication Bypass ATutor 2.2.1 - Directory Traversal / Remote Code Execution Cubecart Admin Authentication Bypass Trendmicro smart protection bypass to RCE Password Reset Vulnerability Testing Password rest functionalities OWASP - Forgot Password Cheatsheet How we hacked multiple user accounts using weak reset tokens for passwords SQL Injection: RCE with SQL Injection - MSSQL SQL Injection to LFI to RCE - MySQL From SQLi to SHELL (I and II) - PentesterLab Pre-Auth Takeover of OXID eShops Blind SQL Injection [Paper] PostgreSQL Injection Having Fun With PostgreSQL Blind Postgresql Sql Injection Tutorial SQL Injection Cheat Sheet - PentestMonkey SQL Injection Cheat Sheet - PayloadAllTheThings Exploiting H2 SQL injection to RCE JavaScript Injection: Server Side JS Injection Remote Code Execution in math.js Arbitrary code execution in fast-redact NVIDIA GeForce Experience OS Command Injection - CVE-2019-5678 SetTimeout and SetInterval use eval therefore are evil Pentesting Node.js Application : Nodejs Application Security NodeJS remote debugging with vscode Escape NodeJS Sandboxes PHP Type Juggling: OWASP - PHPMagicTricks TypeJuggling PHP Type Juggling - Introduction Type Juggling, PHP Object Injection, SQLi Writing Exploits For PHP Type Juggling Type Juggling Authentication Bypass Vulnerability in CMS Made Simple PHP Magic Hashes Detailed Explanation of PHP Type Juggling Vulnerabilities [Video] PHP Type Juggling Vulnerabilities, Netsparker [Video] Falafel machine from HackTheBox Deserialization: Deserialization_Cheat_Sheet Insecure deserialization - PayloadAllthethings [Paper] Deserialization Vulnerability Serialization : A Big Threat JAVA Deserialization Understanding & practicing java deserialization exploits Understanding JAVA Deserialization Exploiting blind Java deserialization with Burp and Ysoserial Details on Oracle Web Logic Desrialization Analysis of Weblogic Deserialization [Video] Matthias Kaiser - Exploiting Deserialization Vulnerabilities in Java .NET Deserialization Use of Deserialization in .NET Framework Methods and Classes. Exploiting Deserialisation in ASP.NET via ViewState Remote Code Execution via Insecure Deserialization in Telerik UI [Video] Friday the 13th: JSON Attacks - BlackHat [Paper] Are you My Type? [Video] JSON Machine from HackTheBox - Ippsec PHP Object Injection/Deserialization What is PHP Object Injection phpBB 3.2.3: Phar Deserialization to RCE Exploiting PHP Desrialization Analysis of typo3 Deserialization Vulnerability Attack Surface of PHP Deserialization Vulnerability via Phar [Video] Intro to PHP Deserialization / Object Injection - Ippsec [Video] Advanced PHP Deserialization - Phar Files - Ippsec [Video] Exploiting PHP7 unserialize (33c3) NodeJS Deserialization Exploiting Node.js deserialization bug for Remote Code Execution The good, the bad and RCE on NodeJS applications Attacking Deserialization in JS Node.js Deserialization Attack – Detailed Tutorial [Video] Celestial machine from HackTheBox - Ippsec XML External Entity (XXE) Attack A Deep Dive into XXE Injection From XXE to RCE: Pwn2Win CTF 2018 Writeup Blind XXE to RCE Apache Flex BlazeDS XXE Vulnerabilty WebLogic EJBTaglibDescriptor XXE Server Side Template Injection (SSTI) [Portswigger Research] Server Side Template Injection [Video] SSTI : RCE For The Modern Web App - albinowax Server Side Template Injection Jinja2 template injection filter bypasses Exploitation of Server Side Template Injection with Craft CMS plugin SEOmatic <=3.1.3 Websocekts InSecurity Introduction to WebSockets [Video] Hacking with Websocket - BlackHat Remote Hardware takeover via Websocket Hijacking Cross-Site WebSocket Hijacking to full Session Compromise Source Code Audit Introduction to Code Review [PentesterLab] Static code analysis writeups TrendMicro - Secure Coding Dojo Bug Hunting with Static Code Analysis [Video] Shopify Remote Code Execution - Hackerone Finding vulnerabilities in source code ( APS.NET) A deep dive into ASP.NET Deserialization Writeups by mr_me Youtube Playlist Further References/Reviews From AWAE to OSWE the preperation guide - hansesecure OSWE Exam Review 2020 Notes gifts inside - 21y4d OSWE Cheat Sheet - V1s3r1on wetw0rk/AWAE-PREP https://codewhitesec.blogspot.com/ https://blog.ripstech.com/ https://rhinosecuritylabs.com Sursa: https://z-r0crypt.github.io/blog/2020/01/22/oswe/awae-preparation/
-
Zolom C# Executable with embedded Python that can be used reflectively to run python code on systems without Python installed Usage zolom.exe --script:"from random import seed; from random import random; seed(1); print 'getting random number'; print random();" zolom.exe --b64script:"ZnJvbSByYW5kb20gaW1wb3J0IHNlZWQ7IGZyb20gcmFuZG9tIGltcG9ydCByYW5kb207IHNlZWQoMSk7IHByaW50ICdnZXR0aW5nIHJhbmRvbSBudW1iZXInOyBwcmludCByYW5kb20oKTs=" Building Using Visual Studio restore the nuget packages and then click build. Adding more modules Unzip the Lib.zip file and add your modules, rezip the file and embed as a resource, finally recompile and your new lib should be available Sursa: https://github.com/checkymander/Zolom
- 1 reply
-
- 1
-
-
ARM64 Reversing and Exploitation Part 2 - Use After Free SEPTEMBER 6, 2020 In this blog post, we will be exploiting a Use-after-free vulnerability in the vuln binary. The binaries for this and the next article can be found here. This UaF challenge is based on the one used by Protostar Use-after-free vulnerabilities occurs on the use of heap allocated memory after it has been freed. This can lead to several unexpected behaviours, from a crash to code execution. Anyways, let’s get started. Copy the vuln binary to your iOS or Corellium device. Run the binary vuln. You get a message that says “Better luck next time” Let’s open the binary in Hopper to see what’s going on. Let’s have a look at the main function. Just like the previous example on Heap Overflow, our objective here is to jump the useafterfree function. For that, we need to pass in the argument uaf The function then jumps execution to the function useafterfree ./vuln uaf The output shows the address of the user and the customerChat object. We see several commands here, however on reversing the function, we find there is another hidden command reset that basically frees the user object. This can be confirmed by looking at the code itself void useafterfree(char *input){ printf("Use after free challenge. Try to log in without entering the password. Available commands are:\na) username XYZ\nb) login\nc) customerChat XYZ.\n"); char line[0x400]; while(1) { printf("{user = %p, customerChat = %p }\n", user, customerChat); if(fgets(line, sizeof(line), stdin) == NULL) break; if(strncmp(line, "username ", 9) == 0) { user = malloc(sizeof(struct currentUser)); memset(user, 0, sizeof(struct currentUser)); if(strlen(line + 5) < 0x100) { printf("Setting username\n"); strcpy(user->username, line + 9); } } if(strncmp(line, "reset", 5) == 0) { printf("Freeing user object\n"); free(user); } if(strncmp(line, "customerChat ", 13) == 0) { customerChat = strdup(line + 12); } if(strncmp(line, "currentUser", 11) == 0) { printf("Current user is %s", user->username); } if(strncmp(line, "login", 5) == 0) { if(strncmp(user->password, "BBB", 3) == 0) { printf("You have successfully logged in with password %s!\n", user->password); } else { printf("Please enter your password\n"); printf("current password is %s\n", user->password); } } } } We see that the user struct object has an attribute password . This is being checked later on. If the password has three B’s, the user gets logged in. if(strncmp(user->password, "BBB", 3) == 0) { printf("You have successfully logged in with password %s!\n", user->password); } This is an example of a UaF since the user object can be freed by using the reset command and then calling if(user->password) will basically trigger the UaF. We can also calculate the size of the user object. The user object is a object of struct currentUser as can be seen in the following line user = malloc(sizeof(struct currentUser)); struct currentUser { char username[0x100]; char password[4]; }; The size of the user object is 256 + 4 = 260 bytes. If we can free the user object using reset and then overwrite it with the value BBBB such that we are able to overwrite the password property, we might be able to execute a Use-after-free condition and successfully log in. Since our objective is to login, so let’s try that by first entering the username command, $username admin $login Now let’s enter the reset command, this will free the buffer. Now let’s enter the customerChat command followed by the chat and send 260 B’s (so the size of cutomerChat object is the same as than of user object), we keep entering the size of the chat around the same size of the user so that it can take over the memory address of the freed user object. After some tries, we see that the customerChat address is overlapping the user address, in this case we were able to overwrite the password property of the freed user object with all B’s. And hence entering the login command again gives us a success. Command in order username admin login reset customerChat BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB login Sursa: http://highaltitudehacks.com/2020/09/06/arm64-reversing-and-exploitation-part-2-use-after-free/
-
HEVD writeups Sep 15, 2020 Yuvaly0 Intro This writeups do not aim to replace all of the existing good places already. I wrote them so I could get deeper understanding of the vulnerabilities I’ve decided to write writeups only for the vulns that interested me the most. There are references to the articles I used in the git repo. At the end of each section, I put a reference to the full source code Non Paged Pool Overflow Double Fetch Non Paged Pool Overflow This bug will occur when writing data passed the end of a buffer, in this case, the buffer is in the non paged pool. For example, a function receives a buffer and just copies it to her buffer without checking its length. Analysing the binary We are interested in the function TriggerNonPagedPoolOverflow First of all the function creates a chunk using the function ExAllocatePoolWithTag, the requested chunk is in size of 0x1f8, it’s tag will be ‘Hack’ and it will be allocated in the non paged pool. We’re given the information mentioned above and some info on our sent buffer Next, they use memcpy to copy our buffer with our given size (the vulnerability) to their buffer without any size checking. Lastly, they free the chunk. Explotation Our goal is to pop a cmd with system permissions Derandomize the pool (get to a predictable state) - pool spray Trigger the overflow and overwrite an address with a shellcode address jump to the shellcode and pop a cmd We cant just the overwrite the buffer because it will mess up the pool structure and cause a BSOD: Derandomize the pool We will be using a technique called pool spray.</br> This technique is used to get the pool to a controlled state, this is possible because of its allocator mechanism. But with what objects? We can use the event object, they are each sizeof 0x40, but if we will multiply by 8 will get 0x200 which is the size of our driver allocated chunk 0x1f8 (+ 0x8 for the _POOL_HEADER struct) The idea is that the first wave will derandomize and the second wave will start in a state where the pool is already derandomized. We could do it in one wave. Some handles address, so we could check the state with windbg We can see that because we freed 8 consecutive chunks, they became one big chunk in size of 0x200 (including the pool header) Trigger Overflow The TypeIndex field in the _OBJECT_HEADER is an index to a table of pointers that will point to different OBJECT_TYPE types. Inside the OBJECT_TYPE, there are a couple of pointers for functions, such as: OkayToCloseProcedure, CloseProcedure.</br> See below So if we could overwrite the pointer to the table, causing it to point to another index in the table say - the first index, 0, is a null pointer, because we are operating on windows 7 we can allocate a null page and simulate the OBJECT_TYPE struct there, giving us the ability to control EIP But we cannot just overwrite the object header with random or even some other chunk metadata because its unsafe. Because we know that we will overwrite an event object we can take one of our known headers, after all, we know all of them are the same (at least until the Lock field offset, which is 0 anyway). Getting system Now we need to concat all of our previous steps and run the program: full source code Double Fetch This kind of bug happens when the user-supplied data is fetched twice, for example, there is an ioctl that receives an array of chars and its length, if the function will check the size and will copy using it (the same reference to the variable). It will expose itself to the double-fetch bug. This is also called TOC-TOU, TimeOfCheck and TimeOfUse, when you are fetching this value for the second time you are exposing yourself to the fact that the user will be able to change this data between the check and the use thus the vulnerability. Analysing the binary We are interested in the function TriggerDoubleFetch. First of all the function prints for us some data. Then a check is made, the size that we supplied vs the size of the kernel buffer size to prevent overflow If we passed the check, our buffer is copied to the kernel buffer using memcpy and the size we sent. The fact that the function “fetches” the size twice we have a window of opportunities to change its value. So if we look again at what we can achieve, we can get OOB(out of bounds) write on the stack. Explotation Ok, so we want two things to happen Change the value before its use and after the check. Jump to an arbitrary address of our choosing So we will run two threads, one that will repeatedly engage with the driver and will trigger a double fetch vulnerability and another to change the value of the size being sent. Ok, let’s create two threads and attach our functions To pop a cmd with system we need to consider something else like our computer resources At first, my VM was with one processor, we must think about our OS resources, for example, how much processors we have? a low number (<4) will give us a hard time when trying to exploit. It took me quite some time to trigger the exploit using two processors Also, we need to consider the fact that our threads are not alone in the system and we are not even in the highest priority for our system Let’s change our threads priority And a check to verify the number of processors Now we can run the exploit with success Another thing we can do is set each of our threads to a different processor, so he will not be competing with our second thread about the processor resources where i represents the location of a bit in a bitmask that represents the processor number</br> (i == 0 -> first processor) of course, we will set by our machine capabilities or the call will fail. full source code updated_at 15-09-2020 Sursa: https://yuvaly0.github.io/2020/09/15/hevd-writeups.html