News for hackers. Stuff that matters.

mh0pe

Re:Deprecate 0.0.0.0 for Private Network Access on Friday August 09, 2024 @12:56AM (#41198884)
Fun fact, ping 0 works because 0 is the IP decimal notation of 0.0.0.0. One of my favorite age-old WAF bypass since it doesn't match octet notation regexes that are often in place.
Re:The UX of UUIDs on Thursday April 11, 2024 @11:12PM (#40009059)
Screenreaders pronounce it "line".
Re:SMS Pumping Attack on Thursday August 03, 2023 @11:10PM (#36995063)
It looks like you still have this kind of capability. You might need to adjust settings and supply KYC info as requirements change. From the Fraud Guard docs, "You can mark known phone numbers using the Safe List feature so they are never blocked."
Moving from hot to cold wallets in an environment with redundancy, multiple partial keyholders, and offsite storage could easily take days to weeks and require scheduling access to the physical vault holding the cold storage. You're conflating hot and warm storage - warm can replenish hot but cold requires physical access to somewhere ideally unrelated to where day-to-day operations run.
Re:A fake job offer took down Axie Infinity on Thursday July 07, 2022 @11:23PM (#32022694)
I work in conjunction with this segment of the industry. You can do it, but don't be surprised when you can't recover anything in a termination suit.
I would absolutely use this if it existed.
As a member of the Security community, it's disappointing to hear that this is the perception on the table, because our community can and should do much better than that. In my experience and goals, the best Info/AppSec/SecEng teams put people before processes, build guardrails instead of walls, and demonstrate first hand what they want to see engineering teams doing. If you're open to it, I'd like to offer perspective on why some of the perceptively dumb things that sec teams do, do.

Those automated tools are better than ever. Manual code reviews are very important, but automated tools at this point can stand in for "over the fence" pre-production code reviews, as long as periodic reviews occur. In particularly sensitive contexts, especially finance, code is always signed off on by security before release when it can have impact on anything important. It's all about risk management.

Additionally, the cloud and SaaS is nothing like it was a decade ago. Security is now more focused on compliance due to the nature of building software today. You used to maybe provision a handful of nodes on EC2, use an autoscaling group if you were super fancy, and probably integrate into a handful of third party APIs. Every business is different, but that was the core of running a workload. Now, I can delegate specific responsibilities to third parties and reduce both people and operating costs. But with that comes massive risk since you just transferred an internal business function to a third party you have no control over. The most common approach to that risk is through process: vendor reviews, compliance and cloud posture security management.

And then there's DevOps who ends up being ad-hoc security way too often with no relevant background (or interest).

All that to say, good, compassionate security teams do exist.

Re:No-code startup Integromat becomes Make, snatches huge domain on Wednesday February 23, 2022 @09:30PM (#30449556)
In their defense, they kind of crush the competition. https://www.integromat.com/en/help/integromat-comparison-to-...
Re:No-code startup Integromat becomes Make, snatches huge domain on Wednesday February 23, 2022 @09:28PM (#30449544)
I've been referring to it as "make.com" and it's worked well for me so far.
This looks to be an activist project focused on shutting out Airbnb, check out the about page.
It looks like it dropped a few months after TFC[1] with a bunch of additional features. At least these days, Teams supports Sentinel, and in personal use cases, I've had TFC be backend and threw a git pre-commit hook at it for Sentinel on my machine. My guess is that for some time, they wanted to focus on enterprise sales and Sentinel was an easy way to upsell. SSO still makes Business worth it though.

[1]: https://www.hashicorp.com/blog/announcing-hashicorp-sentinel...

If you really want access to the execution engine, looks like one team found a way. https://orca.security/resources/blog/aws-cloudformation-vuln...
I never understood this sentiment. Hashicorp offers Sentinel for free [1], publicly. The documentation is also open [2]. There's also open rulesets for CIS benchmarks [3] (minimal but demonstrates what Sentinel can do), and a ton of public drop-in rules for several clouds [4]. There's helpers [5,6] for common use cases, supports custom integrations [7] and it can be run in CI [8].

[1]: https://docs.hashicorp.com/sentinel/downloads [2]: https://docs.hashicorp.com/sentinel/intro/getting-started/ru... [3]: https://github.com/hashicorp/terraform-foundational-policies... [4]: https://github.com/hashicorp/terraform-guides/tree/master/go... [5]: https://github.com/hashicorp/terraform-guides/tree/master/go... [6]: https://github.com/hashicorp/terraform-guides/tree/master/go... [7]: https://github.com/hashicorp/sentinel-sdk [8]: https://docs.hashicorp.com/sentinel/commands/apply

I have not, I've been lucky enough to remedy most of those issues but I may give EMDR a crack. Thanks!
Re:YAML and Configuration Files on Saturday August 14, 2021 @11:03PM (#28185941)
My stance is that YAML is a good format for configuration management and generation -- it's wonderful at filling gaps as your deployment model increases in complexity to provide a mechanism to "render" your configuration -- much like Skylark [1] does (derived from Google's internal GCL).

YAML ends up being a powerfully declarative model [2] for the state of a data structure, rather than a straight representation, ironically often enough being used in turn for an imperative model like in Ansible [3]. Definitely friendlier than JSON. But personally, I really like YAML because it lets me compose using a traits/mixins-like model using & and *, which allows for verbose, structured configuration inputs but concise configuration files.

docker-compose YAML files extension fields [4], imo, are a great example of this type of model in action. When you leave this much pre-deserialization flexibility in your configuration representation, it makes building cool stuff like docker-compose ECS support x-aws-* extension keys [5] and other plugin system-type capabilities much more straightforward than, for example, adding a new language feature to HCL.

[1]: https://github.com/google/skylark

[2]: https://en.wikipedia.org/wiki/YAML#Advanced_components

[3]: https://docs.ansible.com/ansible/latest/user_guide/playbooks...

[4]: https://docs.docker.com/compose/compose-file/compose-file-v3...

[5]: https://docs.docker.com/cloud/ecs-integration/#rolling-updat...

I have a near-photographic memory that's been tested as I grew up, and personally, it's a mixed bag.

I have a solid and clear recollection of the good, which is useful from a business management and engineering career perspective. Literature retains on the first pass, which is very useful in operations for manual/business requirements/security framework ingestion, and I don't need to keep a TODO list or agenda (but still do for transparency's sake to my reports and superiors). Having an excess of information readily available gives a lot of opportunity to drive impact, and has allowed me to move vertically in my career very quickly. There's a feedback loop of retaining information, which presents me as more qualified to offer support to my peers, which puts more people in my direction soliciting input and building a positive reputation. With that, I made leadership in my early twenties, and it feels like it took less effort than some others to get here, based on what I've heard from other people.

Unfortunately for me and I'm sure others, I've been through a lot, and all of that retains just as well. It's not an active decision to retain. I'm not going into much detail on those events, but I've encountered about a dozen substantially negative events in my life, and having the information for those who've needed it has been helpful when necessary. It's been empowering to revisit those moments from a different angle as I've worked through those challenges.

All in all, not to be too cliche, but it's both a gift and a curse, but one I'm grateful to have.

Prior eng from Tinder/Match Group here. Opinions are my own, not my previous or current employers'. I haven't worked there for a few years but I can tell you with strong confidence that doing something like this would throw public metrics out of whack, and would cause massive brand damage across the Match Group family. They take security pretty seriously and this kind of initiative is very unlikely.

What's far more likely as a source of random bot traffic is that a click farm is using real devices (it can take a bit to get abuse banhammered), and I'm guessing you're in a major metro area where a few bots are more likely to sneak under the radar. Elo[1] is deprecated these days, but much of ranking leans on 2nd- and 3rd-degree evaluation of both yourself and the other person, implying those users are generally evaluated as real and not reported much. Bouncer[2] helps the engine take this kind of data into account.

All this is to say if someone seems suspicious, leverage that Safety Toolkit. But Tinder seeding in fake users themselves would be quite visible externally after a quarter, cause a big spike in reports over time, damage user retention, daily sessions, and stickiness massively, all of which negatively impact ARPPU and paid conversion rates. Throwing tons of standard KPIs isn't worth a fractional boost in sales with the kind of revenue and growth factors[3] they're driving.

[1] https://www.theverge.com/2019/3/15/18267772/tinder-elo-score...

[2] https://techcrunch.com/2015/02/03/tinder-tests-limited-right...

[3] https://ir.mtch.com/overview/default.aspx