Blog

Archive for SANS

Verifying SSL/TLS configuration (part 2), (Wed, Aug 7th)

This diary is the second part in the series on verifying SSL/TLS configuration – penetration testers, but also security auditors should find this series really useful (let us know if you like it, or if there is another related topic you think should be covered).

In this part we will talk about certificates used on SSL/TLS services. In the previous part, available HERE, I showed couple of tools I like to use when testing SSL/TLS configuration. In this diary we will talk about checking certificates, while the next one will cover ciphers.

As I mentioned, one of my favorite tools for checking SSL/TLS configuration is nmap, with some of really useful NSE scripts. The one I use for checking certificates is the ssl-cert script. This script is very easy to use and will basically show all information that we need to know about to us, as shown below for the isc.sans.edu web site:

$ nmap -sT -p 443 -Pn isc.sans.edu –script ssl-cert
Starting Nmap 7.70SVN ( https://nmap.org ) at 2019-08-07 09:38 UTC
Nmap scan report for isc.sans.edu (204.51.94.153)
Host is up (0.085s latency).

PORT    STATE SERVICE
443/tcp open  https
| ssl-cert: Subject: commonName=isc.sans.edu
| Subject Alternative Name: DNS:isc.incidents.org, DNS:isc.sans.edu, DNS:isc.sans.org, DNS:isc1.sans.org, DNS:isc2.sans.org, DNS:www.incidents.org
| Issuer: commonName=Let’s Encrypt Authority X3/organizationName=Let’s Encrypt/countryName=US
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2019-07-16T13:52:00
| Not valid after:  2019-10-14T13:52:00
| MD5:   6c32 54b2 b168 29de fd51 3955 0789 b46d
|_SHA-1: c714 a765 b0bc 5770 78b5 2e33 0dee 4cc0 de80 c879

Nmap done: 1 IP address (1 host up) scanned in 0.76 seconds

I have highlighted important fields that we should be paying attention to when verifying certificates, so let’s explain them:

  • Not valid before and Not valid after fields define the time interval in which the certificate is valid. Obviously, when verifying certificates we should make use that the certificate is currently valid and not expired, otherwise an error will be presented.
  • The Issuer field defines who issued the certificate. This should be a well known, trusted Certificate Authority – in this example we can see that isc.sans.edu is using Let’s Encrypt Authority, which is a free CA (another reason to encrypt everything today!).
    We could verify the trust chain now and find that this is a trusted CA – just keep mind that if you are performing this test on an internal network that, before starting with the penetration test, you should ask the client to specify which internal CA’s they use – these should be trusted, of course.
    Additionally, if you are using automated vulnerability scanners such as Nexpose, Nessus or Qualys, with most of them you can import the list of trusted CA’s. This will help with reducing false positives.
  • The Subject field defines the web site for which the certificate has been issued. The parameter we are interested in is the cn (commonName) parameter and it must match exactly the target site name (what is being entered in the address bar in a browser). So when we access https://isc.sans.edu, the cn field must be isc.sans.edu (and not isc2.sans.edu).
    That being said, I must also stress out that modern web browser deprecated the cn parameter in the Subject field and now require an additional field: Subject Alternative Name (SAN) that must be present and must match the site name. As we can see, the certificate used on isc.sans.edu correctly sets that field as well. A lot of browsers will report an incorrect certificate if that field does not exist – for example Google Chrome requires SAN from version 58 and later. In other words – make sure that you verify if the SAN field is there, and if it is set correctly.
    Notice here that if the Subject and Issuer fields are the same – we are looking at a self-signed certificate. Otherwise, it is an untrusted certificate – I wanted to stress this our specifically because I see a lot of incorrect reports (even in vulnerability scanners!).
  • Public key type and size for this certificate are set to RSA and 2048 bits. This is (currently) the de facto standard – anything lower than 2048 bits is not considered safe, and will be reported by modern browser. So when you see a certificate with 1024 bits, that should be reported and a new one should be generated.
  • Finally, signature algorithm: today it should be always SHA-256 (as we can see above it is set to sha256WithRSAEncryption). MD5 and SHA-1 are not considered safe any more and should be avoided. Google Chrome stopped supporting SHA-1 from version 57.

With this we know how to read the output of the ssl-cert script, so we can report on any issues identified.

In next diary we will talk about encryption algorithms and protocols that we need to pay attention to.


Bojan
@bojanz
INFIGO IS

(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) →

Scanning for Bluekeep vulnerable RDP instances, (Mon, Aug 5th)

Since the Microsoft Remote Desktop Protocol (RDP) vulnerability CVE-2019-0708, commonly knows as BlueKeep, was  first announced in May of 2019, the security industry has been holding their breath waiting for the worse case scenario. Scanning for vulnerable RDP instances began almost immediately after the announcement. Since then a number of exploits for BlueKeep have been seen that can crash vulnerable systems, but the anticipated wormable exploit hasn’t yet materialized.

Now that both Immunity’s Canvas and Rapid7’s Metasploit have working exploits in their penetration testing tools you have to believe that it is only a matter of time until the bad guys have one as well.

It would be nice to say that the number of systems running a vulnerable RDP instance has decreased since the vulnerability announcement, but for the IP space I have been tracking I have only seen a decrease of about 10% in vulnerable systems over the last 90 days.

If you are a security administrator and want to find the BlueKeep vulnerable systems on your network, how would you go about it?  For the Bluekeep vulnerability it is relatively easy. With access to a *nix box with the high speed scanner masscan and the rdpscan tool installed along with their dependencies, it is a very easy bash script. 

I called this bash script scan_bluekeep.sh

—–

#!/bin/bash
#create a date parameter for the various files so scans run on different dates don’t overwrite each other.
TDATE=`date +%Y%m%d`
 
# put your IPs or IP ranges you would like to scan in scan_ips.txt 
# this will be used as the input to masscan
# the output file is rdpips-.txt
echo “executing masscan”
/usr/bin/masscan -p3389 -v -iL scan_ips.txt > rdpips-$TDATE.txt
 
#the output from the masscan will be used as the input to rdpscan
#the output file will be RDP_results-.txt
echo “executing rdpscan”
rdpscan –file rdpips-$TDATE.txt > RDP_results-$TDATE.txt

—–

As the comments state, place your IP addresses or ranges to be scanned in the file scan_ips.txt.  This will be used as the input file for this script.  The output will be two files:

* The masscan output file will be rdpips-.txt, all IPs found with RDP open on port 3389
* the rdpscan output file will be RDP_results-.txt, the rdpscan result showing each detected RDP instance and whether or not rdpscan believes they are vulnerable to BlueKeep

Checking the rdpscan output in RDP_results-.txt you will generally find one of 3 results:

1.2.3.4 – SAFE – Target appears patched

or 

1.2.3.4  – VULNERABLE – got appid

there is also an UNKNOWN result, which is usually one of:

1.2.3.4 – UNKNOWN – RDP protocol error – receive timeout
1.2.3.5 – UNKNOWN – no connection – connection closed (RST)
 

Concentrate on resolving the VULNERABLE results and you will sleep much better when the wormable exploit finally hits.

 

— Rick Wanner MSISE – rwanner at isc dot sans dot edu – http://namedeplume.blogspot.com/ – Twitter:namedeplume (Protected)

(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) →

Sextortion: Follow the Money – The Final Chapter, (Mon, Aug 5th)

For the background on this diary please see the previous diaries on Sextortion: Follow the Money: Diary 1, Diary 2, Diary 3

Since the last update in the Sextortion series I have contined to track the bitcoin addresses reported to the ISC.  Altogether 563 BTC addresses have been reported.  90 of those addresses received 497 payments totalling over $785,000 USD. That is an average payment of nearly $1600 USD at current Bitcoin prices. Over $530,000 USD of that value has been moved out of the tracked addresses, leaving about $250,000 USD still sitting in the tracked addresses.

I still believe that the addresses we are tracking are a very small percentage of the overall addresses used in the various sextortion campaigns, but even these addresses received, and moved out a not insignificant amount of value.

As shown in Diary 3,at that point is was possible to track over $40 Million USD of payments being sent into Bitcoin mixers to have the payments laundered for extraction, and that was only a small amount of the value that was in the consolidation addresses.   The rest had not moved out yet, leaving over $100 Million USD behind presumably to be moved out later. 

Unfortunately, shortly after that diary was published, the bad guys got more creative with the way they moved value out of the BTC wallets, breaking the tools I was using to find the consolidation wallets. It appeared as if they were consolidating the value in new addresses, fragmenting the value again, reconsolidating, etc.  in order to make it far more difficult to follow where the value was going.

Still I was, with some patience, able to track some of the BTC value to some consolidation wallets, and the dollar values are truly frightening.  Keep in mind that I cannot attribute all of the value in these consolidation BTC addresses to the Sexploitation campaigns, all I can be sure of is that the money from some of the sexplotiation BTC addresses was moved into these addresses, so presumably it belongs to the same criminal enterprise that was running the Sexploitation campaigns. Also, the value is based on the current value of Bitcoin.  With the volativity of Bitcoin the actual value may have been more or less at the time the value was moved out. Some of these consolidation BTC addresses appear to still be in use.  The values in them were changing as I was writing this diary. 

Here are the top 5 consolidation BTC addresses by value that I could find:

Consolidation Address Total BTC Total USD
39id1GfYff4x5r7UEALUjPYVQPGuMj5L1g 61.93172327 $683,881.05
3QR7FADzk6U227eJ3Ud1vxzmh4HNWpnbgp 140.1842615 $1,547,984.71
1DX3MvGTanzcTgnHw8SnorhgpQNHspSWTX 655.84167 $7,242,131.68
179KLpQM8Mse6MmG5gk6JTSokQohiGGrbh 6,437.50 $71,086,105.01
1NDyJtNTjmwk5xPNhjgAMu4HDHigtobu1s 6,229,301.73 $68,787,064,396.14
    ——————————
    $68,867,624,498.59

Like I said a truly frightening number…almost $69 Billion USD! It is important to remember that these consolidation addresses are the ones I was able to find using only our very limited set of tracked Sexploitation BTC addresses, there are very likely many more consolidation addresses in use.

— Rick Wanner MSISE – rwanner at isc dot sans dot edu – http://namedeplume.blogspot.com/ – Twitter:namedeplume (Protected)

(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) →

Detecting ZLIB Compression, (Sun, Aug 4th)

In diary entry “Recognizing ZLIB Compression“, I mention my tool file-magic.py: it’s mainly a wrapper for command file (libmagic).

By default, command file has no definitions to detect ZLIB detection, but my tool file-magic.py uses an additional file with custom definitions:

Take for example a ZLIB compressed stream in a PDF document:

As you can see, the stream starts with 0x78, an indication that this is ZLIB compression.

Piping this stream in my file-magic.py tools helps identifiying the unfiltered stream content:

Of course, if you don’t want to use this tool, you can just integrate these ZLIB definitions in your own definiton files.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(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) →

Combining Low Tech Scams: SMS + SET + Credit Card Harvesting, (Fri, Aug 2nd)

As Infosec folks, we spend a lot of time on the latest and greatest exploits, attacks and malware – we seem to be (abnormally) driven towards continuing education in our field.  This is a great thing, but often we lose sight of the fact that the attackers don’t always try so hard.

I got a text this morning, telling me my Netflix payment was unsuccessful.  This was really interesting to me, as I’ve canceled my Netflix subscription (I guess I’m a luddite).  Looking at the text, the link is pretty obviously malicious.

So let’s browse there (from a sandbox VM).  That login page looks pretty good!  It should, since if you look at the page source, it pulls most of the visible elements from the Netflix website.  This looks a lot like something we’d do in a penetration test using the Social Engineering Toolkit (SET).

Let’s put some fake credentials in:  [email protected] / TestTest123!

Oh surprise, the credentials worked!  What are they asking for next?   Credit Card information of course!

So no fancy malware, just “click here and give me your credit card” phishing – the only different thing is the SMS source, and really that’s not even all that out-of-the way these days anymore.

This follows along with what you might do in a penetration test, except in a pentest likely you are just collecting the credentials – I don’t think anybody would be cool with pentesters taking that next step. (least of all Law Enforcement).  Though depending on the site, quite often your credentials might be worth more than your credit card information.

Oh, but I’d never fall for that you say!  But think of other folks in your family, the ones who ask you about “computer stuff” over the holidays.  Or your neighbours, coworkers and so on.  This attack was a pretty obvious “spray the area code / cell phone range” attack – they didn’t attack me personally, they’re blanketing as many people as they can find.  Even if 1 person in a hundred, or one person in a thousand go the distance, this makes money.  And think about it, if you made a list of people you know, there’s almost certainly a “clicker” in the 10, I know my “clicker friends and family” ratio is certainly well above 1%.

Also think of how people work.  Once they click that first link (in the text message), they’re almost certain to take that next step.  In fact, the more hoops they need to jump through, the more likely they are to jump through that next hoop.  It’s almost like they’re determined to get the prize at the bottom of the cracker-jack box (I just dated myself there too I guess).

Every person who get to the end of this scam is now on the hook for fraudulent credit card transactions.  Either it’ll be a one-time $4999 hit (or whatever the fraud watermark number is these days), or they’ll be buying small items forever (which the attacker then likely returns, with the return going into a different account) until they figure out that they’ve been hacked.  And given the supply chain, the victim’s credit card info might be sold a few times before it’s ever used.  I doubt that the original attacker wants the risk of being busted on the financial side.

If you’ve been following my recent blogs, you’ll note that I tend to write  a lot about the Center for Internet Security Critical Controls.  This attack falls squarely into Control 17 – Implement a Security Awareness and Training Program.  An attack like this is certainly something that you might present to the non-technical folks in your workplace.  Or from the other perspective, if you can get your developers to look at unusual site activity (for instance – identify and log on malicious IP addresses that pull the site graphics but aren’t actually loading the page), you can work that into your perimeter IPS or WAF configs – a decent home-grown Threat Intelligence feed (those are often the best kind IMHO).

Unfortunately, effective end user education is hard.  Either you need to pay for it, or you need to take time away from your technical challenges and prepare material to then deliver the actual program (whatever format that takes).  And almost without fail, we are almost all measured more heavily on the tech work we do, as opposed to things like end user education.

Has your organization’s web assets been impersonated in an attack on 3rd parties?  Have you had folks in your organization fall for something like this?  Or have you used attacks of this kind to bolster your perimeter?  Please, share via our comment form, almost every facet of this topic is something we fall short on.

===============
Rob VandenBrink
www.coherentsecurity.com

 

(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) →

What is Listening On Port 9527/TCP?, (Thu, Aug 1st)

Last week, Kevin wrote a diary about a marked uptick of %%port:34567%%. When I looked at some of the hosts scanning for it, I noticed that many of them are also scanning %%port:9527%%. So I put up a little honeypot for this port, and what I found is not the HTTP requests I expected (there are some vulnerabilities in webcam servers associated with this port). Instead, I found that it looks like the attacker is expecting an unauthenticated shell. Here is a typical set of commands:

/bin/busybox LA;
cd /var/tmp; echo -e “/bin/busybox telnetd -p9000 -l/bin/sh; /bin/busybox LA” > telneton; sh telneton;

The first command is a typical test if busybox is installed on the system. The attacker is expecting something like “LA: applet not found” back in return. Next, the attacker is creating a little script in /var/tmp/telneton. This script will be used to start the telnet server on port 9000. 

I haven’t found yet what the “next step” will be, but am waiting for incoming telnet connections on port 9000. So far I am just getting the usual “webcam” HTTP requests on port 9000 like 

REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0
CSeq:12
Accept:text/HDP
Func-Version:0x10
Content-Length:15
Segment-Num:0

But I think these are unrelated. Scans for %%port:9527%% had some interesting “decay patterns” over the last few months.

Let me know if you have any insight into this activity
 


Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
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) →
Page 3 of 295 12345...»