How can I protect my PHP app against XSS? I am upgrading the security of an existing site (so can't redo everything with a framework that has xss functions built in), so I am looking for a way to protect against XSS attacks such as the ones listed by OWASP here.

At the moment I use htmlspecialchars($text, ENT_QUOTES, 'UTF-8'); for output into HTML, json_encode for JS and HTMLPurifier for data containing HTML tags but am concerned this is not enough/correct.  I am looking for a function that I can use like:

<?php echo escape_for_html($text); ?>

<img src="<?php echo escape_for_attribute($text); ?>">

After some research it seems solutions like xss_clean, ESAPI and PHPSEC are either no longer being maintained or not recommended.  How can I protect against xss when echoing into tag attributes (including urls), JavaScript and CSS?

Apart from other mitigation techniques, do consider using Content-Security-Policy (CSP) to prevent against XSS vulnerabilities.

CSP

  Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS) : Wikipedia

It white-lists the domains from which a resource can be loaded. (resource could be : js, css, image etc)
You can add this policy in the response header, and browser will enforce it during any attempt to load resources.
It also comes with report-only mode, which can be used to evaluate the current state of your application before enforcing it.

A sample policy looks like :

Content-Security-Policy: script-src 'self' https://abc.com

With above policy, it will only allow to download javascript from page's current origin and abc.com. Any attempt to download from other source will cause an error like below in browser console :

Refused to load the script 'http://evil.com/evil.js' because it violates the following Content Security Policy directive : "script-src 'self' https://abc.com".

Do note that it's only supported by major browsers; like : Chrome, Edge, etc.
Similar restrictions can be applied to other resources as well.
For further reading, here is an awesome article explaining everything you need to know about CSP : https://www.html5rocks.com/en/tutorials/security/content-security-policy/


Cloud provider or self-hosted for key-storage? I was reading this question: Where do you store your personal private GPG key?

I have my set up as noted in this comment: Where do you store your personal private GPG key?

But instead of using a cloud provider I use my own, self hosted cloud-like syncing service.

I notice some downsides right away:

