Fi8sVrs

Nu era pt tine man, am pus ^ In fine, merge mutat la bashed, 8+1, mai sunt cazuri / specii ce comunica cu iIsus, fecioara Maria etc.. // daca continui prezic Apocalipsa

Copiii când citesc acest post, oare ce zic? Să-mi dai doo beri ca mi-am pierdut secunde sa citim aberatii de etnobotanic

Tu esti acela din Forbes? De si-a ucis bunica? . // Killuminatii, pogorâți-vă, Amin

The first cloud-based private DNS service that gives you full control over what is allowed and what is blocked on the Internet. https://www.nextdns.io/

Vulnerabilities in the Linux kernel are not uncommon. There are roughly 26 million lines of code, with 3,385,121 lines added and 2,512,040 lines removed in 2018 alone. The sheer complexity of that much code means that vulnerabilities are bound to exist. However, what is not at all common is the existence of unauthenticated remote code execution (RCE) vulnerabilities — a critical issue that every system administrator hopes to avoid. On May 8, 2019, the National Vulnerability Database (NVD) published details for a Linux kernel vulnerability, CVE-2019-11815, with a Common Vulnerability Scoring System (CVSS) 3.0 base score of 8.1. The details of the vulnerability include: having an attack vector of “network,” no privileges required, and administrative level code execution — i.e., the confidentiality, integrity, and availability (CIA) impact are all “high.” At first glance, this seems like a worst-case scenario. But assessing a vulnerability’s potential impact goes beyond the attack vector, privileges, and CIA impact of the CVSS base score. One component of the CVSS 3 base score is attack complexity, for which this vulnerability has a rating of “high” as well. This means that a successful attack is dependent on a very specific set of circumstances that is hard to achieve. According to the CVSS 3.0 standard, this rating means that “a successful attack depends on conditions beyond the attacker’s control” and “a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected.” Looking at the vulnerability itself in some detail will reveal why the scoring is technically correct, especially when taking the attack complexity rating into account, but is not completely representative of the actual risk to enterprises and users. Breaking down the vulnerability The description of the vulnerability from the NVD states that the issue was “discovered in rds_tcp_kill_sock in net/rds/tcp.c in the Linux kernel before 5.0.8,” and that there is “a race condition leading to a use-after-free, related to net namespace cleanup.” This is an accurate and concise description of the vulnerability from a code perspective, but the lack of some critical information may lead to alarm given the mention of TCP, or Transmission Control Protocol. The first major component of this vulnerability is Reliable Datagram Sockets (RDS), a socket interface and protocol developed by Oracle, which was created to allow a single transport socket to facilitate sending and receiving to a very large number of different endpoints. This vulnerability involves RDS when TCP is used as the underlying transport protocol: The application data in an RDS header is encapsulated and sent via TCP, typically to port 16385, where it is then unencapsulated and passed to the RDS socket. Beyond Oracle’s documentation and a very short Wikipedia page, there is not much information about RDS or where it’s typically used. The obscurity of this protocol, combined with the existence of previous local privilege escalation vulnerabilities, has led most popular Linux distributions such as Ubuntu to blacklist kernel modules relating to RDS for many years. This immediately reduces the potential harm of such a vulnerability by a large margin. What if the rds and rds_tcp kernel modules are enabled? When using RDS over TCP, the underlying TCP transport is completely managed by the kernel. This means that when a client establishes a new RDS socket, the TCP socket is opened by the kernel in rds_tcp_conn_path_connect() in tcp_connect.c, which is called by the worker thread function rds_connect_worker() in threads.c. Figure 1. rds_connect_worker() in threads.c calling rds_tcp_conn_path_connect() The RDS-specific portion of the vulnerability arises when the underlying TCP client-side socket continually fails to connect. When TCP connect()fails, the rds_tcp_restore_callbacks() function is called, and sets the t_sock pointer in the rds_tcp_connection structure to NULL, which is completely reasonable behavior. Figure 2. rds_tcp_conn_path_connect() calling rds_tcp_restore_callbacks() Figure 3. t_sock set to NULL in rds_tcp_restore_callbacks() The problem arises when we introduce the second major component of the vulnerability: network namespaces. Network namespaces allow for the use of a separate set of interfaces and routing tables for a given namespace, where traditionally the entire operating system shares the same interfaces and routing tables as every other process. This namespace functionality is used by platforms such as Docker to provide network isolation for containers. When an RDS-TCP socket is initialized in rds_tcp_init(), the network namespaces function register_pernet_device() is called, passing in a pointer to a pernet_operations structure, rds_tcp_net_ops, which contains initialization and exit functions to perform when a network namespace is initialized or removed and the socket is active. Figure 4. register_pernet_device() called to register network namespace device Figure 5. rds_tcp_exit_net() as the exit function for the network namespace device The exit function rds_tcp_exit_net() will call rds_tcp_kill_sock(), which is used to perform cleanup of various parts of the RDS-TCP socket. Part of the process is the creation of a list of connections to be cleaned up, called the tmp_list. One of the checks performed on each connection is to see if the t_sock pointer is NULL for the underlying TCP socket in use and if so, the t_tcp_node is not added to the “cleanup list.” As a result, rds_conn_destroy() is not called for those nodes and much of the “cleanup” is not performed. Figure 6. rds_tcp_kill_sock() skipping cleanup if t_sock is NULL Most importantly, the rds_connect_worker() thread is not stopped and will continue to try reconnecting. Eventually, the underlying net structure is freed as part of the namespace cleanup, and may be used by a still running rds_connect_worker(), triggering a use-after-free issue. Technically, this flaw is as described: no privileges required, and administrative level code execution possible if exploited. The fix for the issue is simple: System administrators simply need to ensure the vulnerable modules are disabled or an updated kernel is installed. The real risks posed by CVE-2019-11815 Given the characteristics of CVE-2019-11815, what does this mean for users? A potential victim would first have to have the commonly blacklisted rds and rds_tcp modules loaded — if these are not loaded, no further movement is possible. If an attacker happens to find such a rare target — because the TCP connect() is performed only by RDS-TCP clients, not servers — an attacker would then have to entice their target into connecting to an attacker-controlled RDS-TCP socket from within a network namespace. The attacker’s next job would be to cause a failure on the underlying TCP connection and at the same time to cause the target user’s network namespace to be cleaned up — a task that a remote attacker has practically no chance of performing. To make things even more impossible, race conditions — flaws caused by unexpected timing of events that affect other actions — are notoriously difficult to exploit and would likely require a large number of attempts. With all these conditions taken into consideration, the chances of this vulnerability being “remotely exploitable without authentication” are essentially zero. There is a very small chance that this could be used as a local privilege escalation, but that would require that the commonly blacklisted rds andrds_tcp modules are loaded. Although the CVSS score of this vulnerability is technically correct in its assessment, users should be aware that risk is also dependent on the probability of the attack due to its complexity and the conditions required for an attacker to be successful. The circumstances in which this attack would be feasible are unlikely to ever be seen in a real production environment. The vast majority of Linux servers are simply not vulnerable in a remote context. Source

