Should I hash session IDs before storing the session contents? I am wondering if it is smart to hash my session IDs before writing sessions to the session storage, in order to prevent session ID disclosure.

I am writing an application in PHP on top of the Symfony framework. By default PHP stores sessions as files in a directory readable by the PHP process using the session ID as part of the file name. The problem I see is that, if there is a local file inclusion bug or RCE in the application, an attacker can easily list all valid session IDs and hijack sessions.

Alternative session storage for PHP exists, such as Redis or Memcache, but these suffer from the same flaw. You can easily enumerate all keys in Redis or memcache and thus get a list of valid session IDs.

My idea for mitigation is very simple. Instead of storing sessions using the session-ID as the key, use the hash(session-ID) as the key instead. If an attacker then enumerates all existing keys, he still does not have any session IDs. Performacne matters and sessions are relatively short lived (as opposed to e.g. passwords) so I would use a fast hash like SHA-256 or BLAKE instead of e.g. bcrypt for hashing the session IDs.

My question: Does this make any sense? Does this buy me any extra security? Or does a local file inclusion bug or RCE already mean "Game Over" and is this just security theatre?

I can't be the first person to see this possible threat, but I cannot find any mention of this, or of hashing session IDs as a good mitigation or defense-in-depth. Perhaps I just lack the right vocabulary to put into Google?

LFI on session file is possible, but there are plenty of other options like /proc/self/environ, file descriptors, web server logs, raw database files, SSH/FTP/mail logs, an uploaded file or a temporary uploaded file located in /tmp is also possible, so you gain very little security through obfuscation from doing this. If the attacker can enumerate all session files they can just try all of them until one works. You would be better off spending the would be development time hardening your server or reviewing your code.


What can entreprise admins do with our secured sessions? The enterprise where I work has a proxy server that traces and filters our web activities. Employees claim that they can know the links that we visited and see the content of HTTP web sites, but they can't see the content of HTTPS secured web sites because the content would be encrypted by the server. I don't share the same idea and I think that there are plenty of ways to access the HTTPS content.

Could someone give me some type of attacks that could let them access the content of our HTTPS secured navigation or hijack our sessions?

Just guessing: One of the things that could increase the risk that they can execute a MITM attack as the image shows is the fact that they give a preinstalled Windows XP/7 system to new employees so they can install malicious certificates to these computers and make them trust additional Certification authorities

The graphic you posted is a setup which isn't actually that uncommon in corporations. It allows the intercepting proxy server to eavesdrop and even modify any web activity. Legitimate use of this technique is usually to enforce acceptable use policies in the organization, like preventing people from playing games or looking at porn while they should be working. It also allows to scan any traffic for web-based exploits or viruses before they reach the client. With end-to-end encryption, this would be impossible for the proxy.

However, should a network administrator really have malicious intentions, they could, for example, snoop any usernames and passwords people enter on any website. They could also redirect websites to their own servers without the user noticing and give them false information or luring them into entering information the legitimate website isn't asking them for.

But let's assume they don't use this setup and the end-to-end encryption between client and webserver works as they believe. What other information can be logged on the proxy?  While the proxy doesn't know the exact URLs you visited, it still knows which domains you contacted. So it doesn't see http://reallypervertedporn.example/videos/167642/hot_girl_on_girl_on_guy_on_goat_action_part4.flv but it still sees that you made a TLS-handshake with https://reallypervertedporn.example and received several MB of data, which might be something you have to explain.


Factory reset on a smartphone On resetting a smartphone, the default factory image replaces the OS completely and restores it to known good settings.

Is there any known way by which this default image can be compromised? On Android, by getting root access, can't some malware just outright flash the ROM itself? And how viable is such an attack on a Windows Phone(which doesn't have such superuser accounts)?

The factory reset on any phone/computer shouldn't be trusted, as it can be modified by the system and thus becomes a heaven for malware that wishes to persist. This also applies to the Windows 8 "refresh my PC" feature, the "recovery partition" nonsense OEMs put up to avoid supplying $0,01 recovery DVDs (which are write-once media and can't be compromised) and any similar feature.

To properly "nuke and reinstall" a phone, you should use a known good machine to download a clean ROM image (either an official one or a third-party one you trust), reboot the device in bootloader/DFU mode (for iPhones) and then install the image (in the Android and Windows phone worlds, a nice bonus is that you have the chance to install a non carrier-branded ROM and say goodbye to their bloatware and lack of updates).

Theoretically the bootloader itself could be compromised and evil, and at this point there isn't much to do besides physically unsoldering the memory chips from the phone and writing a new firmware & bootloader to them from a clean machine. The only reason these attacks aren't more widespread is the same as for malicious BIOSes for PCs - the fact that this kind of malware isn't portable and targets only a single make/model of machine and the difficulty needed to develop such malware (a lot more complicated than your average malware running in userland).


Why does the password field not show the entered text? Why does the password field not show the entered text?

When we enter password it shows ... or '*'.

What are the security advantages of this?

The primary concern is to prevent "shoulder surfing", where a user is in a position where someone else may see their screen as they enter a password. You don't want users to be forced to secure their visual surroundings before entering a password, as that may not be plausible for them. It isn't always necessary, but it's a good practice.

There is some detailed analysis on the pros and cons of this practice here. (Note the many links to follow.)


Windows security & data protection I work for a hotel. The hotel stores a MySQL database online. This database only contains a Reference ID, number of nights and so on, but no private data. No names, no personal information on guests. So if it fully leaks, it doesn't matter as much.

Then I have a new laptop (Windows 10), with Bitdefender and Zone Alarm. This laptop does not have any other software installed other than Microsoft Office nor is it used for anything else but one purpose.

The laptop has a .xls with customer names, phone numbers, email addresses in cleartext. A small Visual Basic program I wrote sends a feedback email (via SMTP) to each guest after their stay.

Now my questions are as follows:

Is this setup safer than storing encrypted versions of their emails and phone numbers in the MySQL database?
Since the IP of the laptop leaks when an email is sent via SMTP (an attacker would know the local IP) is there a risk of somebody attacking the laptop via the internet?
Would it be safer to deploy the .xls and the macro on a Windows based server?
How safe is this type of setup, what would your thoughts and advice be?

Keep in mind that I do have to be able to retrieve the emails and phone numbers on the laptop in order to send the emails.

Generally speaking, storing that information in the DB, encrypted is the better choice. Is there any reason you are not doing this?

I would be less worried about an attacker trying to attack the Laptop via a leaked Local IP since most laptops don't allow incoming connections, I would be more concerned about a person clicking a link which compromises the computer, allowing an attacker full access.

For question three, yes, generally, these systems are monitored, and locked down. If all it has is arbitrary stay information, than having it on the server system is better. I would assume you get their info from another DB? Even if you generate the XLMS on the server and have a script run, it's better than have it on one persons laptop.

The setup's safety is relative to the person managing the system. For instance, I as a Info Sec person, generally, have a more secure laptop than a lot of Small, Medium businesses. However, your admin should be following some basic best practices, which should increase the overall security of the server, so unless you are a paranoid Info Sec Bod, with an encrypted HDD, and 12 char password, who takes regular backups of files, than you "might" be fine, but from a business standpoint, no user laptop should run business functionality.


API message verification without storing private key? I'm in the process of implementing a public API for my web service. Security is a key concern as money is involved.

It seems the current common practice for "authenticating" users in API requests is by confirming message authenticity, having the user send along a HMAC of the parameters (including a unique nonce), for each request.

This is fine, but it uses a shared secret: both the server and the client have to store the private key in order to generate the HMAC.

I don't like this. What's the point in going to all the hoopla with salting/hashing passwords, if I'm then going to start storing unencrypted shared secrets in the database?

Is there a better way? I was thinking of using GPG, and having the user provide their own GPG public key for me to store; they could then sign messages using their private key. However, I fear this might be a bit of a pain for Windows users to play with.

In general, isn't public/private key signing a much better way to do this? There must be some reason why everyone is choosing HMAC with a shared secret... what am I missing?

I will of course set limits on customer interactions via APIs, provide notifications and limit removing money from the system, but a great deal of damage could still be done if the shared secrets were leaked.

I asked the same question just yesterday, but in the meantime I have found what I believe will answer both of our questions: SRP. This question has the best answer I've found so far. Here is a reference to SRP.  The main problem with SRP is there are no modern implementations that can be used at the application level.

Edit to add more information from my research:

I have decided to use a database backed session store, so it still meets the definition of stateless.  This requires SSL to be the only protocol for communication, which eliminates MITM and replay attacks.

Use bcrypt to store passwords in DB
use Two Factor Authentication, such as Authy or Google Authenticator - this does not meet your requirement of no external dependencies, but in my case I'm ok with that. It prevents a user leaking his password - attckers still need the user's TFA device.
Have a session ID and Session length (in secs) field in each user record
Upon successful authentication (typical auth, user sends userid and password, use bcrypt to hash password using stored hashed pw from db), compare hashes, etc)
Upon successful password, generate cryptographically sound guid, and store in db, along with how long you would like to keep session alive
send this session id as response to auth
if you want true statelessness, require client to HMAC hash every request with this ID - he can keep the ID, he doesn't have to send it to you
verify request by hashing request with stored sid, compare to hash he sent you
on each request, verify that expire-time hasnt passed - you dont need a process that checks expires, just check it each time the client attempts an API call.

