Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I learned about corporate firewalls

valcanbuild.tech

Post reply on HN
Print view View original

191–200 of 204 posts

Re: How I learned about corporate firewalls

#191

Post by xist »

P5fRxh5kUvp2th wrote: post #171
slt2021 wrote: post #170

Earlier quoted context omitted.

Developers dont need local admin rights to develop software, plenty of devs at regulated industries work with user rights. And statistics of developers falling victim of phish attack, credentials stealing that leads to major breach - there are plenty. The most recent Uber hack or Okta hack - were all tied to developer clicking on stupid stuff, opening executables from Internet and getting his a$$ owned. You just gott…

> Developers dont need local admin rights to develop software And now I'm going to quote myself from earlier to make it clear you're displaying exactly the silliness I was speaking to, with added emphasis. "If human beings took the same approach to safety that Security people do to security, they'd insist the wheels on your vehicle should only be able to turn straight and right. That the vehicle should _actively_ pre…

> Put yourselves in the shoes of that developer who can access PHI at will, but cannot update their Visual Studio in the name of security because it requires local admin rights to do so.

One possible thought - they think very highly that you will do the proper thing, but they cannot and do not trust every single vendor out there. Have you heard of SolarWinds?

And honestly updating Visual Studio is something that can be arrange but would take probably 1 hour of IT time to solve and I'm sure they have other things they need to do.

Developers are not special to NEED admin access. they may WANT it because it's more convenient, but convenient is not secure. Maybe you're the most 1337 developer out there, or maybe you're a corporate spy.

Perhaps instead of lashing out and getting angry, approach this like a developer - what are they trying to achieve? Do they have technical debt like you? Is this a good enough solution for most use cases?

Inconveniencing you is not the main goal, so perhaps understand what their main goal is.

Re: How I learned about corporate firewalls

#192

Post by rtev »

xist wrote: post #189
TheRealDunkirk wrote: post #127

Earlier quoted context omitted.

Oh, how I have learned the hard way on this. Our IT now blocks outbound SSH entirely . You know, the secure way to access VM's in, say, our cloud? Sigh. I'm sure there's a "jump" server somewhere that I'd have to log into, `sudo` to another account, THEN SSH to my target box. Whatever. I just avoid the VPN. I used to use `cntlm` to tunnel requests through our firewall for things like Ruby's bundler, as it required NT…

The way you brush it off is insane. Using a jumpbox IS more secure. I understand this may cause problems for your workflow (though there are many ways to work within the confines) it sounds like you're stubbornly insisting your way is the best (and therefore most secure) way. This reeks of entitlement. Work with people and stop being a prima donna, you're not above security concerns.

As a security engineer, most developers I work with are like this.

Re: How I learned about corporate firewalls

#193

Post by rtev »

P5fRxh5kUvp2th wrote: post #177
slt2021 wrote: post #174

Earlier quoted context omitted.

I've been on both sides, was a developer and then security engineer, now back to dev work. I know there are quite a few very well talented engineers, but there are also quite a lot of mediocre developers, including interns, new grads, or startup folks who are used to cowboy style edits directly in production and no tests. You always want to plan your security controls for the weakest link, for the dumbest person, pre…

None of the things you're describing are protected by removing local admin rights. That's the point. First you compare the risk of losing limbs to having admin rights, now it's drifting on public streets is like wanting to install python. You can't find anything reasonable because there isn't any.

I’ve personally abused unauthorized developer python installs for privilege escalation > 3 times while red teaming.

Consider the possibility that you may be wrong.

Re: How I learned about corporate firewalls

#194

Post by rtev »

bheadmaster wrote: post #66
gwillz wrote: post #22

I have a government client that has locked down all outgoing access for a web server except though a socks proxy. It makes simple things really hard - like a links checker, package dependencies, remote servers or integrations with Google. We can't even run test scenarios on the machine because we're also locked _out_ of the server. Instead, we rely on their IT department to run test scripts that we send them via emai…