An attacker can supply a malicious hyperlink in order to secretly alter the download path for files shared in a Slack channel. A remotely exploitable vulnerability in the Windows desktop app version of the Slack collaboration platform has been uncovered, which allows attackers to alter where files from Slack are downloaded. Nefarious types could redirect the files to their own SMB server; and, they could manipulate the contents of those documents, altering information or injecting malware. According to Tenable Research’s David Wells, who discovered the bug and reported it via the HackerOne bug-bounty platform, a download hijack vulnerability in Slack Desktop version 3.3.7 for Windows would allow an attacker to post a specially crafted hyperlink into a Slack channel that changes the document download location path when clicked. Victims can still open the downloaded document through the application, however, that will be done from the attacker’s Server Message Block (SMB) share. Wells said in a posting on Friday. The reason it has to be an SMB share is because of a security check built into the platform. The Slack application filters certain characters out – including colons – so an attacker can’t supply a path with a drive root. Wells explained. Remote Exploitation An attack can be carried out by both authenticated and unauthenticated users, Wells said. In the first scenario, an insider could exploit the vulnerability for corporate espionage, manipulation or to gain access to documents outside of their role or privilege level. In the second scenario, an outsider could place crafted hyperlinks into pieces of content that could be pulled into a Slack channel via external RSS feeds. Wells said. Success here would require knowing which RSS feeds the target Slack user subscribes to, of course. Malware and More In addition to being an information-disclosure concern (attackers could access sensitive company documents, financial data, patient records and anything else someone shares via the platform), the vulnerability could be used as a jumping-off point for broader attacks. Wells explained. He added, Because it does require user interaction to exploit, the vulnerability carries a medium-level CVSSv2 rating of 5.5. However, the researcher said that attackers can use a spoofing technique to mask the malicious URL behind a fake address, say “http://google.com,” to give it more legitimacy and convince a Slack user to click on the link. More specifically, it’s possible to link to words within Slack by adding an “attachment” field to a Slack POST request with appropriate fields, Wells said. The attack surface is potentially large. Slack said in January that it has 10 million active daily users, and 85,000 organizations use the paid version (it’s unclear how many are Windows users). Fortunately, Slack patched the bug as part of its latest update for Slack Desktop Application for Windows, v3.4.0, so users should upgrade their apps and clients. Via threatpost.com

