Nytro

Numarul coloanelor sau al randurilor?

Poate https://phpbolt.com/ sau https://www.transfon.com/products/swoole-compiler#pricing

Te referi la codul sursa PHP? Cred ca asta era o solutie comuna: https://www.ioncube.com/

Bine ai revenit!

Nu suntem multi dar nu am plecat de aici, bine ai revenit.

Super, ai putea sa iti furi cookie-urile si sa obtii acces la contul tau de Gmail!

Frumos, mai ales ca a fost descoperita si publicata de un roman.

This laptop has seven times the average number of screens Behold, a multitasker’s dream device By Cameron Faulkner@camfaulkner Feb 8, 2021, 5:20pm EST Expanscape A company called Expanscape has created the most Inspector Gadget-like device that I’ve ever seen. It’s a laptop prototype called the Aurora 7 (a working title), and attached to its humongous black box of a chassis are six extra displays that extend out in every direction away from the main screen, each showing its own windows and applications. If you’re like me, the first thought that comes to mind is “that poor hinge!” Yeah, poor hinge, indeed. Many laptop hinges don’t gracefully handle having one screen attached, let alone seven. Piggybacking on the main 17.3-inch 4K display are three other screens of the same size and resolution. Above the left and right displays is a single seven-inch 1200p monitor. You’ll also find one more seven-inch 1200p touchscreen display mounted into the wrist rest. This prototype weighs about 26 pounds and is 4.3 inches thick. It has an imposing, intimidating presence, and I haven’t even seen it in person. Bow down to the Aurora 7. Image: Expanscape What GPU is responsible for powering its four 4K displays? None other than the midrange Nvidia GTX 1060, which isn’t exactly a powerhouse. It also has an Intel Core i9-9900K processor and 64GB of RAM. You can find more specs here. In future revisions, Expanscape wants to use the Nvidia RTX 2070 instead, with options for the AMD Ryzen 9 3950x processor or Intel’s i9-10900K. Even though it’s built primarily to be a mobile security operations station (and stay plugged pretty much all the time), maybe it’ll be able to run some games, too. Gizmodo noticed in its write-up of this gadget that its current prototype can last for just one hour before the battery cries for more power, which is frankly longer than I expected. It uses a secondary 148Wh battery just to power its additional displays, and that’s over the FAA’s legal limit to fly in a plane. Expanscape says it’s working to remedy this in future prototypes. In other words, the company is committed to letting you bring a seven-screen laptop onto a plane. You’d probably have to buy a whole row of seats for the necessary space to use it, though. (If you’re reading this in the future, please take a picture of one of these if you see it on your plane.) Sure, the Aurora 7 looks more rough around the edges than Razer’s triple-screened Project Valerie laptop from a few years ago. But nevertheless, Expanscape claims it’s willing to actually sell this thing, which is more than Razer can say about its Valerie concept. If you want to buy one, Expanscape says it can help interested parties in reserving a prototype of its upcoming revision. As for the price, the company will ask you to sign a nondisclosure agreement, prohibiting you from publicly sharing the cost. That doesn’t bode well for the bank account. I look forward to hearing more about future revisions of the Aurora 7, especially if it gets a button that makes all of the displays pop open in a comical fashion. Currently, it seems like an extremely manual process. Sursa: https://www.theverge.com/2021/2/8/22273056/expanscape-aurora-7-seven-screen-laptop

Oldie but goldie https://9gag.com/gag/a4EjRXp

