pull down to refresh

100 sats \ 4 replies \ @mega_dreamer OP 6 Jan \ parent \ on: 🚨 Important Announcement from Predyx 🚨 oracle
Thanks for the kind words, yes for sure we will provide the details. We've figured out the attack mechanism. Its a parallel/concurrent API attack on the sell orders api.
We do have a rate-limit user-id/IP on nginx for that sell api. But some how this attacker is able to bypass that rate-limit.
When we try perform the same attack, nginx protects it seq 1 10 | xargs -n1 -P10 curl --output - 'https://beta.predyx.com/api..., but some how this attacker is able to bypass that rate-limit.
So far for the mitigation. today we switched to Cloudflare WAF. Most probably tomorrow we will be bring up the Broadcom Layer7 API Gateway.
write
preview
100 sats \ 3 replies \ @ek 6 Jan
We do have a rate-limit user-id/IP on nginx for that sell api. But some how this attacker is able to bypass that rate-limit.
Maybe they use multiple IPs?
But why do you need a rate limit in the first place? Are they able to sell the same shares multiple times?
reply
0 sats \ 2 replies \ @mega_dreamer OP 6 Jan
Possibly multiple IPs. But we also have rate-limit per user-id to mitigate the multiple IPs.
Yes they are able to sell same shares multiple times. We use mongodb with transaction locking. Maybe we need to switch to a transactional db like MySQL or Postgres.
reply
100 sats \ 1 reply \ @ek 6 Jan
But we also have rate-limit per user-id to mitigate the multiple IPs.
Ah, sounded like you rate-limit the combination
Maybe we need to switch to a transactional db like MySQL or Postgres.
Sounds like the right move
reply
0 sats \ 0 replies \ @mega_dreamer OP 7 Jan
Yes, we're working on moving to Postgres.
We fixed the issue by queuing the request via RabbitMQ.
The hacker tried to perform the same attack within minute of us coming back online but failed, gave us a real-time feedback that our fix worked.
We're back online! Thanks for your support and advice.
reply