Windows Terminal Windows Terminal is a new, modern, feature-rich, productive terminal application for command-line users. It includes many of the features most frequently requested by the Windows command-line community including support for tabs, rich text, globalization, configurability, theming & styling, and more. The Terminal will also need to meet our goals and measures to ensure it remains fast, and efficient, and doesn't consume vast amounts of memory or power. This repository contains the source code for: Windows Terminal The Windows console host (conhost.exe) Components shared between the two projects ColorTool Sample projects that show how to consume the Windows Console APIs Other related repositories include: Console API Documentation Download Source

Se rezolva la primul update, se primeste si in România Persistă de 4, 5 zile

Presupun ca vrei să faci radio, streaming, aş adăuga Pop filter sau Daca tot te "arunci cu banii" + •mixer •sintetizator

By Brennon The definitive guide to Secure Shell (SSH) tunneling, port redirection, and bending traffic like a boss. Want to up your penetration testing skills and reach the dark corners of networks? Wish you knew how attackers pivot and move within networks? Are you maximizing the capabilities within SSH? This book is packed with practical and real world examples of SSH tunneling and port redirection in multiple realistic scenarios. It walks you through the basics of SSH tunneling (both local and remote port forwards), SOCKS proxies, port redirection, and how to utilize them with other tools like proxychains, nmap, Metasploit, and web browsers. Advanced topics included SSHing through 4 jump boxes, throwing exploits through SSH tunnels, scanning assets using proxychains and Metasploit's Meterpreter, browsing the Internet through a SOCKS proxy, utilizing proxychains and nmap to scan targets, and leveraging Metasploit's Meterpreter portfwd command. For the complete list of topics covered, check out the table of contents. The book is a PDF packed with 80 pages of examples, code snippets, and figures to transform you into a Cyber Plumber! The book is available to download immediately after purchasing. Lastly, as part of giving back to the information technology community, this book is free for students with a .edu email! Download: https://gumroad.com/l/the_cyber_plumbers_handbook/hackernews20190518 Source

Sunt o multime, esti dispus sa platesti? Posteaza in categoria potrivită, in primul rand e piraterie, next... mai ai ceva de zis? il am eu, dar pariu ca nu ai habar cum sa il folosesti

Machine Learning for .NET ML.NET is a cross-platform open-source machine learning framework which makes machine learning accessible to .NET developers. ML.NET allows .NET developers to develop their own models and infuse custom machine learning into their applications, using .NET, even without prior expertise in developing or tuning machine learning models. ML.NET was originally developed in Microsoft Research, and evolved into a significant framework over the last decade and is used across many product groups in Microsoft like Windows, Bing, PowerPoint, Excel and more. ML.NET enables machine learning tasks like classification (for example: support text classification, sentiment analysis) and regression (for example, price-prediction). Download: https://github.com/dotnet/machinelearning.git Sources: https://github.com/dotnet/machinelearning https://dot.net/ml