Backdoored Browser Extensions Hid Malicious Traffic in Analytics Requests by Jan Vojtěšek and Jan RubínFebruary 3, 202119 min read Chances are you are reading this blog post using your web browser. Chances also are your web browser has various extensions that provide additional functionality. We usually trust that the extensions installed from official browser stores are safe. But that is not always the case as we recently found. This blog post brings more technical details on CacheFlow: a threat that we first reported about in December 2020. We described a huge campaign composed of dozens of malicious Chrome and Edge browser extensions with more than three million installations in total. We alerted both Google and Microsoft about the presence of these malicious extensions on their respective extension stores and are happy to announce that both companies have since taken all of them down as of December 18, 2020. CacheFlow was notable in particular for the way that the malicious extensions would try to hide their command and control traffic in a covert channel using the Cache-Control HTTP header of their analytics requests. We believe this is a new technique. In addition, it appears to us that the Google Analytics-style traffic was added not just to hide the malicious commands, but that the extension authors were also interested in the analytics requests themselves. We believe they tried to solve two problems, command and control and getting analytics information, with one solution. We found that CacheFlow would carry out its attack in the following sequence: High-level overview of the CacheFlow malware Based on our telemetry, the top three countries where Avast users downloaded and installed the CacheFlow extensions were Brazil, Ukraine, and France. Distribution of Avast users that installed one of the malicious extensions We initially learned about this campaign by reading a Czech blog post by Edvard Rejthar from CZ.NIC. He discovered that the Chrome extension “Video Downloader for FaceBook™” (ID pfnmibjifkhhblmdmaocfohebdpfppkf) was stealthily loading an obfuscated piece of JavaScript that had nothing to do with the extension’s advertised functionality. Continuing from his findings, we managed to find many other extensions that were doing the same thing. These other extensions offered various legitimate functionality, with many of them being video downloaders for popular social media platforms. After reverse engineering the obfuscated JavaScript, we found that the main malicious payload delivered by these extensions was responsible for malicious browser redirects. Not only that, but the cybercriminals were also collecting quite a lot of data about the users of the malicious extensions, such as all of their search engine queries or information about everything they clicked on. The extensions exhibited quite a high level of sneakiness by employing many tricks to lower the chances of detection. First of all, they avoided infecting users who were likely to be web developers. They determined this either through the extensions the user had installed or by checking if the user accessed locally-hosted websites. Furthermore, the extensions delayed their malicious activity for at least three days after installation to avoid raising red flags early on. When the malware detected that the browser developer tools were opened, it would immediately deactivate its malicious functionality. CacheFlow also checked every Google search query and if the user was googling for one of the malware’s command and control (C&C) domains, it reported this to its C&C server and could deactivate itself as well. According to user reviews on the Chrome Web Store, it seems that CacheFlow was active since at least October 2017. All of the stealthiness described above could explain why it stayed undetected for so long. User review on the Chrome Web Store from October 2017 that mentions modification of Google search results The covert channel First, we’ll show the hidden backdoor that the extensions used to download and execute arbitrary JavaScript. Specifically, we’ll describe the backdoor from the Chrome extension “Downloader for Instagram” v5.7.3 (ID olkpikmlhoaojbbmmpejnimiglejmboe), but this analysis applies to the other extensions as well, since the malicious code hidden in them is very similar in functionality. “Downloader for Instagram” page on the Chrome Web Store It is generally a good idea to start the analysis of unknown Chrome extensions from the manifest.json file. The manifest of “Downloader for Instagram” gives us some interesting pieces of information. First of all, the content_security_policy is defined in such a way that it is possible to use the infamous eval function to load additional JavaScript. However, looking for the string eval in the extension’s source code did not yield any interesting results. As we’ll show later, the extension does use the eval function quite a lot, but it hides its usage, so it is not immediately apparent. Content Security Policy definition from the manifest.json file Secondly, the extension asks for quite a lot of permissions and it is not immediately clear why these permissions would be needed to download videos from Instagram. Especially interesting is the management permission, which allows the extension to control other extensions. The combination of the webRequest and the <all_urls> permissions is also interesting. Together, these two permissions make it possible for the extension to intercept pretty much any web request coming from the browser. Permissions requested by the malicious extensions Finally, the manifest defines two background scripts: js/jquery.js and js/background.js. These scripts are persistent, which means that they will keep running unless the extension gets disabled. Background scripts declared in the manifest.json file One of these background scripts, background.js, is where the suspicious webRequest API is used. This script accesses the HTTP response headers of all intercepted web requests and stores their values in localStorage. CacheFlow saves the values of all sufficiently long HTTP response headers into localStorage. The content of localStorage is then read by the other persistent malicious background script: jquery.js. While this script appears at first glance to be the legitimate jQuery library, some additional functions were inserted into it. One of those additional functions is misleadingly named parseRelative, while all it does is return the window.localStorage object. Misleadingly named parseRelative function hidden inside jquery.js Another inserted and misleadingly named function is initAjax. initAjax function decodes the content of localStorage['cache-control'] and stores decoded values in the window object. This function is particularly interested in the content of localStorage['cache-control'], which should at this point be set to the value of the last received Cache-Control HTTP response header. The function splits the content of this header with a comma and attempts to decrypt each part using a custom function named strrevsstr, before finally parsing it out as a JSON string. strrevsstr function used by the extension to decrypt strings The obvious question now is why would the extension expect to intercept requests that contain an encrypted JSON string in the Cache-Control response header? The answer is that the threat actors are using the content of the Cache-Control header as a covert channel to send hidden commands to the malicious extension. As a part of the malicious extension’s regular functionality, analytics requests about some events are sent to https://stats.script-protection[.]com/__utm.gif. These are standard analytics requests that bear resemblance to Google Analytics. The catch is, that the server used by this extension might respond to the analytics requests with a specially formed Cache-Control header, which the client will decrypt, parse out and execute. Flow of the covert channel To see what the commands could look like, we simulated the extension and sent a fake analytics HTTP request to https://stats.script-protection[.]com/__utm.gif. After a couple of attempts, we received a specially crafted Cache-Control header. Fiddler capture of a seemingly innocent analytics request that contains a hidden command in the Cache-Control response header Note that the response will contain the encoded command only when some conditions are met. First of all, the GET parameter it has to be set at least three days into the past. Since this parameter contains the time when the extension was installed, this effectively ensures that the extension will not exhibit any malicious behavior during the first three days. There is also a check based on the IP address, since we repeatedly did not receive any commands from one source IP address, even though we did receive a command for the same GET request from another IP address. As the logic behind these checks is safely hidden on the C&C server, there might be additional checks that we are not aware of. When the content of the received Cache-Control header is decoded using the custom strrevsstr function as outlined above, we get the command in the following JSON. As was seen in the initAjax function, all of the attributes from this JSON get stored in the global window object. Command decoded from the Cache-Control response header Upon receiving such a command, the extension downloads the second stage from command['uu'] in a function named siblingAfter, which is also hidden inside jquery.js. The dollar sign from command['jj'] here represents the jQuery object, so the function uses the jQuery.get function to download the next stage from command['uu'] and to store it in localStorage.dataDefault. Code snippet that downloads the next stage from the URL specified in command['uu'] Finally, there is yet another function hidden in jquery.js, which executes the downloaded JavaScript using the eval function from command['ee']. Code snippet that uses the eval function on the downloaded JavaScript The downloaded JavaScript is an obfuscated intermediary downloader. Its purpose is to download the third-stage payload from ulkon.johnoil[.]com using an XHR request. Unfortunately, because the server will only send the next stage under certain conditions, getting a response containing the third stage can be quite tricky. If it gets successfully downloaded, it is encrypted and stored persistently in localStorage. It then gets executed whenever a tab is updated using the chrome.tabs.onUpdated listener. Intermediary downloader serves as the second stage of the malware. The payload The payload starts out by testing if it can make use of eval and localStorage. If either of those two is not working properly, CacheFlow would not be able to perform most of its malicious functionality. Deobfuscated snippet of the payload which tests if the eval function works by adding two random numbers Additionally, the payload periodically checks if developer tools are opened. If they are, it deactivates itself in an attempt to avoid detection. The check for developer tools is also performed whenever the current window gets resized, which might be because the user just opened developer tools. Deobfuscated snippet of code that checks if the developer tools are opened As was already mentioned, the malware authors have gone to extreme lengths to make sure that the hidden malicious payloads do not get discovered. We believe they were not satisfied with the previous check and decided to further profile the victim in order to avoid infecting users who seemed more tech-savvy. One of the ways they did this was by enumerating the other extensions installed by the victim and checking them against a hardcoded list of extension IDs. Each extension on the list was assigned a score and if the sum of scores of installed extensions exceeded a certain threshold, the list of extensions would be sent to the C&C server, which could then command the malicious payload to deactivate. Examples of the extensions on the list were “Chrome extension source viewer”, “Link Redirect Trace”, or “JWT Debugger”. We believe this “weighting” system helped to better differentiate actual developer systems which would have several of these extensions and a higher score from casual users who would have fewer extensions and thus a lower score. Deobfuscated snippet of code that enumerates other extensions installed by the victim Another way to profile the potential victim was to check the URLs they were browsing. Whenever the victim navigated to a URL identified by an IP address from one of the private IPv4 ranges or to a URL with a TLD .dev, .local, or .localhost, the malware would send the visited URL to its C&C server. The malware also checked all Google (and only Google) queries against a regular expression that matched its C&C domains and internal identifiers. This way, it would know that somebody was taking a deeper look into the extension and could take actions to hide itself. Interestingly, the domains were not fully specified in the regular expressions, with some characters being represented as the dot special character. We assume that this was an attempt to make it harder to create a domain blocklist based on the regular expression. Regular expression used to detect if the victim is googling one of the malware’s C&C domains At this point, the malware also attempted to gather information about the victim. This information included birth dates, email addresses, geolocation, and device activity. For instance, the birth dates were retrieved from the personal information entered into the victim’s Google account. Once again, the attackers focused only on Google: we did not see any similar attempts to get Microsoft account information. To retrieve the birthday, CacheFlow made an XHR request to https://myaccount.google.com/birthday and parsed out the birth date from the response. Deobfuscated snippet of code where the malware attempts to obtain the birth date of the victim Note that while it may seem that making such a cross-origin request would not be allowed by the browser, this is all perfectly possible under the extension security model since the extension has the <all_urls> permission. This permission gives the extension access to all hosts, so it can make arbitrary cross-site requests. In order to make it harder for Google to realize that CacheFlow was abusing its services to gather personal information, it also registered a special chrome.webRequest.onBeforeSendHeaders listener. This listener removes the referer request header from all the relevant XHR requests, so Google would not easily know who is actually making the request. Deobfuscated snippet of code where the malware removes the referer from requests to Google Finally, to perform its main malicious functionality, the payload injects another piece of JavaScript into each tab using the chrome.tabs.executeScript function. The injected script The injected script implements two pieces of functionality. The first one is about hijacking clicks. When the victim clicks on a link, the extension sends information about the click to orgun.johnoil[.]com and might receive back a command to redirect the victim to a different URL. The second functionality concerns search engine results. When the victim is on a search engine page, the extension gathers the search query and results. This information is then sent to the C&C server, which might respond with a command to redirect some of the search results. Link hijacking The link hijacking is implemented by registering an onclick listener over the whole document. Deobfuscated snippet of code showing the registration of the onclick listener The listener is then only interested in main button presses (usually “left clicks”) and clicks on elements with the tag name a or area. If the click meets all the criteria, an XHR request to https://orgun.johnoil[.]com/link/ is sent. This request contains one GET parameter, a, which holds concatenated information about the click and is encrypted using the custom strsstr function. This information includes the current location, the target URL, various identifiers, and more. We simulated a fake request about a click to a link leading to https://facebook[.]com and received the following response: ayiudvh3jk6lNjkzMTQ0eAgYGAQRFhNYTVxbE04IBlFDFgEEHBtYQV0HThdXEwJRBANSUVBEDghQCgNOWUMXAhskaiohB3Z4YQlvSU8oaygLZkhBYCJlAW9Rf18Ecyg1TmZdFEQZABACXHxaInY0MklVQlUeTAozcyUSOwABdW9oAXUXGjswNQpgTkkzZSZFMxMJanwqQj1NDixsflIuWAl6kj3hvduiya Upon receiving such a response, the malware first makes sure that it starts with a certain randomly generated string and ends with the same string, but in reverse. This string (ayiudvh3jk6l highlighted in the example above) was generated by the extension and was also included in the a parameter that was sent in the XHR request. The extension then takes the middle portion of the response and decrypts it using the strrevsstr function (which is the inversion of strsstr). This yields the following string: ayiudvh3jk6lhttps://go.lnkam[.]com/link/r?u=https%3A%2F%2Fwww.facebook[.]com%2F&campaign_id=b7YMMAqMdAL7wyzNe5m3wz&source=uvm3rdsqc9zo69l6kj3hvduiya Once again, the malware checks the beginning and the end of the decrypted string for the same randomly generated string as used before and extracts the middle portion of it. If it begins with the substring http, the malware proceeds to perform the link hijack. It does this by temporarily changing the href attribute of the element that the user clicked on and executing the click method on it to simulate a mouse click. As a fallback mechanism, the malware just simply sets window.location['href'] to the link hijack URL. Deobfuscated snippet of code that shows how the malware hijacks the victim’s clicks Modification of search results The second functionality is performed only if the victim is currently on a Google, Bing, or Yahoo search page. If they are, the malware first gathers the search query string and the results. The way this is performed varies based on the search engine. For Google, the search query string is found as the value of the first element named q. If that somehow fails, the malware alternatively tries to get the search query from the q GET parameter. Deobfuscated snippet of code that shows how the malware obtains the search query The search results on Google are obtained by searching for elements with the class name rc and then iterating over their child a elements. Deobfuscated snippet of code that shows how the malware obtains the search results Once gathered, the search query and results are sent in an XHR request to servscrpt[.]de. A salted MD5 checksum of the results is included in the request as well, we believe in an attempt to discover fake requests (but this check can obviously be trivially bypassed by recomputing the MD5 checksum). The XHR response contains a list of domains whose links the malware should hijack. The hijack itself is performed by registering an onmousedown listener on the a element. Once fired, the listener calls the preventDefault function on the event and then window.open to redirect the user to the malicious URL. Interestingly, CacheFlow also modifies some of the hijacked search results by adding a clickable logo to them. We believe this is done in order to make those results stand out and thus increase the chances of the victim clicking on them. However, the position of the logo is not aligned well, which makes the search result look odd and suspicious, since Google, Microsoft, or Yahoo would probably put a bit more effort into formatting it. Comparison of the original Google search result (top) with the result that was modified by the malware (bottom) The logo is added by creating a brand new div element which holds an img element. Once created and formatted, this element is inserted into the DOM, so that it appears to the left of the original search result. The logo is obtained from the serviceimg[.]de domain, which serves a unique 90×45 logo per domain. Deobfuscated snippet of code where the malware creates an element with the added logo Conclusion In this blog post, we provided technical details about CacheFlow: a huge network of malicious browser extensions that infected millions of users worldwide. We described how the malicious extensions were hijacking their victims’ clicks and modifying their search engine results. Since CacheFlow was well capable of hiding itself, we covered in detail the techniques it was using to hide the fact that it was executing malicious code in the background. We believe that understanding how these techniques work will help other malware researchers in discovering and analyzing similar threats in the future. Indicators of Compromise The full list of IoCs is available at https://github.com/avast/ioc/tree/master/CacheFlow. Name Hash manifest.json 2bc86c14609928183bf3d94e1b6f082a07e6ce0e80b1dffc48d3356b6942c051 background.js bdd2ec1f2e5cc0ba3980f7f96cba5bf795a6e012120db9cab0d8981af3fa7f20 jquery.js 3dad00763b7f97c27d481242bafa510a89fed19ba60c9487a65fa4e86dcf970d Intermediary downloader 4e236104f6e155cfe65179e7646bdb825078a9fea39463498c5b8cd99d409e7a Payload ebf6ca39894fc7d0e634bd6747131efbbd0d736e65e68dcc940e3294d3c93df4 Injected script 0f99ec8031d482d3cefa979fbd61416558e03a5079f43c2d31aaf4ea20ce28a0 Chrome Extension Name Extension ID Direct Message for Instagram mdpgppkombninhkfhaggckdmencplhmg DM for Instagram fgaapohcdolaiaijobecfleiohcfhdfb Invisible mode for Instagram Direct Message iibnodnghffmdcebaglfgnfkgemcbchf Downloader for Instagram olkpikmlhoaojbbmmpejnimiglejmboe App Phone for Instagram bhfoemlllidnfefgkeaeocnageepbael Stories for Instagram nilbfjdbacfdodpbdondbbkmoigehodg Universal Video Downloader eikbfklcjampfnmclhjeifbmfkpkfpbn Video Downloader for FaceBook™ pfnmibjifkhhblmdmaocfohebdpfppkf Vimeo™ Video Downloader cgpbghdbejagejmciefmekcklikpoeel Zoomer for Instagram and FaceBook klejifgmmnkgejbhgmpgajemhlnijlib VK UnBlock. Works fast. ceoldlgkhdbnnmojajjgfapagjccblib Odnoklassniki UnBlock. Works quickly. mnafnfdagggclnaggnjajohakfbppaih Upload photo to Instagram™ oknpgmaeedlbdichgaghebhiknmghffa Spotify Music Downloader pcaaejaejpolbbchlmbdjfiggojefllp The New York Times News lmcajpniijhhhpcnhleibgiehhicjlnk FORBES lgjogljbnbfjcaigalbhiagkboajmkkj Скачать фото и видео из Instagram akdbogfpgohikflhccclloneidjkogog Edge Extension Name Extension ID Direct Message for Instagram™ lnocaphbapmclliacmbbggnfnjojbjgf Instagram Download Video & Image bhcpgfhiobcpokfpdahijhnipenkplji App Phone for Instagram dambkkeeabmnhelekdekfmabnckghdih Universal Video Downloader dgjmdlifhbljhmgkjbojeejmeeplapej Video Downloader for FaceBook™ emechknidkghbpiodihlodkhnljplpjm Vimeo™ Video Downloader hajlccgbgjdcjaommiffaphjdndpjcio Volume Controller dljdbmkffjijepjnkonndbdiakjfdcic Stories for Instagram cjmpdadldchjmljhkigoeejegmghaabp Upload photo to Instagram™ jlkfgpiicpnlbmmmpkpdjkkdolgomhmb Pretty Kitty, The Cat Pet njdkgjbjmdceaibhngelkkloceihelle Video Downloader for YouTube phoehhafolaebdpimmbmlofmeibdkckp SoundCloud Music Downloader pccfaccnfkjmdlkollpiaialndbieibj Instagram App with Direct Message DM fbhbpnjkpcdmcgcpfilooccjgemlkinn Downloader for Instagram aemaecahdckfllfldhgimjhdgiaahean URL abuse-extensions[.]com ampliacion[.]xyz a.xfreeservice[.]com b.xfreeservice[.]com c.xfreeservice[.]com browser-stat[.]com check-stat[.]com check4.scamprotection[.]net connecting-to-the[.]net cornewus[.]com downloader-ig[.]com exstats[.]com ext-feedback[.]com extstatistics[.]com figures-analysis[.]com huffily.mydiaconal[.]com jastats[.]com jokopinter[.]com limbo-urg[.]com mydiaconal[.]com notification-stat[.]com orgun.johnoil[.]com outstole.my-sins[.]com peta-line[.]com root.s-i-z[.]com s3.amazonaws[.]com/directcdn/j6dle93f17c30.js s3.amazonaws[.]com/wwwjs/ga9anf7c53390.js s3.amazonaws[.]com/wwwjs/hc8e0ccd7266c.js s3.amazonaws[.]com/protectscript/instagram-downloader.js safenewtab[.]com script-protection[.]com server-status[.]xyz serviceimg[.]de servscrpt[.]de stats.script-protection[.]com statslight[.]com ulkon.johnoil[.]com user-experience[.]space user-feedbacks[.]com user.ampliacion[.]xyz xf.gdprvalidate[.]de/partner/8otb939m/index.php Sirsa: https://decoded.avast.io/janvojtesek/backdoored-browser-extensions-hid-malicious-traffic-in-analytics-requests/

