Monthly Archives: February 2014

Episode #175: More Time! We Need More Time!

Tim leaps in

Every four years (or so) we get an extra day in February, leap year. When I was a kid this term confused me. Frogs leap, they leap over things. A leap year should be shorter! Obviously, I was wrong.

This extra day can give us extra time to complete tasks (e.g. write blog post), so we are going to use our shells to check if the current year is a leap year.

PS C:\> [DateTime]::IsLeapYear(2014)
False

Sadly, this year we do not have extra time. Let's confirm that this command does indeed work by checking a few other years.

PS C:\> [DateTime]::IsLeapYear(2012)
True
PS C:\> [DateTime]::IsLeapYear(2000)
True
PS C:\> [DateTime]::IsLeapYear(1900)
False

Wait a second! Something is wrong. The year 1900 is a multiple of 4, why is it not a leap year?

The sun does not take exactly 365.25 days to get around the sun, it is actually 365.242199 days. This means that if we always leaped every four years we would slowly get off course. So every 100 years we skip the leap year.

Now you are probably wondering why 2000 had a leap year. That is because it is actually the exception to the exception. Every 400 years we skip skipping the leap year. What a cool bit of trivia, huh?

Hal, how jump is your shell?

Hal jumps back

I should have insisted Tim do this one in CMD.EXE. Isn't is nice that PowerShell has a IsLeapYear() built-in? Back in my day, we didn't even have zeroes! We had to bend two ones together to make zeroes! Up hill! Both ways! In the snow!

Enough reminiscing. Let's make our own IsLeapYear function in the shell:


function IsLeapYear {
year=${1:-$(date +%Y)};
[[ $(($year % 400)) -eq 0 || ( $(($year % 4)) -eq 0 && $(($year % 100)) -ne 0 ) ]]
}

There's some fun stuff in this function. First we check to see if the function is called with an argument ("${1-..."). If so, then that's the year we'll check. Otherwise we check the current year, which is the value returned by "$(date +%Y)".

The other line of the function is the standard algorithm for figuring leap years. It's a leap year if the year is evenly divisible by 400, or divisible by 4 and not divisible by 100. Since shell functions return the value of the last command or expression executed, our function returns whether or not it's a leap year. Nice and easy, huh?

Now we can run some tests using our IsLeapYear function, just like Tim did:


$ IsLeapYear && echo Leaping lizards! || echo Arf, no
Arf, no
$ IsLeapYear 2012 && echo Leaping lizards! || echo Arf, no
Leaping lizards!
$ IsLeapYear 2000 && echo Leaping lizards! || echo Arf, no
Leaping lizards!
$ IsLeapYear 1900 && echo Leaping lizards! || echo Arf, no
Arf, no

Assuming the current year is not a Leap Year, we could even wrap a loop around IsLeapYear to figure out the next leap year:


$ y=$(date +%Y); while :; do IsLeapYear $((++y)) && break; done; echo $y
2016

We begin by initializing $y to the current year. Then we go into an infinte loop ("while :; do..."). Inside the loop we add one to $y and call IsLeapYear. If IsLeapYear returns true, then we "break" out of the loop. When the loop is all done, simply echo the last value of $y.

Stick that in your PowerShell pipe and smoke it, Tim!

Amazon’s Mobile Shopping Clients and CAPTCHA

Amazon is a popular online retailer serving millions of users. Unfortunately, FireEye mobile security researchers have found security issues within Amazon’s mobile apps on both Android and iOS platforms through which attackers can crack the passwords of target Amazon accounts. Amazon confirmed our findings and hot fixed the issue.

Recently, we found two security issues within Amazon’s mobile apps on both Android and iOS platforms:

  • No limitation or CAPTCHA for password attempts
  • Weak password policy

Attackers can exploit these two security issues remotely against target Amazon accounts.

fig1 Figure 1. Verification Code for Wrong Password Attempts

A CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a challenge-response test designed to determine whether the user is a human. CAPTCHAs are well adopted for preventing programmed bots from accessing online services for bad purposes, such as conducting denial-of-service attacks, harvesting information and cracking passwords.

The web version of Amazon requires the user to complete a CAPTCHA after ten incorrect password attempts (Figure 1), to prevent password cracking. However, Amazon’s mobile apps haven’t adopted such protection using CAPTCHA (Figure 2 and Figure 3). This design flaw provides attackers the chance to crack any Amazon account’s password using brute force.

 fig2 Figure 2. Amazon Android App

fig3 Figure 3. Amazon iOS App

Furthermore, Amazon doesn’t have a strong password strength requirement. It accepts commonly used weak passwords such as "123456" and "111111". We know that the weaker the password, the easier for hackers to break into an account. Therefore, allowing weak passwords puts account safety to potential security risks. Given that there are many well-known previous password leakages, attackers can use these password leakages as knowledge bases to conduct password cracking.

As a proof of concept, we figured out the password of one Amazon account we setup within 1000 attempts, using the latest version (2.8.0) of Amazon’s Android shopping client.

