Nytro

Sunt lucruri diferite, pfSense (firewall) si OpenWRT (router OS). De OPNsense nici nu am auzit, sincer.

Pare interesanta inventia: https://www.powercanister.com/ro/# Insa nu cred ca este aplicabila in mining. Nu cred ca produce prea multa energie. De fapt in general, orice sursa de energie ar fi, nu cred ca merita. Doar daca nu cumva iti faci un imens platou pentru energie solara.

Romanian Cyber Security Challenge (ROCSC) is an yearly CTF event organised in Romania to reward local best talents in cyber security, available for juniors (16-20 yo) & seniors (21-25 yo). At this stage can participate: For prizes: the 31 contestants who won the qualification phase For fun: anyone interested to sharpen their cyber skills. The best competitors of the national competition will have the opportunity to join other young cyber talents from 20 countries (EU Member States and EFTA countries) to represent Team Europe at the International Cyber Security Challenge in 2021. They have to prove their abilities in web and mobile security, crypto puzzles, reverse engineering, forensics and escape room. Format: Jeopardy Play format: Individual Genres: Crypto, Pwning, Reversing, Web, Miscellaneous … Language: English Access: Available for everybody, prizes only for the finalists of ECSC 2020 RO Qualification Phase. Difficulty: Medium - Hard Website: CyberSecurityChallenge.ro The event is organised by SRI, CERT-RO, ANSSI with the support of Orange Romania, Bit Sentinel, CertSIGN, Cisco. The challenges are provided by Bit Sentinel and CertSIGN. Sursa: https://rocsc20.cyberedu.ro/

Da, tot ce face util e ce a postat gigiRoman. In rest e o porcarie. Foloseste wmiexec si smbclient sa trimita screenshot? Mai bine luati acea bucata de cod si o folositi in orice alt mod.

Super, era nevoie de asa ceva. Toate mizeriile astea care vin cu acces la Internet sunt scrise cu picioarele.

Eu cunosc personal din ce in ce mai multe cazuri si nu e de joaca... Cred ca ar fi necesara o carantina de 2-3 saptamani sa se linisteasca apele. Sincer.

Salut, foarte pe scurt, nu se poate. Iti dai seama cum ar fi daca s-ar putea?

Call for papers e deschis. Daca e cineva interesat sa prezinte, astept un PM si putem discuta, va putem ajuta. Mi-ar placea sa prezinte, cel putin la prima editie, persoane de pe forum. Nu trebuie sa fie ceva rocket science, trebuie doar sa fie ceva tehnic, interesant si mai ales util pentru ceilalti. Detalii pentru a aplica: https://rstcon.com/cfp/ - toti urmam acest proces, inclusiv eu care voi tine prezentarea de introducere la conferinta.

CONCURS NAȚIONAL DE INFOSEC ÎȚI PLACE SECURITATEA CIBERNETICĂ? Dezvoltă-ți aptitudinile și cunoștințele de securitate cibernetică INSCRIE-TE! COMPETIȚIE NAȚIONALĂ DE ETHICAL HACKING PENTRU TINERI UNbreakable România este o inițiativă națională ce include organizarea de concursuri și activități practice de securitate cibernetică cu scopul de a încuraja tineri să aleagă o carieră în acest domeniu. Într-un mediu din ce în ce mai digitalizat, avem nevoie de tineri talentați în securitate cibernetică să facă față cu brio provocărilor venite din partea atacatorilor. CITEȘTE MAI MULT FIECARE ETAPĂ, ALTE PROVOCĂRI ALEGE SĂ FII LIDER Fiecare etapă de concurs va pune la încercare atât aptitudinile tehnice ofensive cât și defensive prin numeroase exerciții practice inspirate din viața reală. Scenariile vor conține vulnerabilități și incidente de securitate întâmpinate de companii cunoscute la nivel global. FIECARE ETAPĂ, ALTE PROVOCĂRI ALEGE SĂ FACI DIFERENȚA Nivelul de pregătire cât și motivația fiecărui participant va face clasamentul atractiv pentru lideri. Vor fi momente în care gândirea creativă și perseverența va aduce în top adversari de temut dar și alți participanți de care poate nu ai știut până în acel moment. Sursa: https://unbreakable.ro/

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/

All The Little Things was a pretty hard web challenge from the Google CTF 2020. In this video we do some initial recon and research and try to find an angle to attack.

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/

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