> I have a government client that has locked down all outgoing access for a web server except though a socks proxy. If you're running Linux, there's a utility called "tsocks" which wraps any other command and redirects all network servers through a SOCKS proxy defined in /etc/tsocks.conf, e.g.: tsocks pip install somepackage One downside is that since it relies on some linker magic, it doesn't work for static binarie…

I believe proxychains also would work

Re: How I learned about corporate firewalls

#195

Post by sillystuff »

slt2021 wrote: post #165
sillystuff wrote: post #126

Earlier quoted context omitted.

Some of these "security" products that MiM TLS traffic allow configurations that objectively reduce your security. You can configure Palo Alto devices to accept a self-signed cert from the Internet, but present your trusted MiM cert to the on-site user. Now the user isn't aware that they are the victim of a second MiM outside the organization. The organization also exposes itself to greater liability. E.g., a rogue e…

I am afraid you are talking about stuff you have absolutely no idea about. Palo Alto appliance should be configured with both Forward Trust and Forward Untrust CA certificates, and the issue you described will not exist. If some people misconfigure - thats their fault for not following instructions. Secondly, rogue employee doesnt have access to CA key that is stored in Palo Alto appliance. Only your firewall admin w…

You seem to acknowledge that you currently can configure the device in the manner described while simultaneously being extremely aggressive. A conversation I had with PA support gives me the impression that PA didn't have 'Forward Untrust' when they first started back-dooring TLS i.e., the PA support person did not counter my point of negative security implications of their MiM back-door for invalid certificates encountered externally. This conversation was something of an on-site debate between PA reps and a few of our tech staff. PA pushing for spying on users and tech staff trying to come up with technical reasons why it was a bad idea (management already loved the idea of spying on the users, so no appeal to decency was going to work. Management arranged the debate without telling staff it would happen until the last minute while it was planned ahead with PA for weeks; IT staff at that college were good people who had a history of advocating for user privacy).

Having PA MiM TLS connections is the organization back-dooring itself as well as the external sites the users connect to. This back-door is available for abuse by IT staff, management and/or an attacker(internal or external).

There is a rule that seems to eventually always be proven-- if you provide infrastructure that can enable abuse, eventually it will be abused. Even if you and everyone else involved in the decision at your organization have good intentions, your future coworkers / management may not. Presumably the FBI and NSA have more thorough back ground checks of their employees than the average employer, and both have had employees abuse their access to surveillance data to e.g., stalk ex-girlfriends. And, even if the employee isn't rogue themselves, when the order comes from above, many will obey immoral/illegal orders-- e.g., Ronald Reagan, as president, had the FBI spy on his daughter's boyfriend. The safest option is to not to install the back-door in the first place.

PA's ability to tie Internet activity to specific users' identities was central to their sales pitch-- our tech staff assumed this was targeted at windows shops, but we used non-MS stuff including our LDAP servers and hoped this could kill the surveillance project-- PA countered that they could, at a last resort, do things like e.g., scrape radius logs to associate identities.

PA appears to be a competently run company that probably knows what messages are most effective at selling their product, and they really pushed user surveillance. Therefore, I suspect that many organizations who purchased PA products based that decision on the user surveillance capabilities (explicitly to enable abuse by management).

PAs main feature seems analogous to an illegal phone wire tap, and IMO should be illegal (especially without notification to the victims-- both on-site and off-site). It is curious how corporate circumvention of encrypted communications without permission of the external site hasn't been seen as a CFAA violation while a simple 'view source' on a browser can result in SWAT pointing a gun at your child.

Re: How I learned about corporate firewalls

#196

Post by pilif »

slt2021 wrote: post #140
pilif wrote: post #47

My favourite issue caused by a corporate firewall was when it altered an AJAX request to replace a specific combination of digits (in a long product ID) by asterisks. Turns out that a substring of that product ID matched the client company's phone number and their security theatre intercepting proxy was replacing all occurrences of "sensitive" strings sent to the internet with asterisks. The irony is, of course, that…