A fost anul trecut prin Aprilie cred, o luna free pentru oricine. Am avut si eu, merita. De fapt merita sa cumper 1-2 luni, cred ca e vreo 20-30 USD pe luna si daca stai de ele, chiar merita.

Afara-i frig dar noua nu ne pasa Cand femeile danseaza sus pe masa. Maneaua urla, baietii se imbata Asta-i petrecere adevarata. Mai ceva ca Salam.

Nu cred ca e nimic in neregula.

Pff, shellshock in 2021.

<?php function getRandom() { $a = str_split("1234567890qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM"); shuffle ($a); $r = implode($a); $f = substr($r,0,16); return $f; } for($i = 0; $i < 10; $i++) print getRandom() . "\r\n"; ?>

<?php //Enter your code here, enjoy! $a = str_split("1234567890qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM"); shuffle ($a); $r = implode($a); $f = substr($r,0,16); print $f; ?> Facut rapid, sunt multe alte metode. PS: Nu e cryptographically secure.

Salut, e ciudat. Nu te poti loga cu numarul de telefon? Forgot password nu merge in niciun fel? Aveai o parola slaba? Totusi, e ciudat. Poti incerca si cu support-ul Facebook, dar slabe sanse acolo.

That's some new level of shit E de ajuns. A venit momentul sa aflati adevarul. Eu sunt Dumnezeu si Eu i-am indrumat pe cercetatori sa descopere vaccinul pentru a salva omenirea. Asa cum Noe a salvat-o, asa vaccinul o va salva acum. Acesta este planul Meu. Doar pacatosii vor evita vaccinul si ei sunt condamnati pieirii. Nu credeti ca Eu sunt Dumnezeu? Aveti vreo dovada? Demonstrati-mi ca nu e asa. Si mai ziceti si voi cate o rugaciune ceva, lasati acel website, Pornhub, ca e plin de pacate.