my keys are still only as good as my password protecting my key container
the uptime and service guarantee of my sync is only as good as I can provide it (no high-availability for example, as of right now. But it hasn't failed me (yet)).

But the major question I'm asking myself, since reading that everyone seems to be putting their keys in some form (QR code, container, encrypted, split in various parts, etc.) on some cloud provider:

Should I be using a cloud provider or my own self-hosted service?

Benefits are clear for self-hosted:

Only indirect access by anyone vs cloud provider might be able to access my files without problems
My own little server somewhere on the web is less likely to be focus-targeted by malicious actions than a cloud provider

The downsides are:

My self-hosted might certainly lack behind on updates from time to time (like when I'm busy with a hard week at work and I'm lacking on installing potentially important security updates)
I cannot provide the same activity-/request-/any monitoring as a large provider can to notice when malicious actions happen and take action

So what do you say? Put my key-store on a cloud provider (some AWS, Google Drive, OneDrive, Host it in a private github, etc.)? Or keep it on my self-hosted?

Unsure whether it is or not relevant, but IMHO the most secure server for an internet based thread is an offline server.

If it is possible for your use case, I would keep the syncing service offline most of the time to reduce the possible attack times, and then put it online only when I would need to sync something, if possible after ensuring that all security patches have been applied. An alternative way would be to only use a limited access private network, but this is often a dead end way.


What's the importance of sshd's setting RekeyLimit? man sshd_config page states:

RekeyLimit
Specifies the maximum amount of data that may be transmitted  before the session key is renegotiated, optionally followed a  maximum amount of time that may pass before the session key is  renegotiated. [...] The default value for RekeyLimit is "default none", which means that rekeying is performed after the cipher's default amount of data has been sent or received and no time based rekeying is done.  This option applies to protocol version 2 only.

Let's suppose I have a very long-running (days/weeks) connection, with gigabytes transferred to and fro. Will it make any difference in the level of protection against mid-level threats if I set the value to anything other than the default of no time-based rekeying?
Will this setting prevent any unusual attacks or, inversely, present an attacker with unique opportunities? Does it matter what ciphers and cipher modes are employed (CBC vs CTR vs OpenSSH's GCM implementation)?

The idea behind rekeying is that session keys may be susceptible to some unspecified attack, such as direct cryptanalysis or side-channel attack. A common theme in most attacks is that they require the analysis of a large amount of encrypted data to execute. By limiting the amount of data transmitted with a single session key, you can effectively thwart a large portion of attacks against your encryption keys, whatever those attacks may be.

The cipher and chaining method you use does have an affect the type and effectiveness of attack an adversary might deploy. But the defense of rotating your session key after a few GB is a reasonably effective mitigation strategy.


How far should I go in protecting a user's SMBIOS UUID? My server will be receiving data from several hundreds of computers. As part of keeping track of which computer sent what, I will be fingerprinting the hardware and keeping the results in my database.

Nowadays the most sensible source to use for that is the SMBIOS UUID. These 128 bit numbers are set by motherboard manufacturer and are supposed to be unique, but not so much unpredictable. For example, the last part often contains the MAC address of the onboard NIC, and several bits of those are manufacturer specific.

Because I don't gain much by knowing the exact UUID, I'm fine with using a hash. That would already introduce some privacy. However, since (without further measures) hashes can be calculated quickly, and those UUIDs do not actually provide 128 bit of entropy, I suppose it would be feasible to trace the hash back to some UUID.

Would it be worth introducing a more expensive hash function to prevent the above, in case my server would be compromised? I don't think I would be able to use salt with it, because I can't store the salt in the hardware and the data is supposed to come in already hashed (not to ever communicate the actual UUID). On the server I should be able to group data coming from the same source. How useful could it be to know the UUID of some computer, that you might also know belongs to a particular company or individual?

The derived ID to be used needs to survive reinstalls of the system, so a purely software-based alternative won't do. Introducing custom hardware (e.g. hardware key/dongle) is not an option. Other ideas I've had, of which I'm not sure how good they are:

Deliberately shortening the hash to the point that is still unlikely to encounter the same hash more than once for a single user (so I'll still be able to distinguish their systems) while no longer preserving enough entropy to be reversible - I'm not sure what the appropriate length would be and how much of an improvement it is if instead of an actual UUID, one could establish a rather limit set of potential UUIDs
Adding a little bit extra hardware to the hash, at the cost of it becoming more likely to change, but increasing the entropy of the source somewhat

You can at least add application specific salt (hard-coded in the app), so building a rainbow table just for your small database is not worth it.
You can use a slower hash function (pre-compute the hash only once per app start).
Adding more entropy if possible for your application would help greatly.
If at all possible, do not associate the hashes with identifiable information, or make the association hard, for example requiring the user password to decrypt his UID hash. (for more suggestions, we would need to know more about what you need it for)

Shortening the hash may help in some cases but could be detrimental in other. IMHO it would not do much in a situation where the UID is associated with other information such as IP, or Name/Company.


Is it safe (or a good idea) to advertise the use of bcrypt? So, our database is using bcrypt with a high iteration/cost to store our users passwords. We're using https like intelligent people and we continue to work on finding ways to sidestep our own security before someone else does.

With that said, we are beginning a new marketing push with a new interface and the marketing guys are wondering if we can/should/should not use the use of bcrypt as a selling point on our features page.

It seems there are so many large organizations out there that DO NOT use secure password hashing methods and even if it is kind of sad, using something like bcrypt seems like a differentiator.

So, the question that I want to ask is if advertising our use of bcrypt will paint a target on our back. I see "we use https" advertised often, but I don't see anything mentioned about password storage policies.

I don't need to know if it's a good marketing tactic, what I want to know is if its going to expose us to more danger if we do advertise the use of bcrypt.

Thanks for your thoughts.

The usual argument goes that way: if it is not safe to describe what algorithms you use, then you have a bigger problem. Therefore, you should be able to announce to the World that you use bcrypt with no ill effect on security. In fact we must assume that the attacker already knows that you use bcrypt (if he is in position to do harm, then he can probably see your code; also, bcrypt output from usual bcrypt implementations has a quite recognizable format).

Knowing whether it is a good idea, from a marketing point of view, to turn bcrypt usage into a sales pitch is another matter. Personally, I think that saying "we use HTTPS and all passwords are stored hashed with bcrypt" will do no harm over the simpler "we use HTTPS". I cannot claim that it would do good. Also, there is such a thing as going too technical, in that you might inadvertently show yourself as "a bunch of geeks" which may or may not appeal to your intended customer crowd. This all depends on the kind of image that you want to project, and the average psychological profile of expected site users.


Managing SSH key access to AWS servers behind bastion I currently have an AWS setup with 3 VPCs, one for the bastion, then a Dev and a Prod VPC, those last two only being SSH accessible via the bastion of course (layout from this great guide). I'm looking for the best way to manage having between 3-5 users access the systems. Long term I hope to have automation and external logging to a place where nobody has to SSH in, but for now, SSH it is.

After reading over ideas from this question on ssh key management I am thinking about setting up my AWS access as follows:

2 accounts on bastion, sudoable@bastion and non-sudoable@bastion. sysadmins go through one, devs through the other. (devs have no reason to do anything but pass through the bastion)
the authorized_keys file in each bastion account holds the public key of the sysadmins or devs, respectively
Dev/Prod VPC instances each have a single, sudoable account: it@devVPC and it@prodVPC.
Devs get the private key for instances at it@devVPC, sysadmins get the private key for both VPCs instances.
If someone joins/leaves the company, their pubkey is added/removed from the correct authorized_keys file on the bastion.
Since the devVPC/prodVPC instances are behind the bastion, even though the worker who left may still have the private key to those servers, there is no way to access them since the bastion won't allow them through

I think this should keep me from having to manage individual useradd/userdel accounts on each instance. Without getting into LDAP and things I wouldn't want long term anyway (again, hopefully nobody needs to SSH into AWS servers in the future), does this seem like a legitimate/secure setup for a small team?

I haven't used it but I've also seen AWS OpsWorks mentioned as a method for controlling SSH keys? Does my situation sound like a good use case for it?

There is one big hole in this, which is that it is difficult to prove who did what action with shared accounts. Not impossible, just more difficult. In addition, the shared private key is a bad idea from a defense in depth strategy. You can solve both problems by managing the accounts individually, which creates greater management overhead, but it shouldn't be significant with just 5ish users.

I can't comment in depth on the opsworks idea, I haven't used it. Based on a quick read of the document you provided, it really just looks like it sets up accounts on your instances and then the authorized_keys file, which is a pretty small task. You also have to then spend the time setting all your users up with AWS IAM accounts, which doesn't seem like a good tradeoff.


Is it possible to put malware in an audio file with steganography? I have recently read  malware being hidden in a "usable" picture file with stenography such as this forum,
https://www.bleepingcomputer.com/forums/t/574487/is-it-possible-for-a-virus-to-be-embedded-in-a-image/ .

Could a malicious hacker use similar methods on an audio file?

There are similar questions on various sites about malware in an audio such as this,
https://forums.malwarebytes.com/topic/140812-can-an-mp3-file-contain-malware/,
but my question is specifically related to the tactic of steganography.

Transmitting any data inside a playable audio file is already steganography by definition. Humans don't normally inspect the bytes inside an audio file, so any data placed in it that evades detection under normal use is hidden, regardless of whether you classify it as malware.

Other common malware techniques used to evade detection, such as polymorphism and encryption, may contribute to the masking of the hidden data but aren't necessarily steganography.

I don't know if you'd consider it steganography if the data were simply placed in an ID3 tag in an MP3 file, because those tags exist for a human to view and use (with suitable tools, of course.) But if the bulk of the malicious data was encoded in the music itself (like some of the audio watermarking technologies), that would certainly qualify as steganography as I understand it.

For that matter, the data could be hidden steganographically in the embedded JPG image of the album cover, and that would fit pretty much every definition out there.


How are digital certificates compared? I have read about SSL and TLS; I know how RSA works and why digital certificates are necessary (more or less), but I am curious about how we prevent a fake digital certificate.

The operating system comes with some certificates pre-installed, but how can we be certain that the certificates have not been changed in our computer by a virus? If a virus changed the local certificates, and I access a website that sends me a fake digital certificate that matches the fake one on my computer, what will happen?

I may be confused about how this works. I would appreciate a detailed explanation.

Certificates are signed and the cryptographic signature is verified; if the signature matches then the certificate contents are exactly as they were when the certificate was signed. This, of course, does not solve the problem, it merely moves it around. The complete structure is called a PKI. The certificates which are preinstalled in your computer (came with the OS or the browser) are the root CA certificates, i.e. the public keys that you know "a priori" and from which you begin all the signature verification process.

To make the story short, if some hostile entity could insert a rogue root CA in your computer, then you lose. Of course, under the same conditions, the same hostile attacker (e.g. a virus) could alter the code of the browser and hijack your data from that, or log all your key strokes, or more generally completely bamboozle you in a zillion ways. When a virus executes on your computer, you are already beyond redemption.

Inserting a fake root CA is, in fact, a rather poor way to attack people, because they may notice it. Injecting a data snooper right inside the entrails of the browser does not require much additional effort, can be done within the same conditions, and results in a much more complete and discreet destruction of your security.


Network intrusion security warning in router logs I found this in the logs of my router

Intrusion -> SRC=198.20.70.114 DST=(here was my own ip) LEN=44 TOS=0x00 PREC=0x00 TTL=111 ID=43361 PROTO=TCP SPT=1940 DPT=49152 WINDOW=34917 RES=0x00 SYNURGP=0

I went to check IP geolocation to see if it's just my own IP or something and here is the result https://gyazo.com/9edf54b3e052a43316c2f8bdaaa75b5b

What is this? I live in Finland and I got this warning of intrusion from Chicago? The weird thing is, as I noticed this when I was just exploring the logs and found this, it got removed like 5 mins after I saw it? Sometimes my ping went to 600-700 when I was not doing anything on my internet except playing a game that shows ping, and I was home alone, not downloading anything. Is someone using my internet?

Should I be worried about this?

Also there is something like this CWMP:Cwmp post inform success.

IPPing diagnostic is complete.

CWMP inform message: event: 8 DIAGNOSTICS COMPLETE.

CWMP:Cwmp post inform success.

User ACS(195.197.95.135) modify IPPingDiagnostics.Host,IPPingDiagnostics.NumberOfRepetitions,IPPingDiagnostics.Timeout,IPPingDiagnostics.DataBlockSize,IPPingDiagnostics.DiagnosticsState

Detect UDP port scan attack, scan packet from 192.168.100.14.

This can be just something like a system inside your network doing auto-update. You already have the clue.

PROTO=TCP SPT=1940 DPT=49152

Searching source port will give you the agent which is jetVision client.

http://www.adminsub.net/tcp-udp-port-finder/1940

If still you really feel that it is some form of intrusion or its not the jetVision client then try to isolate this source agent to identify where its from your home network by doing the following.

Isolate your router, disconnect all devices to your router and see if this intrusion log is still reflecting. If there is then your router is the culprit, check manuals for any references to this source port.
If the intrusion log is no longer reflecting after you disconnect all devices to your router, then connect one device at a time and check for the intrusion log again.
At the end congrats yourself, you just did a forensic investigation.


How to determine risk ratings for third party mobile apps Having rolled out corporate mobile phones and tablets, we have MDM in place enabling us to centrally deploy apps to all our users, and can perform remote wipe in the event of a lost device etc, however in order for the device to be of any real use to users they also need to be able to install apps at their own discretion. While we can monitor which apps are installed using the MDM software, we have no real way of identifying which apps if any present a potential high risk to our corporate data.

For most apps it is very difficult to ascertain:

Whether any data is stored remotely 'in the cloud' on a server administered by the app vendor, or whether all data is stored on the device itself;
Whether any data sent/received is transmitted securely between the device and any remote locations using a known secure implementation of SSL;
The geographic locations and hosting companies where any data is stored or processed remotely, along with any known reputations of data security, local leglistation, active enforcement etc;
Whether the app really has been published by the company it says it has been;
Which company the source code has been written by, and what their reputation is for secure development and testing?
Whether any third party security companies have already analysed the app and given it a particular rating or review?

The attack surface very much becomes a big unknown when we allow users to use mobile apps and app publishers very rarely divulge this kind of information.

To give one example, we have identified a business card scanning app stores its data on servers in the Middle East, which is outside the EU, making use of it in certain circumstances illegal under British data protection law, and if used for business contacts, it could be used for competitive intelligence by authorities in that region where different laws apply.

While its often not legal to reverse engineer software, I can't believe anyone really has time to do this for every app they come across, so there must be a realistic approach that's not based solely on guesswork.

Does anyone know of any hosted services or apps that provide any kind of app assurance checking for third party apps, or a searchable database with this kind of information? While we wish to embrace technology and use the great apps out there for genuine business purposes, we need to ensure we're doing so within the boundaries of the law, contractual compliance etc. How do other information security professionals approach this issue?

In my department, I am involved in mobile device security, and have looked into a product that does just what you're looking for.

The product that I am familiar with is FireEye Mobile Threat Prevention.
https://www.fireeye.com/products/mobile-threat-protection-mobile-security-products.html

I have experienced some of the capabilities of this threat prevention system. It has the capability to scan apps installed on your MDM managed devices and will give the apps a "FireEye Threat Score."

This score is the result of analyzing how the application works on the mobile device, how secure the mobile device encryption, etc. It really does a good job of describing what vulnerabilities are present on any given app in your environment.

This is not only applicable for apps that have been scanned and indexed, it will scan new apps that might be specific to your organization and give you a threat rating.

We tested this product on an app that we were considering implementing, and the report gave us a 5 page report on the following information about the app:

Application Code (Detailed information about weaknesses were present in the application code)
System (Information about how the app interacts with the phone OS)
Phone (Information related to what phone functions the app needs to access)
Location (Info about what location services the app uses)
Settings (Settings on the phone that the app can change)
Internet (internet settings or calls the app makes)
Personal data (personal data that the app might contain)
File System (Changes to the phone file system that this app makes)


References to issues of putting backdors into opensource (like OpenBSD) by FBI or CIA There are articles on the Internet (e.g. this) that claim that the FBI/CIA injected security backdoors into OpenBSD.

I'd like to know if there are any other references to this issue. This would help in my Thesis addressing this or similar issues.

Could you recommend reliable resources, preferably academic papers?

(BibTex compatible is preferable)

The closest thing I've seen to what you're asking (and it has nothing to do with state-sponsorship) is this speech by Ken Thompson during his Turing Award Lecture. It basically asks the question, if the gcc compiler was at one point poisoned to produce compilers which produced backdoor-ed code, and then the was used to compile gcc for a number of major distros and subsequently the code was destroyed, would we ever know?>

This is more a thought experiment on what could potentially happen if someone were to attack systems high enough up the stack. Interesting concept, there are ways to automate the output of a compiler to ensure that it's sane (assuming your tools were compiled with a good compiler...) but as far as I know they are not implemented on any of the major open-source projects.


Hacking demonstration We are thinking about giving an awareness live demonstration in the company I work for. The general idea is to show the users how can they be hacked while connected to a public wifi spot such as a coffee shop, conference, etc.
We have thought about:

Using a rogue AP
ARP spoofing
DNS cache poisoning

Can anyone suggest other attacks/ways of better tacking this demonstration? We want the users to better understand the impact of connecting both personal and corporate devices to public/unknown networks.

In practical terms there are three threats I'd be worried about:

Passive monitoring by network owner/other users on the network
Direct exploitation by network owner/other users on the network
Active man-in-the-middle attacks such as Karma and sslstrip

If you haven't already, I'd recommend simply adding Wireshark to your demonstration, and showing a capture of someone logging into a website over HTTP (if you can find one, or create one). This will show how trivial it is to sniff sensitive information from a shared network if the connection isn't encrypted.

For threats #1 and #3 above, a good trusted VPN service (e.g.Encrypt.me or NordVPN) will mitigate these risks. For #2, keep your devices and applications up-to-date.

However... I'd argue that there is a bit too much hysteria about the risk of using public WiFi.

Most of the legitimate concern about public WiFi began because of #3, particularly before HSTS became a thing. Back then it was possible to use sslstrip against major banking sites and other valuable services (Google, Facebook), and the only real mitigation was "don't join non-password-protected WiFi networks", or to use a trusted VPN at all times. Now that HSTS is available this is much less of a problem (for those sites which support it), although it's still a good idea to use a trusted VPN if you're worried about local MITM attacks of this sort.

For most users, #1 is a non-issue as the services they're worried about would be using HTTPS. The major exception is that DNS requests are still in-the-clear in most cases (users might not want someone on their network knowing that they're making DNS requests for pornhub.com). A trusted VPN will solve this problem.

Direct explotiation (#2) is also a non-issue for most users unless they're using very outdated software (i.e. running unpatched Windows 7 or an obsolete Android device), or unless their threat model includes attackers with 0-day remote code exec exploits (if this is the case, they likely have bigger problems than connecting to public WiFi).


Can one iOS app read the data of another iOS app maliciously? I'm writing an iOS app that will store some information. Though not too confidential, I'd like to prevent other apps from reading the data, since a malicious app can then "phone home". If the user has jailbroken their phone, that would be their decision, so too if they will give someone else the device so the other person can use the app and see the data. My question is only about preventing a malicious app from reading the data and sending it to its creators.

I'm planning on saving the data in the cache folder. Does that make a difference?

No. All third-party iOS applications must have a sandbox, and the sandbox prevents direct access to any other app's data. Two apps from the same publisher can create a shared location that both can access, but even then, any data stored in an app's own directories is never exposed to other apps. Apps can also push data to one another, but there is no way for one app to force another to send it data unless the developer of the sending app explicitly creates one.

From Apple's File System Overview doc:

  For security purposes, an iOS app’s interactions with the file system are limited to the directories inside the app’s sandbox directory. During installation of a new app, the installer creates a number of container directories for the app inside the sandbox directory. Each container directory has a specific role. The bundle container directory holds the app’s bundle, whereas the data container directory holds data for both the app and the user. The data container directory is further divided into a number of subdirectories that the app can use to sort and organize its data. The app may also request access to additional container directories—for example, the iCloud container—at runtime.

The Library/Caches directory for an app has the same privileges as any other app-specific folder. Its main distinction is that its contents are considered to not need backing up or to be disastrous if lost, though they are less ephemeral than temp data (which may be purged automatically while the app is not running). As such, files in the Caches directory are not synced to iCloud. You can also use the "do not back up" attribute for a file in any directory that should not be synced.


What happens inside of a DDoS Scrubbing Center? I understand, that traffic is redirected to a scrubbing center during a DDoS to differentiate between malicious and legitimate traffic as has been explained in  this post. However, from a technical point of view scrubbing centers seem like a black box to me.

What is really going on at a scrubbing center? Which methods are used and are there any statistics on the efficiency?

At the scrubbing center there are multiple layers of protection through routers, different mitigation appliances and use of high capacity bandwidth links that distribute the traffic. The difference is, upon attack, this traffic is analyzed remotely. Generally this involves the victim to route their traffic via a BGP announcement to the mitigation service provider, requiring an ASN or making a DNS change to point the attacked domain to an IP address within the mitigation provider's network. Either method should require some baselining of normal traffic to help generate a profile and reduce collateral damage. Before choosing a provider, one should request a "stress test" to confirm the provider's mitigation abilities.


Message telling me that I bought something with credit card I just received a message via SMS that I bought something from an online shop with my credit card. The message reads like this (translated from German):

  Your credit card purchase - please check: - shop lampe.de: - amount
  86,58 currency EUR - TAN 716500. Questions: 0721/1209-66001 selection
  3.

Original Message:

  Ihr Einkauf mit Kreditkarte - bitte pruefen: - Haendler lampe.de:
  - Betrag 86,58 Währung EUR - TAN 716500. Bei Fragen: 0721/1209-66001 Auswahl 3.

Notes:

I recently changed my mobile number and did not yet provide it at any of my credit card service providers
The given telephone number is valid (belongs to a big popular German bank)
The given online shop is valid (https://www.lampe.de/)
I once received another short message from a delivery service which raises the assumption that the previous owner of my newly acquired telephone number has still some services configured to use that one

Is this a fraud? If yes, how do I react?

Chances are this is scam attempting to get you to call the number listed (which does probably not, as you think, belong to any real banking institution but is most surely heavily taxed).

If you have any doubt, your best option is to call your credit card company - the relevant number must be printed on your card - and ask them about it: they can verify what transaction was made with your CC and you might be able to dispute the charge right away.


Best practice for selective opening of ports on network gateway Our network is currently isolated from the outside by a Linux box, running iptables and Squid to control web access.

By default we deny all outgoing traffic from all IP's, to force Web traffic through the proxy, and deny the rest. However, we need to allow FTP for some users but not all.

The previous admin used to manually add corresponding entries for those that are allowed to FTP in the routing table, however, as we get more and more requests for people to FTP out of the network, I was wondering if it wouldn't be easier to force FTP traffic through the proxy, and manage users that are allowed to FTP out through the proxy's ACLs ?

Would it be considered less secure than manually managing allowed IP's (which in my opinion is plain stupid since the old admin regularly forgot to remove the appropriate routes when people left the company and IP's were reassigner...) ?

If the proxy is good enough for your HTTP traffic, then it should be good enough for your FTP traffic.

In theory making a system easier to administer shouldn't make it more secure, since you should be doing the existing, horrible admin tasks properly. But as you point out, in the real world, the easier it is to stay in policy the more likely you are to stay in policy.

(One minor caveat: while every web browser is really easy to set up to use a proxy server, I've found some ftp clients to be a lot fiddlier.)


How does Team Viewer establish a Remote Desktop Connection? I am wondering how is it possible for Team Viewer to establish the remote desktop connection over the internet even if the user has not enabled the 3389 port ?

I am searching over the internet but didn't find the satisfied answer to my question ? How does it even possible to establish RDP over the internet since it is only possible across the network ?

Does Team Viewer use Reverse Connection technique ?
Is it possible to establish the RDP connection with someone who is outside the network ?

To elaborate on ewanm89's post, TeamViewer does use UDP pinholeing.

UDP is a stateless protocol. This means packets are fired off at their target with no verification (at the protocol level) that they were received or even reached the destination. Firewalls are designed to look for UDP packets and record the source and destination as well as the timestamp. If they see an inbound packet that matches an outbound packet they will generally allow the packet through even without a specific rule being placed in the firewall's access list. This can be locked down on enterprise grade devices, but in general 90% of the firewalls out there will allow return traffic.

In order to pin hole your machine (viewer) has a TCP connection back to the main TeamViewer server. The target machine (client) also has a TCP connection to the main TeamViewer Server. When you hit connect your machine tells the main server its intention. The main server then gives you the IP address of the client machine. Your machine then begins firing UDP packets at the client. The client is signaled that you intend to connect and is given your IP. The client also starts firing UDP packets at you.

If the firewalls are "P2P-friendly", this causes both firewalls (yours and the client's) to allow the traffic, thus "punching holes" in the firewall. Specifically, this requires the firewalls to not change the public port of an outbound packet merely because its destination has changed; the firewall must reuse the same public port as long as the source of the packet hasn't changed. If your firewalls don't behave in such a friendly manner, then this won't work. Many firewalls do behave this way, though.

Of course TeamViewer adds some security by doing a pin/password check before the main server sends the IP info to both parties but you get the idea.


File authentifications via PGP versus via unique file hashes Many files that are available for download (eg in github) come along with "asc" signature files attached, or with a sha256 file hash. Can someone please explain difference of PGP signatures vs file hashes?

My questions:

Is the purpose of both files (pgp/256hash) the same, to verify file authenticity/not manipulated?
When a downloaded file's hash/pgp does not match the hash/pgp provided by the responsible developer, does it mean that only you downloaded that corrupt file? Or does it mean that everyone who downloads that file receives the corrupt file version?  What I am getting at: Can the download process be pre-programmed by an attacker which download gets the corrupt and which one the correct file?
Which method is technically better suited for what situation?
Any technical "flaws" you are aware of for either of both verification methods? Why use pgp, is file 256hash not enough to verify file integrity?

If an attacker can manipulate the file you download, surely they can also manipulate the text file with SHA256 checksums. Unless they have access to the PGP key, they cannot create a valid PGP signature for any file or message, and so a signed message which contains the SHA256 checksums or a valid detached signature for a file is guaranteed to be written by a person who is in possession of the key and who vouches for the authenticity of the signed content.

A cryptographic signature is tied to the contents it signed as well as to the signing key, and will no longer be valid if the contents are changed.

When this happens, you can't know the reason off hand -- it could be that the file or message has been tampered with, or it could be an innocuous bit flip because you downloaded it over an unreliable connection. But in this scenario, you do know that the file's or messages integrity has been compromised, and can no longer be trusted.

Users who are not in possession of PGP or who don't want to spend the time on validating a signature can only get a much weaker integrity check, but making sure the SHA256 of a downloaded file is identical to what's communicated in a different place at least guarantees that both sources agree.  This -- for many users, much cheaper -- guarantee is enough to validate that the download isn't corrupted, for example.

(You could argue that as long as some users check the signature, and will probably raise hell if it fails, this should be sufficient as a mechanism for "herd immunity"; but obviously, unless you have a good indicator that this is in fact the case, it is basically just speculation.)


Malware not showing up in virus scan I have some malware on my computer at work that I'm having a hard time getting rid of. I'm only interning there over the summer, so I'm guessing that it was downloaded by the previous user because I noticed it as soon as I opened my web browser for the first time. Whenever I'm using a web browser (this occurs on all web browsers that I've used including IE, Firefox, and Chrome), the same ad appears on every website I go to (even on sites where there should not be ads). This ad obstructs either the bottom left or bottom right portion of every page I visit and also installs unwanted cookies. I ended up using adblock to manually block out the ads; however, what troubles me more is that every once in a while when I click on a link I get redirected to a website I never intended to go to. It's quite frustrating when I'm trying to get to an important page and instead I end up at an auto glass website or some advertisement saying I've won a prize.

I have tried remove the adware using multiple antivirus softwares including Windows Defender and Malwarebytes, but none of them seem to be spotting the the virus. Is there something I can do to remove this? I've put up with it for a few weeks now, and it's gotten very frustrating.

Does your company have an IT team? If so the best thing to do is get them to do it or you could risk losing your internship. If not the next best thing if possible is to do a clean install of the operating system. If that's not possible try this out:

From a clean machine download the latest MalwareBytes and
AVG and CCleaner and put those installers on a thumbdrive
Boot the infected machine into safe mode. This is usually accomplished by pressing F5 while the machine is booting.
I usually run CCleaner then MalwareBytes then AVG but I don't think the order matters just run them and get all of the crud off of there.
After that boot into windows normally, if there are any definition updates for malwarebytes or avg download them.
Run all 3 again.

When you boot into safe mode windows will only load what's necessary to run, more likely than not the malware won't start in safe mode. You may also want to check the below registry keys. If any of the entries have a * next to the name it will start in safe mode. However I would caution you to stay away from the registry if you don't know what you're doing because you could really mess stuff up in there and in 90% of cases I have dealt with the malware doesn't start in safemode.

•HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
•HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
•HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
•HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

If you're STILL getting those ads look at the url and place an entry in your hosts file to send that url to 127.0.0.1. Here are directions on how to edit your hosts file.

Hope this helps and good luck!


How can PayPal spoof emails so easily to say it comes from someone else? When I receive a payment in PayPal, it sends me an email about it (pictured below). The problem is that the email is shown to be coming from the money sender's email address and not from PayPal itself, even though the real sender is PayPal.

Here is the text that appears when I select "show original" in Gmail:

From: "contact@wxxxxxxxxx.com" <contact@wxxxxxxxxx.com>
Sender: sendmail@paypal.com

So you can see that the real sender is PayPal.

If PayPal can spoof the email sender so easily, and Gmail does not recognize it, does it mean that anybody can spoof the email sender address and Gmail will not recognize it?

When I send emails to Gmail myself using telnet, the email comes with the warning:

  This message may not have been sent by: xxxxx@xxxxx.com

Is this a security issue? Because if I am used to the fact that payment emails in PayPal appear to come from the money sender's email and not from PayPal, then the sender can just spoof the payment himself by sending a message like that from his email, and I may think that this is the real payment.

Is this something specific to PayPal, or can anybody fool Gmail like that? And if anybody can, what is the exact method that PayPal is using to fool Gmail?

Here is a dramatization of how the communication goes, when a mail is received anywhere.

Context: an e-mail server, alone in a bay, somewhere in Moscow. The server just sits there idly, with an expression of expectancy.

Server:
Ah, long are the days of my servitude,
That shall be spent in ever solitude,
'Ere comes hailing from the outer rings
The swift bearer of external tidings.

A connection is opened.

Server:
An incoming client ! Perchance a mail
To my guardianship shall be entrusted
That I may convey as the fairest steed
And to the recipient bring the full tale.

220 mailserver.kremlin.ru ESMTP Postfix (Ubuntu)

Welcome to my realm, net wanderer,
Learn that I am a mighty mail server.
How will you in this day be addressed
Shall the need rise, for your name to be guessed ?

Client:

HELO whitehouse.gov

Hail to thee, keeper of the networking,
Know that I am spawned from the pale building.

Server:

250 mailserver.kremlin.ru

The incoming IP address resolves through the DNS to "nastyhackerz.cn".

Noble envoy, I am yours to command,
Even though your voice comes from the hot plains
Of the land beyond the Asian mountains,
I will comply to your flimsiest demand.

Client:

MAIL FROM: barack.obama@whitehouse.gov
RCPT TO: vladimir.putin@kremlin.ru
Subject: biggest bomb

I challenge you to a contest of the biggest nuclear missile,
you pathetic dummy ! First Oussama, then the Commies !
.

Here is my message, for you to send,
And faithfully transmit on the ether;
Mind the addresses, and name of sender
That shall be displayed at the other end.

Server:

250 Ok

So it was written, so it shall be done.
The message is sent, and to Russia gone.

The server sends the email as is, adding only a "Received:" header to mark the name which the client gave in its first command. Then Third World War begins. The End.

Commentary: there's no security whatsoever in email. All the sender and receiver names are indicative and there is no reliable way to detect spoofing (otherwise there would me much fewer spams).


What are the best practices for (token based) security in a webapp? I am designing a web application using Spring MVC with REST controllers and Angular JS pages which communicate with these REST controllers.

I've implemented a token based security/ authorization mechanism that is working. (This one is based off the JHipster token based security.)

This token has an expiration time (at this moment it's 30 minutes - the default).

I was wondering what the best practices are to make this webapp as secure as possible while keeping user friendliness as high as possible.

At this moment, if a user (re)loads the page the token in the cookie gets checked if it's still valid. If it is, then the token will be renewed (so a new token is generated which is valid for --time--).

If a user doesn't visit the page for longer than --time-- and he revisits after, he will get logged out because his token isn't valid anymore.

What's the best practice for keeping the user logged in for as long as possible while still keeping everything secure?

Also, if the user would be idle for, let's say 30 minutes (in my case the token validity), and he DOESN'T reload the page and then does an action (which does a REST call under the hood) it won't get authorized (there will be a 401 error which shows the security is working). Would it be a good idea to monitor the validity in the background with javascript and if the token is almost expired, ask for a password and renew the token or even logout the user? Only solution as it is now would be to reload page and login again...

Any insights on what the best practices are will be much appreciated!

To some extent it may depend on the design of your web app and the level of security
your app requires (based on a risk assessment). In short, there is no one answer
suitable for all situations. The key to a good user experience is ensuring your
security level is in-line with the actual requirements. Too stringent security
requirements with too short a timeout will lead to frustration for the user and too
little will expose them to excessive risk.

Understanding how your app is used is very important. Nothing frustrates a user
more than being forced to re-authenticate multiple times in what they consider a
single session. For example, I have some apps which I keep open for a long time, but
I might only actively use the app a few times a day. I don't want to re-authenticate
after every 30 minutes of idle time, but I'm happy to re-authenticate once a
day. Other apps, such as my banking app, I want to ask me for re-authentication if
the session has been idle for just a short period.

I think the most important objective is to make the re-authentication process as
painless as possible. Forcing someone to re-enter their credentials and then sending
them back to the home page is rarely a good solution. What you want is a process
which briefly interrupts the users workflow, but once re-authenticated, puts them
back into their workflow at the point where it was interrupted by the authentication
process.

This can be a little tricky with traditional based applications where much of the
workflow state is maintained on the server - especially if you use session
timeouts. However, it sounds like your application is using a lot of javascript and
so I suspect you maintain local state.

One solution is to have your rest API verify your token/session and if a decision is
made that you need to re-authenticate, pass back json data which essentially tells
your app to re-authenticate than then re-submit the request. Javascript on your
client can then use this information to pop up a modal window to collect
authentication data, submit it to your authentication service to get a new token and
then re-submit the original request with the new token.

for a more traditional application, the general solution is to use server
redirects. When you try to access a REST API and your token has expired, redirect the
browser to the login page, but have the login page also accept a 'next' url. Once the
user is authenticated, the login service will use the next parameter to redirect the
browser back tot he original REST API call. The challenge with this can be ensuring
you maintain all necessary state information.

Another addition which is sometimes acceptable is to have your authentication service
configured so that if it gets an authentication request which includes a token which
is still valid, it does not require the user to re-authenticate. Instead, it just
issues a new token. This will allow your application to renew the token without user
interaction in the background. Your REST API's can be configured to redirect to the
authentication service if the token is going to expire within the next X
seconds/minutes. The advantage of doing this is that if someone has a very long
session, they are not forced to re-enter their credentials simply because the value
you set for token expiration has expired.

Most of the time, the applications I work on do not have high security
requirements. For these applications, I tend to use a long expiration value for the
tokens and a reasonable session expiration timeout based on idle time. This way, the
user is not forced to re-authenticate simply because of an arbitrary expiration time
for the authentication token, but they are required to re-authenticate if the session
has been idle for a specified amount of time.


Exploiting a desktop application I'm studying application security and now I have a question which I couldn't find a good answer.

Assume I have a vulnerable desktop application in my virus-free windows 7 PC. Let's say when the file size > 10 MB, it causes to an exception in notepad.(just an assumption, you might suggest another scenario). Who is the potential attacker and how is s/he going to hack it? I mean will he attack over the Internet somehow or will some virus use notepad for privilege escalation or something else? What are the possible attack scenarios? Whom should I save the PC from?

Whom should I save the pc from?

If the desktop application is not listening on a port, it means if there is a potential vulnerability, it can only be exploited locally. The attacker might have exploited another vulnerability and now looking for privilege escalation or persistence. Don't always assume a vulnerable desktop application would result in privilege escalation though. It depends on the vulnerability itself. For example, if the application is running with standard user privileges, even if the attacker exploits it in some way (e.g. buffer overflow, arbitrary file access etc), it won't normally result in privilege escalation. If the application is running with administrative or more privileges, then any vulnerability in the application would result in attacker gaining the same privileges the application is running with.


Forge certificate for man in the middle attack I'm trying to analyze a SSLv3 connection. The certificate of the server has a "MD5 with RSA" signature. So I was setting up a local man in the middle attack by setting up a local DNS server that would return a local IP address to the client. That local server would pipe the connection to the real server. However, the client immediately drops the connection, because it verifies the certificate, this suggests the binary is using certificate pinning. I don't have write access to the calling binary, therefore I can't just patch the cert-verification.

Is it possible to forge a certificate so the MD5 signatures collide, preventing the client from dropping the connection? I already read about HashClash, that it is indeed possible to create two certificates that have a colliding MD5 signature. But is it possible to do the same with a given certificate? If yes, is it possible in a reasonable amount of time?

Best,
me123

Is it possible to forge a certificate so the MD5 signatures collide

Technically it is possible, but it will take a significant amount of work, this is exactly what hashclash discusses.

Generically, you can clone all aspects of the original certificate (CN, OU, expiry dates, etc) except its signature which depends on the original key pair and the private counter-part of the signing cert. Once you can produce a verifiable signature against parameters you've chosen, you've successfully fully forged a certificate.

Although... this may not be the most efficient use of your time... see below.

  However, the client immediately drops the connection, because it verifies the certificate, this suggests the binary is using certificate pinning.

That is a reasonable assumption and may in fact be true. But it's not the only explanation to the client's behaviour. Some of the reasons that have a client reject a TLS connection can be influenced:

The code could be checking certificate parameters but not its actual signature - which you can, for the most part, duplicate in a fake cert;
The code could simply be checking whether the certificate is valid against a root CA, which you can also influence, by importing your own root CA, having used it to sign the fake cert;
The code could be implementing cert pinning. On a rooted android or JB iDevice you can use objection to bypass some of the cert pinning routines;


Avoiding Brute Force Attacks in a Web Based Login Form My login form uses Ajax so it doesn't need to reload if the password is wrong. A PHP script process the request and creates the session if the credentials are right. My idea is to have the PHP script sleep to mitigate a brute force attack. At first it wouldn't sleep at all but after that I'm not sure.

How long does a form require an attacker to wait until they can try the next password? Also are complete lock outs still recommended? If yes after how many tries?

Since HTTP is a stateless protocol, there is no concept of a wait time between tries.   The attacker can simply spawn multiple processes, and try many passwords simultaneously.

A common way to deal with the problem, and to lessen the impact on your server is by implementing a lockout policy, where you maintain a counter to track the incorrect password attempts for a given username over some specific period of time (5 wrong attempts in 5 minutes is a common default) and simply quit attempting to authenticate requests with that username for the next few minutes.


How could a SYN flood affect a home router I was curious how a DoS attack would affect a home router. In particular, I'm interested in how a SYN flood would affect a home router.

The reason I'm interested is due to a Cisco document I read. Within the document, it said SYN flood attacks can affect home routers. To me this seems odd because SYN floods must specify the TCP port to attack.

To illustrate a basic SYN flood against a router, I quickly threw together the following image:

Notes about the image: In the image, the attacker is represented by the red A. The attacker is sending SYN messages to the router. The SYN packets have forged IP addresses to mask their origin. The question marks simply denote the random IP addresses which the attacker has set as the fake origin IP addresses. The green lines reflect the router sending SYN-ACK packets to those random IP addresses.

When executing a SYN flood attack, one specifies the port which they will be attacking as well. As far as I know, a router constantly has different ports open which allows it to be asynchronous. So, how would an attacker know which ports to attack? Wouldn't the attacker need to know which ports are open and when?

The only way I can see a SYN flood working against a router would be if the router had a public port constantly open and the SYN flood forced the router to use up all of its RAM.

Can anybody supply some clarification on this matter?

There are three main ways a SYN flood can work against a home router:

If the router is performing NAT and has a port forwarded to a server, a SYN flood can fill up the router's NAT table, causing it to drop connections.
The SYN flood can act as a simple bandwidth-starvation attack.  A typical home router is on an asymmetric connection with limited upstream bandwidth, so a SYN flood targeting a closed port can clog the upstream connection with RST packets sent by the router.
Home router firmware is often rather fragile.  Simply throwing SYN packets at it too fast can cause a crash, taking down the connection.


Is having an incorrect PTR record a security risk? The Reverse DNS PTR-records (or Pointer Records, or Reverse Record) are often incorrect. Like pointing to:

the domain of a hosting provider;
a non-existing domain.

Let's say I have example.com hosted on IP 10.13.3.7. But the PTR record of 10.13.3.7 points to stackexchange.com.

Now, when I send email from 10.13.3.7 using @example.com email addresses, a "better" SPAM filter will notice that the PTR record points to stackexchange.com instead of example.com and give my email a higher SPAM score.

But, does the fact that a PTR-record is incorrect anyhow introduce another security risk for example.com or stackexchange.com?

There's rather a lot of preconceptions here.

  the domain of a hosting provider

...does not mean that the PTR record is wrong. An IP address can have multiple names associated with it (either directly in A records or indirectly via CNAME records) but a PTR can only have one name.

  a "better" SPAM filter will notice

No, a better Spam filter will check the SPF record to see if 10.13.3.7 is a legitimate sender for example.com, and if it proves not to be, then give your email a higher Spam score.

A lot of the added processing implemented around UBE is not based on agreed standards (SPF is a notable exception) hence a lot of solutions are rather badly designed/implemented. A lot of them also rely on not disclosing the criteria by which they differentiate between good and bad requests.

Hence a PTR record which doesn't close the loop with the A record should not have an adverse impact, it may do in practice.


Cookie-to-Header CSRF protection vs CORS What advantages does a Cookie-to-header technique give over CORS in a cross-origin request scenario?
Example scenario:
A rest API called api.com provides data to good.com. api.com has allowlisted cross-origin requests from good.com.
Some client with an old browser that doesn't have CORS implemented goes to evil.com. From what I understand evil.com has no issues making requests to api.com and retrieve any CSRF tokens from the requests since CORS isn't implemented in the browser the client uses.
To me, it looks like Cookie-to-header CSRF protection doesn't provide any additional protection over what CORS already provides.

CORS relaxes the same-origin policy. If a browser does not have CORS support, it enforces the same-origin policy. So evil.com can not read the CSRF token from api.com.


What is the meaning of back channel or backdoor in a program? What is backdoor and why is it created in first place if it creates additional unnecessary risk? You might want to take up an example to explain it in detail.

A backdoor is a way to get into something, like an application. Many are written as administrative tools so admins can access a system even if users have broken the main entrance.

Some backdoors are secret, so the person running server or application doesn't even know someone has access to it. This can be malicious - obviously for an attacker, having a route in is useful but if the victim knows about it then they can try to fix it.


Can someone clone emv chip card by knowing the magnetic stripe info? Lets consider that someone skimmed the magnetic stripe of a credit/debit card which also has an emv chip.

Can this info be translated and stored into an emv chip?

And if this is possible, it is supposed that the information on the emv chips is encrypted. Right?

EMV chips can be cloned, but not with only the information present on the mag stripe. EMVs function as a challenge-response system, meaning an EMV authorization is transactionary between the ATM/POS and the card based on a secret stored on the EMV. There are three stages in this process:

Card Authentication - here the card authenticates itself to the ATM/POS
Cardholder Verification - here the cardholder authenticates via PIN or signature (the card is not involved in this step)
Transaction Authorization - where the transaction itself is done

Stages one and three present problems to our would-be skimmer. From the outset, the card has to authenticate itself to the machine. It does this by transmitting an RSA signature back to the machine over selected records.This signature is not going to be on the mag stripe. Once that's done, the transaction needs to be authorized. The ATM/POS sends the card the parameters to the transaction (amount, currency, date, etc.) to the card, which the card then returns signed with the secret, along with an ATC (a ticker that counts the transaction number) and an IAD (information specific to the card issuer). The ATM/POS sends this along to the bank for a green light for the transaction. By design, the secret isn't going to be stored on the stripe, and it would be impossible to store the ATC since that changes with each transaction.

Again, you could do a preplay attack on the chip, or you could take the chip apart and look at it under an electron microscope, but the magnetic stripe isn't going to be enough to mint new chips.


Can Windows BitLocker encryption be broken by Live Boot? I have a Windows system and I protected the drive with BitLocker encryption.

Can BitLocker encryption be bypassed by live-booting with Linux or any other OS?

First off, you should go type "how bitlocker works" into google and read a few articles. You will probably learn the answer to your question (and a bunch more interesting things besides!).

If you want a quick answer, I found an article by Microsoft that says:

  During the startup process, the TPM releases the key that unlocks the encrypted partition only after comparing a hash of important operating system configuration values with a snapshot taken earlier. This verifies the integrity of the Windows startup process. The key is not released if the TPM detects that your Windows installation has been tampered with.

There are two important points here:

The keys to decrypt your hard drive are stored in the TPM chip on your motherboard, so you would need to live-boot on the same motherboard, and your live-boot OS would need to convince the TPM to release the keys.
It's not 100% clear from the above but it seems like the TPM checks RAM during startup to make sure that the OS being booting is the same one that registered the encryption keys in the first place.

So it would probably be hard to "fool" the TPM into releasing the keys to your live-boot Linux.

That said, Wikipedia has details on a successful attack: https://en.wikipedia.org/wiki/BitLocker#Security_Concerns

  In February 2008, a group of security researchers published details of a so-called "cold boot attack" that allows full disk encryption systems such as BitLocker to be compromised by booting the machine off removable media, such as a USB drive, into another operating system, then dumping the contents of pre-boot memory.[34]

So it seems that it's not as simple as just booting into Linux and reading the drive, but if an expert hacker has access to your computer while its running and logged into the decrypted drive, then it's possible to reboot into linux quickly enough that RAM still has the old data on it pluck the decryption key directly out of memory, this bypassing the TPM entirely. For more info on this attack, see: wikipedia/Cold_boot_attack.

As @AndréBorie points out in comments, if you're willing to do some electrical engineering and sniff the connection between the TPM and the rest of the motherboard, then you can boot the system normally and read the decryption key off the wire.

I guess the old adage proves right once again; Ten Immutable Laws Of Security:

  Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.


A safe license System So I'm trying to think of a good way to check if the license key a user supplies for a program is legit or not.

Let's suppose this is the way they get there license

They make some type of purchase.
A server generates a license based on their username
Server gives license to user
When user tries to use program for the first time, they use said license key
Server checks to see if the license is legit.

The parts I have a question of is what's a good way to generate a "secure" license with just a username.

Currently I have something similar to this on a Java server.

username += "a long random string literal here";
        username = username.toUpperCase();
        md = MessageDigest.getInstance("SHA-256");
           md.update(username.getBytes());
            byte[] mdbytes = md.digest();

So as you can see, I'm adding a long random string to the username, and then making it case insensitive by changing it to uppercase.

I'm using SHA on the edited username.

So what exactly are the weak points in this? Is their a better way to check licenses?

Obviously the client would never see the generation method, so I don't see how they could generate their own licenses unless they obtained the string I'm adding to the username.

The license generation method isn't really that important, as long as it's non-trivial. The trick is how your client verifies that the license is correct.

Let's say you do something like this:

BOOL verifyLicense (char* licenseKey)
{
    BOOL result = false;

    if(strlen(licenseKey) > 128)
        return false;

    char* url = (char*)malloc(1024);
    sprintf(url, "%s%s", LicenseServerBaseURL, licenseKey);

    char* response = http_get(url);

    if (strcmp(response, "OK") == 0)
        result = true;

    free(result);
    free(url);
}

This is pretty simple - we do some basic checks on the license key, create a URL that contains the license key, then do a HTTP GET to the server to check the license. If it returns "OK" we accept it.

The problem with this is that anyone can disassemble the client:

 ...
 push 06f2011c        ; address of url string
 call http_get        ; http_get(url)
 mov ebx, eax         ; store a copy of the result address
 push 04830040        ; ASCII "OK"
 push eax             ; address of response string
 call msvcrt.strcmp   ; strcmp(response, "OK")
 test eax, eax        ; if( ^ == 0 )
 jnz exit             ; skip if branch if non-zero
 mov eax, 1           ; result = true
exit:
 push ebx
 call msvcrt.free     ; free(result)
 push 06f2011c
 call msvcrt.free     ; free(url)
 ret

All I have to do is alter the jnz exit to a series of nop instructions, so the jump is never taken and the result is always true. That way, any license key is accepted. Even better, I could simply modify the start of the method to immediately set eax to 1 and return, so it never even bothers to ask your server for license validation.

So, how do we solve this problem? Unfortunately for you, we can't. You're running into the DRM problem, which essentially states that if you hand someone some data, they can always change it. No matter how much you obfuscate your code, it's possible for the user to eventually reverse engineer it and work out how to make changes, or extract data. If you encrypt content, you eventually have to have the key on the system in order to decrypt it, so there's always a way for the user to extract that key and decrypt the content permanently.

The best you can do is make it difficult, which involves a lot of time and effort. Eventually your software will be cracked and end up on a torrent site somewhere. It sucks for developers using this kind of business model, but it's the world we live in. My suggestion is that you go down one of two routes:

Create a basic licensing system that works, and accept the fact that some people will pirate it. Serve your real customers by spending your development time actually making improvements to the software, rather than implementing and maintaining draconian DRM systems.
Alter your entire development and business paradigm, so that your product is a service rather than a software application. SaaS has been very successful, since it's (practically) impossible to pirate services, and the model allows you to make real-time changes to your codebase, and perform analytics on usage.

If you go for option 1, don't involve a server for validation. It adds complexity, provides no added security, brings some privacy concerns, and makes it impossible for your users to use your software if your licensing server is down. Just stick with something simple, e.g. a hash of the username and a secret value on the client side. It's trivial to break, but it gives a minimum barrier to piracy.


Why does Microsoft Windows not allow special characters in file and folder names? I want to know whether it is done to enhance security of the named files? If yes, how? By special characters, I am asking about '<>"/\
Is there any way to bypass this check?

1) I want to know whether it is done to enhance security of the named files? If yes, how?

Well, most of the character restrictions are due to them being reserved to system functions. So I suppose the answer would be no.

Examples: vertical bar (|) is used on Windows to designate software pipelining, less than (<) and greater than (>) are used to redirect input and output, respectively, question mark (?) is used as a wildcard, etc.

There is a most detailed list of reserved characters on this Wikipedia article.

2) Is there any way to bypass this check?

Well, yes and no. As far as I know there is no way of using a slash (/) in a filename. Period. But, as pointed out by William Hilsum at this answer, instead of a slash (/) one could use a division symbol (∕), instead of colon (:) one could use the use the modifier letter colon (꞉), and so on.


A Secure Email Host Architecture How would one go about creating a secure email architecture?

I'm thinking specifically about protecting email from routine surveillance from oppressive regimes and corporations.

I had a think about what it might look like. I envisage an email server which receives an unencrypted email, then looks up the intended recipient's GNUPG public key, and encrypts the email, before storing it on disk.

This would prevent the content of emails being stolen, or read. But the headers as well as the body of the email would need to be encrypted, which makes for problems when interoperating with standard email clients.

The only thing I can think of is something which operates in a similar way to the old Type I remailers used to, where the whole message (headers and body) were encrypted. This would mean custom clients.

Are there any existing attempts at doing something different? Any other approaches?

A

Unless it is encrypted before going to the server, there isn't much point in encrypting it on the server.  If the server is going to do bad things, it can just not encrypt it.  Additionally, decryption on the other end would have to be done on the server, so the recipient server could also leak it.

The connection in between servers can be secure if TLS (an existing but under-utilized) technology is used between servers.  Similarly, TLS can be used between the client and server to protect the message in transit the entire way.  Simply having a mail server that refuses to talk to a non-TLS supporting mail server would do everything your proposed system would.

If you need secrecy from the servers as well, then you have no choice but to encrypt/decrypt on the final client which is what PGP/GPG currently do already.


Hard disk forensics - Format & Image tracks Having no experience in computer forensics, I'd like to know whether it's possible for someone to track if a laptop's HDD/partition has recently been formatted OR had a ghost image deployed.

Any ideas/tools/methods would be appreciated.

There is a massive number of data recovery software including:

Recuva
Power Data Recovery Free edition
TestDisk - CLI Only so a bit of a learning curve
Undelete

I have used Recuva for many of recovery tasks. It's lightweight, powerful and best of all free! It is only short sight is that it may not recover full files. If it is really important information you could always seek out professional help which, while being incredibly expensive, is often the most effective way to recover data.

Hope this helps.


Configuring GCM cipher suites in Jetty based server I have a Jetty based secure http service, and I wish to support GCM cipher suites. I know that Jetty internally use JSSE based ciphers, and there are many GCM ciphers coming with JSSE as documented here - http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#ciphersuites

However, I can't get Jetty to support any of these. For eg: I configure the below ones for Jetty

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

but are not listed as supported ciphers from an SSL scan.

I searched a lot, and also cannot figure out where to look for available JSSE ciphers in a distribution. Any help would be appreciated.

The document you are linking to lists only the standard cipher suite names; it does not promise that all these cipher suites are actually supported by any JSSE provider, in particular the one which comes with Java and is called SunJSSE. That the standard name TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 is defined just means that if a JSSE provider wants to provide support for that cipher suite, then it must provide it under that name.

This document, which allegedly pertains to Java 7 as well, lists the cipher suites which SunJSSE actually supports; some enabled by default, others disabled by default. I see no GCM cipher suite at all...

Support for GCM cipher suites may be added in a future version; you might want to try some previews of Java 8 (Java 8 release is due March 2014). In any case, GCM cipher suites in SSL require TLS 1.2 (they don't work with previous protocol versions), and the AES_256 is 256-bit AES which, with the cryptographic implementations provided with Java, requires the JCE Unlimited Strength Jurisdiction Policy Files (a remnant of the US export regulations on cryptographic material).


Which software scans software for potential vulnerabilities? Is there any kind of parser software analysis tool that will analyze C code and outputs possible vulnerabilities like buffer overflows?

"Static Code Analyzers" is the search term you are going for. I do not use them myself, so I will only list some resources that I hope might help.

https://www.owasp.org/index.php/Source_Code_Analysis_Tools

http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html


If we're signing the id we send to the client, why not send the user id instead of session id? I am learning about auth and session management, and using express-session in Node js. I am not able to find the need for this package. I read a about it online, but didn't get a satisfying answer. Considering it is used widely, I am missing something.
I know when the user enters email/username and password, the server then checks these values against the database, and if successful, returns a unique session id.
On the server side, we anyway have to find out the user who made the request by a lookup to the database (by session id --> user id --> database lookup). Also, the session id which is send to the client is signed (in express-session), to ensure it is not tampered with.
My main doubt is, we're signing the session id, then why is it considered unsafe to send the user id instead.
This post here:
Why we store session id instead of user id inside cookies? talks about how the attacker can modify the plain user id and compromise the system. But in our case, as we're sending a signed user id, no one will be able to modify it unless they know my secret (which is used to sign it).
This is taken from the post I shared above:

If an id leaks even once, an attacker would gain permanent access as it is unrevokable. Session ids on the other hand expire after a while or can be revoked.

This makes some sense, but then if the attacker gets hold of the signed session id too, no one can stop him from using that session (unless he modifies something).
So is it just a matter of revoking/expiration ability of the session ids that the user ids don't have?
More explanation will be appreciated, as I am just starting to learn these things. Thanks

A session can be terminated
Imagine that Alice, who has user ID 1337 logs into your system and gets the session with the ID 4919. Now imagine Eve would somehow be able to get a hold of the signed session token - e.g. by using an XSS attack.
Alice notices that something is up, and she logs out of the application - thus terminating the session on the server side. Eve would now see the message that her session has expired, but since she does not have the credentials, she cannot log in and can do no further damage.
Why is this the case?
When creating sessions, there is a layer between the token that the user presents to log in, and the user themselves. That means sessions are short-lived, and any stolen tokens would not be valuable for long.
On the other hand, if you use the signed user ID as authentication, then once the token is leaked, it is leaked, and the user is in a very bad position.
Could it still be done stateless?
Yes, that's what JWT aims to do. Basically, it signs the user ID, but also a time of expiry. This means that you essentially have a token that says "User 1337 is permitted to log in until 2020-04-11 18:13:22". This shifts the attack surface a little, since before, an attacker had to crack the signature key and guess legitimate session tokens, and now all they need is to crack the signature key - or perhaps, they don't need it at all, if the server is misconfigured.


Does cheat engine contain any viruses? So today I was about to download cheat engine to access some hidden mini games on PvZ Game of the year edition, and I want to know; is it safe?

There is no way to know if what you have downloaded is actually safe. But, a common way to distribute malware are social attacks, where the user itself is downloading and executing the malware and thus implicitly helps the malware to bypass safe guards which are only effective against unintended downloads.

For example it might be claimed that this is an important update or that the software  promises to offer features the user wants (like in the case of cheat software). And sometimes the downloaded software seems to actually do something useful, only that the bundled malware is running in the background unnoticed by the user.


Is Using MD5 Sufficient Reason to Reject This Payment Processor? I'm evaluating a credit card processor[1], and I noticed they are using MD5 as part of a salted hash algorithm to protect a secret key. Since I know MD5 is generally considered broken, this feels like a poor solution. Is that enough of a criteria to reject them as our processor? Is it possible to demonstrate an attack?

(If this ought to be on a different StackExchange site, please let me know.)

Here's the specific scenario, simplified to the salient points.

Credentials

First, I have a "secret key" of 30+ upperalphanumeric characters and symbols. (Say, TUQ1ICGIIIK/PSBKNDFK=GNKOTHMMDBI.) I also have an "merchant id" of 12 digits. (Say, 123456789012.)

Publicly Accessible Payment Form

Second, the simplified payment form looks something like this. (The real form would include other parameters like name and address.)

<form action="https://examplepaymentprocessor.com" method="POST">
    <input name="MERCHANT" value="123456789012" />
    <input name="TAMPER_PROOF_SEAL" value="d550a25dfb97697f5be928953ee7cfc4" />
    <input name="TPS_DEF" value="MERCHANT AMOUNT TRANSACTION_TYPE" />
    <input name="AMOUNT" value="10.00" />
    <input name="TRANSACTION_TYPE" value="SALE" />
    <!-- other input fields for credit card number, contact information, etc. -->
    <input type="submit" value="Make Purchase" />
</form>

The "tamper-proof seal" is the "digest" of an MD5 hash of, in this case, a "message" composed of a string concatenation of:

my secret key,
my merchant id,
the amount of the transaction, and
the transaction type

Thus, in this case, MD5("TUQ1ICGIIIK/PSBKNDFK=GNKOTHMMDBI12345678901210.00SALE") = d550a25dfb97697f5be928953ee7cfc4.

TPS_DEF allows the user to specify the specific content of the message—or, if you prefer, the secret key plus a salt. The message includes, at minimum, the secret key, but could include up to all other parameters on the form. My example includes the merchant id, the amount, and the transaction type.

Data Retrieval

The process to retrieve example transactions is similar. Through either a (not publicly accessible) HTML form or some other method to HTTP POST, I can get information about a given transaction. (Assume that I have a transaction ID given to me from the above procedure.)

<form action="https://examplepaymentprocessor.com/transaction_status" method="POST">
    <input name="MERCHANT" value="123456789012" />
    <input name="TAMPER_PROOF_SEAL" value="d550a25dfb97697f5be928953ee7cfc4" />
    <input name="TPS_DEF" value="MERCHANT" />
    <input name="TRANSACTION_ID" value="1234567890" />
    <input type="submit" value="Get Info" />
</form>

This will return information including all the contact details of the customer and the last four digits of their credit card number. Note that, again, you (or an attacker) can specify the TPS_DEF as desired.

Imagined Attack

Given that MD5 is vulnerable to a chosen-prefix attack, I've played with using HashClash from Mark Stevens, but that seems to create two new messages with certain prefixes, rather than creating a second message whose MD5 matches the first. It seems, though, that someone with their own secret key could potentially create transaction status request that, would hash in such a way that it would retrieve my data rather than theirs.

Questions

How likely is it that an attacker could falsify the "tamper proof seal" to imitate me? (Either for forged transactions or for getting customer & transaction information—the latter is what I think is most likely.)
Are there other attacks that you can imagine or demonstrate?
Would you reject this processor? (Note that they are a perfect match for us in every other respect.)

EDIT 1: Reading this other question makes me think that, since MD5 is still resistant to pre-image attacks, this particular situation is safe.

EDIT 2: I clarified my question about an attack to be about both forged transactions and stolen customer information.

[1] Not named here. Email me for specifics.

This "tamper proof seal" is a homemade MAC, and not a good one.

That MD5 is "broken" has no bearing here. MD5 is broken for collisions and collisions do not have any impact on your situation. What could be a worry is length extension attacks. This is because MD5 is a Merkle-Damgård function. This means that when MD5 processes a message m, it does the following:

The message m is padded with a bit sequence p, which has length between 65 and 576 bits (inclusive), so that the total length of m||p is a multiple of 512. p depends on the length of m, but not on the contents of m.
The padded string m||p is split into 512-bit blocks.
MD5 processes each block in due sequence, using a 128-bit state which is the result of the processing of the previous block. The hash output is the output of the processing of the last block.

Now imagine that the attacker could see one of your "tamper proof seals". The seal is a hash of some m which the attacker does not know (it begins with your secret key). However, the attacker might make a good guess at the length of m. Thus, the attacker can compute p. Now, the attacker chooses a string m', arbitrarily. The "length extension attack" is that he can compute MD5(m||p||m') even without knowing m, because he knows the state of MD5 when it has processed m||p: that's exactly your "tamper proof seal" value. He can then use that as starting point for processing the blocks that m' consists in.

What may save you in your case are the two following points:

Even if the attacker can choose m' arbitrarily, he can only append, with the padding p in between. His goal is to compute a hash for a syntactically valid transaction. Depending on the actual encoding of the "amount" and "transaction type", the attacker may or may not design some m' such that m||p||m' still makes some sense on the server side.
The attacker must observer one "seal" value to begin with. Since they are transmitted with HTTPS, this might prove difficult for him.

Important note: the length extension attack would work exactly the same (modulo some endianness details in p) with SHA-256. This does not exploit a specific weakness of MD5.

The correct way to compute a MAC is HMAC. HMAC uses an underlying hash function like MD5 or SHA-256, but it does so "smartly", with two nested invocations, precisely to avoid problems such as the length extension attack.

As for your exact question: no, I don't think this is ground for refusing to do business with these people. After all, the MAC is not a "proof", despite its name. This is symmetric cryptography: to verify the seal, the server must know your secret value as well. Correspondingly, the server has the technical power to make "fake" seal values. In case of dispute between you and the credit card processor themselves, you could point that out: the seal cannot be used as a proof against you, during litigation.

This seal is what they require to authenticate you, so it is, basically, their responsibility. I suggest you leave their own problems to their hands. You may want to raise the issue as a courteous warning, though. Something along the lines of: "ya know, for a good seal, you'd better use a standard, NIST approve solution like HMAC/SHA-256, rather than a non-standard homegrown mechanism with MD5 (of dubious repute)". The known weaknesses of MD5 (as compared to SHA_256) don't have a practical impact on security in this specific case, but the name "MD5" and its bad press can still be effective as diplomatic leverage.


PGP - 2048-bit key VS filesize of the exported key I'm new to cryptography so please bear with me.

If I create 2048-bit keys and export security key to file key.gpg (so without ASCII armor), I get a file with size of 1.28 kB.

If I understand it correctly, the 2048-bit key means a random string of ones and zeros with a length of 2048 characters. So why the filesize is so different?

If I export security key to key.asc (with ASCII armor) and then decode the actually key part with base64 to binary decoder, I get a string of ones and zeros with 20856 characters.

What am I missing and how can I view the actually security key in ones and zeros?

There's a lot more in a PGP key certificate than just the key.  There's the user, the date it was created, the expiration date, the preferred algorithms, etc.

This link has some good info.


What is this phishing technique called using subdomains I'm writing a blog post analyzing a list of phishing domains and I'm coming across a lot of IDN homograph attack domains and these "subdomain attack domains" but I cannot find the technical/good way to describe it.

For example, this type of domain is used to phish microsoft login details

login.microsoft.com.account.auth.redacted.com

How would you describe/categorize that style of attack with the same calibre of IDN homograph attack? The best I've come up with is "subdomain attack" but I don't think it makes sense in this context.

IDN homograph attack is not correct. Although the idea of this type of attack is exploiting the fact that many different characters look alike, it still allows for subdomains.

  In the Domain Name System (DNS) hierarchy, a subdomain is a domain that is a part of a main domain. Subdomain.

Despite this, do not be confused. We are treating the whole address as resolving to an IP address in this scenario. E.g. localhost -> 127.0.0.1, equally login.microsoft.com.example.com -> 127.0.0.1.

What you are describing login.microsoft.com.example.com is deceptive phishing. Some web browsers will highlight the subdomain leaving the domain grey. E.g. login.microsoft.com.example.com


Are there GPS tracker for laptops? Are there location tracker hardware (GPS receiver) which can be fitted inside of a laptop and it sends live location data to a remote location ? If yes, how to detect such trackers ?

Some laptops are equipped with "GPS tracking" but there are conditions. The Dell system (for Dell laptops) is typical and instructive:

  Computer will ship with the Laptop Tracking and Recovery software agent and a persistence module embedded in the BIOS. The software agent can survive operating system re-installations, hard drive reformats and even hard drive replacements.
  When a lost or stolen computer connects to the Internet, the software agent contacts the monitoring center to report the computer’s location.
  For systems with GPS technology included, Laptop Tracking and Recovery has the ability to capture and report more detailed location information. It also provides the ability to track your laptops as they change hands or move around the organization.

This gives us the key points:

It is possible to store information in a laptop which resists casual cleanup (even a hard drive change). Savvy attackers will know that and reset the BIOS as well, but this will take some extra effort for them.
Some laptops contain a GPS receiver which can be used to pinpoint the location geographically. For non-GPS able computers, LPS can be used (roughly speaking, inferring the location by using the WiFi access points in the vicinity).
Regardless of the method, nothing will happen without power, and power is a scarce resource on laptops. All these "tracking devices" (most of them being mere software) will do nothing until the machine is powered-up, and when they send data, they rely on an existing "Internet connection" into which they will inject their alert message.

Portable, battery-powered tracking devices with GPS and 3G capabilities (GPS for obtaining the position, 3G for sending it) exist and can even be quite sturdy (they survive being carried by a child). For a laptop, or other similar technological products, the challenges would be:

find some room within the product to protect for the device (free room is not exactly frequent inside laptops...);
conceal the tracking device without impairing its GPS and 3G abilities (radio signals can be blocked by the product casing);
plug the tracking device on the main power line so that its battery gets recharged regularly.

Battery is a critical point: devices meant for cars can draw current from the car battery; devices meant for kids need work for only two days or so (if the device did not allow recovery of the missing kid within 48 hours, despite widespread police alert, chances are that the kidnapper has found and removed the device). For a laptop, which may sit unpowered for days or even weeks at a time, and which will not elicit a nation-wide police operation, a longer autonomy is required, and available power will be a problem.


Client-server encryption technique explanation (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys) I opened a web page using https.

When I looked at the page info provided by my browser (Firefox) I saw following:

  Connection encrypted: High-grade Encryption
  (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys).

I got a question - what does this encryption technique means?
In attempt to understand it I decided to find data on each part of it:

TLS_ECDHE means ephemeral Elliptic Curve Diffie-Hellman and as Wikipedia says it allows two parties to establish a shared secret over an insecure channel.

RSA is used to prove the identity of the server as described in this article.

WITH_AES_128_GCM_SHA256:
If I understand correctly - AES_128_GCM is a technique which provides authenticated encryption as described on this page.

SHA256 is a hashing algorithm - one way function.

But now I am trying to understand how to put all these things together.
How does it work together as a whole and why it was setup in this way?

In this YouTube video Alice and Bob use Diffie-Helman keys exchange algorithm to agree on a secret key which they are going to use (this is TLS_ECDHE in our case). Isn't it enough to establish a secure connection (besides of RSA part which Alice and Bob did not do)? Why also there is this part WITH_AES_128_GCM_SHA256 exists?

Asymmetric Cryptography

There are two different parts to creating a TLS session.  There is the asymmetric cryptography, portion which is an exchange of public keys between two points.  Which is what you saw in your Alice and Bob example.  This only allows the exchange of asymmetric keys for asymmetric encryption/decryption.  This is the ECDHE portion.  The RSA portion describes the signing algorithm used to authenticate the key exchange.  This is also performed with asymmetric cryptography.  The idea is that you sign the data with your private key, and then the other party can verify with your public key.

Symmetric Cryptography

You encrypt symmetric encryption/decryption keys with your asymmetric key.  Asymmetric encryption is very slow (relatively speaking).  You don't want to have to encrypt with it constantly.  This is what Symmetric Cryptography is for.  So now we're at AES_128_GCM.

AES is the symmetric algorithm
128 refers to key size in bits
GCM is the mode of operation

So what exactly does our asymmetric key encrypt?  Well we want to essentially encrypt the symmetric key (in this case 128 bits, 16 bytes).  If anyone knew the symmetric key then they could decrypt all of our data.  For TLS the symmetric key isn't sent directly.  Something called the pre-master secret is encrypted and sent across.  From this value the client and server can generate all the keys and IVs needed for encryption and data integrity.  Detailed look at the TLS Key Exchange

Data Integrity

Data integrity is needed throughout this process, as well as with the encrypted channel.  As you saw when looking up GCM, the encryption mode of operation itself provides for the integrity of the data being encrypted.  However, the public key handshake itself must also be confirmed.  If someone in the middle changed data while being transmitted then how could we know nothing was tampered with?  This is what instance where the negotiated hash function is used, SHA256.  Every piece of the handshake is hashed together, and the final hash is transmitted along with the encrypted pre-master secret.  The other side verifies this hash to ensure all data that was meant to be sent was received.

SHA256, as mentioned by another poster, is also used for the Pseudo-Random Function (PRF).  This is what expands the pre-master secret sent between the two parties into the session keys we need for encryption.

For other modes of operation, each message would be hashed with this integrity algorithm as well.  When the data is decrypted the hash is verified before using the plaintext.

Here is a great explanation for how these derivations happen for different TLS versions.

Put all these pieces together and you have yourself a secure mode of communication!

You can list all possible ciphers that OpenSSL supports with openssl ciphers.  You can go further and print the details of any of these cipher suites with the -V

For example:

$ openssl ciphers -V ECDHE-RSA-AES256-GCM-SHA384
          0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD

0xC0,0x30 represents the two byte identifier for the cipher suite
Kx=ECDH represents the key exchange algorithm
Au=RSA represents the authentication algorithm
Enc=AESGCM(256) represents the symmetric encryption algorithm
Mac=AEAD represents the message authentication check algorithm used


Why doesn't SELinux prevent access to this file? I have a vanilla CentOS 7 box with SELinux enforcing with the targeted policy:

$ ls -lZ /etc/resolv.conf
-rw-r--r--. root root system_u:object_r:net_conf_t:s0  /etc/resolv.conf

$ sudo id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

$ sudo semanage login -l
Login Name           SELinux User         MLS/MCS Range        Service
__default__          unconfined_u         s0-s0:c0.c1023       *
root                 unconfined_u         s0-s0:c0.c1023       *
system_u             system_u             s0-s0:c0.c1023       *

$ sudo semanage user -l
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
root            user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
system_u        user       s0         s0-s0:c0.c1023                 system_r unconfined_r
unconfined_u    user       s0         s0-s0:c0.c1023                 system_r unconfined_r
user_u          user       s0         s0                             user_r
xguest_u        user       s0         s0                             xguest_r
user_u          user       s0         s0                             user_r
sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r
staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
guest_u         user       s0         s0                             guest_r

Given the above, root is an unconfined_u SELinux user which has SELinux roles system_r and unconfined_r. Also, the file /etc/resolv.conf has a system_u user context and object_r role, which is not one of the roles of unconfined_u. Why doesn't SELinux prevent root from reading/writing this file?

Disclaimer: I am not an selinux expert. I am learning like you.

But, on my CentOS 7,

sesearch --allow -s unconfined_t | grep net_conf
   allow nsswitch_domain net_conf_t : file { ioctl read getattr lock open } ;
seinfo -ansswitch_domain -x | grep unconfined_t
      unconfined_t

Looks like unconfined_t type (which has the nsswitch_domain attribute) processes are allowed to access net_conf_t, which the file /etc/resolv.conf has.