this is because you deployed your somewhere in the public cloud and testing it from your workstation over public Internet? This is policy violation, and you need to learn how to develop and test properly over secure channels. Reach out to your Director of Engineering and request proper instructions how to develop and test software. public Internet facing channel is rightfully scanned and screened for these kind of pa…

I think you misunderstood my tale. I'm running a SaaS business and one of our customers users had this issue when they were interacting with the site because that end user's proxy server was arbitrary altering AJAX requests made by their browsers.

This is a end user making a request to an online shop and the POST request to "add product 123456 to the basket" gets changes to "add the product 12***6 to the basket" by a security* proxy between the end user and the web site.

This isn't specific to the site we run. This would have happened on any site they were posting to.

Re: How I learned about corporate firewalls

#197

Post by alexvoda »

pstuart wrote: post #113
HPsquared wrote: post #75

Earlier quoted context omitted.

Did you let them know? They of course need to patch this vulnerability by blocking anything containing 11 consecutive digits.

That's crazy! The right thing would be to add a lookup function to first verify the phone number is in use and then call the number to ask for permission to use it; followed by a webhook to send a confirmation back to the database to cache that info because this needs to be efficient! /s

How do you propose to tackle the cache invalidation challange?

/s

Re: How I learned about corporate firewalls

#198

Post by alexvoda »

pilif wrote: post #196
slt2021 wrote: post #140

Earlier quoted context omitted.

this is because you deployed your somewhere in the public cloud and testing it from your workstation over public Internet? This is policy violation, and you need to learn how to develop and test properly over secure channels. Reach out to your Director of Engineering and request proper instructions how to develop and test software. public Internet facing channel is rightfully scanned and screened for these kind of pa…

I think you misunderstood my tale. I'm running a SaaS business and one of our customers users had this issue when they were interacting with the site because that end user's proxy server was arbitrary altering AJAX requests made by their browsers. This is a end user making a request to an online shop and the POST request to "add product 123456 to the basket" gets changes to "add the product 12***6 to the basket" by a…

Shouldn't HTTPS prevent this unless the client has the certificate of the MITMer installed?

This being security theatre, it is entirely plausible that the "security" proxy actually decrypted trafic and required the user to have the certificate installed.

Re: How I learned about corporate firewalls

#199

Post by [deleted] »

alexvoda wrote: post #197
pstuart wrote: post #113

Earlier quoted context omitted.

That's crazy! The right thing would be to add a lookup function to first verify the phone number is in use and then call the number to ask for permission to use it; followed by a webhook to send a confirmation back to the database to cache that info because this needs to be efficient! /s

How do you propose to tackle the cache invalidation challange? /s

[deleted]

Re: How I learned about corporate firewalls

#200

Post by alexvoda »

alexvoda wrote: post #198
pilif wrote: post #196

Earlier quoted context omitted.

I think you misunderstood my tale. I'm running a SaaS business and one of our customers users had this issue when they were interacting with the site because that end user's proxy server was arbitrary altering AJAX requests made by their browsers. This is a end user making a request to an online shop and the POST request to "add product 123456 to the basket" gets changes to "add the product 12***6 to the basket" by a…

Shouldn't HTTPS prevent this unless the client has the certificate of the MITMer installed? This being security theatre, it is entirely plausible that the "security" proxy actually decrypted trafic and required the user to have the certificate installed.

As I was saying, (from uncle comment):

https://news.ycombinator.com/item?id=33095888

> I work at a government agency and here are my tales.

> 1) They install a root certificate on all machines and use that to MITM all TLS connections using a firewall appliance. They turn this MITM on one day without notifying any developer. Overnight, all our builds (run on-prem) fail because npm install, pip install etc fail and we spent a long time trying to figure it out. They are still failing to this day and I have to get off the VPN every time I need to run these simple commands. IT absolutely doesn't give a flying * about developers.

Post reply on HN