Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27852PUBLISHED: 2021-01-20A stored Cross-Site Scripting (XSS) vulnerability in the survey feature in Rocketgenius Gravity Forms before 2.4.21 allows remote attackers to inject arbitrary web script or HTML via a textarea field. This code is interpreted by users in a privileged role (Administrator, Editor, etc.).
CVE-2021-3137PUBLISHED: 2021-01-20XWiki 12.10.2 allows XSS via an SVG document to the upload feature of the comment section.
CVE-2020-27850PUBLISHED: 2021-01-20A stored Cross-Site Scripting (XSS) vulnerability in forms import feature in Rocketgenius Gravity Forms before 2.4.21 allows remote attackers to inject arbitrary web script or HTML via the import of a GF form. This code is interpreted by users in a privileged role (Administrator, Editor, etc.).
CVE-2020-27851PUBLISHED: 2021-01-20
Multiple stored HTML injection vulnerabilities in the "poll" and "quiz" features in an additional paid add-on of Rocketgenius Gravity Forms before 2.4.21 allows remote attackers to inject arbitrary HTML code via poll or quiz answers. This code is interpreted by users in a privile...
CVE-2020-13134PUBLISHED: 2021-01-20
Tufin SecureChange prior to R19.3 HF3 and R20-1 HF1 are vulnerable to stored XSS. The successful exploitation requires admin privileges (for storing the XSS payload itself), and can exploit (be triggered by) admin users. All TOS versions with SecureChange deployments prior to R19.3 HF3 and R20-1 HF1...
2020: The Year in SecurityDownload this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Tweet This
0 Comments
User Rank: Strategist
5/12/2018 | 10:29:41 AM
The real problem here, as it always is with SMS-based 2FA where a message is sent to the user, is excatly that: that the message is sent TO the user.
Text messages sent to phones are, by definition, both unencrypted and easy to intercept, as Mr. Mitnick has amply demonstrated. The answer to this problem is to reverse the process and have the user authenticate their login or identity by sending a message FROM their phone.
Here's why this works: the U.S. short code system eliminates spoofing of phone numbers thanks to the carriers. Cloning/spoofing/duplicating SIMs and IMEIs is a problem for carriers for a simple reason: the lose money when someone doesn't pay for another line. They solved this problem long ago by implementing a barrier that has yet to be successfully hacked.
This more secure approach reverses the process by having the user send a text from their device into an independent third-party server. The server then makes a secure handshake with the web page where the authentication is occurring. This completely eliminates the type of attack Mr. Mitnick successfully used (man-in-the-middle or man-in-the-browser) and confirms that the inbound SMS has come from the right number, registered IMEI and contains the right code. I welcome Mr. Mitnick to test the system. I will be happy to provide him with complete information about it and give him a test account.
Nothing is unhackable (although ours has not yet been successfully hacked) but we are confident that SnapID is substanially LESS hackable than any other SMS-based 2FA method on the market.