Is Security a Joke Everywhere? Or Only When Peoples' Identities Are At Stake?

[POFP]

My company does Point of Sale Software Development, Consulting, and Managed Services for Retail and Hospitality (Restaurants/Hotels) chains, both large and small-scale, and everything in between. Part of this involves the design and implementation of a slimmed-down Linux or Windows OS Image that has our POS Application and its dependencies baked in so that it can be deployed to hundreds-thousands of Tills easily via PXE Boot, or by some unlucky prick they talked into driving to every store to deploy the image via Flash Drive (We, once, had a customer convince one of their employees to do this to 1.) Retrieve logs and 2.) Deploy patches to our application - Totally ignoring the Central Management Server they paid hundreds of thousands of dollars for that has functions for these tasks built in to allow remote access at the touch of a button.).

I've only been exposed to the OS Creation and implementation aspect recently (Within the last 4 months or so), and have since learned of several fundamental security flaws in both our Application itself, as well as the original design of our POS OS Image.

For example, we cache all Product, Customer, and Transaction data locally on each machine in an Oracle, DB2, or MySQL database (Depending on customer requirements) to allow Lanes to be up even if the Central Server goes down. Once the server's back up, all Tills will send up their transaction data and the Central Server will send down any updates it received once coming back online. The credentials for this database are stored in plaintext properties files, which are readable and accessible by the default user (The one that auto-runs the Desktop on startup.) at any time.

But don't worry, they encrypted the credentials in the properties file with DES (Notice I didn't say Triple), and left the DES Encryption Module Class (Which contains a Main() Method, so it can be run at any time by the default user) in a directory 1 level down from the root directory called "encryption". In 3 commands, you can have the Database's credentials and all customer information, and you wouldn't have had to enter a single password that wasn't provided.

And let's not forget that our application is based on Java Applets, which are deprecated and vulnerable as fuck - And we don't Checksum or otherwise validate ANY Classes before they're loaded at startup, so you can tell the application to load whatever custom-compiled classes you want it to and it will without a single complaint.

But what disgusts me the most is that our customers will run a Pentest AFTER they've taken our systems into Production, AND ALL THEY COMPLAIN ABOUT IS THE GODDAMN SSH CONFIGURATION AND JAVA VERSION BEING 2 UPDATES BEHIND? And our own, internal security specialists have the nerve to complain that the customer "ran a Pentest against our system without my involvement or permission." THEY'RE MAKING OUR SYSTEMS RESPONSIBLE FOR THEIR CUSTOMERS' TRANSACTION DATA - OF COURSE THEY'RE PENTESTING IT YOU FUCKING MORON.

I mean, do they just pick security specialists up off the fucking streets? I don't even have a background in Security, and these issues are glaringly obvious to me.

So anyways, I'll be Black-Boxing the entire goddamn application using some Linux-specific tricks of the sudoers file and some other trickery. If I can remove read and write access to all of our application files by adding a new default Desktop user, and only giving them the ability to start our application indirectly via sudo by using sudoer file modifications and black-boxed deployment scripts, I should be able to prevent a System-wide security breach or unintended analysis of our application (Technical details below). Hopefully, we don't end up on the cover of Wired Magazine for the most severe Retail security breach in history before then.

Problem: You have User A and User B. You want User A to run a script owned by User B, but not be able to read the contents of that script for security reasons. Maybe it contains a hardcoded password, or otherwise confidential information that User A should not have access to.

Solution: Remove non-owning Read/Execute from your confidential script (chmod 700). Create a script in /usr/bin that calls the confidential script that you intended to run. Remove write permissions from this Calling script, and make it owned by Root (chmod 755). You can configure the sudoers file (defines restrictions for the use of sudo command) to allow User A to run the calling script as User B (Or root), which triggers the confidential script.

Solution extra steps: A this point, someone could use a Process Analyzer to view the contents of confidential script as you're running it, since by default, users have access to processes owned by other users. In order to prevent this, you'll need to remount the /proc directory with hidepid level=2.

This solution will be extended for my purposes by having the POS Application user made to be anything but the default Desktop user. A new default user will be created, who will be granted permissions to run a script via sudo that calls the POS Application start script as the POS Application user. And then read access will be removed from virtually everything on the machine for the default user, making them only capable of executing the Graphical Display and the POS Application indirectly.

Cain, or anyone else: Do you have any other recommendations for securing our Image and Application? Or do you think a Black Box designed like above with a LUKS-encrypted harddrive would suffice?

