Leaderboard

Eu vreau sa stiu cine e diavola!

La cartela am zambit, la raspberry pi-ul ala sau ce e m-a bufnit rasul hahahah :)))))

Adevarul despre masti! https://9gag.com/gag/a6KDq5b

De acord, nu ramaneau telefoanele/clipurile dacã era sa fie prãpãd Totuși refrenul din 2004 spune multe: YT: Profethu - Protest ( 2004 )

Written by Alexandr Shvetsov on August 4, 2020 Openfire is a Jabber server supported by Ignite Realtime. It’s a cross-platform Java application, which positions itself as a platform for medium-sized enterprises to control internal communications and make instant messaging easier. I regularly see Openfire on penetration testing engagements, and most of the time all interfaces of this system are exposed to an external attacker, including the administrative interface on 9090/http and 9091/https ports: Openfire Administration Console Since the Openfire system is available on GitHub, I decided to examine the code of this web interface. This is a short writeup about two vulnerabilities I was able to find. Full Read SSRF Vulnerability Assigned CVE: CVE-2019-18394 Vulnerable file: FaviconServlet.java (the fix commit) This vulnerability allows an unauthenticated attacker to send arbitrary HTTP GET requests to the internal network, and obtain full-sized outputs from the targeted web services. Let’s look at the vulnerable code contained in the FaviconServlet.java file: ... public void doGet(HttpServletRequest request, HttpServletResponse response) { String host = request.getParameter("host"); // Check special cases where we need to change host to get a favicon host = "gmail.com".equals(host) ? "google.com" : host; byte[] bytes = getImage(host, defaultBytes); if (bytes != null) { writeBytesToStream(bytes, response); } } private byte[] getImage(String host, byte[] defaultImage) { // If we've already attempted to get the favicon twice and failed, // return the default image. if (missesCache.get(host) != null && missesCache.get(host) > 1) { // Domain does not have a favicon so return default icon return defaultImage; } // See if we've cached the favicon. if (hitsCache.containsKey(host)) { return hitsCache.get(host); } byte[] bytes = getImage("http://" + host + "/favicon.ico"); .... } ... In the doGet and getImage methods the code gets the host variable from the get parameters, and constructs an URL from it without any constraints to the component parts. Thus, an attacker can place any sequence of characters inside of it, and make the server connect to any URL they want. An HTTP request to test the vulnerability: GET /getFavicon?host=192.168.176.1:8080/secrets.txt? HTTP/1.1 Host: assesmenthost.com:9090 An example of a vulnerable server’s behavior: An example of CVE-2019-18394 exploitation in Burp Suite Arbitrary File Read Vulnerability Assigned CVE: CVE-2019-18393 Vulnerable file: PluginServlet.java (the fix commit) This vulnerability affects only Windows installations of the OpenFire server, and an attacker has to have an administrative account on the server to exploit it. The vulnerable code is located in the PluginServlet.java file: ... @Override public void service(HttpServletRequest request, HttpServletResponse response) { String pathInfo = request.getPathInfo(); if (pathInfo == null) { response.setStatus(HttpServletResponse.SC_NOT_FOUND); } else { try { // Handle JSP requests. if (pathInfo.endsWith(".jsp")) { ... } // Handle servlet requests. else if (getServlet(pathInfo) != null) { handleServlet(pathInfo, request, response); } // Handle image/other requests. else { handleOtherRequest(pathInfo, response); } } ... } private void handleOtherRequest(String pathInfo, HttpServletResponse response) throws IOException { String[] parts = pathInfo.split("/"); // Image request must be in correct format. if (parts.length < 3) { response.setStatus(HttpServletResponse.SC_NOT_FOUND); return; } String contextPath = ""; int index = pathInfo.indexOf(parts[1]); if (index != -1) { contextPath = pathInfo.substring(index + parts[1].length()); } File pluginDirectory = new File(JiveGlobals.getHomeDirectory(), "plugins"); File file = new File(pluginDirectory, parts[1] + File.separator + "web" + contextPath); // When using dev environment, the images dir may be under something other that web. Plugin plugin = pluginManager.getPlugin(parts[1]); ... } This vulnerability is interesting in that it exists in the URI itself, and the HTTP parameters are not involved. The handleOtherRequest method, which is responsible for handling the /plugin/search/ path, makes an assumption that if it splits the pathInfo variable by the “/” character, the obtained sequence will be safe to use. But since there is no allowlist of characters or any checking for the “\” character, we can perform a path-traversal attack for Windows systems. To test the vulnerability, log in to the server, and send the following request with the administrator’s JSESSIONID cookie: GET /plugins/search/..\..\..\conf\openfire.xml HTTP/1.1 Host: assesmenthost.com:9090 Cookie: JSESSIONID=node01aaib5x4g4p781q3i2m2tm74u91.node0; An example of a vulnerable server’s behavior: An example of CVE-2019-18393 exploitation in Burp Suite Conclusion Both discovered vulnerabilities were the result of unexisting user input data validation. So, my recommendation for the developers was to validate the parameters before performing sensitive operations with them, such as reading files and accessing URLs. It’s worth noting that system administrators should also protect all of the administrative interfaces against unauthorized access, and not make them available to external or internal attackers. The timeline: 2 October, 2019 – Reported to Ignite Realtime 3 October, 2019 – Issues have been addressed in main codeline 1 November, 2019 – Ignite Realtime released the 4.4.3 version 4 August, 2020 – Public disclosure Links: https://issues.igniterealtime.org/browse/OF-1885 https://issues.igniterealtime.org/browse/OF-1886 If you have an Openfire server, make sure you’ve updated it to version 4.4.3 or higher. Source

Mark Russinovich Chief Technology Officer, Microsoft Azure Microsoft has invested in the security of open-source software for many years and today I’m excited to share that Microsoft is joining industry partners to create the Open Source Security Foundation (OpenSSF), a new cross-industry collaboration hosted at the Linux Foundation. The OpenSSF brings together work from the Linux Foundation-initiated Core Infrastructure Initiative (CII), the GitHub-initiated Open Source Security Coalition (OSSC), and other open-source security efforts to improve the security of open-source software by building a broader community, targeted initiatives, and best practices. Microsoft is proud to be a founding member alongside GitHub, Google, IBM, JPMC, NCC Group, OWASP Foundation, and Red Hat. Open-source software is core to nearly every company’s technology strategy and securing it is an essential part of securing the supply chain for all, including our own. With the ubiquity of open source software, attackers are currently exploiting vulnerabilities across a wide range of critical services and infrastructure, including utilities, medical equipment, transportation, government systems, traditional software, cloud services, hardware, and IoT. Open-source software is inherently community-driven and as such, there is no central authority responsible for quality and maintenance. Because source code can be copied and cloned, versioning and dependencies are particularly complex. Open-source software is also vulnerable to attacks against the very nature of the community, such as attackers becoming maintainers of projects and introducing malware. Given the complexity and communal nature of open source software, building better security must also be a community-driven process. Microsoft has been involved in several open-source security initiatives over the years and we are looking forward to bringing these together under the umbrella of the OpenSSF. For example, we have been actively working with OSSC in four primary areas: Identifying Security Threats to Open Source Projects Helping developers to better understand the security threats that exist in the open-source software ecosystem and how those threats impact specific open source projects. Security Tooling Providing the best security tools for open source developers, making them universally accessible and creating a space where members can collaborate to improve upon existing security tooling and develop new ones to suit the needs of the broader open source community. Security Best Practices Providing open-source developers with best practice recommendations, and with an easy way to learn and apply them. Additionally, we have been focused on ensuring best practices to be widely distributed to open source developers and will leverage an effective learning platform to do so. Vulnerability Disclosure Creating an open-source software ecosystem where the time to fix a vulnerability and deploy that fix across the ecosystem is measured in minutes, not months. We are looking forward to participating in future OpenSSF efforts including securing critical open source projects (assurance, response), developer identity, and bounty programs for open-source security bugs. We are excited and honored to be advancing the work with the OSSC into the OpenSSF and we look forward to the many improvements that will be developed as a part of this foundation with the open-source community. To learn more and to participate, please join us at: https://openssf.org and on GitHub at https://github.com/ossf. To learn more about Microsoft Security solutions visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity. Via microsoft.com

Nu e frumos si corect sa dai vina pe victime imediat. Esti tu mare intelectual pana iti iei si tu o teapa si dupa plangi si tu pe aici. Se poate intampla oricui, sunt multe situatii, oameni mai deinformati si nu e neaparat vina lor ca nu au pregatire in crypto. PS: Stiu multi 'investitori' in crypto care rad de victime de genul in timp ce ei baga 1000lei la pacanele...

Crap de ras :)))) "Nu am gasit un primar la Topoloveni, Flopanu". Concluzie: Daca auzi dedicatie de la lautari cu "imparatul femeilor", cauti repede sa vezi cine e ala. Hahahaha