Lawman Technology and Consulting Group LLC

Ubuntu has released a security advisory and update that fixes PAM. The vulnerable code would allow any user with local login privileges to escalate to root. http://www.ubuntu.com/usn/usn-959-1 It is recommended to upgrade immediately.
-Kyle Haugsness (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Juha-Matti was the first to write in with this article from Brian Krebs. The article explains how the Pirate Bay user database was compromised via SQLinjection. http://krebsonsecurity.com/2010/07/pirate-bay-hack-exposes-user-booty/
Of course, I am sure that none of our readers would have an account at the Pirate Bay except for the rare I'm doing security research purpose only. But you may want to drop a helpful hint to your friends.
-Kyle Haugsness (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

As more people seem to be releasing 0day vulnerabilities against Microsoft products, Iposted a new poll on the Microsoft-Spurned Researcher Collective. Give us your opinions. http://isc.sans.edu/poll.html?pollid=295 (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

If you have kids and you are at all familiar the classic children's board book Brown Bear, Brown Bear, What Do You See? authored by Bill Martin Jr and illustrated by Eric Carle, then you will understand that the subject of this diary is a tribute to that book and read in the same tone.
All good things should be used in moderation. The same goes for the social networking sites Facebook, LinkedIn, Twitter, etc. (There are plenty more...) Those that jump in and friend, connect, post, and share in excess may expose themselves if they are not aware of all of the consequences possible from using these sites.
The information you post and share on these sites are not only controlled by the companies that host it, but may also be available to a countless sized audience. There is an article posted on darkREADING yesterday that highlights some good reasons to show moderation when using social networking sites.



http://www.darkreading.com/insiderthreat/security/privacy/showArticle.jhtml?articleID=225702468
There are many reminders through out the piece that your private information should NOT be shared on these sites.



So go back to each of your social networking sites and ask yourself the question:
What do I see?


--

Kevin Shortt

ISC Handler on Duty

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

Drew, one of our readers, wrote us let us know about a new scam being used to spread malware - - well, ok, not so new, but certainly new to me and becoming more popular, enough that it should be on your radar.



Picture this - you're surfing away, and your phone rings. A person claiming to be from a support company or in some cases a Registered Microsoft Support Partner (note that Microsoft does not use this term, it's a made-up designation) tells you that you have a virus, and that for a few hundred in your favourite currency, they'll clean your computer for you. Of course, if this happened as a pop-up, you'd know it was a scam right? maybe? Your Antivirus might catch it, but if not, you'd probably close the window, or perhaps reboot your computer. But would you fall for the live operator on the phone? Would your parents, grandparents or other relatives? How about your manager? your CEO?
The attackers in these schemes have nothing but time to help you to install malware, remote desktop applications or really anything they feel would make their life easier.


After digging a bit, some of these scams seem to be run from locations in India (but most likely not all of them), but when they call your phone, they'll most likely have an area code in your country. They also take advantage of VOIP services to keep their costs low and profits high.



There is no good protection against things like this except for user education in security awareness. Especially in corporations, this should be an ongoing effort, and things like phishing, vishing, fake antivirus and the like should be presented to your user community for what they are as frequently as possible.



More info here == http://www.pcpro.co.uk/news/security/359233/the-unstoppable-tech-support-scam
and here ==http://www.pcpro.co.uk/news/security/356833/pensioner-targeted-by-fake-virus-phone-scam

=============== Rob VandenBrink, Metafore =============== (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Seems to be ITunes accounts have been hacked to make mass purchases of one developer's app.
As a safety measure, I recommend to change your ITunes password ASAPand, if you feel paranoic like me, delete your credit card info from the account until this issue is clarified.
More information at: http://www.alexbrie.com/archives/205, http://thenextweb.com/apple/2010/07/04/app-store-hacked
-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

XSS vulnerabilities are often underestimated, but they can sometimes be extremely dangerous. It looks as if couple of hours ago attackers started exploiting what looks like a stored XSS vulnerability on YouTube.
I don't want to go into details on how to exploit it until YouTube fixes it, but it indeed looks pretty widespread already. So far, all exploits I've seen just enter some benign HTML and are more of comment spam, but as this appears to be a full-fledged vulnerability things could get out of control easily unless this is fixed.
What could an attacker do? Well, they could steal your YouTube cookies, which probably doesn't mean much to them, but they could also post various JavaScript code that will execute in your browser, in the context of YouTube. I've seen nasty XSS attacks that are used to fake whole login screens and we know how many people use same passwords for multiple accounts.
We'll keep you informed on the development of this.
UPDATE
We received a lot of questions from our readers asking details about the vulnerability. Now that Google patched it, we can explain how it worked.
Stored XSS vulnerabilities allow an attacker to store valid HTML/JavaScript/VBScript code in the system. This is most often done through comment systems, such as was the case with YouTube, but can be in any field that the attacker can edit. For example, if you let a user enter his first and last name, and you don't properly filter/encode this data, once it is displayed back arbitrary script code can be executed. This is, obviously, particularly dangerous if an administrator is viewing attacker's profile as the script code will be executed under privileges of the administrator.
The backend comment application used by YouTube incorrectly encoded output data only the first entered tag was correctly encoded, so by supplying the comment with two scriptscript tags, the browser would get back the following: ltscriptgtscript. We can see here that the first tag is properly encoded and will be displayed by the browser as it is supposed to, but the second tag actually starts script code.
This incident shows how important it is to properly check every single point of your application that receives data from users, or displays it back to them. Besides correctly encoding data that is sent back to the browser, the script could have been fixed by also properly encoding data immediately after receiving it from the user.
Luckily for Google, the vulnerability has only been abused by various users to hide other comments they weren't really hidden, they just weren't displayed because the rendered HTML code was broken due to supplied malicious code.
As I said in the initial diary, vulnerabilities such as this one must not be underestimated. While typical examples of XSS vulnerabilities just show you how to popup an alert window, stealing cookies is just the first step it is actually pretty easy to display fake login forms that will look completely legitimate to users.
Before ending this diary, below you can see a screenshot of one exploit of YouTube that didn't just hide comments but also displayed a popup to the visitor.




--

Bojan

INFIGO IS (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

There is a vulnerability posted in June under CVE-2010-2225regarding a bug in the PHP SplObjectStorage. I found an excellent analysis made for this vulnerability, including a POC. More information at http://nibbles.tuxfamily.org/?p=1837#more-1837.
If you use PHP and a vulnerable version, find the patch at http://svn.php.net/viewvc?view=revisionrevision=300843.
-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

There is an interesting trend of malware: Javascript Malware inside PDFfiles.Many people have not updated their programs to read PDFfiles (I have seen personally people with Adobe Reader 5 on their computers) and so they are exposed to old exploits.
There is an interesting analysis posted by Kimberly (http://stopmalvertising.com/malware-reports/analysis-of-wzzc_pdf-exploitjspdfkacnk) that shows a Obfuscated Javascript inside a PDFfile taking advantage of CVE-2008-2992 and CVE-2009-0927. The Wepawet service (http://wepawet.iseclab.org) shows possible malware inside PDF files.
Please remember: if a new version for a software goes out and it does not affect your operation, please use it. It will help you to prevent future headaches.
-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Winpcap 4.1.2 is out!! Check http://www.winpcap.org/install/default.htm
-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander| http://manuel.santander.name| msantand at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

To all of our US readers Happy Independence Day. I hope that you will have a safe and relaxing holiday.To our none US readers I wish a good day.

May you also have a safe and relaxing weekend.
Deb Hale Long Lines, LLC (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

This morning in my abuse@ inbox I had an email that appeared to come from one of my users. It appeared to be the typical Delivery Status Notification Failure.

As the mail admin and abuse coordinator for a small ISP it is not unusual for the customers to forward these notices to me with a request to determine why

they can't email.
As I have done a few hundred times in the past I right clicked on the failure notice to look at the reason given by the NDR. Imagine my shock when my

computer immediately began running JAVA. I immediately killed the process and booted my computer into safe mode so that I could try to determine the

just exactly what had happened. As soon as the laptop booted up my AV and Windows Defender both reported that I had Trojan.bredo. I ran my cleanup

and researched the characteristics of this Trojan and the files that are altered.About 2 hours later it appears that I was able to recover from this attempt

to infect my computer.



I just wanted to give you a heads up. It looks the scumbags are now using NDR and Failure reports to attempt to further their malicious activity.
Deb Hale Long Lines, LLC (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

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

Earlier this week, Adobe released a patch for PDF Reader and Acrobat, resolving among many vulnerabilities the Launch vulnerability which allowed an attacker to execute arbitrary code [1]. One of the problems was that this vulnerablity existed due to a feature in the PDF specification and Adobe was not willing to alter the specs in order to fix this problem.
As pointed out in a blog post by Le Manh Tung, the vulnerability is still exploitable if the command is included in quotes. However, unlike in earlier versions of the PDF reader, it is no longer possible to modify the warning dialog giving users a fighting chance to not execute the code.
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1240
------
Johannes B. Ullrich, Ph.D.

SANS Technology Institute

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

-- Bojan INFIGO IS (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

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

In this diary I will continue with the analysis of the PHP script that the RogueAV guys use on their frontend web servers. You can read the first diary at http://isc.sans.edu/diary.html?storyid=9085.
Now that we understand how the poisoning of search engines work, we can see some specifics about the PHP script that the attackers use. As I said in the first question, the script was obfuscated but it was still possible to understand what they are doing. The code snippets I will be showing in this and next diaries were actually beautified and made easier to read by me.
Infecting the whole site


Once the site has been compromised, the attackers install their script in any directory, preferably in a directory that is not accessible directly from the web since they will not need to access it directly.

The next step the attackers do is to infect all (and I mean all!) PHP files on the compromised web site. If it's a shared web site, and the permissions are not setup correctly, they will actually infect absolutely every web site hosted on that machine.
The infection consists of insertion of one line at the beginning of every PHP file, as seen below:

This line (which I deliberately shortened) contains a small PHP script that is just Base64 encoded. So, when any web page on the compromised web site is accessed, the attackers PHP script gets executed first! Below is the decoded script:

The decoded part shows what the attackers do:

If the global msfn variable is not set and the ob_start function exists (it's a standard PHP function) the following code gets executed.
The global variable is set to point to the master PHP script (the one we're talking about called style.css.php in this example). Notice that it can be anywhere on the disk as long as the Apache process has access to it.
If the file exists, it is included. This causes the master PHP script to execute and do main processing. I'll cover this execution process in subsequent diaries.
If the master PHP script ran correctly, it will define functions gml and dgobh so the last line can execute. This is the part that actually displays the original web sites and, if needed, appends the links to search engines I covered this in the previous diary.

This way the attackers made sure that their script will execute whenever another PHP script on the compromised web site is accessed. This allows them unlimited freedom in using different URLs for poisoning search engines but for redirecting users to the sites serving RogueAV (or any other malware). Cleaning a web site after such infection is not too difficult all you have to do is remove the first line, but as with any infection or compromise I would recommend that you restore files off backups (you do make them, right?).
If you wonder how the attackers insert this line into every single PHP file, the answer is simple a special function in the master PHP script takes care of this. It recursively traverses all directories, finds any PHP files and if it can modify them inserts the line at the beginning. Once the attackers installs the master PHP script (style.css.php), all he has to do is call the script with a proper parameter, as you can see in the screenshot below:

This interface is password protected, so you can't access it directly without authenticating first. For those curious, there is also a function that clears the whole site (parameter dgr=1, probably for remove) but access to it is, as well, password protected.
Scared of other attackers?


The master PHP script consists of dozens of functions that take care of various tasks. Today I will cover the first couple of lines that get executed as they are relatively interesting. You can see the PHP code below:

This code does something interesting. It takes the contents of $_GET, $_POST and $_COOKIE superglobals which contain request parameters and (of course) contents of the cookie. Then the code does a bit of shuffling with the content, converts it to all lower case and performs urldecode on it. This will normalize any content (for example, %61 will be converted to lower case a).
Finally, the code compares this content with any of the strings in line 12: 'base64','user_pass','substring(','or id=','eval(','nutch','_users','union all','mid('. If any of these matched, the script exits immediately!
This is interesting as it appears that the author of the script tried to implement a very simple intrusion detection system notice how it contains SQL injection strings or parts of PHP code. This does not make a lot of sense (especially matching of SQL injection) since the master PHP script, for example, does not use a database at all so I wonder if this was part of another program that the author just reused.
And with this we come to the end of the second diary. In next diary I'll go through some advanced functions of the PHP script such as auto-update as well as the administrators interface. Of course, you are always welcome to contact us if you have any questions.


--

Bojan

INFIGO IS

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

With the way the RogueAv teams are using SEO to poison search results one of the isc.sans.org readers Andy submitted this idea in response to this article by Bojan.

http://isc.sans.edu/diary.html?storyid=9085



If search engines were to ignore everything that is not Visible on a page they crawl, then a lot of this malware

would lose their stealth.

Drop all hidden, non formatted, and even white text on a white background.

It would improve search results.



Google may already be doing something like this as they are not getting hit as hard as some other search engines in the fakeav SEO poisoning attacks.

Thanks Andy. (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Adobe has released the update they promised earlier this month for Reader and Acrobat (flash player 10.0.45.2 code execution).

It addresses the following vulnerabilities including the recently announced CVE-2010-1297 :

CVE-2010-1240, CVE-2010-1285, CVE-2010-1295, CVE-2010-1297, CVE-2010-2168, CVE-2010-2201, CVE-2010-2202,

CVE-2010-2203, CVE-2010-2204, CVE-2010-2205, CVE-2010-2206, CVE-2010-2207, CVE-2010-2208, CVE-2010-2209,

CVE-2010-2210, CVE-2010-2211, CVE-2010-2212



The new version is 9.3.3 and the Security Bulletin is here:

http://www.adobe.com/support/security/bulletins/apsb10-15.html
More details can be found at:

http://blogs.adobe.com/adobereader/2010/06/adobe_reader_and_acrobat_933_a.html
don smith (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

On Monday, a number of Russian nationals got arrested for espionage against the US [1]. With all the talk and attention paid to cyber spies, spear phishing, APT and new high tech satellites and drones, it is almost refreshing to see that good old fashioned human spies are still used and apparently found valuable. Skynet hasn't taken over quite yet. However, the story has a few neat cyber security lessons.
Lesson 1: Encrypt your Wifi
The spies evidently used WiFi networks to communicate. However, instead of all of them to connect to a particular access point, they established Ad-Hoc networks. This idea is interesting in so far as it does make remote surveillance of the connection a bit harder. The FBI had to have a listening post close by in order to intercept the connection. It appears the FBI used to be parked close to coffee shops and such frequented by the spies in order to observe them meeting with their embassy contacts. The FBI was able to intercept the communication, and apparently used MAC addresses to track the participant. It is not clear if any kind of encryption was used for the WiFi connection. But Ad-Hoc networking would only allow for WEP unless encrypted chat software is used.
As a sub lesson one may take away that you should change your MAC address as a spy to avoid tracking. But it is not clear if this would have made a difference.
One neat side effect of this meeting method: The participants of the meeting never had to acknowledge each other visibly.
Lesson 2:Keep your password secure
The FBI followed these spies for a while already. A few years back, the FBI secretly searched the homes of some of the spies, copying various hard disks in the process. Small problem: The hard disk was encrypted. Luckily, an observant FBI agent noted a piece of paper during the search with a long number / letter combination. Turned out it was the password. This turned out to be critical as it allowed the agents to not only decrypt the hard disk, but after decrypting the hard disk the agents found steganography software and other encryption tools, as well as lists of web sites used to exchange steganographic messages.
Lesson 3:Obscurity != Security
The spies to some extend used steganography to exchange messages. These messages where encoded into an image, and then uploaded to various web sites. As explained above, the FBIwas able to obtain a list of these sites and the software used to encode them. However, at least according to some reports, the messages were not encrypted. Typically, if you want to do steganography right, first encrypt the message, then encode it in an image. In particular if you use standard software to perform your steganography. (Update:Some reports mention that the messages had been encrypted before encoding them into the images)
Lesson 4: Perfect forward security
Perfect forward security is an important cryptographic concept. You never want to use an old password to encrypt the new password. If you do, once an attacker figured out one password, they will be able to decrypt all future passwords. It appears that the spies frequently made arrangements about future meetings and communication protocols over insecure channels (like the ad-hoc wifi). In some ways this may also be considered as relying on obscurity again.
[1] http://newyork.fbi.gov/dojpressrel/pressrel10/nyfo062810a.htm

various other news reports like:
http://www.cnn.com/2010/POLITICS/06/28/russian.spying.arrests/index.html?hpt=T1

http://www.guardian.co.uk/world/2010/jun/29/russian-spies-uk-irish-passports

http://www.dailymail.co.uk/news/worldnews/article-1290475/U-S-charges-Russian-spies-FBI-swoop-Cold-War-style-espionage-plot.html

http://www.nytimes.com/2010/06/30/world/europe/30spy.html?hp

http://www.theregister.co.uk/2010/06/29/spy_ring_tech/

------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

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