Se pare ca Da

Google Analytics is a good tool: it’s free, easy to implement, and has served me well over the years. However, partly because I’m not in love with Big Brother Google looking over the shoulder of all my website visitors, and partly because I like experiments in minimalism, I decided to replace Google Analytics on benhoyt.com with a simple analytics setup based on log file parsing. Log file parsing is an old-skool but effective way of measuring the traffic to your site. It works with or without JavaScript (my version uses a hybrid approach), and doesn’t send any data to Google or other tracking companies. To do this, I used three main tools: Amazon Cloudfront serving a transparent 1x1 pixel image (with logs going to S3) A Python script to convert the pixel logs to Apache/nginx “combined log format” GoAccess to actually parse the logs and show an analytics report This article describes why I used this approach and how I implemented it using GoAccess and a tiny bit of custom code. Cloudfront pixel My website is a simple and fast static site hosted via GitHub Pages (it’s probably handling a Hacker News traffic spike as you read this ;-). To use GoAccess, I needed a simple way to write to a log file whenever someone requests a page. I decided to use a ping to a pixel.png file hosted on S3 and served via Cloudfront. So I created a new S3 bucket and uploaded a single transparent 1x1 pixel.png file. Then I created a Cloudfront distribution with logging enabled and pointed it at the S3 bucket (logs go to another S3 bucket). Finally I added a small code snippet at the bottom of my page template (Cloudfront domain replaced to avoid bots hitting it from here): <script> if (window.location.hostname == 'benhoyt.com') { var _pixel = new Image(1, 1); _pixel.src = "https://cloudfront.example.net/pixel.png?u=" + encodeURIComponent(window.location.pathname) + (document.referrer ? "&r=" + encodeURIComponent(document.referrer) : ""); } </script> <noscript> <img src="https://cloudfront.example.net/pixel.png? u={{ page.url | url_encode }}" /> </noscript> If JavaScript is enabled, we create an image and point its src to the Cloudfront pixel file, with the URL and referrer encoded in the query string (my log converter will later decode the u and rparameters and output a log line in combined log format). If JavaScript is disabled, we only have the page URL (no referrer), but at least we can still log the request. Most tracking systems, including Google Analytics, don’t work at all without JavaScript. Why a pixel versus direct logging? In some ways it would have been simpler to put Cloudfront in front of GitHub Pages and point my benhoyt.com domain directly to Cloudfront. But I wanted to avoid having to modify DNS and fiddle with the SSL certificate in Cloudfront to prove out the approach. This does mean I had to write a log conversion script (to decode the u and r parameters in the query string). I may switch to the direct-to-Cloudfront approach later, but in the meantime the pixel-based approach works well, and is easier to change. Plus, writing a few dozen lines of Python is good therapy. The log converter So how does the converter script work? It reads Cloudfront log input files, decompresses them, decodes the u and r parameters in the pixel.pngquery string, and writes the output in combined log format. One of the things that’s nice about Python is its standard library. There’s a lesser-known package called fileinput which helps you read a bunch of input files line-at-a-time. Quoting from the help, typical use is: import fileinput for line in fileinput.input(): process(line) This iterates over the lines of all files listed on the command line (or stdin if there are no args). Exactly what you want for a text processing program. It also handles .gz files (like Cloudfront log files) seamlessly with a simple tweak: finput = fileinput.input(openhook=fileinput.hook_compressed) Once the script has read a Cloudfront log line and ensured it’s a pixel.png request, it decodes the query string and outputs in combined log format: # Decode "u" (URL) and "r" (referrer) in query string path = urllib.parse.unquote(query['u'][0]) referrer = urllib.parse.unquote(query.get('r', ['-'])[0]) try: date = datetime.datetime.strptime(fields['date'], '%Y-%m-%d') except ValueError: log_error(finput, 'invalid date: {}'.format(fields['date'])) continue user_agent = unquote(fields['cs(User-Agent)']) ip = fields['c-ip'] if fields['x-forwarded-for'] != '-': ip = fields['x-forwarded-for'] # Output in Apache/nginx combined log format print('{ip} - - [{date:%d/%b/%Y}:{time} +0000] {request} 200 - ' '{referrer} {user_agent}'.format( ip=ip, date=date, time=fields['time'], request=quote('GET ' + path + ' HTTP/1.1'), referrer=quote(referrer), user_agent=quote(user_agent), )) The output is a single log file with all the log lines in it. My site is fairly low traffic, so this should be fine for the foreseeable. At some point I’ll write a script to go into S3 and delete old logs. GoAccess Report GoAccess is a great little tool that does the actual parsing and presentation of the data. It can be used in the terminal mode, but I prefer to output an HTML report. Here’s a screenshot of the output (showing hits/visitors per day, and hits per URL): Looks like my articles about pygit and scandir are pretty popular (even though I wrote them a couple of years ago). There’s a bunch more detail, including an operating system breakdown: And referring domains: Obviously with log parsing you don’t get as much information as a JavaScript-heavy, Google Analytics-style system. There’s no screen sizes, no time-on-page metrics, etc. But that’s okay for me! I’m free of the Google, and I had a bit of fun building it. Feel free to reuse or hack my code: cloudfront_to_combined.py log converter analytics.sh bash script to drive the process Source

