Showing posts with label Trojans. Show all posts
Showing posts with label Trojans. Show all posts

Thursday, 23 June 2011

WordPress Compromised – Time To Verify Things

With the number of folks using WordPress as their blogging platform, the news that the WordPress site has been compromised will be of great concern.

The date of the above post is June 21, 2011. What was not mentioned in the above post is a timeline for the compromise.

Hopefully the WordPress folks make that information available to help users figure out if they downloaded any content with malicious code in it.

Affected content:

Hat Tip: Derek Knight

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*Our original iMac was stolen (previous blog post). We now have a new MacBook Pro courtesy of Vlad Mazek, owner of OWN.

Windows Live Writer

Thursday, 11 March 2010

Yet Another Attack Vector? LCD TVs As Zombies

Have a moment for some good reading?

While the reading may not be “good” in the sense of reading a good Star Trek novel (yes I read them ;) ), the implications of the TV OS hack methodologies explained in the above links gives one cause for pause.

The PC industry, especially on the Microsoft side with Apple recently taking up their security slack with key personnel hiring, has the infrastructure in place to address vulnerabilities. But, it looks as though vendors/manufacturers of products that drop some sort of OSS distro on their boxes will need to learn the same _hard_ lessons.

Currently, it looks to be quite simple to get into the LCD TVs with full shell access. No security, no authentication, nothing. Depending on the horsepower driving everything underneath it all, there are lots of ways to work this situation.

With many of these new devices needing an Internet connection for whatever new features they are implementing, there will be a need for us to be aware of whether they are properly secured or not.

If not secured, then a serious decision needs to be made about whether that device should be purchased or if purchased then if it should be plugged in to an Internet connection.

The thought of a worldwide BotNet of LCD TVs is hopefully a fiction . . . at least today.

Links and thoughts courtesy of ObiWan a fellow MVP. Thanks for that and the insights Andrea!

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*Our original iMac was stolen (previous blog post). We now have a new MacBook Pro courtesy of Vlad Mazek, owner of OWN.

Windows Live Writer

Tuesday, 9 March 2010

It Seems That Even USB Battery Chargers Are Vulnerability Deliverers?

The wonders of the human mind. :|

Ingenuity comes in many forms, with the old cliché being Necessity is the mother of all invention. The necessity for the bad folks is grabbing our banking information, identity, or anything else of value from our computer.

While Energizer has no idea as of yet as to how the Trojan software was planted in their device’s monitoring software package, it is now pretty much out in the open that their product did indeed deliver a Trojan to folk’s computers if they installed it.

image

A while back, USB based electronic picture frames were delivering some malicious software to folk’s systems too.

It is getting to the point where we need two systems, whether one physical and one virtual, or otherwise so that we can split off the extremely important things such as online banking to a Vista/Win 7 box with UAC enabled, Standard User permissions, and _NO_ e-mail or other browsing allowed.

Obviously, the VM OS would be used to run the daily tasks with the host being the exclusive banking and sensitive transaction machine.

We flatten. We format and reset that drive to “0” leaving no sector unturned.

If the system’s owner refuses to allow for that and requires us to “clean” a Trojan or Rootkit infected machine we get them to sign a liability waiver that exonerates us before they walk out the door.

There are absolutely _NO_ guarantees when it comes to “cleaning” a system that had a backdoor in it. None. Nada. Zippo. Zilch.

The same goes for a compromised DC by the way.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*Our original iMac was stolen (previous blog post). We now have a new MacBook Pro courtesy of Vlad Mazek, owner of OWN.

Windows Live Writer

Friday, 10 July 2009

Rogue Infection: WARNING! YOUR’RE IN DANGER!

One of our clients received a link via an e-mail from a friend saying that they needed to purchase, download, and install a product to help keep their system running great!

Now, the machine is virtually unusable due to constant battering by pop ups from a product called System Security 2009 (also a Rogue AntiSpyware blog link). The rogue also prevents any .EXE from running on the system except an IE window that takes us to the “online activation system”.

