Voyz
Urgent Security Concern: Unauthorized Withdrawal Attempt
At approximately 3:00 AM today, there was an unauthorized attempt to withdraw funds from my Interactive Brokers account while using iBeam as an API interface.
Details
- Date and Time: 2024.10.08 03:45:04 -0400
- Nature of the Incident: Attempted unauthorized withdrawal
- Account Affected: Personal Interactive Brokers account
Questions and Concerns
- Is there any known security vulnerability in iBeam that could have led to this incident?
- Are there any recommended security measures or best practices when using iBeam with Interactive Brokers?
- Has anyone else reported similar issues?
Request
- I kindly request the maintainers to investigate this issue and provide any insights or recommendations to prevent such incidents in the future.
Hi @patrickmuhi, I'm terrified to see that this has happened to you. Thanks for reporting this back here with details.
This is the first time this has happened to an IBeam user as far as I'm aware. Hence, bear with me as I'm not familiar with proper handling of such cases. Contacting people who specialise in dealing with this kind of security breaches may be a wise action here.
I cannot find any endpoint that would allow to withdraw funds using the Client Portal Web API in the docs. This would indicate that the withdrawal was issued in a non-programmatic way, and as such is not related to IBeam and will have to be investigated with the IBKR support team.
Nevertheless, I'd recommend you do the following:
- Access the machine where IBeam is deployed. If remotely, SSH to the deployed instance.
- Access the IBeam container, eg.
docker exec -it -u 0 [CONTAINER_NAME] bash - Navigate to
/srv/clientportal.gw/logs - There you'll find log files which, among other things, should contain any requests that the Gateway has processed, along the lines of
-> GET /v1/portal/sso/validate - I encourage you to look through these and see if you can find the withdrawal request in any form. I'd imagine that looking for the time around the timestamp you posted should be a good starting point, although look thoroughly in case the withdrawal was requested some time before IBKR received it, processed it and sent you this email.
If the withdrawal is present and IBeam is deployed remotely, I'd recommend you start a conversation with the customer support of the cloud provider you're using. You'd want to investigate if there has been an unauthorised access - I'd imagine IP address could indicate that.
Whether it is present or not, I'd suggest contacting IBKR and discussing the problem with them.
I'm terribly sorry this has happened to you, I hope you manage to mitigate the losses. Let us know how it goes.
This might help. I have created a secondary account that I funded from my main one, and on this one I created a user (login/password) that has access only on this secondary account. The user has only limited permissions (i.e. trading, of course, but not withdrawals), and access only to the funds I transferred to this secondary account. Also note that I have only cash accounts, so there's no way to borrow on margin.
I don't know if this is available in any regions, but in EU, with IBKR Pro, I was able to set this up.
It doesn't solve your issue, but it certainly limit the amount of damage an attacker can do if your credentials are stolen.
I was just thinking about iBeam and security when I came across this issue. First of all, I just want to say how impressed I am with iBeam—it’s such a useful tool, and I’m really glad it exists!
That said, I noticed the cloud deployment wiki from iBeam uses the following defaults for IP settings:
ips: allow: - 10.* - 192.* - 131.216.* - 127.0.0.1 - 0.0.0.0 - 172.17.0.* deny: - 212.90.324.10
I’m new to iBeam, but if I understand correctly, once the iBeam login has been successful, everyone in the allowed IP list can access your trading account using the IBKR API, right? Most of the IPs are private, but maybe it would be a good idea to add comments next to the IP addresses to indicate who they belong to. For example, 131.216.* — who owns this range? This entire IP range has access to your API when running in the cloud.
Why deny only 212.90.324.10? Wouldn’t it be safer to deny all IPs by default? Also, why is 0.0.0.0 in the allow list? Doesn’t this essentially open access to all IPs?
@Voyz, as you’ve mentioned, withdrawing funds is not possible using the API. But what about abusing the API through legitimate calls?
Once again, thanks for all the effort that has gone into iBeam. It’s an amazing tool, and I look forward to using it more!
@xantos05 many thanks for the kind words and for sharing your observations 👍 let me address them:
once the iBeam login has been successful, everyone in the allowed IP list can access your trading account using the IBKR API, right?
Yes
Most of the IPs are private, but maybe it would be a good idea to add comments next to the IP addresses to indicate who they belong to.
Good idea 👍
For example, 131.216.* — who owns this range?
No idea, this is already present in the conf.yaml that is shipped with the Gateway
Why deny only 212.90.324.10?
Same story, shipped by IBKR
Wouldn’t it be safer to deny all IPs by default?
Wouldn't take a lot of explaining, telling people to undo this once they deploy?
Also, why is 0.0.0.0 in the allow list? Doesn’t this essentially open access to all IPs?
Yeah, that doesn't sound like a good idea. I think I might have added it a while back when trying to deploy on Docker, but this may not be the wisest thing to do.
as you’ve mentioned, withdrawing funds is not possible using the API. But what about abusing the API through legitimate calls?
Absolutely, someone could abuse it if they have access to your local network in which you're running the Gateway.
As a summary, what steps do you propose to improve the security?
Absolutely, someone could abuse it if they have access to your local network in which you're running the Gateway.
...or access to your cloud server, which is much worse. ;-)
As a summary, what steps do you propose to improve the security?
I would suggest editing this part of the documentation and advising the following configuration:
ips: allow: - 127.0.0.1 #localhost (mandatory) - x.x.x.x # IP address of your machine used to call the API deny: - 0.0.0.0/0 #all other addresses
Configure your firewall to only accept inbound TCP connections from your own IP address on port 5000. I just tested this setup, and it’s all you’ll need.
This mainly applies if your server is connected to the internet.
@patrickmuhi were you able to trace the transaction? From the discussion it doesn't appear to be related to ibeam. Can this be closed?
As a newer trader ramping up on IB and ibeam, this issue title wasn't the best first impression @Voyz :)
@xantos05 sounds like a great PR candidate :D
Thanks @xantos05 I appreciate your contribution here 🙌
I've published voyz/ibeam:0.5.7-rc2 with the proposed conf.yaml changes. Please give it a shot and let me know if it works and if it successfully blocks 0.0.0.0/0 as expected.
I'm going to close this issue due to inactivity. Thanks for your contribution and please feel free to request a reopen if you'd like to continue the discussion 👍