[altered]

I have no recommendations, but it’s worth saying that yes, they actually do just hire anyone who walks in off the street for computer security.

Why?

Because properly secure systems irritate the consumer who wants everything easy and simple, and the most knowledgeable security consultants say things like “you can’t completely secure any system, that’s impossible unless you run a bandsaw through it and then set it on fire,” and the shareholders don’t want to hear that defeatist mumbo-jumbo.

So they pick up anyone who can tell a convincing enough set of lies that make them feel good, and it turns out basic, low level Linux CLI ability is a rare enough skill set that if you can cd to /bin and ls you’ll blind the hiring managers with your unmitigated brilliance. (If you can write a good bash command you can even knock the socks off the ones who are smart enough to tell when you’re bullshitting them with basic user competence.)

So yes. Everyone in your organization’s IT security group is a fucking idiot, I assure you. And in fact, this is the gold standard. Nothing to worry about, this is all etc.

[altered]

I should mention that I know this because in Missouri I almost got a job as a security pentester but I hurt the IT managers feelings by saying “pentesting this system isn’t fair because the only difference between regular usage and penetration is whether you have been hired by the organization”. They hired someone else, and I have it on good authority that the other guy literally just wrote a bash command to pretend they were doing something sneaky rather than just logging in to the unsecured root user.

Edit: this was for a life insurance company, by the way.

[chaotic neutral observer]

I am not a security expert, but I sat in an armchair, once.

Did I read that you are actually running a full desktop?  You shouldn't even need a window manager, just X, and your application.  If the POS application exits (crashes), then you should just be kicked back to the login screen.

The POS app user shouldn't even have a login shell configured.  If they try to log into a CLI (via xterm, ssh, or a virtual terminal), it should immediately kick them out.

Why is access to the database credentials an issue?  Whoever has access to the application, already has some (indirect) capability to read and write the database.  To what extent does having credentials increase the risk exposure?  The database shouldn't be allowing the application any access to data it doesn't already need.  It also shouldn't be relying on the application to sanitize any inputs.  (I'm assuming that your database vendors all support some sort of fine-grained access control.  If they don't...uhh....good luck with that?)

Also, none of the clients should be caching data beyond the bare minimum.  Breaking one client shouldn't compromise the whole system.

The requirement to survive a loss of connection to the central server while remaining secure is interesting.  Sounds like a job for a Professional.

[Cain]

I'm not the best person to ask regarding technical matters. All of my computer related hijinks involved getting credentials via non-technical means.

But yes, security is a joke everywhere. Companies are slowly waking up to the fact that information technology makes them more vulnerable in most cases, and if customers knew what was going on, class-action lawsuits would be coming down the line daily (a relative lack of lawyers trained in this area does not help...but the Magic Circle firms are already looking to change that). So they hope by hiring someone, anyone, they can avoid at least some liability.

[altered]

I am not a security expert, but I sat in an armchair, once.

Snip

The requirement to survive a loss of connection to the central server while remaining secure is interesting.  Sounds like a job for a Professional.

Could just hash and salt the entire database at the key level. Should be perfectly possible to test against records the way you’d test a password attempt against a password hash if you do that. Yeah, it can be attacked at leisure, but since you’re assuming the server owner is hostile you absolutely can’t secure the data anyway. You can only make it progressively more and more annoying to break into. A giant database where every single fucking key-data pair is hashed and salted is really, really fucking annoying to break open. A relatively weak hash algorithm would suffice for security there given how many you’d need to break to get a single useful set of data, so you can check hashes pretty fast to keep DB lookups from getting too slow.

[POFP]

I am not a security expert, but I sat in an armchair, once.

Did I read that you are actually running a full desktop?  You shouldn't even need a window manager, just X, and your application.  If the POS application exits (crashes), then you should just be kicked back to the login screen.

The POS app user shouldn't even have a login shell configured.  If they try to log into a CLI (via xterm, ssh, or a virtual terminal), it should immediately kick them out.

Why is access to the database credentials an issue?  Whoever has access to the application, already has some (indirect) capability to read and write the database.  To what extent does having credentials increase the risk exposure?  The database shouldn't be allowing the application any access to data it doesn't already need.  It also shouldn't be relying on the application to sanitize any inputs.  (I'm assuming that your database vendors all support some sort of fine-grained access control.  If they don't...uhh....good luck with that?)