Am gasit si eu ceva, este, cod rosu, galben, verde C1/C2 pt cazuri de urgenta la smurd, am auzit prin statie cand comunicau intre ei, sa stie pt ce vin pregatiti http://ambulantamh.ro/112/dispecerat/ Edit: este sigur si precis man, stiu asta de cand a facut bunica mea stop cardio-respirator ceva de genul mi-qu spus sa raman in telefon si am auzit in background "cod '123' (numai retin cifrele exact) pe adresa.. " data de mine Nu poti trimite politia locala pe un Salam Alecum incarcat cu TNT pregatit sa arunce orasul in aer Edit2, citez: [...] More...

Salut, detine cinva lista de codyri petru apeluri de urgenta 112, spre exemplu: cod 1234 pt. violenta in familie; cod 4321 pt. incendii; cod 2341 pt. accidente rutiere. Banuiesc ca ar ajunge intr-un timp util fara prea multe explicatii prin telefon. Multumesc

Engleza in prima linie, cursuri gasesti pe net

2FA daca lucrati la comun

Evil-WinRAR-Generator Generator of malicious Ace files for WinRAR < 5.70 beta 1 Vulnerability by research.checkpoint.com Developed by @manulqwerty - IronHackers. Usage Help: ./evilWinRAR.py -h Generate a malicius archive: ./evilWinRAR.py -o evil.rar -e calc.exe Evil-WinRAR-Generator works out of the box with Python version 3.x on any platform. Proof of Concept (CVE-2018-20250) Screenshots Credits https://github.com/droe/acefile https://github.com/WyAtu/CVE-2018-20250 Source

Description DC-6 is another purposely built vulnerable lab with the intent of gaining experience in the world of penetration testing. This isn't an overly difficult challenge so should be great for beginners. The ultimate goal of this challenge is to get root and to read the one and only flag. Linux skills and familiarity with the Linux command line are a must, as is some experience with basic penetration testing tools. For beginners, Google can be of great assistance, but you can always tweet me at @DCAU7 for assistance to get you going again. But take note: I won't give you the answer, instead, I'll give you an idea about how to move forward. Download Download DC-6 here. Sha1 Signature - 21b782c260f0e20ffe39df762cd6b90b3f3888a2 Source

Nu-i mai puneti alb, il derutati #800080

La cine te referi prin 'trompetisti'? A fost vorba sa am unde incasa taxele in Londra, monese, monzo, revolut, etc... nu te recunosc nici cu cnp, nici cu nr. tel cand vine vorba de sume

Trompete de banci cu sediul in coltul strazii, vrei ceva serios, apeleaza sus, am pierdut cateva miare, ma cert cu ei prin fax-uri, de m-am plictisit

Impaca-te cu ideea