After receiving our vulnerability report, Amazon hot fixed the first issue by patching their server. Now if the user tries multiple incorrect passwords, the server will block the user from login (Figure 4). In the future, we suggest adding CAPTCHA support for Amazon mobile (Android and iOS) apps, and enforcing requirements for stronger passwords.

fig4 Figure 4. Wrong Password Block

Hack Naked TV 14-15

FTP Passwords!! They are everywhere!! http://tinyurl.com/HNTV-FTP-Creds

Chargeware.. It is legal, but it can still get you shot. http://tinyurl.com/HNTV-EULA

Target breach and the state of phishing: http://tinyurl.com/HNTV-Target-Email

SANS 560 Orlando April 7th - 12th

http://tinyurl.com/SANS-560-Orlando

Please note the link and the dates in the video are wrong for SANS Orlando.

Background Monitoring on Non-Jailbroken iOS 7 Devices — and a Mitigation

Background monitoring mobile applications has become a hot topic on mobile devices. Existing reports show that such monitoring can be conducted on jailbroken iOS devices. FireEye mobile security researchers have discovered such vulnerability, and found approaches to bypass Apple's app review process effectively and exploit non-jailbroken iOS 7 successfully. We have been collaborating with Apple on this issue.

fig1

Fig.1 Background Monitoring

We have created a proof-of-concept "monitoring" app on non-jailbroken iOS 7.0.x devices. This “monitoring” app can record all the user touch/press events in the background, including, touches on the screen, home button press, volume button press, and TouchID press, and then this app can send all user events to any remote server, as shown in Fig.1. Potential attackers can use such information to reconstruct every character the victim inputs.

Note that the demo exploits the latest 7.0.4 version of iOS system on a non-jailbroken iPhone 5s device successfully. We have verified that the same vulnerability also exists in iOS versions 7.0.5, 7.0.6, and 6.1.x. Based on the findings, potential attackers can either use phishing to mislead the victim to install a malicious/vulnerable app or exploit another remote vulnerability of some app, and then conduct background monitoring.

fig2

Fig.2 Background App Refresh Settings

fig3

Fig.3 Killing An App on iOS7

iOS7 provides settings for "background app refresh". Disabling unnecessary app's background refreshing contributes to preventing the potential background monitoring. However, it can be bypassed. For example, an app can play music in the background without turning on its "background app refresh" switch. Thus a malicious app can disguise itself as a music app to conduct background monitoring.

Before Apple fixes this issue, the only way for iOS users to avoid this security risk is to use the iOS task manager to stop the apps from running in the background to prevent potential background monitoring. iOS7 users can press the Home button twice to enter the task manager and see preview screens of apps opened, and then swipe an app up and out of preview to disable unnecessary or suspicious applications running on the background, as shown in Fig.3.

We conducted this research independently before we were aware of this recent report. We hope this blog could help users understand and mitigate this threat further.

Acknowledgement: Special thanks to Jari Salomaa for his valuable comments and feedback. We also thank Raymond Wei, Dawn Song, and Zheng Bu for their valuable help on writing this blog.

Deep Data Governance

One of the first things to catch my eye this week at RSA was a press release by STEALTHbits on their latest Data Governance release. They're a long time player in DG and as a former employee, I know them fairly well. And where they're taking DG is pretty interesting.

The company has recently merged its enterprise Data (files/folders) Access Governance technology with its DLP-like ability to locate sensitive information. The combined solution enables you to locate servers, identify file shares, assess share and folder permissions, lock down access, review file content to identify sensitive information, monitor activity to look for suspicious activity, and provide an audit trail of access to high-risk content.

The STEALTHbits solution is pragmatic because you can tune where it looks, how deep it crawls, where you want content scanning, where you want monitoring, etc. I believe the solution is unique in the market and a number of IAM vendors agree having chosen STEALTHbits as a partner of choice for gathering Data Governance information into their Enterprise Access Governance solutions.

Learn more at the STEALTHbits website.

RSA Conference 2014

I'm at the RSA Conference this week. I considered the point of view that perhaps there's something to be said for abstaining this year but ultimately my decision to maintain course was based on two premises: (1) RSA didn't know the NSA had a backdoor when they made the arrangement and (2) The conference division doesn't have much to do with RSA's software group.

Anyway, my plan is to take notes and blog or tweet about what I see. Of course, I'll primarily be looking at Identity and Access technologies, which is only a subset of Information Security. And I'll be looking for two things: Innovation and Uniqueness. If your company has a claim on either of those in IAM solutions, please try to catch my attention.

CVE-2014-0499 (adobe_air, adobe_air_sdk, flash_player)

Adobe Flash Player before 11.7.700.269 and 11.8.x through 12.0.x before 12.0.0.70 on Windows and Mac OS X and before 11.2.202.341 on Linux, Adobe AIR before 4.0.0.1628 on Android, Adobe AIR SDK before 4.0.0.1628, and Adobe AIR SDK & Compiler before 4.0.0.1628 do not prevent access to address information, which makes it easier for attackers to bypass the ASLR protection mechanism via unspecified vectors.

CVE-2014-0502 (adobe_air, adobe_air_sdk, flash_player)

Double free vulnerability in Adobe Flash Player before 11.7.700.269 and 11.8.x through 12.0.x before 12.0.0.70 on Windows and Mac OS X and before 11.2.202.341 on Linux, Adobe AIR before 4.0.0.1628 on Android, Adobe AIR SDK before 4.0.0.1628, and Adobe AIR SDK & Compiler before 4.0.0.1628 allows remote attackers to execute arbitrary code via unspecified vectors, as exploited in the wild in February 2014.

CVE-2014-0498 (adobe_air, adobe_air_sdk, flash_player)

Stack-based buffer overflow in Adobe Flash Player before 11.7.700.269 and 11.8.x through 12.0.x before 12.0.0.70 on Windows and Mac OS X and before 11.2.202.341 on Linux, Adobe AIR before 4.0.0.1628 on Android, Adobe AIR SDK before 4.0.0.1628, and Adobe AIR SDK & Compiler before 4.0.0.1628 allows attackers to execute arbitrary code via unspecified vectors.

Operation GreedyWonk: Multiple Economic and Foreign Policy Sites Compromised, Serving Up Flash Zero-Day Exploit

Less than a week after uncovering Operation SnowMan, the FireEye Dynamic Threat Intelligence cloud has identified another targeted attack campaign — this one exploiting a zero-day vulnerability in Flash. We are collaborating with Adobe security on this issue. Adobe has assigned the CVE identifier CVE-2014-0502 to this vulnerability and released a security bulletin.

As of this blog post, visitors to at least three nonprofit institutions — two of which focus on matters of national security and public policy — were redirected to an exploit server hosting the zero-day exploit. We’re dubbing this attack “Operation GreedyWonk.”

We believe GreedyWonk may be related to a May 2012 campaign outlined by ShadowServer, based on consistencies in tradecraft (particularly with the websites chosen for this strategic Web compromise), attack infrastructure, and malware configuration properties.

The group behind this campaign appears to have sufficient resources (such as access to zero-day exploits) and a determination to infect visitors to foreign and public policy websites. The threat actors likely sought to infect users to these sites for follow-on data theft, including information related to defense and public policy matters.

Discovery

On Feb. 13, FireEye identified a zero-day Adobe Flash exploit that affects the latest version of the Flash Player (12.0.0.4 and 11.7.700.261). Visitors to the Peter G. Peterson Institute for International Economics (www.piie[.]com) were redirected to an exploit server hosting this Flash zero-day through a hidden iframe.

We subsequently found that the American Research Center in Egypt (www.arce[.]org) and the Smith Richardson Foundation (www.srf[.]org) also redirected visitors the exploit server. All three organizations are nonprofit institutions; the Peterson Institute and Smith Richardson Foundation engage in national security and public policy issues.

Mitigation

To bypass Windows’ Address Space Layout Randomization (ASLR) protections, this exploit targets computers with any of the following configurations:

  • Windows XP
  • Windows 7 and Java 1.6
  • Windows 7 and an out-of-date version of Microsoft Office 2007 or 2010

Users can mitigate the threat by upgrading from Windows XP and updating Java and Office. If you have Java 1.6, update Java to the latest 1.7 version. If you are using an out-of-date Microsoft Office 2007 or 2010, update Microsoft Office to the latest version.

These mitigations do not patch the underlying vulnerability. But by breaking the exploit’s ASLR-bypass measures, they do prevent the current in-the-wild exploit from functioning.

Vulnerability analysis

GreedyWonk targets a previously unknown vulnerability in Adobe Flash. The vulnerability permits an attacker to overwrite the vftable pointer of a Flash object to redirect code execution.

ASLR bypass

The attack uses only known ASLR bypasses. Details of these techniques are available from our previous blog post on the subject (in the “Non-ASLR modules” section).

For Windows XP, the attackers build a return-oriented programming (ROP) chain of MSVCRT (Visual C runtime) gadgets with hard-coded base addresses for English (“en”) and Chinese (“zh-cn” and “zh-tw”).

On Windows 7, the attackers use a hard-coded ROP chain for MSVCR71.dll (Visual C++ runtime) if the user has Java 1.6, and a hard-coded ROP chain for HXDS.dll (Help Data Services Module) if the user has Microsoft Office 2007 or 2010.

Java 1.6 is no longer supported and does not receive security updates. In addition to the MSVCR71.dll ASLR bypass, a variety of widely exploited code-execution vulnerabilities exist in Java 1.6. That’s why FireEye strongly recommends upgrading to Java 1.7.

The Microsoft Office HXDS.dll ASLR bypass was patched at the end of 2013. More details about this bypass are addressed by Microsoft’s Security Bulletin MS13-106 and an accompanying blog entry. FireEye strongly recommends updating Microsoft Office 2007 and 2010 with the latest patches.

Shellcode analysis