We are going to flatten this system, extract their data from an earlier ShadowProtect image, and start fresh.

Since much of the infections legitimately found on the system are Trojan related, there can be no guarantees that removing them does not leave a backdoor of some sort into the system.

The desktop as it is now:

Security-Warning

And:

Security-Warning-2

Our client new something was well out of sorts due to the misspelling of “YOUR’RE” when the background started showing up.

Note the constant fight between the malware and AVG Free.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*All Mac on SBS posts will not be written on a Mac until we replace our now missing iMac! (previous blog post)

Windows Live Writer

Thursday, 11 October 2007

SBS Premium - Rootkit, Backdoor, Trojan ... Panic...

Ever had one of these?

Too many long nights and early mornings were partially to blame for the precipitation of a sense of panic that ensued when the following was seen in ISA's live query:


ISA: Unidentified IP Protocol: Source Port 1175, Destination Port 5571

So, a quick search for the destination port of 5571 turns up: Trojan "Lamer Variant".

The next step was to figure out what the program/service was and where it was.

The inital PortQry using the GUI version turned up (unknown service) for the sending port of 1175. That was not too encouraging.

SysInternals' Process Explorer was also turning up nothing out of the ordinary.

The next step was to run the SysInternals Rootkit Revealer. After 45 minutes of scanning - this particular server has huge arrays - nothing out of the ordinary seemed to be there. The scan kept on going with nothing to show for it.

The Symantec A/V on the server was up to date and running with no indications of any interference.

By now, the panic has set in, and the thoughts swirling around were along the lines of, "Mr. Client, we need to perform a Swing Migration in the next 5 minutes." Not really a bad thing given they have a secondary AD server that also has the arrays mirrored. Or is it? With the possibility of rootkit infection, we may be pulling just the data from backups.

Mr. Client's reaction would probably not be too happy. :(

So, as a final effort before having to consider the above meeting, a full port analysis was needed - just in case.

In the command line PortQryV2 directory the following was done:
  • portqry -local -l serverlog.txt [Enter]
This command runs a full query of absolutely everything on the local machine that is related to ports and services on those ports.

After the serverlog.txt file was created, we opened it in NotePad, and did a find for 1175 to see if anything came up and low and behold:

Process ID: 2476 (javaw.exe) on UDP Port 1175

Bingo. Open the Task Manager and shutdown the javaw.exe service, and the UDP errors in ISA disappeared.

Java is required for the Intel Management software that runs on the server. We had updated it during the last update run last week on that particular SBS box. So, something has changed in the program.

The DNSStuff.com report for the IP:
Reverse DNS for 229.111.112.12
Details:
strul.stupi.se. (an authoritative nameserver for 229.in-addr.arpa., which is in charge of the reverse DNS for 229.111.112.12)
says that there are no PTR records for 229.111.112.12.

A Whois for the mentioned .se server turned up Switzerland with no details. Not sure what Java is up to there.

For now, we will leave Java running, but not allow the UDP communication to pass through ISA to that 229 IP. We may even place a full ISA application restriction against it just in case.

After all of that, a huge sigh of relief and a little Irish kick! We got to smile and say, "Good day" to Mr. Client on our way out. ;)

UPDATE 2007-10-12: One thing that wasn't considered was searching for the actual IP listed. It seems that the IP is drawing people to the blog via search.

A question on Experts Exchange: Possible Hacker 229.111.112.12 mentions that the IP address may be an internal "Multicast" IP for the 229/8 range.

It would possibly explain why the Destination Network in ISA was Internal and the Source was the Local Host. It would also explain why there were no rDNS PTR records for the IP.

From the Internet Assigned Numbers Authority we have the following document: Internet Protocol V4 Address Space that indicates:

229/8 Sep 81 IANA - Multicast
Personally, this is not one of my strong points. So, please feel free to comment on whether this is the right direction or are we barking up the wrong tree?

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.