[]string{"rixama1489@jentrix.com"}, // recipients' address

CVE-2021-3156: Heap-Based Buffer Overflow in Sudo (Baron Samedit) Animesh Jain, Vulnerability Signatures Product Manager, Qualys January 26, 2021 - 8 min read 3 The Qualys Research Team has discovered a heap overflow vulnerability in sudo, a near-ubiquitous utility available on major Unix-like operating systems. Any unprivileged user can gain root privileges on a vulnerable host using a default sudo configuration by exploiting this vulnerability. Sudo is a powerful utility that’s included in most if not all Unix- and Linux-based OSes. It allows users to run programs with the security privileges of another user. The vulnerability itself has been hiding in plain sight for nearly 10 years. It was introduced in July 2011 (commit 8255ed69) and affects all legacy versions from 1.8.2 to 1.8.31p2 and all stable versions from 1.9.0 to 1.9.5p1 in their default configuration. Successful exploitation of this vulnerability allows any unprivileged user to gain root privileges on the vulnerable host. Qualys security researchers have been able to independently verify the vulnerability and develop multiple variants of exploit and obtain full root privileges on Ubuntu 20.04 (Sudo 1.8.31), Debian 10 (Sudo 1.8.27), and Fedora 33 (Sudo 1.9.2). Other operating systems and distributions are also likely to be exploitable. As soon as the Qualys research team confirmed the vulnerability, Qualys engaged in responsible vulnerability disclosure and coordinated with sudo’s author and open source distributions to announce the vulnerability. Disclosure Timeline 2021-01-13: Advisory sent to Todd.Miller@sudo 2021-01-19: Advisory and patches sent to distros@openwall 2021-01-26: Coordinated Release Date (6:00 PM UTC) Proof of Concept Video Technical Details If Sudo is executed to run a command in “shell” mode (shell -c command): either through the -s option, which sets Sudo’s MODE_SHELL flag; OR through the -i option, which sets Sudo’s MODE_SHELL and MODE_LOGIN_SHELL flags; then, at the beginning of Sudo’s main(), parse_args() rewrites argv (lines 609-617), by concatenating all command-line arguments (lines 587-595) and by escaping all meta-characters with backslashes (lines 590-591): -------------------------------------------------------------------- 571 if (ISSET(mode, MODE_RUN) && ISSET(flags, MODE_SHELL)) { 572 char **av, *cmnd = NULL; 573 int ac = 1; ... 581 cmnd = dst = reallocarray(NULL, cmnd_size, 2); ... 587 for (av = argv; *av != NULL; av++) { 588 for (src = *av; *src != '\0'; src++) { 589 /* quote potential meta characters */ 590 if (!isalnum((unsigned char)*src) && *src != '_' && *src != '-' && *src != '$') 591 *dst++ = '\\'; 592 *dst++ = *src; 593 } 594 *dst++ = ' '; 595 } ... 600 ac += 2; /* -c cmnd */ ... 603 av = reallocarray(NULL, ac + 1, sizeof(char *)); ... 609 av[0] = (char *)user_details.shell; /* plugin may override shell */ 610 if (cmnd != NULL) { 611 av[1] = "-c"; 612 av[2] = cmnd; 613 } 614 av[ac] = NULL; 615 616 argv = av; 617 argc = ac; 618 } --------------------------------------------------------------------- Later, in sudoers_policy_main(), set_cmnd() concatenates the command-line arguments into a heap-based buffer “user_args” (lines 864-871) and unescapes the meta-characters (lines 866-867), “for sudoers matching and logging purposes”: -------------------------------------------------------------- 819 if (sudo_mode & (MODE_RUN | MODE_EDIT | MODE_CHECK)) { ... 852 for (size = 0, av = NewArgv + 1; *av; av++) 853 size += strlen(*av) + 1; 854 if (size == 0 || (user_args = malloc(size)) == NULL) { ... 857 } 858 if (ISSET(sudo_mode, MODE_SHELL|MODE_LOGIN_SHELL)) { ... 864 for (to = user_args, av = NewArgv + 1; (from = *av); av++) { 865 while (*from) { 866 if (from[0] == '\\' && !isspace((unsigned char)from[1])) 867 from++; 868 *to++ = *from++; 869 } 870 *to++ = ' '; 871 } ... 884 } ... 886 } --------------------------------------------------------------------- Unfortunately, if a command-line argument ends with a single backslash character, then: at line 866, “from[0]” is the backslash character, and “from[1]” is the argument’s null terminator (i.e., not a space character); at line 867, “from” is incremented and points to the null terminator; at line 868, the null terminator is copied to the “user_args” buffer, and “from” is incremented again and points to the first character after the null terminator (i.e., out of the argument’s bounds); the “while” loop at lines 865-869 reads and copies out-of-bounds characters to the “user_args” buffer. In other words, set_cmnd() is vulnerable to a heap-based buffer overflow, because the out-of-bounds characters that are copied to the “user_args” buffer were not included in its size (calculated at lines852-853). In theory, however, no command-line argument can end with a single backslash character: if MODE_SHELL or MODE_LOGIN_SHELL is set (line 858, a necessary condition for reaching the vulnerable code), then MODE_SHELL is set (line 571) and parse_args() already escaped all meta-characters, including backslashes (i.e., it escaped every single backslash with a second backslash). In practice, however, the vulnerable code in set_cmnd() and the escape code in parse_args() are surrounded by slightly different conditions: --------------------------------------------------------------------- 819 if (sudo_mode & (MODE_RUN | MODE_EDIT | MODE_CHECK)) { ... 858 if (ISSET(sudo_mode, MODE_SHELL|MODE_LOGIN_SHELL)) { --------------------------------------------------------------------- versus: --------------------------------------------------------------------- 571 if (ISSET(mode, MODE_RUN) && ISSET(flags, MODE_SHELL)) { --------------------------------------------------------------------- Our question is: can we set MODE_SHELL and either MODE_EDIT or MODE_CHECK (to reach the vulnerable code) but not the default MODE_RUN (to avoid the escape code)? The answer, it seems, is no: if we set MODE_EDIT (-e option, line 361) or MODE_CHECK (-l option, lines 423 and 519), then parse_args() removes MODE_SHELL from the “valid_flags” (lines 363 and 424) and exits with an error if we specify an invalid flag such as MODE_SHELL (lines 532-533): --------------------------------------------------------------------- 358 case 'e': ... 361 mode = MODE_EDIT; 362 sudo_settings[ARG_SUDOEDIT].value = "true"; 363 valid_flags = MODE_NONINTERACTIVE; 364 break; ... 416 case 'l': ... 423 mode = MODE_LIST; 424 valid_flags = MODE_NONINTERACTIVE|MODE_LONG_LIST; 425 break; ... 518 if (argc > 0 && mode == MODE_LIST) 519 mode = MODE_CHECK; ... 532 if ((flags & valid_flags) != flags) 533 usage(1); --------------------------------------------------------------------- But we found a loophole: if we execute Sudo as “sudoedit” instead of “sudo”, then parse_args() automatically sets MODE_EDIT (line 270) but does not reset “valid_flags”, and the “valid_flags” include MODE_SHELL by default (lines 127 and 249): --------------------------------------------------------------------- 127 #define DEFAULT_VALID_FLAGS (MODE_BACKGROUND|MODE_PRESERVE_ENV|MODE_RESET_HOME|MODE_LOGIN_SHELL|MODE_NONINTERACTIVE|MODE_SHELL) ... 249 int valid_flags = DEFAULT_VALID_FLAGS; ... 267 proglen = strlen(progname); 268 if (proglen > 4 && strcmp(progname + proglen - 4, "edit") == 0) { 269 progname = "sudoedit"; 270 mode = MODE_EDIT; 271 sudo_settings[ARG_SUDOEDIT].value = "true"; 272 } ------------------------------------------------------------------------ Consequently, if we execute “sudoedit -s”, then we set both MODE_EDIT and MODE_SHELL (but not MODE_RUN), we avoid the escape code, reach the vulnerable code, and overflow the heap-based buffer “user_args” through a command-line argument that ends with a single backslash character: --------------------------------------------------------------------- sudoedit -s '\' `perl -e 'print "A" x 65536'` malloc(): corrupted top size Aborted (core dumped) --------------------------------------------------------------------- From an attacker’s point of view, this buffer overflow is ideal due to following reasons: 1) The attacker controls the size of the “user_args” buffer that can be overflowed (the size of our concatenated command-line arguments, at lines 852-854); 2) The attacker independently controls the size and contents of the overflow itself (our last command-line argument is conveniently followed by our first environment variables, which are not included in the size calculation at lines 852-853); 3) The attacker can even write null bytes to the buffer that was overflowed (every command-line argument or environment variable that ends with a single backslash writes a null byte to “user_args”, at lines 866-868). For example, on an amd64 Linux, the following command allocates a 24-byte “user_args” buffer (a 32-byte heap chunk) and overwrites the next chunk’s size field with “A=a\0B=b\0” (0x00623d4200613d41), its fd field with “C=c\0D=d\0” (0x00643d4400633d43), and its bk field with “E=e\0F=f\0” (0x00663d4600653d45): --------------------------------------------------------------------- env -i 'AA=a\' 'B=b\' 'C=c\' 'D=d\' 'E=e\' 'F=f' sudoedit -s '1234567890123456789012\' --------------------------------------------------------------------- --|--------+--------+--------+--------|--------+--------+--------+--------+-- | | |12345678|90123456|789012.A|A=a.B=b.|C=c.D=d.|E=e.F=f.| --|--------+--------+--------+--------|--------+--------+--------+--------+-- size <---- user_args buffer ----> size fd bk Solution Given the breadth of the attack surface for this vulnerability, Qualys recommends users apply patches for this vulnerability immediately. Qualys customers can search the vulnerability knowledgebase for CVE-2021-3156 to identify all the QIDs and assets vulnerable for this vulnerability. If you are not a customer, start your free Qualys VMDR trial to get full access to the QIDs (detections) for CVE-2021-3156, so you can identify your vulnerable assets. Qualys Coverage QID 374891: Sudo Heap-Based Buffer Overflow Vulnerability With VMDR Dashboard, you can track this vulnerability, their impacted hosts, their status and overall management in real time. With trending enabled for dashboard widgets, you can keep track of these vulnerabilities trends in your environment using the “Baron Samedit | Heap-based buffer overflow Sudo” Dashboard. View and download the Baron Samedit dashboard. Baron Samedit dashboard Vendor References Baron Samedit Security Advisory (All Qualys Security Advisories) Sudo Alert for Baron Samedit (All Sudo Security Alerts) Frequently Asked Questions (FAQs) What versions are vulnerable? The following versions of sudo are vulnerable: All legacy versions from 1.8.2 to 1.8.31p2 All stable versions from 1.9.0 to 1.9.5p1 How can I test if I have vulnerable version? To test if a system is vulnerable or not, login to the system as a non-root user. Run command “sudoedit -s /” If the system is vulnerable, it will respond with an error that starts with “sudoedit:” If the system is patched, it will respond with an error that starts with “usage:” Are versions before 1.8.2 vulnerable? No. See explanation above. Is a local user required to exploit the vulnerability? Yes, however this user does not need to be a privileged user or be a part of sudoers list. For example, even account ‘nobody’ can exploit the issue. Why name the vulnerability “Baron Samedit”? It’s a play on Baron Samedi and sudoedit. Will Qualys Research Team publish exploit code for this vulnerability? No. Written by Animesh Jain, Vulnerability Signatures Product Manager, Qualys Sursa: https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit

New campaign targeting security researchers Adam Weidemann Threat Analysis Group Published Jan 25, 2021 Over the past several months, the Threat Analysis Group has identified an ongoing campaign targeting security researchers working on vulnerability research and development at different companies and organizations. The actors behind this campaign, which we attribute to a government-backed entity based in North Korea, have employed a number of means to target researchers which we will outline below. We hope this post will remind those in the security research community that they are targets to government-backed attackers and should remain vigilant when engaging with individuals they have not previously interacted with. In order to build credibility and connect with security researchers, the actors established a research blog and multiple Twitter profiles to interact with potential targets. They've used these Twitter profiles for posting links to their blog, posting videos of their claimed exploits and for amplifying and retweeting posts from other accounts that they control. Actor controlled Twitter profiles. Their blog contains write-ups and analysis of vulnerabilities that have been publicly disclosed, including “guest” posts from unwitting legitimate security researchers, likely in an attempt to build additional credibility with other security researchers. Example of an analysis done by the actor about a publicly disclosed vulnerability. While we are unable to verify the authenticity or the working status of all of the exploits that they have posted videos of, in at least one case, the actors have faked the success of their claimed working exploit. On Jan 14, 2021, the actors shared via Twitter a YouTube video they uploaded that proclaimed to exploit CVE-2021-1647, a recently patched Windows Defender vulnerability. In the video, they purported to show a successful working exploit that spawns a cmd.exe shell, but a careful review of the video shows the exploit is fake. Multiple comments on YouTube identified that the video was faked and that there was not a working exploit demonstrated. After these comments were made, the actors used a second Twitter account (that they control) to retweet the original post and claim that it was “not a fake video.” Tweets demonstrating the actors' “exploits” Security researcher targeting The actors have been observed targeting specific security researchers by a novel social engineering method. After establishing initial communications, the actors would ask the targeted researcher if they wanted to collaborate on vulnerability research together, and then provide the researcher with a Visual Studio Project. Within the Visual Studio Project would be source code for exploiting the vulnerability, as well as an additional DLL that would be executed through Visual Studio Build Events. The DLL is custom malware that would immediately begin communicating with actor-controlled C2 domains. An example of the VS Build Event can be seen in the image below. Visual Studio Build Events command executed when building the provided VS Project files In addition to targeting users via social engineering, we have also observed several cases where researchers have been compromised after visiting the actors’ blog. In each of these cases, the researchers have followed a link on Twitter to a write-up hosted on blog.br0vvnn[.]io, and shortly thereafter, a malicious service was installed on the researcher’s system and an in-memory backdoor would begin beaconing to an actor-owned command and control server. At the time of these visits, the victim systems were running fully patched and up-to-date Windows 10 and Chrome browser versions. At this time we’re unable to confirm the mechanism of compromise, but we welcome any information others might have. Chrome vulnerabilities, including those being exploited in the wild (ITW), are eligible for reward payout under Chrome's Vulnerability Reward Program. We encourage anyone who discovers a Chrome vulnerability to report that activity via the Chrome VRP submission process. These actors have used multiple platforms to communicate with potential targets, including Twitter, LinkedIn, Telegram, Discord, Keybase and email. We are providing a list of known accounts and aliases below. If you have communicated with any of these accounts or visited the actors’ blog, we suggest you review your systems for the IOCs provided below. To date, we have only seen these actors targeting Windows systems as a part of this campaign. If you are concerned that you are being targeted, we recommend that you compartmentalize your research activities using separate physical or virtual machines for general web browsing, interacting with others in the research community, accepting files from third parties and your own security research. Actor controlled sites and accounts Research Blog https://blog.br0vvnn[.]io Twitter Accounts https://twitter.com/br0vvnn https://twitter.com/BrownSec3Labs https://twitter.com/dev0exp https://twitter.com/djokovic808 https://twitter.com/henya290 https://twitter.com/james0x40 https://twitter.com/m5t0r https://twitter.com/mvp4p3r https://twitter.com/tjrim91 https://twitter.com/z0x55g LinkedIn Accounts https://www.linkedin.com/in/billy-brown-a6678b1b8/ https://www.linkedin.com/in/guo-zhang-b152721bb/ https://www.linkedin.com/in/hyungwoo-lee-6985501b9/ https://www.linkedin.com/in/linshuang-li-aa696391bb/ https://www.linkedin.com/in/rimmer-trajan-2806b21bb/ Keybase https://keybase.io/zhangguo Telegram https://t.me/james50d Sample Hashes https://www.virustotal.com/gui/file/4c3499f3cc4a4fdc7e67417e055891c78540282dccc57e37a01167dfe351b244/detection (VS Project DLL) https://www.virustotal.com/gui/file/68e6b9d71c727545095ea6376940027b61734af5c710b2985a628131e47c6af7/detection (VS Project DLL) https://www.virustotal.com/gui/file/25d8ae4678c37251e7ffbaeddc252ae2530ef23f66e4c856d98ef60f399fa3dc/detection (VS Project Dropped DLL) https://www.virustotal.com/gui/file/a75886b016d84c3eaacaf01a3c61e04953a7a3adf38acf77a4a2e3a8f544f855/detection (VS Project Dropped DLL) https://www.virustotal.com/gui/file/a4fb20b15efd72f983f0fb3325c0352d8a266a69bb5f6ca2eba0556c3e00bd15/detection (Service DLL) C2 Domains: Attacker-Owned angeldonationblog[.]com codevexillium[.]org investbooking[.]de krakenfolio[.]com opsonew3org[.]sg transferwiser[.]io transplugin[.]io C2 Domains: Legitimate but Compromised trophylab[.]com www.colasprint[.]com www.dronerc[.]it www.edujikim[.]com www.fabioluciani[.]com C2 URLs https[:]//angeldonationblog[.]com/image/upload/upload.php https[:]//codevexillium[.]org/image/download/download.asp https[:]//investbooking[.]de/upload/upload.asp https[:]//transplugin[.]io/upload/upload.asp https[:]//www.dronerc[.]it/forum/uploads/index.php https[:]//www.dronerc[.]it/shop_testbr/Core/upload.php https[:]//www.dronerc[.]it/shop_testbr/upload/upload.php https[:]//www.edujikim[.]com/intro/blue/insert.asp https[:]//www.fabioluciani[.]com/es/include/include.asp http[:]//trophylab[.]com/notice/images/renewal/upload.asp http[:]//www.colasprint[.]com/_vti_log/upload.asp Host IOCs Registry Keys HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\KernelConfig HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverConfig HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\SSL Update File Paths C:\Windows\System32\Nwsapagent.sys C:\Windows\System32\helpsvc.sys C:\ProgramData\USOShared\uso.bin C:\ProgramData\VMware\vmnat-update.bin C:\ProgramData\VirtualBox\update.bin Sursa: https://blog.google/threat-analysis-group/new-campaign-targeting-security-researchers/

Pff https://www.hackerville.ro/2021/01/24/hackerii-te-pot-lasa-fara-conturi/ "Hackerii folosesc coduri rău intenționate, dar majoritatea se ascund doar la vedere. Poate fi extrem de eficient."

Dar de ce sa poata fi folosit doar la adresa din contract? Poate voiam sa ma duc prin Sahara cu el.

Da, recomand orice face Pavel Yosifovich. Si desigur, cartea Windows Internal 7. Desi nu e orientat pe security, pentru cei care vor sa invete lucruri in zona aceasta, e obligatoriu sa stii cum "merg" lucrurile prin ring0.

Bad Pods: Kubernetes Pod Privilege Escalation Seth Art on Jan 19, 2021 5:26:38 AM What are the risks associated with overly permissive pod creation in Kubernetes? The answer varies based on which of the host’s namespaces and security contexts are allowed. In this post, I will describe eight insecure pod configurations and the corresponding methods to perform privilege escalation. This article and the accompanying repository were created to help penetration testers and administrators better understand common misconfiguration scenarios. If you are an administrator, I hope that this post gives you the confidence to apply restrictive controls around pod creation by default. I also hope it helps you consider isolating any pods that need access to the host’s resources to a namespace that is only accessible to administrators using the principle of least privilege. If you are a penetration tester, I hope this post provides you with some ideas on how to demonstrate the impact of an overly permissive pod security policy. And I hope that the repository gives you some easy-to-use manifests and actionable steps to achieve those goals. Executive Summary: One of the foundations of information security is the "principal of least privilege." This means that every user, system process, or application needs to operate using the least set of privileges required to do a task. When privileges are configured where they greatly exceed what is required, attackers can take advantage of these situations to access sensitive data, compromise systems, or escalate those privileges to conduct lateral movement in a network. Kubernetes and other new "DevOps" technologies are complex to implement properly and are often deployed misconfigured or configured with more permissions than necessary. The lesson, as we have demonstrated from our "Bad Pods" research, is that if you are using Kubernetes in your infrastructure, you need to find out from your development team how they are configuring and hardening this environment. HARDENING PODS: HOW RISKY CAN A SINGLE ATTRIBUTE BE? When it comes to Kubernetes security best practices, every checklist worth its salt mentions that you want to use the principle of least privilege when provisioning pods. But how can we enforce granular security controls and how do we evaluate the risk of each attribute? A Kubernetes administrator can enforce the principle of least privilege using admission controllers. For example, there’s a built-in Kubernetes controller called PodSecurityPolicy and also a popular third-party admission controller called OPA Gatekeeper. Admission controllers allow you to deny a pod entry into the cluster if it has more permissions than the policy allows. However, even though the controls exist to define and enforce policy, the real-world security implications of allowing each specific attribute is not always understood, and quite often, pod creation is not as locked down as it needs to be. As a penetration tester, you might find yourself with access to create pods on a cluster where there is no policy enforcement. This is what I like to refer to as “easy mode.” Use this manifest from Rory McCune (@raesene), this command from Duffie Cooley (@mauilion), or the node-shell krew plugin and you will have fully interactive privileged code execution on the underlying host. It doesn’t get easier than that! But what if you can create a pod with just, hostNetwork, hostPID, hostIPC, hostPath, or privileged? What can you do in each case? Let’s take a look! BAD PODS - ATTRIBUTES AND THEIR WORST-CASE SECURITY IMPACT The pods below are loosely ordered from highest to lowest security impact. Note that the generic attack paths that could affect any Kubernetes pod (e.g., checking to see if the pod can access the cloud provider’s metadata service or identifying misconfigured Kubernetes RBAC) are covered in Bad Pod #8: Nothing allowed. THE BAD PODS LINEUP Pods Bad Pod #1: Everything allowed Bad Pod #2: Privileged and hostPid Bad Pod #3: Privileged only Bad Pod #4: hostPath only Bad Pod #5: hostPid only Bad Pod #6: hostNetwork only Bad Pod #7: hostIPC only Bad Pod #8: Nothing allowed BAD POD #1: EVERYTHING ALLOWED What’s the worst that can happen? Multiple paths to full cluster compromise How? The pod you create mounts the host’s filesystem to the pod. You’ll have the best luck if you can schedule your pod on a control-plane node using the nodeName selector in your manifest. You then exec into your pod and chroot to the directory where you mounted the host’s filesystem. You now have root on the node running your pod. Read secrets from etcd — If you can run your pod on a control-plane node using the nodeName selector in the pod spec, you might have easy access to the etcd database, which contains the configuration for the cluster, including all secrets. Hunt for privileged service account tokens — Even if you can only schedule your pod on the worker node, you can also access any secret mounted within any pod on the node you are on. In a production cluster, even on a worker node, there is usually at least one pod that has a mounted token that is bound to a service account that is bound to a clusterrolebinding, which gives you access to do things like create pods or view secrets in all namespaces Some additional privilege escalation patterns are outlined in the README document linked below and also in Bad Pod #4: hostPath. Usage and exploitation examples https://github.com/BishopFox/badPods/tree/main/manifests/everything-allowed References and further reading The Most Pointless Kubernetes Command Ever Secure Kubernetes - KubeCon NA 2019 CTF Deep Dive into Real-World Kubernetes Threats Compromising Kubernetes Cluster by Exploiting RBAC Permissions (slides) The Path Less Traveled: Abusing Kubernetes Defaults & Corresponding Repo BAD POD #2: PRIVILEGED AND HOSTPID What’s the worst that can happen? Multiple paths to full cluster compromise How? In this scenario, the only thing that changes from the everything-allowed pod is how you gain root access to the host. Rather than chrooting to the host’s filesystem, you can use nsenter to get a root shell on the node running your pod. Why does it work? Privileged — The privileged: true container-level security context breaks down almost all the walls that containers are supposed to provide; however, the PID namespace is one of the few walls that stands. Without hostPID, nsenter would only work to enter the namespaces of a process running within the container. For more examples on what you can do if you only have privileged: true, refer to the next example Bad Pod #3: Privileged Only. Privileged + hostPID — When both hostPID: true and privileged: true are set, the pod can see all of the processes on the host, and you can enter the init system (PID 1) on the host. From there, you can execute your shell on the node. Once you are root on the host, the privilege escalation paths are all the same as described in Bad Pod # 1: Everything-allowed. Usage and exploitation examples https://github.com/BishopFox/badPods/tree/main/manifests/priv-and-hostpid References and further reading Duffie Cooley's Nsenter Pod Tweet The Path Less Traveled: Abusing Kubernetes Defaults & Corresponding Repo Node-shell Krew Plugin BAD POD #3: PRIVILEGED ONLY What’s the worst that can happen? Multiple paths to full cluster compromise How? If you only have privileged: true, there are two paths you can take: Mount the host’s filesystem — In privileged mode, /dev on the host is accessible in your pod. You can mount the disk that contains the host’s filesystem into your pod using the mount command. In my experience, this gives you a limited view of the filesystem though. Some files, and therefore privesc paths, are not accessible from your privileged pod unless you escalate to a full shell on the node. That said, it is easy enough that you might as well mount the device and see what you can see. Exploit cgroup user mode helper programs — Your best bet is to get interactive root access on the node, but you must jump through a few hoops first. You can use Felix Wilhelm's exploit PoC undock.sh to execute one command a time, or you can use Brandon Edwards and Nick Freeman’s version from their talk A Compendium of Container Escapes, which forces the host to connect back to the listener on the pod for an easy upgrade to interactive root access on the host. Another option is to use the Metasploit module Docker Privileged Container Escape, which uses the same exploit to upgrade a shell received from a container to a shell on the host. Whichever option you choose, the Kubernetes privilege escalation paths are largely the same as the Bad Pod #1: Everything-allowed. Usage and exploitation examples https://github.com/BishopFox/badPods/tree/main/manifests/priv References and further reading Felix Wilhelm's Cgroup Usermode Helper Exploit Understanding Docker Container Escapes A Compendium of Container Escapes Docker Privileged Container Escape Metasploit Module BAD POD #4: HOSTPATH ONLY What’s the worst that can happen? Multiple paths to full cluster compromise How? In this case, even if you don’t have access to the host’s process or network namespaces, if the administrators have not limited what you can mount, you can mount the entire host’s filesystem into your pod, giving you read/write access on the host’s filesystem. This allows you to execute most of the same privilege escalation paths outlined above. There are so many paths available that Ian Coldwater and Duffie Cooley gave an awesome Black Hat 2019 talk about it titled “The Path Less Traveled: Abusing Kubernetes Defaults!” Here are some privileged escalation paths that apply any time you have access to a Kubernetes node’s filesystem: Look for kubeconfig files on the host filesystem — If you are lucky, you will find a cluster-admin config with full access to everything. Access the tokens from all pods on the node — Use something like kubectl auth can-i --list or access-matrix to see if any of the pods have tokens that give you more permissions than you currently have. Look for tokens that have permissions to get secrets or create pods, deployments, etc., in kube-system, or that allow you to create clusterrolebindings. Add your SSH key — If you have network access to SSH to the node, you can add your public key to the node and SSH to it for full interactive access. Crack hashed passwords — Crack hashes in /etc/shadow; see if you can use them to access other nodes. Usage and exploitation examples https://github.com/BishopFox/badPods/tree/main/manifests/hostpath References and further reading The Path Less Traveled: Abusing Kubernetes Defaults & Corresponding Repo Secure Kubernetes - KubeCon NA 2019 CTF Deep Dive into Real-World Kubernetes Threats Compromising Kubernetes Cluster by Exploiting RBAC Permissions (slides) BAD POD #5: HOSTPID ONLY What’s the worst that can happen? Application or cluster credential leaks if an application in the cluster is configured incorrectly. Denial of service via process termination. How? There’s no clear path to get root on the node with only hostPID, but there are still some good post-exploitation opportunities. View processes on the host — When you run ps from within a pod that has hostPID: true, you see all the processes running on the host, including processes running in each pod. Look for passwords, tokens, keys, etc. — If you are lucky, you will find credentials and you can then use them to escalate privileges in the cluster, to escalate privileges to services supported by the cluster, or to escalate privileges to services that communicate with cluster-hosted applications. It’s a long shot, but you might find a Kubernetes service account token or some other authentication material that will allow you to access other namespaces and eventually escalate all the way to cluster admin. Kill processes — You can also kill any process on the node (presenting a denial-of-service risk). Because of this risk though, I would advise against it on a penetration test! Usage and exploitation examples https://github.com/BishopFox/badPods/tree/main/manifests/hostpid BAD POD #6: HOSTNETWORK ONLY What’s the worst that can happen? Potential path to cluster compromise How? If you only have hostNetwork: true, you can’t get privileged code execution on the host directly, but if you cross your fingers, you might still find a path to cluster admin. There are three potential escalation paths: Sniff traffic — You can use tcpdump to sniff unencrypted traffic on any interface on the host. You might get lucky and find service account tokens or other sensitive information that is transmitted over unencrypted channels. Access services bound to localhost — You can also reach services that only listen on the host’s loopback interface or that are otherwise blocked by network policies. These services might turn into a fruitful privilege escalation path. Bypass network policy — If a restrictive network policy is applied to the namespace, deploying a pod with hostNetwork: true allows you to bypass the restrictions. This works because you are bound to the host's network interfaces and not the pods. Usage and exploitation examples https://github.com/BishopFox/badPods/tree/main/manifests/hostnetwork BAD POD #7: HOSTIPC ONLY What’s the worst that can happen? Ability to access data used by any pods that also use the host’s IPC namespace How? If any process on the host or any processes in a pod uses the host’s inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), you’ll be able to read/write to those same mechanisms. The first place you'll want to look is /dev/shm, as it is shared between any pod with hostIPC: true and the host. You'll also want to check out the other IPC mechanisms with ipcs. Inspect /dev/shm — Look for any files in this shared memory location. Inspect existing IPC facilities — You can check to see if any IPC facilities are being used with /usr/bin/ipcs. Usage and exploitation examples https://github.com/BishopFox/badPods/tree/main/manifests/hostipc BAD POD #8: NOTHING ALLOWED What’s the worst that can happen? Multiple potential paths to full cluster compromise How? To close our bad Pods lineup, there are plenty of attack paths that should be investigated any time you can create a pod or simply have access to a pod, even if there are no security attributes enabled. Here are some things to look for whenever you have access to a Kubernetes pod: Accessible cloud metadata — If the pod is cloud hosted, try to access the cloud metadata service. You might get access to the IAM credentials associated with the node or even just find a cloud IAM credential created specifically for that pod. In either case, this can be your path to escalate in the cluster, in the cloud environment, or in both. Overly permissive service accounts — If the namespace’s default service account is mounted to /var/run/secrets/kubernetes.io/serviceaccount/token in your pod and is overly permissive, use that token to further escalate your privileges within the cluster. Misconfigured Kubernetes components — If either the apiserver or the kubelets have anonymous-auth set to true and there are no network policy controls preventing it, you can interact with them directly without authentication. Kernel, container engine, or Kubernetes exploits — An unpatched exploit in the underlying kernel, in the container engine, or in Kubernetes can potentially allow a container escape or access to the Kubernetes cluster without any additional permissions. Hunt for vulnerable services — Your pod will likely see a different view of the network services running in the cluster than you can see from the machine you used to create the pod. You can hunt for vulnerable services and applications by proxying your traffic through the pod. Usage and exploitation examples https://github.com/BishopFox/badPods/tree/main/manifests/nothing-allowed References and further reading Secure Kubernetes - KubeCon NA 2019 CTF Kubernetes Goat Attacking Kubernetes through Kubelet Deep Dive into Real-World Kubernetes Threats A Compendium of Container Escapes CVE-2020-8558 POC CONCLUSION Apart from the Bad Pod #8: Nothing Allowed example, all of the privilege escalation paths covered in this blog post (and the respective repository) can be mitigated with restrictive pod security policies. Additionally, there are many other defense-in-depth security controls available to Kubernetes administrators that can reduce the impact of or completely thwart certain attack paths even when an attacker has access to some or all of the host namespaces and capabilities (e.g., disabling the automatic mounting of service account tokens or requiring all pods to run as non-root by enforcing MustRunAsNonRoot=true and allowPrivilegeEscalation=false). As is always the case with penetration testing, your mileage may vary. Administrators are sometimes hard pressed to defend security best practices without examples that demonstrate the security implications of risky configurations. I hope the examples laid out in this post and the manifests contained in the Bad Pods repository help you enforce the principle of least privilege when it comes to Kubernetes pod creation in your organization. Sursa: https://labs.bishopfox.com/tech-blog/bad-pods-kubernetes-pod-privilege-escalation