I have compromised and used express-js's secure session storage, which DOES use a client side cookie, but the cookie is signed with a shared secret that all of my application servers know, so it meets the stateless definition in that the cookie is not unique to the server the client is connected to, since the cookie is still in my app server's domain


Is there any danger in the preview button in blogs? In my Wordpress blog (though this may be true of other blogs too), there is a preview web page feature.

So when I get a comment with a link, I can hover over the link, and it shows me a preview of the page. I sometimes use this to check possible spam messages.

But is there any risk in this? For example, if the webpage has a script or XSS based attack, can my blog be compromised?

To make it clear, I'm not talking about any plugin. In Wordpress comments section, people can optionally post a link to their website. If you hover your mouse over the link, it generates a preview of the website. That's what I was talking about. This seems to be an inbuilt feature of Wordpress.

In the following, I suppose that you are talking about the ShrinkTheWeb plugin for Wordpress. This plugin work with the server maintained by the ShrinkTheWeb people: when a "hover" is done over the link, a request is sent to your server, which will then forward the request to the ShrinkTheWeb server; the latter will actually try to access to target Web site, compute a thumbnail, and send it back to your server as a picture. For your server, there is only a picture, and that's what is sent back to the user's browser.

Any plugin can have its own security issues, but I would say that in this case, the risks are on the ShrinkTheWeb server's side, because it is that server who will do the actual access to the possibly nasty Web site at the end of the user provided link. Your risks are more along the following lines:

If the ShrinkTheWeb server is hijacked, it might be possible that it begins to return malicious data instead of thumbnails of Web sites as innocuous pictures; depending on how poorly the WordPress plugin is written (I have not checked), this may or may not be dangerous for your server or even the user's browser. However, as long as the ShrinkTheWeb server holds the line, it will return only well-formed pictures, which will be harmless for your server and the user's browser.
The screenshots will somehow appear to be "in your blog site" so you might have public relations issues if "unwanted" pictures appear that way. But that's a matter of tracking and deleting spams and trolls; nothing really new here.


Automatically change connection of VPN when accessing certain websites So I am quite new to VPNs, just downloaded and installed NORDVPN despite the latest admission of security breach for a trial period.
I am also running BitDefender TS on my computer.

I wanted to know if there is any way to automatically reconnect to server from another country when accessing particular websites?

I have BitDefender, and whenever I open a banking website it opens the safepay browser for me automatically.

I was wondering if I can configure NordVPN to do that in any way. I'm worried that if the banking website sees logins from different countries, it will red-flag my account. If I can configure it so that whenever I access the bank, NordVPN automatically changes the VPN location (or automatically asks me if I want to change) to my home country, then the bank wouldn't log some change of country and things would be alright

If I cannot do with NordVPN, are there other VPN's that allow that?

P.S.
I was looking at split tunneling but it seems to me that split tunneling is to choose between the original connection and the VPN, but I cannot choose between 2 VPN connections.

I suggest you use Split Tunnelling and use a different browser, then simply allow one browser to be off VPN connection.

Use that browser to access websites with your clear IP.

As for NordVPN, I just spoke with a rep and... there's no support for Split Tunnelling, but there's a browser extension that enables the VPN only for the browser, effectively allowing you to keep your direct IP for banking and such on another browser.


Alternative approaches to letting users identify themselves while maintaining privacy This is kind of a weird question maybe, so let me explain a little background first that I hope is relevant.

I work as a Developer/Analyst for an organization that operates in a federated model with a central authority, except I'm part of one of the many federated entities. We use software (CRM, Business Analytics, etc) curated by the central authority, but they are really bad about being able to provide us the tools and resources we need for our own software development, such as API access.

I am developing an application where we need to track visitors and need to ensure that the visitors we track are de-duplicated during multiple visits and generally identified in some way. Most of them are customers who have information in our systems, while many of them do not.

My preferred solution would be for our customers to sign in upon visiting with the Username/Password they have via SSO, while all other users would be tracked in another way. Even better would be a provided membership card or something that they can simply scan to identify themselves.

As I can't do any of that, I am creating our own Shadow IT API to integrate with our customer data that we pull from our BI tool via a crude ETL process (again, no support from parent entity).

The approach I'm thinking of will be to let visitors find themselves via an email address (something they know that typically others will not), or via a customer id (something that only about 1% of them will actually even know).

I'm worried that it might be a breach of Personally Identifiable Information if I let people search by email address, and they input addresses that are not their own and can see names of people that are not them. I don't know what the odds are for that given the extremely niche use case, but it could happen.

Are there any other approaches I might be able to creatively utilize?

My preferred solution would be for our customers to sign in upon visiting with the Username/Password they have via SSO, while all other users would be tracked in another way. Even better would be a provided membership card or something that they can simply scan to identify themselves.
(...) I can't do any of that (...)

There are three factors you can use for authentication:

First factor: Something the user knows (password): you say you can't do this one. I will assume that this is not a technical limitation. I imagine you have the technology to have a secondary database to store credentials. And you can't do that because reasons beyond the scope of the question.

Second factor: Something the user has: you say the membership card is not viable, also because reasons. There are alternatives. You could use something the user has access to. Will come back to that.

Third factor: Something the user is: for example biometrics.

I'm worried that it might be a breach of Personally Identifiable Information if I let people search by email address, and they input addresses that are not their own and can see names of people that are not them.

Yes.
The user should not see the search results unless authentication can be done. You need a layer between the user and the search.

I don't know what the odds are for that given the extremely niche use case, but it could happen.

I remind you that humans behavior is irrational, not random.
My guess is that chances of people noticing that there is no real authentication are high (they did not have to use a password or show any credential).
Beyond people using this to get information about others, I would be worried about impersonation/identity theft.
If you cannot add a software layer between the people and the search, one way to deter people from searching who they are not is the third factor: something people is. For example, a deterrent would be having a photo of the person shows up in the system and have a staff member overlooking who can compare the photo to the actual person.
That is also a way to use the third factor without putting a camera to people's face and using fancy AI software. Which are hard (for the traditional face recognition) or virtually impossible to understand (if they use artificial neural network reinforcement learning, for example), could be cheated (these systems have false positives), could be percieved a privacy invasion (where does the data go? is it being stored? is it shared with third parties?).

About the second factor...
A cheap alternative to a membership card, is to use email.
I suggest this approach (tweak it as you see fit):

The system asks the user for his email.
The user types their email.
The system searches the database for the email.
The system sends an email message with a (random, unique, single use, time limited) code.
The system asks the user for the code.
The user gets the code from the email account, and types it in the system.
If the code matches... If the email was found in step 3, the system grants access. The email exists in the system and the person proved they have access to the email. Otherwise, you can tell the person that the email is not in the database, and indicate what are the next step (is there some registration process?).

If the email can't be sent. The email the user did enter is not valid. Tell the user.
If the system is asking for the code, let the user: 1) request the code to be sent again (with some delay, let us not let people use this to spam others. You may add a captcha, not for checking if the user is human, but to slow them down and make it tedious to use this to spam). 2) abort the process and start over.
Keep in mind that with this approach the person never has to see the search results. The only way to get access as another person is to have access to the email of that other person. Either that person has the email compromised, or they granted this access.
Note: I'm not suggesting to tell people right away if the email was not found, because that could allow the user to figure out who is in the system by typing the emails of people they know. Also know that this could become an inconvenience for users (a single typo would be annoying). If you add text telling people to double check, people learn to ignore it.

By the way, if you can build the above system on top of what you have. I believe there should not be a technical limitation to implementing passwords. I will not cover how to store passwords here. Hint: you don't. You can research that if you are interested.


Online dealer asks for a photo of my credit card and driver’s license, and also all numbers from my card, is it ok? I was shopping online and I could not buy the desired item, I could only make a request. After that, I received an email from the dealer:

“If you would like to proceed, please fill out the enclosed authorization form and email it back along with copy/picture of your credit card front and back and driver’s license (all required by the Finance Dpt.).  Also please provide the complete street address, telephone and email."

In this “attached authorization form” (just a .doc file) I have to write all the numbers on my credit card, including billing address and card identification number.

Looks like too much information about me.
Is this normal?

Run away!

The only information an online shop should need is address (delivery or invoice, one of which needs to match the card), cardholder name, card number, expiry date and CVV on the back.

Your card issuer will handle any additional authentication - and there's new regs coming in over the next few months to tighten up on this - and this does not go back through the merchant.

The only reason I could think of for additional info like drivers licence or utility bill is you're opening a line of credit with them and they're running a credit check, buying age-restricted items or something that needs a licence to purchase.


PCI DSS for web servers not storing credit card info I plan on deploying our new company website to a dedicated server through a hosting provider. I will personally maintain the server with the exception of dealing with the physical hardware. The company itself does possess credit card info through phone calls and other means, so we are subject to PCI compliance. However, this new website, which is not on the company's private network, has limited if not absent exposure to sensitive cardholder data. We will be using 2 online payment methods:

Payal Express (Totally third party, no sensitive data available)

Authorize.net Direct Post (The credit card form is generated on our site, but submitted directly to Authorize.net. Only a serious and unnoticed breach would make this info available to my server.)

With this setup, the database and web server at no point see any credit card data, which brings me to PCI DSS requirement 2.2.1:

  Implement only one primary function per server to prevent functions
  that require different security levels from co-existing on the same
  server. (For example, web servers, database servers, and DNS should be
  implemented on separate servers.)

