Blog

Archive for June 10th, 2021

Keeping an Eye on Dangerous Python Modules, (Fri, Jun 11th)

With Python getting more and more popular, especially on Microsoft Operating systems, it’s common to find malicious Python scripts today. I already covered some of them in previous diaries[1][2]. I like this language because it is very powerful: You can automate boring tasks in a few lines. It can be used for offensive as well as defensive purposes, and… it has a lot of 3rd party “modules” or libraries that extend its capabilities. For example, if you would like to use Python for forensics purposes, you can easily access the registry and extract data:

This snippet of code starts with an import line. First, I need to load a specific module (in this case winreg) that will add to Python all the required code to manipulate the OS registry hives.

Let’s switch back to the “dark side”. When an attacker needs to write a piece of code to perform specific tasks, he will search for existing modules and not reinvent the wheel. To search for Python modules, the best place is to visit pypi.org[3]. Let’s take another example: injection of code. Python is able to use all the Windows API calls with the help of the ctypes module:

In this example, I’m using the ctypes modules to call the Windows API VirtualAlloc() and allocated 1KB of memory with the flag “0x04” (which means that the memory will be allowed to contain executable code).

ctypes is not a common module used in simple scripts to automate tasks like System Administrators could write. It could be categorized as “suspicious”. Let’s have another example. I found this malicious script that implements a keylogger. It uses another not common Python module:

The suspicious module is pyHook which “provides callbacks for global mouse and keyboard events in Windows” as the documentation says.

Want more? Let’ use now wave and sounddevice to use the host microphone and record some conversations…

Other interesting modules?  Use pyscreenshot to take screenshots or pynput to build another type of keylogger.

The question is now, from a defender’s perspective, how can we detect suspicious Python modules?

If you have access to the host, you can always use the “pip” command (the utility to manage modules):

pip will list the modules that have been installed “manually” (could be done by an attacker). To get a full list of modules, you can use the help() command in the Python interpreter:

As you can see, it’s interesting to spot malicious Python code just by having a look at the imported modules! If you would like to hunt, you can create a YARA rule to search for interesting modules inside text files…

[1] https://isc.sans.edu/forums/diary/Python+and+Risky+Windows+API+Calls/26530
[2] https://isc.sans.edu/forums/diary/From+Python+to+Net/27366
[3] https://pypi.org

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Are Cookie Banners a Waste of Time or a Complete Waste of Time?, (Thu, May 20th)

Legislation, in particular in the European Union, has led to a proliferation of “Cookie Banners.” Warning banners that either ask you for blanket permission to set cookies or, in some cases, provide you with some control as to what cookies you do allow. These regulations emerged after advertisers made excessive use of HTTP Cookies to track users across different sites. But in my opinion, these measures are often implemented poorly. Changes in browsers have made cookies far less menacing than they have been in the past due to changes made in browsers. Other tracking technologies are bound to replace cookies and, in some cases, already have.

There are very legitimate uses for cookies to track a user’s session. In my opinion, a proper session cookie has the following properties:

  • It is restricted to a specific hostname (e.g., “isc.sans.edu”)
  • It has the httponly and secure parameter set (“same-site” is nice to have, of course)
  • There is no expiration time, so the cookie will get deleted as soon as the user closes the browse. This defines a “Session Cookie.” 
  • For extra-extra credit: Start the cookie’s name with __Host or __Secure prefix.

Many sites will set various additional cookies, and often they are inserted by middleware. As I hate “shaming” others, let me use isc.sans.edu as a bad example. 

% curl -si https://isc.sans.edu | grep Set-Cookie
Set-Cookie: visid_incap_2188750=FYohHlwAB06WoVxsdKMnPSB4tsf5BK; expires=Fri, 10 Jun 2022 09:40:10 GMT; HttpOnly; path=/; Domain=.sans.edu; Secure; SameSite=None
Set-Cookie: nlbi_2188750_2100128=4jQpYhNNrz5qk8KuDW1UNgAAAADjVqz5zQSu/0YJRz/fEYuM; path=/; Domain=.sans.edu; Secure; SameSite=None
Set-Cookie: incap_ses_1243_2188750=v0+KUhJRlXC7EJCHVwZAEePvwWAAAAAAE0OXILjXlfNemg/mxkNCeQ==; path=/; Domain=.sans.edu; Secure; SameSite=None
Set-Cookie: ___utmvmpOBuREXZZ=OcBPfJZKGQA; path=/; Max-Age=900; Secure; SameSite=None
Set-Cookie: ___utmvapOBuREXZZ=qloSeVq; path=/; Max-Age=900; Secure; SameSite=None
Set-Cookie: ___utmvbpOBuREXZZ=MZL

Pulling in the index page for the site, you actually do not get a session cookie at all. This is because all these cookies are set by our CDN/WAF (we use Imperva’s service for that). All CDNs will add cookies to track user’s sessions. Cloudflare for example explains its cookies [4].

Comparing this to dshield.org, which doesn’t use Imperva:

% curl -si https://dshield.org | grep Set-Cookie
%

Using a simple curl script and checking the top 100 sites (according to majestic.com), About 30 are setting cookies right as you download the index page before having a chance to approve them, as tested with a simple curl script. Testing with a real browser shows many more “hits.”

Here are some of the current limits to cookies in modern browsers:

  • The RFC requires browsers to track at least 50 cookies per site (and 3000 total) [1]
  • The maximum amount of data allowed per cookie is at least 4kBytes (some browsers allow more)
  • If no “SameSite” property is set, browsers will now typically use “lax,” not “none,” so you get some basic CSRF protection by default
  • Third-party cookies, or the ability to set cookies for another site, are pretty much dead in a modern browser

A “Cookie2” header was introduced to distinguish proper session cookies from regular cookies in the past. But this header never really took off and has since been deprecated. [3]

Sites that do use cookies banners to allow users to select what cookies they want have also gotten crafty in tricking users into allowing them via “dark patterns.” You will typically first see a dialog asking you for blanket permission to set cookies, and you need to review a second dialog to select particular cookie types. Precious seconds will delay you from getting to the content (and as a result, the user will often “approve” the first dialog).

[1] https://datatracker.ietf.org/doc/html/rfc6265
[2] https://www.whatismybrowser.com/detect/are-third-party-cookies-enabled
[3] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie2
[4] https://support.cloudflare.com/hc/en-us/articles/200170156-Understanding-the-Cloudflare-Cookies


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →