LizaMoon mass-injection SQL injection attack

Websense Security Labs and the Websense Threatseeker Network have identified a new malicious mass-injection campaign that we call LizaMoon. Websense customers are protected with the Advanced Classification Engine.

The LizaMoon mass-injection is a SQL injection attack that inserts the following line into the code of the page:

<script src=hxxp://lizamoon.com/ur.php></script>

According to a Google Search, over 28,000 226,000 URLs have been compromised. This includes several iTunes URLs, as you can see below:


And here is the injected code at one of those iTunes URLs:

The way iTunes works is that it downloads RSS/XML feeds from the publisher to update the podcast and list of available episodes. We believe that these RSS/XML feeds have been compromised with the injected code. The good thing is that iTunes encodes the script tags, which means that the script doesn't execute on the user's computer. So good job, Apple.The URL that is injected is unavailable right now, but the server is still up and running, so that could change at any time. While it was up, the script contained simple JavaScript code that redirected the user to a well-known Rogue AV site: hxxp://defender-uqko.in. That site is also unavailable right now, so we don't have the actual binary analysis information available yet.

The domain lizamoon.com was registered three days ago with clearly fake information:

UPDATE2: We have been monitoring the attack since it came out and noticed that the number of the compromised URLs is still increasing, 380,000 URLs so far, moreover, more domains started to be involved except for lizamoon.com.

Follow the story here for more updates.

ThinkGeek

ThinkGeek :: Blurgh! The ThinkGeek Blog - Take these broken things

ThinkGeek is looking for scavengers, hackers, school labs or hackerspaces who can take thier boxes of broken stuff from them every couple of months and then use the parts and pieces for hacking and building something of value, rather than discarding them right away. A novel thought. They want the labs or hackerspaces to pick the shipping cost, but are willing to negotiate on that. Good.

Confirmed News That Samsung IS NOT shipping Keyloggers

Confirmed: Samsung is Not Shipping Keyloggers - F-Secure Weblog : News from the Lab

F-Secure now has confirmation for what they wrote in our previous blog post: Samsung is not shipping keyloggers on their laptops.

The whole saga was caused by a false alarm of the VIPRE Antivirus product. Apparently VIPRE detects the StarLogger keylogger by searching for the existence of a directory called "SL" in the root of the Windows directory. This is a bad idea.

As an example, here's a screenshot showing VIPRE alerting on a completely clean Windows computer after an empty "SL" folder was created:


As some Samsung laptops do indeed have a folder called "C:\WINDOWS\SL" on them by default, VIPRE would alert on them with a similar warning.

Unfortunately Mohamed Hassan (CISSP) who did the original analysis did not double-check his findings and blamed Samsung instead. Apparently he did not look at the contents of the "SL" folder at all.

Samsung is innocent.

Comodo Says Two more CAs Compromised

Officials at Comodo have acknowledged that an additional two registration authorities affiliated with the company have been compromised in the wake of the high-profile attack on the company that was disclosed last week. However, no forged certificates were issued as a result of the new attacks.

In a message on a discussion thread set up after the original attack on a Comodo registration authority, Robin Alden, CTO of Comodo, said that the company has discovered two fresh compromises of its affiliated RAs during the investigation into the first attack. Alden did not furnish any other details about the new compromises.

"Two further RA accounts have since been compromised and had RA privileges withdrawn. No further mis-issued certificates have resulted from those compromises," Alden said in the message about the new RA compromises.Addressing a list of concerns about Comodo's practices raised by customers and browser vendors in the wake of the attack, Alden said that the company is now in the process of rolling out a new two-factor authentication system for its RAs. Comodo also is installing other security measures as a result of the attack.

"We are rolling out improved authentication for all RA accounts. We are implementing both IP address restriction and hardware based two-factor authentication. The rollout of two-factor tokens is in progress but will take another couple of weeks to complete. Until that process is complete Comodo will review 100% of all RA validation work before issuing any certificate," Alden wrote. The technical details of the attack on an RA affiliated with Comodo earlier this month are still unclear, although officials have said that the attacker went in through the account of one of its RAs and then was able to use the account to issue himself fraudulent certificates for a number of sites belonging to Google, Mozilla, Skype and Yahoo.

Someone claiming to be the attacker responsible for the Comodo compromise has posted several messages to Pastebin with the purported details of the attack. And on Monday the same person also posted the forged certificate for Mozilla that he issued himself, as well as the private key for the certificate. Alden said in the message on the Mozilla discussion thread that Comodo has determined that neither the company's hardware security module (HSM) nor its private key material were compromised in the original or subsequent attacks.

After the initial attack on Comodo became public, Mozilla officials called on Comodo to stop issuing certificates to RAs directly from the root that the company maintains. Alden said that the company is in the process of moving to that model. "We understand Mozilla's request that we move to having a separate sub_CA certificate per RA.Currently many of our end entity certificates are issued from RA-specific sub-CAs but some (like this incident) are not. As a short-term measure we will move towards issuing all certificates from sub-CAs. Initially some of these will be Comodo-branded and there will not be a 1:1 match between RAs and sub-CAs, but we think this will give Mozilla the flexibility they seek in this regard. In the slightly longer term we will move to a sub-CA per RA," Alden said. 

Direct link to the news can be found here.

Test Post from ScribeFire.

This is a test post from ScribeFire.

/run in FC15

For quite a while programs involved with early boot used to place
runtime data in /dev under numerous hidden dot directories. /dev/.udev
was the first one, but over time this grew to at least /dev/.mdadm,
/dev/.systemd, /dev/.mount, dracut, initscripts and more tools. (Other
distros have even more) The reason they used directories there is that
/dev was known to be a tmpfs and available from the first instant the
machine was booted. /var/run otoh is only available very late at
boot, since /var might reside on a separate file system.

However, /dev always has been an inappropriate and ugly place for
runtime data: runtime data is not a device node, and thus simply does
not belong there. Also, hiding the existance of directories from the
administator is a bad idea. Then, the fact that some runtime data was
placed in /var/run/xxx, and other in /dev/.yyy is often not
understandable to ther user, and especially when tools originally
intended to be used only after boot are needed during early boot a
complicated move between these directories needed to take place.

Over time different distributions experimented with different broken
solutions for the early-runtime-dir problem: on Debian /lib/init/rw was
introduced, a tmpfs fs mounted during early boot. On Ubuntu /var/run was
mounted as tmpfs even before /var itself was mounted, with some really
ugly bind mount magic. Most software however just sidestepped the issue
and used /dev/.xxx. 

In the past weeks key people from the Debian, Suse, Ubuntu and Fedora
camps (and others, too) discussed the whole issue forth and back, to
find a solution to stop the misuse of /dev before it becomes even more
widespread. Various solutions have been suggested, but in the end it all
boiled down to the fact that /var/run does not belong beneath /var and
what we really want is a top-level directory /run, and that that is the
only really clean solution. The only reason why nobody dared to actually
implement such a directory was unwillingness to deal with the political
backlash, especially messy discussions on mailing lists like this one.

Understanding this, we came to the conclusion that we should rather
implement what everybody thinks is the right technical solution, instead
of evading the political backlash for it. And so we implemented this.

With this upload Fedora and Suse have already adopted /run now. Debian
folks will suggest this for their coming release. Ubuntu has agreed with
introducing /run as well.

Dracut, udev and systemd have already been updated upstream to make use
of /run. We expect mdadm and mount to follow suit quickly.

A few years back Debian folks already suggested introduction of /run,
and even pinged LSB folks about this, and back then there even was a vaguely
positive response from them.

So, what is implemented in F15 precisely?

/run is now a tmpfs, and /var/run is bind mounted to it. /var/lock is
bind mounted to /run/lock. Applications can use /run the same way as
/var/run. Since the latter is FHS/LSB most apps should just use the
latter, only early boot stuff should use /run, for now. The folks who
have packages where this applies already have been informed. If you
haven't heard from any of us, then this doesn't apply to you.

So, what's the benefit of this again?

- There's only one tmpfs used, backing /run, /var/lock and /var/run,
  reducing a bit the ever increasing amount of tmpfs' used on a default
  system.

- All runtime data at the same place. systemd's, udev's, dracut's data
  are all beneath /run and /var/run now. Easily discoverable to the
  admin. For the first time you can see the data all these important
  tools used on your system store just like any other by doing "ls
  /var/run".

- Nothing is hidden anymore. The admin can see everything beneath
  /var/run and /run, no hidden dot-files anymore.

- We have standardized the early-runtime-dir solution across all major
  distributions

- The people involved feel much better since they don't have to misuse
  /dev anymore

- The lifecycle properties of directories are clear from the top-level
  directory name. Lifecycle properties do no longer change the further
  you go down your tree. i.e. /var is "persistant runtime data" and /run
  is "volatile runtime data", and /etc is "persistant system config
  data", and so on. The ugliness that /var/run abd /var/lock had
  completely different liftime guarantees than /var where they both
  reside in is gone.

So, this is what is implemented for F15 now. For F16 we will make a
minor change on top of this: /var/run and /var/lock will become symlinks
to /run (resp /run/lock), so that we don't have to use bind mounts
anymore which are not the most beautiful thing to use by default, and
confusing to the admin. Due to the implications of symlinks and RPM we
didn't want to make that change in F15.

Metasploit Unleashed at Reverse Space Week 5 with Nicholas B. and Mubix | GRM n00bs

One of the Metasploit Unleashed students, Nicholas B. volunteered to teach the client sides lecture this past week. I’ll be back in the spotlight this Thursday and Saturday with Metasploit post exploitation.

The guest speaker this week was Rob Fuller (mubix). He presented Metasploit Magic and even showed us a little something new.

Slides

Metasploit Unleashed Week 5 part 1 from Georgia Weidman on Vimeo.

Metasploit Unleashed Week 5 part 2 from Georgia Weidman on Vimeo.

Metasploit Unleashed Week 5 from Georgia Weidman on Vimeo.

Rob Fuller (mubix) Metasploit at Reverse Space from Georgia Weidman on Vimeo.