My hope is that because the database has no sensitive data (and for that matter, might as well be a database of all my favorite colors and films), then it is not considered a "different security level". My thoughts are that this requirement would apply to larger companies that host various services and applications, where separating the two is quite logical. Can anyone clarify this rule per my situation, or give any thoughts? I find it hard to believe that every VPS or dedicated server with the LAMP stack installed (as all the "PCI Compliant" managed solutions said they would happily setup for us) are all out of compliance. At the very least, is this a situation where special exceptions could apply?

In addition, the server is locked down with a software firewall, TLS 1.1 and up, IP restrictions, log storage and monitoring, file integrity checks, malware and network scanners, etc. Overall, I'd like to avoid the cost and complexity of a separate server to simply check a box.

The requirement is that each server have a primary function rather than a single function. You can argue that the primary function of the server is as a web server and the database functionality is a secondary function. Consider a Domain Controller which can be a DHCP server, NTP server, DNS server, authentication server, security policy server.

In terms of security levels for PCI compliance, given that the database is not storing cardholder data, there is no requirement for this to be a separate server on an internal network segment. As the server itself is in scope, everything on the server is in scope so the database still needs to be hardened and logging so you're still securing the system and mitigating risk.

If you have a QSA, s/he should be able to provide guidance.


Can my workplace view my Tor traffic? I connect to the internet using my company's Wi-Fi and Tor. Can they still see the websites I visit?

First:

Don't use work computers for personal use, people!

Many network policies forbid personal use. Our policy states that personal use is not forbidden but is monitored. If you don't want to be monitored you need to use equipment you control.

TL;DR: If you don't want your parents to know you smoke, don't smoke in front of your parents.

Work Equipment

If you are using a work computer, yes, if they want to, they can monitor everything you do. All they have to do is install software on your computer (which is actually their computer) which logs all web browsing activity.

If I caught someone using Tor in my organisation (absent special permission) I would fire them on the spot, for violating half a dozen policies, including circumventing our protections against data exfiltration, required both by data protection law and our agreements with our customers.

Own equipment

If the equipment is owned and controlled by you, I am wondering why they have given you permission to connect it to the network.

If you don't have permission, then again, that is grounds for termination.

If you have permission

If you are using your own equipment, and you have permission to connect to the network, (for example the company supplies visitor Wi-Fi as a courtesy, and allows staff to use this) then you are in the same position as when you use a hotel, coffee shop, or fast-food restaurant Wi-Fi, and there is then nothing special you need to know.

So what should you do?

If you want to e.g. email your doctor about your cancer diagnosis without alerting your employer, you should do it from your smartphone, using the data connection.


How to convince team mate about using an allowlist for a link created from a parameter? Context
In our development team, we have to build a component. This component is a full client side one written in Javascript.
A client web application wishing to embed this component will call it like below:
<iframe id="fullScreenIframe" src="http://my-server.com/component?param1=val1&param2=..."></iframe>

The problem
One of the parameters accepted by the component makes some of us nervous. The origin parameter is used to generate a link to take the user back to the client web application.
Here is how the component manages this parameter:
$(document).ready(function() {
    var origin = urlParameters["origin"];// Dynamically built from the current document url

    if(origin != undefined){
        // The link to take the user back...
        $("#welcomePage").attr("href",origin);

        // Another link in the breadcrumb using the same `origin` parameter
        $("#simulationPage").attr("href", "index.html"+"?origin="+origin);
    }

    // ...
}

What we already told him

Website phishing

Even if the origin parameter is passed to jQuery, any website can be used in a phishing scam. A user can be asked to (re)enter their credentials thinking they are on a real site. The hole here will be the component.

Allowlist with valid values

The valid values of origin can be stored remotely in an allowlist. The component would check the allowlist first before generating the link. A default link can be generating if an unexpected value is found.
Those two arguments didn't convince him. He wants to be demonstrated that the origin parameter can be a security hole. What would you tell him?
By the way, I'm looking for a good PoC demonstrating the weakness of the origin parameter.

As long as you're relying on incoming user information, you'll never be fully protected/safe. Anything can be spoofed, altered, modified; and, subsequently, your component is now compromised.
If you want to go the route of retaining some trust, it would make sense to allowlist. However, going a step further may be more ideal--you issue tokens in lieu of specifying domains (think of how Google Analytics uses a UA-XXX number over mysite.com). Push administration back on their web admin and the possibility of faulty domains/security vulnerabilities is now their responsibility.

To further elaborate what I'm referring to, instead of having a allowlist, setup a database of tokens:
tokens
id       # Primary Key
token    # Unique generated token

Then, have a 1:* relationship where valid origins can be defined for that key:
origins
id       # Primary key
token_id # Forieign Key, tokens.id
origin   # origin (e.g. google.com)

Then create a token for a specific client (whomever is going to include your component on their page). For example, let's say we have the token abc123def456:

Here, your component would perform a server-side lookup against your tokens table and validate. You could also add additional checks against the Referer header, but that's up to you (and realizing Referer could be spoofed anyways). Default bahvior would be to deny *, so you'd show a page saying "No origins specified, please configure" (or something of the sort).
Next, they login to the admin page and add "abc.com". Now, the widget becomes:

Now, server side, you're validating key along with the origin (against your compiled allowlist in origins table (associated to that key). If a hacker were to try to use this (or modify it) an invalid origin (with respect to the key) would bounce and show an error page.
If they decide not to specify origin, you could also configure a default origin so anytime you include just /component?key=abc123def456 it assumes the default origin.
Or something like that


Why can't a Tor node simultaneously be a guard and an exit node? By looking at probability graphs for nodes at metrics.torproject.org, it seems that exit nodes can't also be guards (they have 0.0000% probability of serving as guard) and vice versa.
Why is that so?

Because guard relays (also called entry relays) can never be exit relays.

If you use a proxy or VPN, you have some anonymity, but also a single point of failure.
If someone compromises the machine doing the relaying, they know your IP and the IP of where you're going.

Tor protects against that by having at least 3 proxies in between (relays):

You---[ Tor 1 (entry) ]--[ Tor 2 (middle) ]--[ Tor 3 (exit) ]--Destination

Relay 1 knows who you are, but not where you're going.

Relay 2 only knows where to forward it in the network.

Relay 3 knows where you're going, but not who you are.

This way, an attacker looking at the network can't easily see where
you're going by looking at where the entry node is sending its data, or where the exit node is getting its data.

It follows that when you're trying to separate things this much, the two most sensitive relays, entry and exit, can not be run on the same machine.


How to protect against an attack where a person claims to be in a position of authority? In an office if a person approaches an employee and claims to be a new IT staff and to give them access to their computer, what can prevent this kind of attack? I've worked a couple tech support jobs and people are all to happy to hand over their password and laptop when I tell them I'm here to fix it.

as @TerryChia said the correct defence against this kind of attack is strong policies.  In this case users should be trained not to provide passwords to people in person or on the phone regardless of what the circumstances are.

If IT need to log in to a users account they should either use something like sudo (for *nix environments) or if that's not available either reset the users password before doing the work and then reset it again afterwards or alternatively they could use an approved remote control mechanism that has strong authentication requirements.

The key is to set policies up in a way that does not encourage people to break them.  If it becomes the norm that IT staff are asking users for their passwords then when an attacker does the same thing, the users will just go along with it.  However if IT never ask for passwords and it's company policy that they shouldn't, users are far more likely to recognise this as an attack and react accordingly.

As with anything with humans, there's no perfect defence, but correctly designed and implemented policies go a long way to helping.


Is 90 day expiration for unique URL too long? A web application I've been developing has a new use case that has me searching for something easier than username/password authentication.

Current users don't sign up for the service themselves because it's a b2b service being used by their companies, so for standard username/password authentication we send them their username and a single-use temporary password via email. They are required to change their password and accept terms of use on first login.

For this new use case, some subset of users will now only be entering data during a 90-day period that happens once a year. Most of the time this means they'll only be doing this for one day, maybe two, a year.

Because it will be easy for them to forget the password they set after logging in with the temp password I would like to try something like a unique URL that expires. The URL needs to be valid for 90-days (or at least until they've finished entering their data if we can figure out how to measure that).

Each year they get a new email with unique URL to start that 90-day period.

The security drawbacks here are the typical ones:

Unique URL shows up in bookmarks and browser history
Unique URL shows up in server logs
User might forward the email to another mailbox and the message is not transported securely.
Need to guard against SQL injection in URL

Normally unique URL schemes are valid for short periods like 24 hours, so I'm worried that a 90 day period is just too long.

As for risks: if an unauthorized person gains access there would be very little information leakage (and certainly nothing that is PII) but there is still some "loss of trust" concerns.

Is this secure enough?  If not, are there any other authentication methods we might use here?

Two problems with this question:

"is XYZ too long?" where "too long" is a qualitative, arbitrary value
Security through obscurity

Nobody can say for sure that X days is too long. If there's nothing at stake and none of this has any value, then X can be infinite and nobody will care.

If there's something at stake, or something of value, though, it depends, and that's where you should perform a risk and threat assessment.

You have a 90 day requirement over which a task may occur; your solution to enabling someone to perform that task is an unknown unique URL and no other protections.

A unique (but unknown except to the trusted party) URL is an example of security through obscurity.

The longer the lifetime, the more chance someone unauthorized will access the URL. The higher the payoff, the shorter that timeframe is likely to be and the larger the likelihood that an attacker will invest time, effort and money in breaking in (or getting someone to forward that URL to them).

Payoffs may include revenge for disgruntled employees/contractors; just because no dollar value is attached to something doesn't make it worthless to hack it (you mentioned reputational damage).

If trusting input is important, leakage of the secret (URL) could lead to erroneous, malicious or misleading information being entered.

So my $0.02 - if it's worth protecting, do a careful analysis on how trustable you expect your user population to be, or just stick with username and password authentication; use a unique URL for password recovery / mail account authentication.


Bypass the "double submit cookie" protection? Is it possible for an attacker to spoof the double submit token/cookie, when the first token/cookie is in the Cookie header and the 2nd token/cookie is in the body params.

Yeah, there is a way using XSS but other than that?

No, unless there is some implementation error, you will not get anywhere. Why? Because you can not read the cookie value, so you wouldn't know what to set the value in the body to.


Why does oAuth and oAuth 2 have access tokens at all? I am trying to implement a system for third-party apps to access data that a user stores on a provider. We have a robust access control system, with separate read/write/etc. levels for each "stream" of data published by a user. Inside our website, these access levels are already enforced depending on which user is trying to do which action with another user's stream.

Now comes time to allow third-party apps to do the same, in an oAuth2-compatible way. We currently represent third-party apps inside the provider app database as regular users with a user id, canonical url, etc. So this user id would be the client_id of the app.

My question is, why does oAuth have tokens at all, which are essentially opaque strings that map to (user_id, client_id) records that have (scope, etc)?

Can't the app simply identify itself with the client_id as its api key and sign its requests with a symmetric secret, for server-to-server requests? These signed requests and responses can be relayed through a user agent if need be, if there is an additional requirement that a user be online when the request is granted.

The provider already stores the access records for the (user_id, client_id) so it knows whether to approve or deny a request from the client app. Why does the client app need to store and spit back extra tokens?

The only thing I have come up with so far is maybe this is to increase the security in case someone gets unauthorized access to the client app's symmetric secret. And this way the attack would be limited to whatever tokens they would be able to get (since the tokens are required as an additional credential). Seems that on the server side, if someone gets the symmetric secret, they probably also get the database credentials as well. So this isn't much of a plus.

Is there any other reason? Or was it just security theater?

maybe this is to increase the security in case someone gets unauthorized access to the client app's symmetric secret.

That's one valid reason, yes. Sending around short-lived access tokens instead of long-lived shared secrets reduces the attack surface.

  Is there any other reason?

OAuth defines several roles. Often a resource doesn't reside on the same server that handles authentication and/or authorization. An access token can be generated by one service and be consumed by another that doesn't actually know anything about who has authorization to what. A resource server might not know which users have access to what resources, but being given a valid access token by an authorization server, it can make a decision about granting access.

Think about access control in a building (or at the border of a country) - the guard at the entrance might not have a list of every person allowed inside and might never have seen you before; but if you show him a valid access card for the restricted area (or passport in the country example), he'll know he's supposed to let you in.

This has a few downsides as well. If access is revoked, but you can retain your access card, chances are you'll still get inside even if you aren't supposed to anymore. This can be countered by putting an expiration date on the access card, and this is why access tokens are usually short-lived, so that even if they're stolen, they can't be used for very long.


Are there any test cases to ensure the "web-attacks.rules" snort file works correctly? I have set up an free evaluation Confluence Server on my local host and have configured "snort.conf" to point to my localhost as "HOME_NET" environment variable.

I tried to test the ICMP rule by running "ping localhost" and I immediately see output in /var/log/snort/alert file.  So I know the ICMP rule works correctly.

However, I cannot get any of the "web-attacks.rules" to work.  For example, how do I test this rule?

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:"WEB-ATTACKS uname -a command attempt"; flow:to_server,established; content:"uname%20-a"; nocase; classtype:web-application-a

ttack; sid:1331; rev:5;)

I would appreciate all / any advise in testing any of the "web-attacks.rules".
In fact, if someone could point me to a test script that triggers all the "web-attacks.rules" that would be ideal.

Thanks.

Usually people use a web application firewall to detect/prevent these attacks.  mod_security is an open source WAF.

Any web application vulnerability scanner should do the trick.  Skipfish and wapiti are both open source web application vulnerability scanners.


Crack Hashed Byte Array? I know it would take forever to crack a simple hashed byte array, though for learning sake I was wondering whether it is possible to crack a hashed byte array?

And if so, any suggestions how to do it?

Cracking tools like hashcat have a brute-force mode that allows you to specify a mask.  One of the available masks is for binary data, so you could use that to attempt to crack your hash.

Something like:

hashcat --attack-mode 3 --increment hash.txt ?b?b?b?b?b?b?b?b

You'll still need to specify --hash-type, but you can find the appropriate value from hashcat's help page.


How an experienced user decides a download is safe? I am new to computer security. I was wondering what an experienced information security user would do when inspecting a file for potential download. Obviously, it would be very difficult to look through all of the files that download and all of the source code (the package is open-source). How does one know what to download and what not to download?

Deep down you don't; from a security perspective I have more software running on my phone than I could effectively ever review in my lifetime. My desktop machine would be 100,000 worse than that.
So you have to trust where you get the software from, you can check to see if it has been tampered with. But that's still no guarantee (for example a few years ago a tiny tiny change to debian caused a massive reduction in entropy of encrypted communications, to the point where data could be guessed, or proftpd (maybe vsftpd I don't remember which) had a malicious commit from a contributor that got missed allowing root level access when a user logged in with a hard coded username and password).