Also, none of the clients should be caching data beyond the bare minimum.  Breaking one client shouldn't compromise the whole system.

The requirement to survive a loss of connection to the central server while remaining secure is interesting.  Sounds like a job for a Professional.

I misspoke. There is no Desktop, unless you count FVWM2 (Technically, I believe it is a Desktop Manager, but it's intended to be limited for systems like these). I just said "Desktop User" to signify that it's the initial user that initializes FVWM and the X Server.

I also agree that the POS User shouldn't have a shell configured. That's probably going to be implemented once I've completed separation of the Default User and POS User, which seems to be the primary cause of confusion here. I do appreciate that recommendation.

Database access by the POS App User is not a problem. The problem is that the Default User is the POS App User, and therefore has access to the Database. If you do have access to a terminal as the default user, you shouldn't be given access to a supposedly secured application's database that contains confidential information.

The whole point of my changes was that that problem would be fixed by creating a new user and layer of abstraction/encapsulation between the Graphical Interface session that runs by default and the POS Application and its files.

I'm not the Architect - I'm a Consultant. I can't really affect the overall design of the system - Just how we implement it at the OS level, as even that is stretching the Scope of my position. Using a local cache for reliability is part of the system, and so is that cache's Schema. I can't make it cache more or less data, although I agree that we should be mindful of what all we cache. Technically, though, it is a condensed/compressed version of the Central Database. In theory, it shouldn't be more than what's necessary.

As far as I'm concerned, since each Till Image is virtually identical, including all credentials within, a breach on one machine is a breach on all of them. If you can break into one machine and go to another store and break into the other in the exact same way, I'd consider that System-Wide. Being able to alter the communications between the Application and the Server by loading your own code could EASILY breach the Central Server.

The design of the application is fundamentally insecure. I'm trying my best to keep the company from going down in a huge lawsuit before I can move up to the point that I CAN influence design decisions, for which others on my team and I have very stern recommendations for - Many along the lines of what you've brought up here. I can go into more detail about all the other design flaws, but it'd be a long depressing rant and I've already done one of those today.

I have no recommendations, but it’s worth saying that yes, they actually do just hire anyone who walks in off the street for computer security.

Why?

Because properly secure systems irritate the consumer who wants everything easy and simple, and the most knowledgeable security consultants say things like “you can’t completely secure any system, that’s impossible unless you run a bandsaw through it and then set it on fire,” and the shareholders don’t want to hear that defeatist mumbo-jumbo.

So they pick up anyone who can tell a convincing enough set of lies that make them feel good, and it turns out basic, low level Linux CLI ability is a rare enough skill set that if you can cd to /bin and ls you’ll blind the hiring managers with your unmitigated brilliance. (If you can write a good bash command you can even knock the socks off the ones who are smart enough to tell when you’re bullshitting them with basic user competence.)

So yes. Everyone in your organization’s IT security group is a fucking idiot, I assure you. And in fact, this is the gold standard. Nothing to worry about, this is all etc.

That actually makes a lot of sense. It's too bad I didn't jump into security early on, as I always had an interest but figured it was gonna require too much official experience and education. I can definitely find a middle-ground between defeatism and blind optimism.

I should mention that I know this because in Missouri I almost got a job as a security pentester but I hurt the IT managers feelings by saying “pentesting this system isn’t fair because the only difference between regular usage and penetration is whether you have been hired by the organization”. They hired someone else, and I have it on good authority that the other guy literally just wrote a bash command to pretend they were doing something sneaky rather than just logging in to the unsecured root user.

Edit: this was for a life insurance company, by the way.

  I wondered if shit like that happened - I know that plenty of people who do the hiring don't have the technical experience to accurately judge the technical ability of candidates. If the person doing the hiring can't confirm real results by reading a candidate's script - Which, by definition is uncompiled and nearly impossible to be made cryptic, especially in the case of Bash - Then they shouldn't be doing the hiring, or they should have more people involved. That's why I play the bad guy in Interviews - Drilling candidates with technical questions regardless of their Background or resume. I've had people with huge resumes come in and not know hardly anything they claimed to know, and that fact completely escaped the other Interviewers, including my boss. It was obvious that they were bullshitters and that they would just be taking advantage of the company, and they'd probably end up getting us into a Lawsuit.

I'm not the best person to ask regarding technical matters. All of my computer related hijinks involved getting credentials via non-technical means.

  The $5 Wrench approach will always be my favorite.

But yes, security is a joke everywhere. Companies are slowly waking up to the fact that information technology makes them more vulnerable in most cases, and if customers knew what was going on, class-action lawsuits would be coming down the line daily (a relative lack of lawyers trained in this area does not help...but the Magic Circle firms are already looking to change that). So they hope by hiring someone, anyone, they can avoid at least some liability.

That makes sense. I know the demand for increased security would essentially have to come from the legal sector, but I've never been exposed to legal discussions on the subject. I didn't know if it was something that the general higher-ups in the legal sector were privy to, or if it was only a problem known by the few in that area of Law.

In-fact, I always wondered about how technology complicates legal disputes these days, in general. I wondered if screenshots or pictures of Webpages, for example, were acceptable forms of evidence in any cases, even though anyone with any browser can modify a local copy of a webpage to show whatever they want, live.

There are so many things that can be spoofed - Unless you have Computer Scientists consulting for cases like these (And in some cases, only technical people may really know whether or not a Consultant is really required, defeating the whole purpose if one wasn't involved in the first place.), there's virtually no way of knowing sometimes whether people have been wrongfully accused, or if some shit was just horribly misunderstood.

[Cain]

Well, the barriers in the legal area are mostly how to apply the already existing law and understanding the technical details, especially for the higher end clients. There are a ton of IP law, corporate/M&A and telecomms lawyers whose work touches upon internet law, and there's a fairly steady revolving door between lawyers in that sector of the market and the in-house teams at Google and Facebook, for example. But specifically for computer security and liability, the expertise takes a while to grow, and while that is being done it is difficult to cultivate top-level talent in a fairly new field. Not to mention combining that with, say, litigation talent too...

For now, I believe the most prominent firms are content to work hand-in-hand with the larger cybersecurity firms. For example,  I believe Crowdstrike worked closely with the lawyers hired by the DNC to handle the matter, coincidentally (or not) the same lawyers who handled the "Trump dossier" contract with Orbis Intelligence. But the lawyers know what most other people are starting to suspect - namely that everything's unsecure as hell - and they want to be in there at the ground level for when the money starts flying around.

[altered]

It’s worth it to be aware that anything short of complete defeatism is blind optimism, under some circumstances.

Unrestricted physical access to a machine? The machine is compromised.

Remote sign-on as a regular user? The machine is compromised.

Exposes enough tools for a power user to your jailed remote users? The machine is compromised.

Restricted physical access to a machine but you let them plug in something to a USB port? The machine is compromised.

Free internet connection and the user can fuck off on the internet without an ad blocker if they so desire? The machine is compromised.

The machine is ever, ever connected to a machine that is or could be compromised at some point? The machine is compromised.

I’m sure there’s more, but this is the list that any knucklehead with five minutes on Google and a single working hand can take advantage of.

So if anyone ever asks you to completely secure a system so no one can ever break in, the answer is “impossible”. You can make it really, really, really fucking annoying but you can never lock it down entirely.

[Fujikoma]

I think I'm in love.

[POFP]

Well, the barriers in the legal area are mostly how to apply the already existing law and understanding the technical details, especially for the higher end clients. There are a ton of IP law, corporate/M&A and telecomms lawyers whose work touches upon internet law, and there's a fairly steady revolving door between lawyers in that sector of the market and the in-house teams at Google and Facebook, for example. But specifically for computer security and liability, the expertise takes a while to grow, and while that is being done it is difficult to cultivate top-level talent in a fairly new field. Not to mention combining that with, say, litigation talent too...

For now, I believe the most prominent firms are content to work hand-in-hand with the larger cybersecurity firms. For example,  I believe Crowdstrike worked closely with the lawyers hired by the DNC to handle the matter, coincidentally (or not) the same lawyers who handled the "Trump dossier" contract with Orbis Intelligence. But the lawyers know what most other people are starting to suspect - namely that everything's unsecure as hell - and they want to be in there at the ground level for when the money starts flying around.

Well, shit. I'll need to start networking and making some lawyer friends and reading up on the newer security standards if it's an industry on an upswing. Perfect timing too, as I've just been given a position with a ton of freedom in regards to how I spend my time and company resources on research and training.

It’s worth it to be aware that anything short of complete defeatism is blind optimism, under some circumstances.

Unrestricted physical access to a machine? The machine is compromised.

Remote sign-on as a regular user? The machine is compromised.

Exposes enough tools for a power user to your jailed remote users? The machine is compromised.

Restricted physical access to a machine but you let them plug in something to a USB port? The machine is compromised.

Free internet connection and the user can fuck off on the internet without an ad blocker if they so desire? The machine is compromised.

The machine is ever, ever connected to a machine that is or could be compromised at some point? The machine is compromised.

I’m sure there’s more, but this is the list that any knucklehead with five minutes on Google and a single working hand can take advantage of.

So if anyone ever asks you to completely secure a system so no one can ever break in, the answer is “impossible”. You can make it really, really, really fucking annoying but you can never lock it down entirely.

Oh yeah, I just meant that I could be technical enough to have a positive impact on security without putting myself or the company at liability risk by being untruthfully embellishing or optimistic regarding actual security flaws, nor would I be so hopelessly realistic about every system's vulnerabilities that they'd wanna get rid of me for someone dumber and more optimistic.

I expect that our systems will be fundamentally vulnerable to most of the problems you listed here (Minus the freely accessible browser, oddly enough. That one is usually not a problem in Retail Environments.) Especially with some of the low-volume amd low-profile Estates we'll be deploying to, soon. For legal and security reasons, I can't quite give much info about the names of some of the customers, but some of them will have so many stores with so little Infrastructural Oversight funding for each store that they'll essentially be unsecured gateways into our system. One would likely have an endless amount of free time with a Till in some locations, especially during off-hours.

The idea is, as you put it, to make it very fucking time-consuming/annoying to break in. Hopefully, for now, it'll just take long enough for the attacker to expose themselves and get caught if I make it damn-near impossible to even see the target application.

[LMNO]

This new season of Mr Robot is weird.

[POFP]

This new season of Mr Robot is weird.

Mr. Robot was always one of those things I'd wished they made when I was little, but now that I'm an Adult, and busy as fuck, I rarely have time to watch it 

[P3nT4gR4m]

Dunno about security but fuck me did I just serve 6 months in what felt like a - how not to infrastructure - case study. The guys who bought us out are running a f'kin foxpro admin system that looks like an out of date warehousing/logistics solution, poorly modded for RIM functionality.

Okay so it's archaic and clunky as fuck but so are a lot of things in this field. Budget aint what it used to be and it can be hard to convince the board that we need something new when what we already have is doing the job, right?

Okay, fair enough but which fucking idiot thought it would be a good idea to serve it over MS RDP in some kind of twisted homage to the 90's thin client craze? So now these guys are wondering why there's smoke pissing out the back of their server every time they turn it on an five hundred users ask for sessions.

I'm guessing the same idiot decided it was a good idea to stick the database on the same box, cos fuck if I haven't got anything better to do than wait one minute and thirty seconds for a hundred-odd work orders to appear on my screen.

The icing on the cake was when tech support sent out an email about a planned server reboot TEN FUCKING MINUTES before they took it down! Surprise surprise, rebooting didn't fix their 90,000% load issue but it did stop us servicing any orders for the best part of twelve hours.

Bear in mind this company is the success story, their acquisition strategy is one per month and they're trying to increase this to two. Fuckers are so backlogged it took three months for them to even email me about data transfer. I can't complain, just picked up half a years salary for an hour and a half's work.

And they still managed to arsehole the transfer. Kinda guessed they would when, two days before I pulled the plug on my side, I was getting emails asking what all my fields did.

Security? At a guess there is none. AD group policy certainly wasn't the slightest bit concerned when our AV cover ended. The application they're using is essentially visual foxpro query builder, with a logo in the corner. That's right, end fucking users are writing SQL. Can't imagine anything going wrong there. Lets hope they've locked down Drop statements. I didn't have the heart to check.

[altered]

Welcome to normal computer security.

What I didn’t mention about that life insurance company is that they were one of the smarter ones I’ve heard of.

Yes, penetrating their network was as simple as logging into the unsecured root user. But their intranet wasn’t connected to the internet, even indirectly, and so an attacker would need to get physical access to a machine. At a life insurance company, that’s hard to do, because there’s very little chance you’ll be left to hang out in an office for long enough to do anything more than get caught red handed.

They did have an Internet-connected network, and that was all Windows machines — cue the cold shudders — but they were all employee owned machines, laptops, and I believe legally they can’t put customer information on employee owned machines. So, all told, that’s actually a lot better than what the norm is.

Read through Troy Hunt’s blog sometime, the Security tag. It’s illuminating: gigantic companies throwing plaintext passwords around. Enumeration attacks possible without authentication. Ridiculously basic shit left wide open.