The shellcode is downloaded in ActionScript as a GIF image. Once ROP marks the shellcode as executable using Windows’ VirtualProtect function, it downloads an executable via the InternetOpenURLA and InternetReadFile functions. Then it writes the file to disk with CreateFileA and WriteFile functions. Finally, it runs the file using the WinExec function.

PlugX/Kaba payload analysis

Once the exploit succeeds, a PlugX/Kaba remote access tool (RAT) payload with the MD5 hash 507aed81e3106da8c50efb3a045c5e2b is installed on the compromised endpoint. This PlugX sample was compiled on Feb. 12, one day before we first observed it, indicating that it was deployed specifically for this campaign.

This PlugX payload was configured with the following command-and-control (CnC) domains:

  • java.ns1[.]name
  • adservice.no-ip[.]org
  • wmi.ns01[.]us

Sample callback traffic was as follows:

POST /D28419029043311C6F8BF9F5 HTTP/1.1

Accept: */*

HHV1: 0

HHV2: 0

HHV3: 61456

HHV4: 1

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; SV1)

Host: java.ns1.name

Content-Length: 0

Connection: Keep-Alive

Cache-Control: no-cache

Campaign analysis

Both java.ns1[.]name and adservice.no-ip[.]org resolved to 74.126.177.68 on Feb. 18, 2014. Passive DNS analysis reveals that the domain wmi.ns01.us previously resolved to 103.246.246.103 between July 4, 2013 and July 15, 2013 and 192.74.246.219 on Feb. 17, 2014.  java.ns1[.]name also resolved to 192.74.246.219 on February 18.

Domain First Seen Last Seen IP Address
adservice.no-ip[.]org adservice.no-ip[.]org 2014-02-18 2014-02-18 2014-02-19 2014-02-19 74.126.177.68 74.126.177.68
java.ns1[.]name java.ns1[.]name 2014-02-18 2014-02-18 2014-02-19 2014-02-19 74.126.177.68 74.126.177.68
java.ns1[.]name java.ns1[.]name 2014-02-18 2014-02-18 2014-02-18 2014-02-18 192.74.246.219 192.74.246.219
wmi.ns01[.]us wmi.ns01[.]us 2014-02-17 2014-02-17 2014-02-17 2014-02-17 192.74.246.219 192.74.246.219
proxy.ddns[.]info proxy.ddns[.]info 2013-05-02 2013-05-02 2014-02-18 2014-02-18 103.246.246.103 103.246.246.103
updatedns.ns02[.]us updatedns.ns02[.]us 2013-09-06 2013-09-06 2013-09-06 2013-09-06 103.246.246.103 103.246.246.103
updatedns.ns01[.]us updatedns.ns01[.]us 2013-09-06 2013-09-06 2013-09-06 2013-09-06 103.246.246.103 103.246.246.103
wmi.ns01[.]us wmi.ns01[.]us 2013-07-04 2013-07-04 2013-07-15 2013-07-15 103.246.246.103 103.246.246.103

 

MD5 Family Compile Time Alternate C2s
7995a9a6a889b914e208eb924e459ebc 7995a9a6a889b914e208eb924e459ebc PlugX PlugX 2012-06-09 2012-06-09 fuckchina.govnb[.]com fuckchina.govnb[.]com
bf60b8d26bc0c94dda2e3471de6ec977 bf60b8d26bc0c94dda2e3471de6ec977 PlugX PlugX 2010-03-15 2010-03-15 microsafes.no-ip[.]org microsafes.no-ip[.]org
fd69793bd63c44bbb22f9c4d46873252 fd69793bd63c44bbb22f9c4d46873252 Poison Ivy Poison Ivy 2013-03-07 2013-03-07 N/A N/A
88b375e3b5c50a3e6c881bc96c926928 88b375e3b5c50a3e6c881bc96c926928 Poison Ivy Poison Ivy 2012-06-11 2012-06-11 N/A N/A
cd07a9e49b1f909e1bd9e39a7a6e56b4 cd07a9e49b1f909e1bd9e39a7a6e56b4 Poison Ivy Poison Ivy 2012-06-11 2012-06-11 N/A N/A

The Poison Ivy variants that connected to the domain wmi.ns01[.]us had the following unique configuration properties:

Domain First Seen Last Seen IP Address
fuckchina.govnb[.]com fuckchina.govnb[.]com 2013-12-11 2013-12-11 2013-12-11 2013-12-11 204.200.222.136 204.200.222.136
microsafes.no-ip[.]org microsafes.no-ip[.]org 2014-02-12 2014-02-12 2014-02-12 2014-02-12 74.126.177.70 74.126.177.70
microsafes.no-ip[.]org microsafes.no-ip[.]org 2013-12-04 2013-12-04 2013-12-04 2013-12-04 74.126.177.241 74.126.177.241

We found a related Poison Ivy sample (MD5 8936c87a08ffa56d19fdb87588e35952) with the same “java7” password, which was dropped by an Adobe Flash exploit (CVE-2012-0779). In this previous incident, visitors to the Center for Defense Information website (www.cdi[.]org — also an organization involved in defense matters — were redirected to an exploit server at 159.54.62.92.

This exploit server hosted a Flash exploit file named BrightBalls.swf (MD5 1ec5141051776ec9092db92050192758). This exploit, in turn, dropped the Poison Ivy variant. In addition to using the same password “java7,” this variant was configured with the mutex with the similar pattern of “YFds*&^ff” and connected to a CnC server at windows.ddns[.]us.

Using passive DNS analysis, we see the domains windows.ddns[.]us and wmi.ns01[.]us both resolved to 76.73.80.188 in mid-2012.

Domain First Seen Last Seen IP Address
wmi.ns01.us wmi.ns01.us 2012-07-07 2012-07-07 2012-09-19 2012-09-19 76.73.80.188 76.73.80.188
windows.ddns.us windows.ddns.us 2012-05-23 2012-05-23 2012-06-10 2012-06-10 76.73.80.188 76.73.80.188

During another earlier compromise of the same www.cdi.org website, visitors were redirected to a Java exploit test.jar (MD5 7d810e3564c4eb95bcb3d11ce191208e). This jar file exploited CVE-2012-0507 and dropped a Poison Ivy payload with the hash (MD5 52aa791a524b61b129344f10b4712f52). This Poison Ivy variant connected to a CnC server at ids.ns01[.]us. The domain ids.ns01[.]us also overlaps with the domain wmi.ns01[.]us on the IP 194.183.224.75.

Domain First Seen Last Seen IP Address
wmi.ns01[.]us wmi.ns01[.]us 2012-07-03 2012-07-03 2012-07-04 2012-07-04 194.183.224.75 194.183.224.75
ids.ns01[.]us ids.ns01[.]us 2012-04-23 2012-04-23 2012-05-18 2012-05-18 194.183.224.75 194.183.224.75

The Poison Ivy sample referenced above (MD5 fd69793bd63c44bbb22f9c4d46873252) was delivered via an exploit chain that began with a redirect from the Center for European Policy Studies (www.ceps[.]be). In this case, visitors were redirected from www.ceps[.]be to a Java exploit hosted on shop.fujifilm[.]be.

In what is certainly not a coincidence, we also observed www.arce[.]org (one of the sites redirecting to the current Flash exploit) also redirect visitors to the Java exploit on shop.fujifilm[.]be in 2013.

greedywonk-campaign-v2

Conclusion

This threat actor clearly seeks out and compromises websites of organizations related to international security policy, defense topics, and other non-profit sociocultural issues. The actor either maintains persistence on these sites for extended periods of time or is able to re-compromise them periodically.

This actor also has early access to a number of zero-day exploits, including Flash and Java, and deploys a variety of malware families on compromised systems. Based on these and other observations, we conclude that this actor has the tradecraft abilities and resources to remain a credible threat in at least the mid-term.

Joff Thyer on Django Static Code Analysis – Episode 362, Part 2 – February 13, 2014

DjangoSCA is a python based Django project source code security auditing system that makes use of the Django framework itself, the Python Abstract Syntax Tree (AST) library, and regular expressions. Django projects are laid out in a directory structure that conforms to a standard form using known classes, and standard file naming such as settings.py, urls.py, views.py, and forms.py. DjangoSCA is designed for the user to pass the root directory of the Django project as an argument to the program, from which it will recursively descend through the project files and perform source code checks on all python source code, and Django template files.

Interview with Paul Paget from Pwnie Express – Episode 362, Part 1 – February 13, 2014

Paul Paget was appointed CEO of Pwnie Express in August 2013 to help grow it into the leader for testing the security of remote operations. Joining Dave Porcello, the founder, and his outstanding team. The PWN Plug has created a hit and they aim to make it a standard around the world. It radically simplifies and reduces the cost of assessing security, especially in hard to reach out of the way part of an organization such as bank offices, stores and off shore facilities.

Forbes Data Breach Impacts Over 1 Millions Accounts

Today The Syrian Electronic army via their Twitter account @Official_SEA16 announced that they have leaked the Forbes WordPress user database not long after it was announced that they had managed to hack their website.

Eduard Kovacs from Softpedia has stated that the leak has a been uploaded to an IP address (91.227.222.39) which was also used last year in a defacement on http://marines.com/ as well.

This breach is quite substantial and includes 1,056,986 unique emails addresses and accounts with 844 of them being government (.GOV) and 14,572 educational accounts (.EDU). In addition, the dump contains credentials from a Forbes wp_users database and contains 564 Forbes.com based emails including administrators accounts.

Forbes has posted a statement to their Facebook page regarding the breach urging all users to reset their password on the Forbes network and on any other sites they may have used the same credentials.

Security message: Forbes.com was targeted in a digital attack and our publishing platform was compromised. Users’ email addresses may have been exposed. The passwords were encrypted, but as a precaution, we strongly encourage Forbes readers and contributors to change their passwords on our system, and encourage them to change them on other websites if they use the same password elsewhere. We have notified law enforcement. We take this matter very seriously and apologize to the members of our community for this breach.

As Eduard points out that although the passwords are encrypted, the email addresses are still very useful. In addition, it is not clear the type of the encryption used and there is still a potential that they can easily be decrypted. It is clear that this breach has the potential to pose a significant risk for many of their users.

Breakout of just a few type of email domains:
844 .GOV
14,572 .EDU
91,464 hotmail.com
3,460 mac.com
185, 271 yahoo.com
407,787 gmail.com
25,050 aol.com

Plasma HTTP

Advert:

Login:

Online bot:

offline bots:

Commands:

Statistics:

Logs:



Yeah take this lame article to second degree, i just talk about Plasma because i've promised to write something today on irc.

I'm not dead but there nothing interesting to review for the moment, only crappy bots
That also one of the reason i haven't talked of JackPos and all the rest.
I have some interesting things but it's too sensitive for the moment and when it's not the reason, it's due to people who request me to don't talk of a subject because they want to cover it 'first' for their company but who finaly write nothing, so i still wait (you know who you are)
e.g: ZeusVM, i wanted to talk about the weird version who appeared since some months now
a version who download from sites (on ssl and fastflux) a picture with a config embedded inside.. but well, fuck it now.
As i already told on a previous article, i may appear inactive but i'm not so inactive.
I've recently do this, i still continue to posts malwares, break things but without necessarily talking about it or just briefly like for jackTrash, and today: PlasmaTrash, and iTrashing.
I still continue to do trashy video, show trashy things on my hackerspace and talk about trashs on irc. (yeah that a lot of trash)
So for the moment, i just wait and see...

Safer Internet Day: 4 Things You Might Not Realise Your Webfilter Can Do

Since it's Safer Internet Day today, I thought i'd use it as an excuse to write a blog post. Regular readers will know I don't usually need an excuse, but I always feel better if I do.

Yesterday, I was talking to our Content Filter team about a post on the popular Edugeek forum, where someone asked "is it possible to block adult content in BBC iPlayer?". Well, with the right web filter, the answer is "yes", but how many people think to even ask the question? Certainly we hadn't thought much about formalising the answer. So I'm going to put together a list of things your web filter should be capable of, but you might not have realised...


1. Blocking adult content on "TV catch up" services like iPlayer. With use of the service soaring, it's important that any use in education is complemented with the right safeguards. We don't need students in class seeing things their parents wouldn't want them watching at home. There's a new section of the Smoothwall blocklist now which will deal with anything on iPlayer that the BBC deem unsuitable for minors.

2. Making Facebook and Twitter "Read Only". These social networks are great fun, and it can be useful to relax the rules a bit to prevent students swarming for 4G. A read-only approach can help reduce the incidence of cyber-bullying and keep users more focused.

3. Stripping the comments out of YouTube. YouTube is a wonderful resource, and the majority of video is pretty safe (use Youtube for Schools if you want to tie that down further — your filter can help you there too). The comments on videos, however, are often at best puerile and at worst downright offensive. Strip out the junk, and leave the learning tool - win win!

4. Busting Google searches back down to HTTP and forcing SafeSearch. Everybody appreciates a secure service, but when Google moved their search engine to HTTPS secure traffic by default, they alienated the education community. With SSL traffic it is much harder to vet search terms, log accesses in detain, and importantly force SafeSearch. Google give you DNS trickery to force the site back into plain HTTP - but that's a pain to implement, especially on a Windows DNS server. Use your web filter to rewrite the requests, and have the best of both.

Interview with Brian Richardson, Interview with Chris Taylor, Drunken Security News – Episode 361 – February 6, 2014

Brian Richardson is a Senior Technical Marketing Engineer with Intel Software and Services Group. After fifteen years of external experience with BIOS and UEFI, Brian joined Intel in 2011 to focus on industry enabling for UEFI. Brian has a Master's Degree in Electrical Engineering from Clemson University, along with five US patents and a variety of seemingly disconnected hobbies involving video production. Brian has presented at Intel Developer Forum, UEFI Plugfest, Windows Ecosystem Summit and WinHEC. Brian can be contacted via twitter at @Intel_Brian and @Intel_UEFI.

Chris has been in IT security since the late 90’s with his first role in network support by monitoring IDS and explaining how hackers were breaking into places and what they did once they were in. He now specializes in intrusion analysis and runs the professional services side of CyTech Services, overseeing the commercial consulting and managed security services.

Plus, the stories of the week!

Working With the Darkleech Bitly Data

Data Driven Security took the time to analyze the raw data that I published in my recent post on Sucuri blog about how I used Bitly data to understand the scale of the Darkleech infection.

In their article, they have a few questions about data formats, meaning of certain fields and some inconsistencies, so I’ll try to answer their questions here and explain how I worked with the data.

So I needed to get information about all the links of the “grantdad” bitly account.

I checked the API and somehow missed the “link_history” API request (it was the first time I worked with the bitly API), so I decided to screenscrape the web pages where bitly listed the links creaded by grantdad. 1,000 pages with 10 links on each. Since pages didn’t contain all the information I needed I only collected the short links so that I could use them later in API calls to get more detailed information about each of them.

As you can see I was limited with the 10,000 links that bitly made available via their web interface. Not sure if I could get more links via that link_history API. Right now it returns “ACCOUNT_SUSPENDED” and when it was not suspended, API calls for known links beyond those 10,000 produced various errors.

When I compiled my list of 10,000 links I used the following API calls to get information about each of the links:

Referring domains

API:link/referring_domains — for each link, it returned a list of domains referring traffic to this link (in our case sites, containing the iframes) along with the number of clicks from each domain. This helped me compile this list of iframe loads per domain: http://pastebin.com/HYaY2yMb. Then I tried to resolve each of the domain names and created this list of infected domains per IP address: http://pastebin.com/Gxr51Nc1.
I also used this API call to get number of iframe loads for each bitly link.

Info

API:link/info – this gave me timestamps of the links and their long URLs (the rest information was not interesting for my research). Unfortunately, this particular API call is poorly documented so I can only guess what this timestamp mean. It is actually called “indexed“. But I guess it’s the time when the link was created. It is definiteley not the time of the first click because there were no registered clicks for many of the links. As a result, I compiled these datasets:
http://pastebin.com/UmkDZZp0
http://pastebin.com/w7Kq3ybV ,
which contain tab separated values of “bitly link id”, “timestamp”, “# of clicks/iframe loads”, and “long URL”.

At that point, I already had the number of iframe loads from the previous step (“link/referring_domains“). Then, for readability, I converted the numeric timestamp using this Python function datetime.datetime.fromtimestamp(). However, you can notice that the second dataset (for January 28th) has a different date format. Instead of “2014-01-25 19:10:07” it uses “Jan 28 23:10:19“. Why? Because of pastebin.com. Because it doesn’t allow unregistered users to post more than 500Kb of data (I deliberately post such data as a guest). Removing the year from the date allowed me to save 4 bytes on each row and fit the dataset in 500Kb.

Actually this 500Kb limit is the reason why I have separate pastebins for each date and only specify bitly ids instead of the full bitly links.

Countries

And finally, API:link/countries – for each link, it returned a list of countries referring traffic to this link along with the number of clicks from those countries. This helped me compile this list of iframe loads per country http://pastebin.com/SZJMw3vx.

The last dataset Feb 4-5

When I wrote my blogpost on February 5th, I noticed that there were new links available on the Bitly.com grantdad acount page. I began to browse pages of his links and figured that most of the links were the same (Jan 25 and 28) but around 1,700 of them were new (late February 4th and the beginning of February 5th). I immediately repeated the same procedure that included screenscraping, and 3 API calls for each new bitly link. After that I created this new dataset http://pastebin.com/YecHzQ1W and updated the rest datasets (domains, countries, etc).

Some more details

If you check the total numbers in these two datasets (domains) http://pastebin.com/HYaY2yMb and (countries) http://pastebin.com/SZJMw3vx you’ll see the different in total number of iframe loads: 87152 and 87269. I don’t know why. I used the same links just different API calls (referring_domains and countries) and the totals are supposed to be the same. I didn’t save the “per link” data so can’t tell exactly whether it was my error or the bitly API produces slightly inconsistent results. Anyway, the difference is neglectable for my calculations and doesn’t affect the estimations (given that I tried to underestimate when in doubt ).

I didn’t check for duplicates that guys from Data Driven security found in my datasets. They must have to do with my screenscraper and the way that Bitly.com displays links in user accounts. The total number of scraped links matched the number of links that Bitly reported for the user. The extra 121 clicks that these duplicates are responsible for are so close to the 117 difference that I mentioned above so I wonder if these numbers somehow connected? Anyway, this shouldn’t affect the accuracy of the estimates either.

Building the geo distribution map

For the map, I used the Geochart from Google visualization. Since the difference in numbers of clicks for the top 3 countries and the lower half of the list was 3 orders of magnitude, I had to re-scale the data so that we could still see the difference between countries with 50 iframe loads and 2 iframe loads.. I used a square of a natural logarithm for that

Math.pow( Math.round( Math.log(i)), 2)

This gave me a nice distribution from 0 to 100 and the below map.

Darkleech iFrame load geo distribution

IFrame Load Geo Distribution

Speculation on the link generation

After checking the link creation per minute-of-an-hour distribution, Bob Rudis wondered:

This is either the world’s most inconsistent (or crafty) cron-job or grantdad like to press ↑ + ENTER alot.

I guess, it was neither cron-job nor manual link creation. I think the [bitly] links were created on-demand. So if someone loads a page and Darkleech needs to inject an iframe then it (or rather the server it works with) generates a new bitly link. Given that this malware may lurk on a server, there may be time periods when no malicious code is being injection into any web pages across all the infected servers. At the same time, the bitly links with zero clicks may refer to page loads by various bots (including our own) when the malicious code is injected but the iframe is never loaded. On the other hand, the volume of bitly links with 0 clicks (~35%) suggests that there might really more complex link generation mechanism than a simple “on-demand” approach.

Anyway, that’s great when people double check our data and try to find new interesting patterns there. Make sure to let me know (here or on the Sucuri blog) if you find more patterns and inconsistencies, or have any comments on how the Darkleech works.

Related posts:

IAM for the Third Platform

As more people are using the phrase "third platform", I'll assume it needs no introduction or explanation. The mobile workforce has been mobile for a few years now. And most organizations have moved critical services to cloud-based offerings. It's not a prediction, it's here.

The two big components of the third platform are mobile and cloud. I'll talk about both.

Mobile

A few months back, I posed the question "Is MAM Identity and Access Management's next big thing?" and since I did, it's become clear to me that the answer is a resounding YES!

Today, I came across a blog entry explaining why Android devices are a security nightmare for companies. The pain is easy to see. OS Updates and Security Patches are slow to arrive and user behavior is, well... questionable. So organizations should be concerned about how their data and applications are being accessed across this sea of devices and applications. As we know, locking down the data is not an option. In the extended enterprise, people need access to data from wherever they are on whatever device they're using. So, the challenge is to control the flow of information and restrict it to proper use.

So, here's a question: is MDM the right approach to controlling access for mobile users? Do you really want to stand up a new technology silo that manages end-user devices? Is that even practical? I think certain technologies live a short life because they quickly get passed over by something new and better (think electric typewriters). MDM is one of those. Although it's still fairly new and good at what it does, I would make the claim that MDM is antiquated technology. In a BYOD world, people don't want to turn control of their devices over to their employers. The age of enterprises controlling devices went out the window with Blackberry's market share.

Containerization is where it's at. With App Containerization, organizations create a secure virtual workspace on mobile devices that enables corporate-approved apps to access, use, edit, and share corporate data while protecting that data from escape to unapproved apps, personal email, OS malware, and other on-device leakage points. For enterprise use-case scenarios, this just makes more sense than MDM. And many of the top MDM vendors have validated the approach by announcing MAM offerings. Still, these solutions maintain a technology silo specific to remote access which doesn't make much sense to me.

As an alternate approach, let's build MAM capabilities directly into the existing Access Management platform. Access Management for the third platform must accommodate for mobile device use-cases. There's no reason to have to manage mobile device access differently than desktop access. It's the same applications, the same data, and the same business policies. User provisioning workflows should accommodate for provisioning mobile apps and data rights just like they've been extended to provision Privileged Account rights. You don't want or need separate silos.

Cloud

The same can be said, for cloud-hosted apps. Cloud apps are simply part of the extended enterprise and should also be managed via the enterprise Access Management platform.

There's been a lot of buzz in the IAM industry about managing access (and providing SSO) to cloud services. There have even been a number of niche vendors pop-up that provide that as their primary value proposition. But, the core technologies for these stand-alone solutions is nothing new. In most cases, it's basic federation. In some cases, it's ESSO-style form-fill. But there's no magic to delivering SSO to SaaS apps. In fact, it's typically easier than SSO to enterprise apps because SaaS infrastructures are newer and support newer standards and protocols (SAML, REST, etc.)

My Point

I guess if I had to boil this down, I'm really just trying to dispel the myths about mobile and cloud solutions. When you get past the marketing jargon, we're still talking about Access Management and Identity Governance. Some of the new technologies are pretty cool (containerization solves some interesting, complex problems related to BYOD). But in the end, I'd want to manage enterprise access in one place with one platform. One Identity, One Platform. I wouldn't stand up a IDaaS solution just to have SSO to cloud apps. And I wouldn't want to introduce an MDM vendor to control access from mobile devices.

The third platform simply extends the enterprise beyond the firewall. The concept isn't new and the technologies are mostly the same. As more and newer services adopt common protocols, it gets even easier to support increasingly complex use-cases. An API Gateway, for example, allows a mobile app to access legacy mainframe data over REST protocols. And modern Web Access Management (WAM) solutions perform device fingerprinting to increase assurance and reduce risk while delivering an SSO experience. Mobile Security SDKs enable organizations to build their own apps with native security that's integrated with the enterprise WAM solution (this is especially valuable for consumer-facing apps).

And all of this should be delivered on a single platform for Enterprise Access Management. That's third-platform IAM.

Interview with Jared DeMott, Windows Meterpreter’s Extended API – Episode 360, Part 1 – January 30, 2014

Jared DeMott is a principal security researcher at Bromium and has spoken at security conferences such as Black Hat, Defcon, ToorCon, Shakacon, DakotaCon, GRRCon, and DerbyCon. He is active in the security community by teaching his Application Security course.

Windows Meterpreter recently got some new capabilities thru the Extended API module by OJ Reeves also known as TheColonial. He added support for: *Interacting with the Clipboard *Query services *Window enumeration *Executing ADSI Queries We will cover in this Technical Segment the ADSI interface since it gives us a capacity in enterprise environments not available previously in meterpreter other than a module from Meatballs called enum_ad_computers.