Is PGP passphrase necessary if I store private key and passphrase in the same place? I'm building a system that generates PGP key and store private key in secret vault. One thing I'm not fully understanding is the need for passphrase.
I can generate a random passphrase during the key generation and then store it in the secret vault along side with the private key, but I'm wondering if it has any benefit.
If I store both passphrase and private key in the same place and that place can be considered secure, is there any additional benefit of using the passphrase? Or just storing the private key securely is enough?

The benefit of a passphrase is an added layer of protection for your keys assuming that the attacker has no way of associating the passphrase and the key.
Let's assume an attacker gained access to this vault.
If it has both the passphrase and the key, then it matters not if the passphrase was randomly generated or what, they key is essentially (for lack of a better word) 'breached'.
If it has only the key with no passphrase, then the same result applies.  Your keys are 'breached'.
If this vault has the keys with a passphrase (which isn't stored in the same vault), then your keys are a lot safe, and if generated properly, secured.


Best way to make a Linux install tamper proof Good day, I am currently planning an environment where it comes down to the biggest security risk being to boot to another environment and tamper with the install on the disk (Older PCs with physical access to the box that are accessible to the public). Since BIOS passwords offer little deterrent and the PC's don't have TPM to best of my knowledge, what would you recommend to make the install tamper-proof? I am currently thinking full block device encryption (LUKS) that includes the /boot folder - should this be enough? This way even though you are able to boot up to another device the install disk shouldn't be a problem, correct? Thanks in advance

EDIT: Just to clarify, the PC's are under surveillance and in cabinets- so attaching a hardware keylogger won't easily go unnoticed. Booting to a USB and tampering with the install - this is the big problem. Advanced attacks like modification to the BIOS/UEFI firmware probably won't happen (school environment) - software keyloggers being the big worry.

EDIT2: Further clarification - the PC's are in a cabinet like so:
    ------------
    |Desktop PC
    ------------

With the top part covered. The keyboards are plugged in at the back, so to access the keyboard USB you would have to remove the whole desktop from the cabinet. The surveillance is not constantly monitored but should a keylogger be found (or a security breach) it would be very easy to see where and when this happened (identification is not a problem since it is a school environment, as for calibre of attackers advanced attacks shouldn't be a problem, more likely is the casual keylogger and modifying install). Since the surveillance is not to the extent where activity on the screen can be monitored booting to another environment and working there can go easily unnoticed. The proposed environment is a Linux install running a non-persistent Windows VM - so an OS exploit shouldn't be a problem from inside Windows and the Linux install would be running a non-privileged user, so damage is limited to almost nothing. But, if the Linux installed can be tampered with before boot up all goes to hell. This is why I see preventing tampering with the Linux install as the biggest problem.

It is probably not possible to make this system tamper proof, at most you can make at some level of tamper resistant. Full disk encryption is a good way and maybe even the best you could achieve with off-the-shelf PC hardware.

But disk encryption does not help against simple hardware key loggers which can be used to get to the disk password. More advanced but possible are modification of the firmware, i.e. BIOS/UEFI, disk, network card, graphic card, Intel SMM ...

In summary, you cannot really build a skyscraper (i.e. tamper-proof) in a swamp (off-the shelf PC).

Edit: based on the updates to the question it looks like that everything which need to be done is to make sure that the system only boots the installed Linux without user specified arguments (i.e. no init=/bin/bash). This can be done by restricting boot medium in the BIOS, protecting the BIOS with a password and protecting the Linux boot loader (grub) with a password. Disk encryption will not help here and in fact hinders unattended boot of the systems which is probably required in this environment.


Universal clipboard iOS10 and macOS. How secure? New iOS10 and macOS Sierra has a feature called universal clipboard. You can copy something (text, image) on one device and paste it on another. How secure is it and does that mean that everything that you'll copy on any device will automatically upload to iCloud?

Personally, I would not put anything truly sensitive there.

Even if you trust that Apple really encrypts its databases, doesn't give away keys or back doors, the algorithm hasn't been perverted by the NSA, the crypto library isn't buggy, it's also secured in transport with perfect forward secrecy and mutual authentication (no MiTM SSL inspection), RAM is randomized and encrypted, you were not on Wi-Fi/Bluetooth, no renegotiation or compression type garbage... then you still need to consider that every time there is a jailbreak, that means someone has discovered a bug that allows them to completely compromise the security of the endpoint's iOS.

It's another tradeoff of security for convenience. Use it wisely. Consider the risk and manage it. For some uses, it's secure enough. For others, it's not.


Why is the issuer certificate different at my workplace and at home? I have viewed Gmail's certificate chain at my workplace, and I realised it's different. It looks like this:

Root CA
   Operative CA1
      ___________.net
         mail.google.com

When I get the certificate chain at home, it looks like this:

GeoTrust Global CA
   Google Internet Authority G2
      *.google.com

Obviously these certificates are issued by my company. I recently read some other thread on security.stackexchange, and they said the company is eavesdropping (using an MITM proxy) the HTTPS communications to protect the internal network and the client machine against viruses. That means they can read my all of the encrypted package that has been sent via HTTPS, including this message too.

If this is true, can I work around this? Or please correct me if I'm wrong.

Yes, a company doing SSL interception could in theory read all your traffic if you use the company network. Depending on where you live and what kind of contract you have the ability for the company to do this might also be somehow part of the contract or working rules which might also include that you are only allowed to use the company network for work related stuff.

  can I workaround this?

Yes, you might use a different machine and network like your mobile phone for your private, not work related, traffic. Depending on the configuration of the firewall it might also be possible to use some VPN tunnel through the firewall. But it is usually explicitly forbidden to do this so you risk to get fired for this.


In the era of cryptolockers, is it possible to prevent Windows from modifying your Linux partition? I could imagine that in few years, cryptolockers could become so advanced that instead of just encrypting some files on the partition of the current OS, they could also touch all other partitions on main drive (let's say in a laptop).

Full hard drive encryption is not what would solve this problem, as cryptolocker could just add one more layer of encryption.

Do we have any reasonable way to separate the systems? Does UEFI offer anything?

Unless virtualization physically prevents the opreating system from seeing the device as such (e.g. the "disk" really being a VHDX or similar), the answer is "yes, of course". There is nothing special needed for that, and nothing you can do to prevent it from happening, once malware has gained admin privileges.

I wouldn't know by heart how to open the device under Windows (something like \device\harddisk1 or such?), but sure enough I've overwritten the raw device under Linux more than once. Something like cat /dev/random > /dev/sda has been "working fine" for, like... forever, assuming you logged in as root. That's poor man's secure erase in lack of something better.

Installing a boot loader (which is part 1 of the ransomware) is nothing but doing just that, only with not-so-random data. Overwrite the boot loader with a binary of yours that shows the "pay me, sucker" text.
Note that this bootloader (nor the encrypt/decrypt portion, if there is a decrypt portion at all) needs to be able to access the partition or the filesystem in a meaningful manner.

Encrypting (or garbling, the user cannot really tell a difference) is the second part, and that is similarly easy. If you can write a boot loader, you can write sectors. So, instead of files, encrypt sectors on the raw device. Who cares about the logical structure inside those sectors when you can make them unusable either way? Different partition type, different filesystem? You couldn't care less. Someone who wants to use them needs to know, you don't need to know.
This is something the malware can do in a few seconds, there is not even much of a need to be secretive or super smart. You do not need to keep a low profile to avoid detection. By the time the user even notices the furiously blinking light on the computer and wonders what may be going on, the malware will already have overwritten hundreds of megabytes (dozens of gigabytes) of data. If the malware writer possesses only a minimum amount of smartness, this is sufficient to overwrite the filesystem metadata on every partition including backup metadata at their respective well-known offsets, and a couple of hundred megabytes of actual file contents.
Certainly, with only the metadata overwritten, it is in principle still possible to recover the contents of the not-yet-overwritten files, but this is an excessively expensive thing to do, and well beyond the average user's capabilities (and may be impossible for small files on some file systems).

You need not even properly encrypt, you can as well just overwrite sectors with garbage data. The user cannot tell a difference, they only realize after having paid if they are so stupid as to pay a criminal in hope the criminal will stand up to his word.

So... yes, technically this is absolutely no problem (for most computers owned by most people).


How to decrypt the Encrypted DEK using KEK which are separated in servers? Decrypting the DEK using KEK under PCI-Standards, which are separated by Servers:

Let say for example we have server1 and server2

  Server1:

It is in East US, called it as Application Server.
Hosted my website and database.
In my code I'm using AES 256-bit cryptograpy.
Store the encrypted cardholder data in DB.
This server contains Encrypted DEK(Data Encryption Key).

  Server2:

It is in WestUS, called it as Key Server.
Only contains the  Key Encryption Key(KEK) to decrypt the DEK.
All port are bocked only accept the request from server1.

I have two processes in my mind for implementation. But just got confused which could be a better way:

  Process 1:

Below code is running in server1:

public string Data()
{
    AES objaes =new AES();
    objaes.key= getkey(EncryptedDEK);
//decrypt the values
}

public string getkey(string EncryptedDEK)
{

  //connect to the server 2 and get the DEK
  request(EncryptedDEK);
}

  The below function access the server 2 for decrypting encrypted DEK:

public string request(string encryptedDEK)
{
    //check the request
    //decrypt the encrypted DEK with KEK
   //return the Decrypted DEK
}

On the above process, the application touches the key server.I didn't like my application to touch the key server.
I need my key server to be very safe and also to be protective against malicious individuals.

  Process 2:

Application requests Card number to server 1 --> Server 1 (Encrypted DEK) --> Server 1 sends Encrypted DEK to the Server2 through SQL SERVER 2012 -->Server 2 decrypts DEK and sends it back to the Server 1 --> server 1 responses to the application with the decrypted data

Through sql server can I decrypt the Encryped DEK by connecting to
the Server 2 from Server 1?
Which one among the two process works fine or comes under PCI-DSS
standards?
Is there any better way than the above two processes?

If your DEK is being used on the application server, then it's not really encrypted by the KEK, since the app server has access to it. You can just toss the key server, as anyone with access to the app server, one time, can get the DEK and you're done.

You're better of using asymmetric crypto (the KEK) and generating a session key (DEK) for each item. That way, the app server can encrypt with the public key of the KEK and a new DEK for each item. The key server will have the private key, and the private key must never leave the key server.

For encryption, the app server doesn't need to touch the key server at all. You can have many front-end systems encrypting without issue.

Of course to decrypt, you need to access the key server. The app sends the previously-encrypted blob and the key server encrypts it. I suggest setting up another keypair for each app server, and using that keypair to sign decryption attempts. The key server can log every decryption attempt, so you can alarm if you get too many decryption requests. That's useful for finding malicious admins.

Also, please use a library like KeyCzar, so that all the details are implemented correctly. KeyCzar has this exact scenario (sessions) implemented for you. KeyCzar also has tools to help with key management, which is another thing you must deal with. KeyCzar has .NET, C++, Java, and Python implementations.

Finally, please talk to your PCI auditor about this. Some auditors require use of an HSM for this scenario -- that's basically what you're setting up with the key server. Some cloud providers (AWS) rent HSMs, so that may be an easy option.


Subject Alt Name certs Is it ok to specify subdomains in certificates that support SAN.
For example base domain is example.com and I want a.example.com, b.example.com, and c.example.com to be included? What is the primary purpose of SANs?

The purpose of SAN is to specify all host names for which a certificate can be used. This also includes any subdomains a certificate should be valid for, i.e. a certificate for example.com will not be automatically valid for foo.example.com but this subdomain must be explicitly specified as valid. Entries can also be wildcards. A proper implementation will no longer look at the common name at all if DNS names are given in the SAN section.


Why can't we copy password fields? On most websites, you cannot copy from a password field. Also, on most websites, if you inspect the password field (Google Chrome), you can easily view the contents of the field in the code.

If we can just view the contents of the field in the code, why can't we also copy from these fields? Why do websites not allow this?

Form input fields of type password don't show the contents, or allow copying. My assumption is so that someone else cannot press 'back' after your logout and read the copy the content out on a shared computer.


Can you resalt hash/rainbow tables after finding the salt for something? After a rainbow/hash table is salted, is it possible to resalt it after finding the correct salt instead of generating it all over again? If not, what is preventing you from doing so? How can you find the correct salt for something?

No.  Every hash would have to be recalculated, essentially reproducing the work that was needed to create the original rainbow table.

Hashing is basically a mathematical formula.  You have a formula (hashing algorithm) of X + 5 = Y, where X is the password and Y is the hash.  You use a rainbow table to store all possible values of X with their Y results.  If you change or add a salt then the formula is now different too (like X + 6 = Y).  So while the values of X wouldn't have changed the values for Y would all be different and need to be recalculated.

Typically the salt is stored alongside the password hash in a database and is not intended to be a secret (at least to those with password database access).  If it isn't stored there it is either stored elsewhere or is a known piece of information (username, system secret, SSID).  The source code of the software that validates logins will typically reveal how the salt is obtained.


Phones broadcast the SSIDs of all networks they have ever connected to. How can these be obtained by an attacker? I just watched an interesting talk from Glen Glenn Wilkinson titled: The Machines that Betrayed their Masters.

He said that your phone is constantly broadcasting all the SSIDs it has ever connected to. How would an attacker be able to capture these wifi requests?

Fairly easy to be honest, all you need is to do is listen for Probe Requests. There is a nice blog explaining how to go about setting up a computer with BT5 to listen for them here.

With a networking card that supports "Monitor mode", you are able to pick up so called "Probe requests". Once the networking card is set up to be in monitor mode you can use something like aircrack, wireshark or hoover to capture the probe requests.

For example when using ubuntu and wireshark, set the network card in monitor mode:

sudo ifconfig wlan0 down
sudo iwconfig wlan0 mode monitor
sudo ifconfig wlan0 up

Now start wireshark and set the filter for "wlan.fc.type_subtype eq 4".

That's it, now you can see all the SSIDs being probed for around you.


How to filter secure (HTTPS) websites by URL with regular expression? I need to block access to certain pages on a website using regular expression and/or wildcard. The site uses https and therefore cannot be blocked using regular parental control filters (this is because you can either block all https traffic or allow them but you cannot allow only certain URLs on a specific domain because the traffic is encrypted).

Is there any way to block specific URLs on a https site (with regex / wildcard) while allowing others?

Only intermediate entities (firewalls) can't see the https URLs, the remote server and your browser obviously can.

If it is a parental control system, maybe you don't need to defend against a highly sophisticated attack (here "highly sophisticated" == "can uninstall browser plugins").

There are numerous plugins for the task (example). Some of them has also a functionality to make its removal much harder.

Next to that, although you can't block an URL from an intermediate entity, but you can block whole sites. The name of the used virtualhost is visible, cleartext-transmitted since some years in the TLS protocol.


Is CSRF protection required for sensitive GET requests with CORS enabled? Based on other questions, it seems protecting GET resources with CSRF tokens is useless. However, that quickly becomes untrue when CORS gets thrown into the mix

I have a server domain server.com and a UI app at client.com. The server.com domain handles user auth and sets a session cookie under the server.com domain. It also has a rest-like endpoint that serves GET requests at /user_data and returns sensitive user data to users with a valid session. The 3rd party UI at client.com needs access to the user_data in an AJAX call, so CORS is enabled at the /user_data endpoint for the origin domain client.com via Access-Control-Allow-Origin.

The endpoint in question has no side effects, although it serves sensitive data to a 3rd party. Do I need to implement some CSRF token protection for the endpoint? Could the user_data be read by a compromised client.com webpage (via persistent XSS)? If so, can I use a query param mechanism of CSRF token exchange? The way I understand it, it's the only option, because the client.com cannot read csrf tokens stored in a server.com cookies. However OWASP guidelines state that:

  Make sure that the token is not leaked in the server logs, or in the URL.

If that's also a problem, how can I secure my application?

it seems protecting GET resources with CSRF tokens is useless.

It's not useless if you have state-changing GET request (which you shouldn't have, but it does happen).

  Do I need to implement some CSRF token protection for the endpoint?

No, requests which do not change state do not need CSRF protection (they may need proper authorization though).

  Could the user_data be read by a compromised client.com webpage (via persistent XSS)?

Yes, if you allow client.com to read data from server.com via CORS, then a compromised client.com can read that data as well.

  If so, can I use a query param mechanism of CSRF token exchange? The way I understand it, it's the only option, because the client.com cannot read csrf tokens stored in a server.com cookies.

No, CSRF protection wouldn't help. client.com can't read the cookie from server.com, but it can read anything on client.com. And you would need client.com to know the CSRF token to be able to send requests with it to server.com.

  how can I secure my application?

Do not let client.com be compromised. There's no other way to prevent client.com (compromised) from accessing data on server.com while also permitting client.com (not compromised) to access data on server.com because those two can't be distinguished.

  Make sure that the token is not leaked in the server logs, or in the URL.

You can send the token in a custom HTTP header to prevent this. But see above as to why it won't help if client.com is already compromised.


Using JTWs in OAuth Implementation I am currently building an api for an app to communicate with. The api endpoints will be protected, so I'd like to use an OAuth flow with JWTs for security. My flow will go something like this:

Receive and validate user credentials
Issue an access token (JWT) and refresh token for valid credentials
Verify integrity of access token then verify expiration

If expired - send a 401 and expect to receive a refresh token which will then be validated and a new access token will be issued
Else use user id claim to gather more context and continue on with request\

My questions:

JWT integrity: A Compact JWT is comprised of three parts - header, payload, and signature. The signature is verified by applying the alg specified in the header section to the base64url encoded header and payload sections separated by a '.' and then base64url encoding the produced value. Does this mean it is possible to create a phony access token? A stolen access token could be unencoded, user id stolen and inserted into a very similiar, but fake, access token. This fake token is then signed as a regular JWT is. When the server receives this access token, would this token not hold its integrity?
OAuth flow: Does this seem to be a proper flow? A user's refresh tokens will be stored in a database so they can be verified in the future (these will have a long lifetime). The access token will rely on its own integrity and the information contained within it since its lifetime is so short.

Does this seem to be a proper flow?

I don't see anything wrong with it. Take care with the word 'flow' though, it has specific meaning when talking about OAuth, and you're note using it in accordance with what "OAuth flow" means.

  Does this mean it is possible to create a phony access token?

In order to sign a JWT, you need to know a secret. JWT supports signatures either via HMAC (which requires a simple, pre-shared secret) or with public key cryptography [1]. All oauth providers I've worked with - most notably Google and Microsoft - use public key cryptography (RSA) to create the digital signature.

So, the attack you describe depends on the attacker having access to the private key of of the institution that signed the JWT. Access to the public key isn't enough; you can use this to check whether the signature is valid, but you can't use the public key to re-sign an altered token.

If the JWT in question used simple hmac instead of public key cryptography to create the signature, then both the signer and the party that needed the secret in order to check the signature would be in a position to correctly sign an altered JWT. But in that case, if the access token was stolen, the thief still wouldn't have the secret. I only see possible danger when the person the access token is intended for willfully changes it and resigns it using the shared secret. I'm not sure what the security implications of such an attack would be, but I guess this is why the big OAuth providers use public key cryptography.

[1] https://jwt.io/introduction/


How did the attackers use ccleaner in order to plant their malware? I recently read about the ccleaner attacks and without knowing anything about viruses/malware I'd like to know how the attackers managed to plant their malware.

Can somebody, with simple words explain how can somebody plant a malware in popular software like ccleaner without the company that produces it noticing?

As @schroeder said, Piriform/Avast haven't yet released details on how the software was backdoored. That said, we can still figure out how it might have occurred with a high level of certainty (that is to say, some guesswork and logic).

According to Avast's reports, they believe that the attacker behind the threat were highly advanced - that is - an Advanced Persistent Threat or APT. This sort of actor doesn't rely solely on publicly disclosed vulnerabilities but also have access to other sources for exploits - zero day exploits or even physical access.

Until Avast discloses just how the attack on their systems took place, the following are possible attack vectors through which they might've been compromised:

Exploitation of zero days on their infrastructure
Social engineering attacks on their developers - to get them to execute/backdoor their own code unknowingly.

In the light of their blog post that claims that the attack was an APT, I'm leaving out other possible vectors such as 'It was an inside job' - the target seems to have been much larger and it's unlikely to have been as small as this might otherwise imply.

So far, we've only looked at how someone might've broken into the production servers. But how about actually backdooring the code?

Well, once you've got access to a system, that part is definitely much easier. They could've smuggled in their backdoor through larger commits in internal systems (guessing here) where they'd have likely gone unnoticed once a developer signed off on the code, or they could have patched the binaries themselves on the update server after stealing the signing certificate (which seems more likely). Detecting these threats before they can do real damage is more difficult than it looks though.

I'll update this answer with more details as they come in, but for now, that's all we get as outsiders.


Ex-contractor published company source code and secrets online Just found my current company code on the plain internet.

We are talking hundreds of thousands of lines of scripts and configurations, including database schemas and a fair amount of internal information. Looks like an archive of some project(s), all concatenated into one file.

Didn't have time to go through everything yet. Quick search for exposed databases and credentials is hinting toward other files/functions that are missing.

This appear to be the personal website of a contractor who worked here 5 years ago.

Edit 1 hour later: Found sensitive information from every company that guy worked for in the last 2 decades, mostly F500: huge national bank, postal service, large electronics manufacturer, general electric...

Mix of code, configuration, notes and what appears to be console input logs. No idea why a guy would keylog himself let alone publish it on the internet, this is really odd.

It's a treasure trove. There are references to all kinds of internals with sometimes username and password. FTP access to production servers. SSH access to god knows what, even with the one-time RSA token number that was used if it was 2FA protected.

What can be done about that and who to contact? Cyber? Legal? FBI? SEC? Other? Any combination of these?

I am in the UK. The contractor is in the US.

First take screenshots of what you find.  For the data that is yours, you should catalogue that. Personally, I would download it so you have a reference.  You should take screenshots of your own data and avoid data that is not yours.  Make sure you include the URLs.  Document those in a way that a lawyer can understand.  This is likely to become a legal problem, not an IT problem. I say "screenshots" because that is unambiguous and lawyers understand screenshots.

Contact your internal lawyers, plus your communications or media people. You need to get this breach onto their radar.  The lawyers will then need to look into the commercial contract with the contractor, probably via the account management team if you work for a big old company.  No one in senior leadership will want to find out about it from everyone's favourite IDS: Twitter. Your comms / PR teams will need to deal with any messages that come about from this.  Your executive team may need to be involved.  You should get guidance from your CIO unless you are the CIO, in which case I would be inclined to inform people internally.

Engage with your company data protection officer.  That may be the lawyer.  They will decide if the breach is GDPR / ICO notifiable.  You have to do this quickly as you have 72 hours to make the decision from the point you are aware; that includes the weekend  (never go looking for incidents on a Friday…). Your DPO will advise.  If you are the DPO then you might want to engage your company external legal counsel to confirm your decisions.

Once you have looked at the data, you will be able to advice how many data subjects are affected, if any. You will also be able to determine if the data breach affects any of your clients as you may have a contractual obligation to inform them.

Contact the hosting company.  If it's something like GitHub then they may be inclined to play nicely.  You may need to get your lawyers to write to them as officers of the company.

Contact the contractor, ideally via their contracted company, and via the in-house lawyer. Demand they take down what is there.

Now you can start to work out the material impact to your business.  Credentials, keys and other authentication tokens will need to be changed I expect.

Depending on the size of your company, your appetite for risk, and your pocket size, you might want to consider bringing in a forensics-type company to go out hunting for similar data.  Yes I know it's a bit of security theatre, but if you work for a FTSE100 firm then a report with a Big4 audit badge saying "no more issues" is exactly what you need should the midden hit the windmill. (I am amazed at what I see big firms spend on such reports as, of course, the same thing from an internal person is often considered to count for little).

I am not sure about the data that is not yours.  If you start trying to engage with third parties then you are bound to be asked what data you have got from them and they are bound to ask you to confirm that any data you have taken has been deleted.  Personally I'd be inclined to ignore any data that is not mine.  You might want to make a disclosure to whomever you think is the data owner, entirely up to you.

You mention keylog; if you are wondering why an individual might have a keystroke logger on their own PC then well to be generous they might be using it as a simple backup of what they type.  I know people who have done that.

Aside: Finally as a tangential observation, what you have found is not that uncommon.  People store all kinds of junk; for example people link their home data storage to the internet via FTP: we run regular assessments for such data that contains our company strings.


DNS zone size overload? Is it possible to DOS DNS by creating custom dns zones with lots of text records in them so that the size of the DNS zone is in the order for example 100 Gigabyes, and then query all the dns records from the zone from the internet and thus possibly filling up the disk of dns caching servers?

Bind9 has a max-cache-size directive but isnt that for the whole server and only the memory?

I'll use BIND as the example server software here, for the obvious reason.

1) You can't fill up the disk of dns caching servers.  Cache is in memory, not on disk.  The only way the cache goes to disk is if the administrator goes in and triggers a dump to disk by hand (and that dumped version isn't used by the cache server, it's just there for the administrator to debug with).

2) You can DOS - or at least impact the performance of - caching DNS servers by filling up the cache.  Consider this post - granted, it's 10 years old, but BIND has always been remarkably predictive of BIND.

3) I'm not even sure AXFR gets cached, or that cacheing nameservers will handle AXFR queries.  For example, you can query this example domain directly:

$ dig axfr @ns12.zoneedit.com zonetransfer.me

; <<>> DiG 9.9.3-rpz2+rl.156.01-P2 <<>> axfr @ns12.zoneedit.com zonetransfer.me
; (1 server found)
;; global options: +cmd
zonetransfer.me.        7200    IN      SOA     ns16.zoneedit.com. soacontact.zoneedit.com. 2013064418 2400 360 1209600 300
zonetransfer.me.        7200    IN      NS      ns16.zoneedit.com.
zonetransfer.me.        7200    IN      NS      ns12.zoneedit.com.
zonetransfer.me.        7200    IN      A       217.147.180.162

However, you can't do the same using the well-known BBN caching nameservers as an intermediary.  Watch as the AXFR fails, but an NS query works fine:

$ dig axfr @4.2.2.1 zonetransfer.me
;; communications error to 4.2.2.1#53: end of file
$ dig ns @4.2.2.1 zonetransfer.me

; <<>> DiG 9.9.3-rpz2+rl.156.01-P2 <<>> ns @4.2.2.1 zonetransfer.me
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49741
...
;; ANSWER SECTION:
zonetransfer.me.        7200    IN      NS      ns16.zoneedit.com.
zonetransfer.me.        7200    IN      NS      ns12.zoneedit.com.

That being said, I couldn't find a good reference that would explain what BIND's caching server will or will not do, so it's hard to make a sweeping statement.

4) Bottom line: Sure, you could DOS a DNS server, but I'm not sure your "large AXFR" method is likely to do it.  And any such DOS would be temporary (in memory), not systemic.  A more likely method would be to create a ginormous number of A records with large TTLs and query them all individually.  (gowen's rule #022: By definition, any Service is susceptible to Denial of Service.)


Can you export a report from OWASP ZAP based off a individual website? I have a list of 30 websites I have scanned. I need to pull out a report for each individual website. Is it possible to do? Right now I am just running a report and getting the results for all 30 and it just comes out in a huge chunk of data I dont have time to sift through.

The ZAP reporting could definitely do with some improvements.
However you can access all of the alerts via the ZAP API in JSON and XML format.
If you enable the API (via the options) you can then access a URL like:

http://zap/JSON/core/view/alerts/?baseurl=http%3A%2F%2Fwww.example.com%2F&start=&count=

to get all of the alerts reported on www.example.com

FYI we do have a ZAP user group: http://groups.google.com/group/zaproxy-users which is also accessible via the ZAP 'online' menu.
That probably a better forum for ZAP specific questions :)


How do we mitigate the unpatched vulnerability "AtomBombing" code injection under Windows machines? Can the unpatched vulnerability called Atombombing bypass the security system's only by executing a malicious.exe program, or are there multiple ways to inject the malicious code?

What are the best practices to mitigate the unpatched vulnerability under Windows machines?

According to Securityweek, the code-injection vulnerability cannot be patched:

  The problem for users is that AtomBombing cannot be fixed -- it's the way Windows works. With no chance of a patch, the solution is some other form of mitigation.

As far as I can guess (not completely sure):

  Can the unpatched vulnerability called Atombombing bypass the security system's only by executing a malicious.exe program, or are there multiple ways to inject the malicious code?

First we must consider how Atom Bombing works:

It works by injecting some malicious code in the Windows Atom Tables. Atom tables are a kind of tables where any program can "save" some data strings to use later or to share with any other application.

So it gives any potential attacker the chance to use this method as a hijacking or privilege escalation vector, but not for a direct attack or intrusion.

Why? Well, unless another vulnerability/bug is used, Atom Tables can only be modified locally. That means: Only when you're already in, you can add something to the atom tables to inject malicious code.

So, there are multiple ways to exploit this vulnerability, BUT, when you're already IN (using a malicious.exe , exploiting another vulnerability to get into the system and then using Atombombing for privilege escalation, etc., etc.).

  What are the best practices to mitigate the unpatched vulnerability
  under Windows machines?

The only way for Microsoft team to patch this would be removing the Atom Tables, or adding many extra security measures.

The easiest way to defend against this kind of threat, is just checking any atom data saved before using it (on programs) and/or any security system/program/module taking a look constantly on those Atom Entries.

The way to fix this shall be by using a pìece of software that checks periodically the Atom Table entries, looking for malicious code. That's probably going to be added by some anti-malware (or antivirus) firms.

You can check those articles for more information:

To know more about the attack: http://blog.ensilo.com/atombombing-a-code-injection-that-bypasses-current-security-solutions
To know more about the Atom Tables "API": https://msdn.microsoft.com/es-es/library/windows/desktop/ms649053(v=vs.85).aspx


Can any Windows app install a kernel driver? if not, then how can Anti-Viruses install kernel drivers? Can any application install a kernel driver? if not, then how Windows decides who can and who cannot?
If AVs can install kernel drivers, considering they are an application with an installer just like the rest of apps, then what stops malware from installing a kernel driver and bypassing the protection of the AV?

On Windows your require local admin permissions to install drivers. I.e. either running as administrator or the user allowing via a UAC prompt.

If malware has that then yes it could install its own. This is why generally you should use a low privilege account and only offer admin passwords in prompts that are expected.


How browser parses the escape characters in Javascript (XSS)? I am new to XSS attacks. Recently, I was doing a project and found that one of my input field (website) is vulnerable to XSS attack. The value in website field is inserted into a href of an anchor tag which causes the XSS attack.

In order to check for various ways in which XSS attack can be performed, I referred a Github document where I found the below code,

\j\av\a\s\cr\i\pt\:\a\l\ert\(1\)

When the above code is inserted into the input field, the anchor tag becomes as follows:

Sample Code

On clicking the above link, an alert box pops up displaying 1

How is the above code parsed and run by the browser when the user clicks on it? I have read about escape sequences, but the above escape characters puts me in dilemma.

As @Jacco mentioned in his comment, the test snippet you used uses escape sequences.
In this situation, the backslash (\) is the escape character.  When a backslash is encountered, it means "the next character may have special meaning, if it does, use that special meaning instead".
However, not all backslash escape sequences are valid.  In those cases, the next character is used as-is.  For example, \j has no special meaning, so it is interpreted as a plain j instead.  However, \n (newlines), \r (carriage return), \v (vertical tab), and \t (horizontal tab) do have special meaning.  This is why you won't see backslashes before those characters in your test snippet.

In your case, I don't even think the backslashes are necessary.  They're merely there to attempt to circumvent any pattern based matching a detection engine might employ.  I imagine it wouldn't fool too many engines though, as it's a pretty common tactic and stands out like a sore thumb.

As for how the attack works, when a browser attempts to visit a URL with a JavaScript scheme (i.e. a URL starting with javascript:), it interprets everything after it as JavaScript code and runs it.


Conficker Anti-IDA packer I am looking for information about the packer used to pack the infamous Conficker virus. Unfortunately I wasn't able to find anything about the packer on the Internet. This packer seems to have used an anti-analysis technique that messed IDA's graphing algorithm, I was told that it is quite a funny site.
I would be grateful if someone that happens to have access to the packed executable was able to send me a copy.
An explanation of how it works would be gratefully accepted as well.

Thanks a million for any answer, this is my first post on this forum and I really liked what I've seen so far.

I'm afraid you'll have a hard time getting someone to directly post a link to a functional binary of malicious code here.

Fortinet's blog has a good explanantion of how to unpack whatever version of conficker you have.
Fortinet: unpacking conficker

This technique, with some modifications, will work well for most single-stage custom packers:

Run the binary under a debugger on an isolated machine
Set breakpoints on anti-debugging branches
Modify the registers so the code will run as if unobserved
Let the binary unpack itself and dump memory
Rebuild an executable from the de-obfuscated shellcode


Letting users pick up where they left off...without logging in (is this bad form?) I have a Grails app I'm working on that allows users to fill out a fairly lengthy application form. One of the requirements I've been given is to NOT require users to log in or create any sort of account. When they start filling out the app, I store their app ID in the session so it can be remembered from page to page. After one hour, the session expires. If they didn't finish the app, I send them an e-mail thanking them for considering us.

What I need to do is give users the ability to pick up where they left off so they can finish the application...again, without an account, without a username/login combination.

One way I thought to do this was to create a unique ID (like adbce-13428-etace-etc...) that is stored in the DB and maps to their application ID. I would then send them a link in the email that says "If you'd like to continue filling out your applicant, click the following link: myapp.com/continue/{their_unique_id}". When they click that, it looks up the unique ID in the database, gets their application ID, and puts the information back in the session so they can finish the application.

My question is: Is this bad form? Is it bad design? Is it bad for security? Why?

You could leverage local storage, but then you also risk exposing it a multi-user or public computer, or usability fail if the user uses multiple computers.

In your email solution, you could add a special code/token/password in addition to your identifier. So you have the identifier (UUID) and then a secret. You do still have an exposure if the email is compromised, but if the UUID is compromised from logs, packet capture, etc. without the secret access cannot be granted through the designed channel. You could put the secret as another parameter in the URL, but that is slightly less secure since it will be exposed whereever the URL is logged since its in the GET

eg.

  Hey, come on back to http://somesite.com?your_app=12345...... on the page enter the following code to continue XXXX

The application data and the secret should expire and be removed or unviewable from the user perspective after a period of time as well (secrets tend to become less secret over time).


What issues might exist with TLS-OBC's emulation of Browser Certificates? TLS-OBC is an RFC proposal that increases SSL/TLS security by using certificates on both ends of the TLS connection.  What's special here is that the client is permitted to dynamically create a local, self signed certificate.

It can also protect users from the "Related Domain Cookie Attack", more info here

Are there any known issues that would cause a problem with pre-existing Browser Certificate deployments and TLS-OBC?

TLS-OBC for System Administrators: http://www.browserauth.net/
TLS-OBC RFC: http://tools.ietf.org/html/draft-balfanz-tls-obc-01

(TLS-OBC is not yet a RFC, just a proposal, and, as all drafts, can be subject to change.)

As presented, TLS-OBC is an extension to the SSL/TLS protocol. There is a scheme for such extensions, which can be added at the end of the ClientHello and ServerHello messages. Nothing related to TLS-OBC happens unless the client and then the server agree to use them. Possibly, some very old and buggy servers could choke on the ClientHello from the client, but the same can be said of every other extension and it does not prevent browsers from using, for instance, the Server Name Indication. So no real issue there.

Possible issues that I see with this draft include:

When TLS-OBC is used, the server should not send a list of accepted CA, and the client MUST ignore them anyway. This means that a given server accepts either OBC-type certificates, or standard certificates, but not both. Moreover, the server must make this decision before knowing the target path, so it is a server-wide setting.
The OBC is remarkably efficient at tracking clients -- that's its point, really, when it is used as a "strengthening of the cookie". This implies the same kind of privacy issues than cookies. I suppose that browsers implementing TLS-OBC will provide the same kind of choice than with cookies (i.e. a way to deny OBC usage with some specific servers).
Contrary to normal client certificates, OBC do not prevent institutional Man-in-the-Middle attacks (when a proxy servers creates a fake server certificate on-the-fly -- this assumes that an accomplice CA is installed in the client trust store, which is a relatively common setup in some big organization which want to monitor their employees closely). The "attacker" (possibly a legitimate attacker, as a sysadmin) just has to substitute his own OBC.

Mostly, I do not see clearly in what way OBC really increases security.


' OR 1=1/* SQL Injection Login Bypass Question Recently I came across a SQL Injection Cheat Sheet which contains this particular cheat sheet which I am confused by ' or 1=1/*

Assuming I am testing it on this server-side code below.

SELECT * FROM users WHERE login='$login' AND password='$password';

Well I can't seem to bypass it with that cheat sheet. I am just curious why do they include it as a cheat sheet instead? How is that particular cheat sheet used?

What I am guessing and using my logic is there is only possibility of this cheat sheet usage is where the programmer mistakenly placed the ending comment tag */ behind the SQL query as shown in the server-side code below.

SELECT * FROM users WHERE login='' or 1=1/*' AND password='$password' */;

Feel free to explain the usage and also possibly verify my own understanding of this particular cheat sheet's usage instead.

Edited : For misunderstandings , what I meant for */ at the end of the code as mentioned if a programmer mistakenly put it is shown below.

SELECT * FROM users WHERE login='$login' AND password='$password' */;

There are a few considerations here, first is to explain how this is supposed to work:

SQL injections are a very old kind of hack that should not affect modern SQL implementations.  Back before you could use prepared statements, SQL queries were normally made using concatenated strings.  This meant that whatever your input was would become part of the executed sql like this:

$login = "John";
$password = "' OR 1=1 --";
$myIP = '555.555.555.555';
$sql = "SELECT * FROM users WHERE login='" . $login . "' AND password='" . $password . "' AND userip = '" . $myIP . "'";
echo $sql;

  OUTPUT: SELECT * FROM users WHERE login='John' AND password='' OR 1=1 -- AND userip = '555.555.555.555'

That first ' will close the string quote to keep the syntax valid.  Then, because 1 always equals 1, you create a select statement that is always true.  That means that you will select the user "John" allowing you to log in as him with no knowledge of his password.  Then -- is the SQL syntax to remark anything that comes after it.  This is used to eliminate any other conditions that might prevent your successful login such as IP validation or something of that nature.

The second thing here is the /*.  This will actually break a 1=1 injection because that is invalid transact SQL syntax.   That said, /* can be used in an execution level attack.  Many developers put too much trust in prepared statements. Just because it does not execute input at the SQL transaction does not mean it can't contain stuff that can be executed later.

For example, if you have an input box on a website, and you want to test to see if the site is vulnerable to JS-XSS attacks, you could input "<script> /*".  This means that when your program goes to take this from your database and run it, you'll execute a JavaScript that remarks the remainder of your page, then it will kill your program when you try to load the output of that information.

In short your source is mixing up remarking syntax for 2 different kinds of attacks, but they are both legitimate concerns given the right vulnerabilities.


Security review: "HTTP header user-agent has been set to (something)" We got a security review done of our PHP code and they team advised this in their report (amongst other things):

/appdir/

Details
The HTTP header user-agent has been set to \" .

Request
GET /appdir/ HTTP/1.0
Accept: */*
User-Agent: \"
Host: localhost
Cookie: PHPSESSID=08rtvlq03bd9d57qor4abjg7q4
Connection: Close
Pragma: no-cache

Response
HTTP/1.1 200 OK
Date: Sat, 18 Dec 2010 09:35:40 GMT
Server: Apache/2.2.14 (Win32) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l mod_autoindex_color PHP/5.3.1 mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.1
X-Powered-By: PHP/5.3.1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html

Does it matter that the HTTP header user-agent can be set to \" ?

I dont see how inserting an escaped quotation mark into the user-agent string is a vulnerability.

I'm not certain that this is the case, I think more information is necessary.
The ONLY thing I can think of is that they're possibly exposing a potential for a session hijack.

Basically, PHPSESSID=08rtvlq03bd9d57qor4abjg7q4 belongs to a different user's session, they are spoofing this session ID via a cookie, and are getting a normal response, even though the user-agent has changed from the original user.

Clarification:

User A opens the website, using the following User-Agent string:

Mozilla Compatible (MSIE)

User A is then assigned the following session ID:

08rtvlq03bd9d57qor4abjg7q4

User B (bad guy) then sends a request to the server using a cookie with the same session ID in his/her cookie, however their User-Agent string is:

\"

Your application should then realize this is not the same user, and destroy the session.

I am by no means certain this is the situation, nor would monitoring the user-agent prevent a session hijack, as user-agents are EASILY spoofed, but this is the only potential I see here.