How cryptographic hardware accelerator is secure?

Simple hardware crypto accelerators have no security benefits, only performance ones (we could argue that this allows for larger key sizes thus increased security).

Hardware security module, on the other hand are similar devices but in addition they can also store the keys securely and never reveal them to the computer itself; when the HSM is set up the keys are either imported into it or generated on it directly and they have no way of leaving the module later (the only way to get the keys out would be physical access, and even then they're tamper-proof).

The computer just gives it the plaintext, instructions on what to do with it, and the module spits out ciphertext.

About the AM335x, in the datasheet of the AM3352, there is the following :

  Crypto Hardware Accelerators (AES, SHA, PKA, RNG)

So it can do AES, SHA in hardware (not sure what PKA stands for), as well as generate cryptographically-secure random numbers. There is no mention of key management however, so the keys will still be stored on the computer itself and the security of those keys can't be compared to an HSM for example.


How can I scan open ports without being traced back

Depending on the environment of your scan and where the server is located etc. You may be able to accomplish this using a TCP Idle Scan - http://nmap.org/book/idlescan.html

You could also do your scanning via a proxy http://funoverip.net/2010/11/socks-proxy-servers-scanning-with-nmap/

Both the above methods are more covert but neither is completely untraceable so do consider this.

Also you should consider legality of port scanning a system unless you have permission to do so - http://nmap.org/book/legal-issues.html


Is there an anti-proxy detection available?

There is no magic way to detect a proxy.  What they are likely doing is looking for IPs that have lots of different users coming from them or that are published as Proxy end points.  A proxy that has a limited number of clients and doesn't publish itself as such would seem no different from any other internet user.  The problem is that such a proxy would need a large number of IPs to avoid being detected as a proxy and would thus be difficult to manage.


Responsibility of disclosing potential social engineering attack

Yes, contact your bank and let them know. I would firstly lookup the fraud department for your institution an send them an email, or call them, and tell them explicitly what you received.

You can run the link URL through Virus Total to see if there are any red flags that pop as well. This will give you more information to pass on to the fraud team.


You should not allow for state to be changed in a meaningful/dangerous way using either URL schemes or deeplinks. Apple gives the following warning:

  Warning

  URL schemes offer a potential attack vector into your app, so make sure to validate all URL parameters and discard any malformed URLs. In addition, limit the available actions to those that do not risk the user’s data. For example, do not allow other apps to directly delete content or access sensitive information about the user. When testing your URL-handling code, make sure your test cases include improperly formatted URLs.

https://developer.apple.com/documentation/uikit/inter-process_communication/allowing_apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app

While this is aimed at URL schemes, Apple still does not guarantee the authenticity of any incoming URL based launches (as shown by the deprecation of the source attribute). If you need to communicate securely between processes, you should use an App Group entitlement to direct the system to create a secure, shared sandboxed environment for a specific set of applications your developer team has created. If you need to communicate something between processes, you can write a message file and then launch the other application by its URL scheme and direct it to try and parse the stored message. This is secure as no false messages can be injected without compromising the iOS sandbox.


Certificates, can they be generated on the fly, without access to a CA?

For proper SSL, the client must make sure that it talks to the right server, not a fake server operated by the attacker. This requires that the client knows the server public key. The certificate is a method for offering this guarantee: the server certificate contains the server public key, and the certificate is signed by the CA. The client knows the CA public key, and thus can use it to verify the signature on the certificate, and thus gain some confidence in the veracity of the purported server public key.

If you can hardcode a copy of the server public key directly in the client, then you can skip the certificates (maybe sending a dummy certificate to keep the client library happy). This is rather inflexible in practice, e.g. if you need to change the server public key, you then have to modify all the clients.

Therefore, it is often considered a better method to actually have a CA. You can operate your own CA; be sure to guard it well (physical security is important; 95% of CA management is procedures and guards and dogs). EJBCA is an open-source software that can help in running a CA. Alternatively, buy certificates from a commercial CA: this could be a good deal since it will save a lot of time on your side.

You could generate certificates on-the-fly (traditionally "self-signed") but such an automatically generated certificate does not prove anything -- anybody can make a self-signed certificate with arbitrary contents, at any time.

  Certificate expiration - is there a limit to how long a certificate can be valid? Our systems runs for many years without user intervention and we'd like to keep it that way.

The format for certificates includes an expiry date which is encoded with ASN.1 type UTCTime or GeneralizedTime. The latter is good until year 9999 (inclusive). However, some poorly written software may have trouble with dates beyond January 19th, 2038. If you control the client code, then you can choose a SSL library that does not have such problems. In general, the SSL implementation in Windows does not suffer from the Y2038 issue, and works fine with certificates valid for a thousand years.

The official reason why certificates expire is to keep CRL small. CRL are used for revocation. Revocation is a damage containment mechanism: this is used to invalidate a certificate whose private key has been stolen. If there is no revocation mechanism, then an attacker who compromised a server once will be able to run a fake server, that all clients will accept as genuine, until the certificate expiration.

If your certificates are valid for 1000 years, and you don't use revocation, then a compromised server becomes a problem that won't solve itself for 1000 years. On the other hand, if you use revocation, then the regularly issued CRL will include the list of revoked certificates; more precisely, a CRL is the list of the serial numbers of certificates which have been revoked and are not expired yet. To prevent the CRL from growing indefinitely, expired certificates are removed from the CRL (in that sense, revocation is just "early expiration"). But this works only if certificates really expire.

Either way, certificate expiration can be useful, and must be well thought about.

(As a side note, all of this implies that clients and servers shall have a reasonably accurate notion of the current date and time -- and by "accurate" I also mean that there shall be no method by which an attacker who is in control of the network could make clients or servers assume a wrong current time.)

  Must a CA-server be available? (No Internet access)

Revocation is regular publication of fresh information about existing certificates. This can use CRL or OCSP, but, in any case, this information is short-lived (CRL publication is typically a daily operation) so some network access is needed at some point.

If server certificate issuance is a rare operation, then the CA could be split into an offline component, that is used manually to issue new certificates, and an online component (say, an OCSP responder), that answers requests from clients that want fresh revocation information.

  Must clients have their own unique certificate?

In all of the above I talked about server certificates. In basic SSL, the server has a certificate, and the client knows that it talks to the real server. However, the server has no idea who the client is. A very common method (that you have used with your Web browser, e.g. whenever you bought something on Amazon) is to have the client send some authentication data (a "password") to the server -- this is safe because at that point, the SSL tunnel is up and running, and the client knows that it is talking to the genuine server.

SSL also supports client certificates, for mutual client-server authentication at the SSL level. This is conceptually justified when the server is not the entity that is responsible for defining who is a valid client and ascertaining their physical identity.

If, in your specific context, you can use a "show the password" model, then this will be a lot simpler to manage, because issuing certificates to all clients is often a neverending stream of nightmares.

  If a device can act as both server and client, does it require multiple certificates?

Technically, the same certificate can be used for both roles, but care is needed.

A certificate is a binding between a public key and a name; software that validates a certificate needs to make sure that the certificate is a real one (signed by a trusted CA, not expired, not revoked...), and also that the name is the expected one. Usually, SSL clients, when they validate the server certificate, expect a specific server name (the one in the URL when the SSL really is HTTPS), and want that server name to appear in the certificate (this is specified in RFC 2818). So, with usual SSL libraries, you need the server certificates to include the DNS name of the server, as seen from the clients.

No such widespread convention exists in the other direction (server that validate client certificates), but the concept is still there and must be managed: all these games about certificates are about knowing who you are talking to, so names must be defined, properly recorded in the certificates, and verified.

You are theoretically free to use any naming convention as you see fit, but your SSL library may be more comfortable if, for the server-by-client validation, you use the "normal" way of having the server DNS name written in the server certificate.

  Can the authorization part be solved using certificates or do we need to do that via a separate user access system?

No. Trying to do authorization with certificates only leads to sorrow and much grinding of teeth. Don't do that. Certificates are for authentication (knowing who you talk to), not for authorization (deciding what you should allow the authenticated peer to do).


Reason for writing Self-Decrypting Virus

It is one of the obfuscation techniques employed by some viruses to mask their presence and avoid detection and facilitate easier spreading (affecting other systems).

Such viruses would encrypt (self-encrypt in case of metamorphic or polymorphic viruses that can mutate with spreading) their payload and as such prevent direct examination, which can result in reduced ability of antivirus software to detect, and/or clean them. They are difficult to detect by fast antivirus detection methods such as checking file signature against virus definitions tables, if the payload moves position within it, effectively changing file signature (metamorphism). Metamorphic viruses don't necessarily use encryption though.

Out of the self-decrypting bunch of the nasties, the hardest to detect are polymorphic viruses, which can change both the encryption scheme (and/or use a random encryption key) for the payload, as well as mutate decryption code itself (the part of the file that is not encrypted and decrypts the payload). Only reliable way to detect such viruses with antivirus software is by deep heuristics, inspecting signatures of smaller chunks of their structure, and/or by running them in a sandbox and inspecting what they actually do. Such scanning techniques are of course compute expensive, disabled by default for speed concerns (and possibly to avoid false positives) on consumer-grade software, and not many users ever enable this on distributions that are actually capable of such advanced detection methods.

So to answer your question, it is still a viable technique as it makes such viruses harder to detect on most systems they might use to spread to others, and increases their survival rate. If you're interested, this page lists most common virus obfuscation techniques.


Prevent unauthorized workstations from joining a Windows Domain

I believe you need to have the domain administrator credentials to join a domain (or an account which has been delegated this ability). It should not be possible for a user to just add their personal computer to a domain. You should not be giving users the ability to copy system files off their work pc to their home pc (do not give them local admin privileges).

Theoretically, it's possible they could image their work machine and put it on their own hardware, but that would not allow them to change the system settings and gain more privileges, it would still generally be your GPO in affect. To counter this, a combination of TPM and encryption would help.

If you want to block unauthorized systems from joining the network, you would probably want to do this a layer domain from Active Directory at the network level. You could implement 802.1x port security or any other type of network access control (NAC).

More resources:

Network Access Protection in Server 2008
Create a new computer Acccount
Server and Domain Isolation


Do any non-GNU/Linux display managers provide the same isolation as Wayland?

Windows
Microsoft Windows, since Vista, has at least attempted to isolate windows, for example using UIPI and session 0 isolation. This is not perfect, and there are some limitations. Windows exposes many large APIs to client windows, making it possible to bypass isolation. This is a particular problem for UAC consent prompts, where the assumption is that only a genuine user can grant consent. Additionally, AppContainer is able to isolate individual windows. Unfortunately, I know little about how Windows manages GUI isolation, and surely the state of things has changed since Vista. What is true though is that Windows does attempt to isolate individual windows to a certain extent, but there are bypasses.
Linux with Xorg
Xorg is one of the original display managers for Linux, having superseded Xfree86. It uses the X11 protocol. When a graphical application wishes to draw to the screen, it connects to the X server through a UNIX domain socket or through the local network, using the X11 protocol. To authenticate to the X server, it must provide the X11 cookie, which is a random value in a file readable only by a single user, or exported as an environmental variable for that user. Any program that has access to the X11 cookie has full access to the X server. It is able to read keystrokes, inject keystrokes, take screenshots, move windows, etc. As such, graphical isolation under Xorg is limited to DAC (UNIX permissions) against the file containing the X11 cookie. Given that we often (foolishly) enter our root passwords in an X11 session at the same time our possibly vulnerable browser has a hundred untrusted tabs open, this security design is not the best idea. Attempts to improve X11 security, such as the XSECURITY extension, have failed miserably. It is too complex, and too easy to bypass.
There is a way to get graphical isolation on systems with X11, though. Creating a nested X server, for example with Xephyr, allows starting individual applications in their own X server. Combining this with mandatory access controls to force each application to only be able to read its own nested X server's X11 cookie completes this. This provides isolation, but does nothing for the excessive complexity of the X11 protocol and its extensions. Vulnerabilities in the decades-old application continue to pop up.
Linux with Wayland
Wayland is supposed to be the answer to Linux desktop security. It integrates itself with the window manager in the form of a shared library, allowing the window manager to be able to manage permissions for individual windows. Each window can request permissions from the window manager, and the window manager can grant or refuse them. The overall architecture for Wayland is vastly different from Xorg, and there are many internal differences not directly related to security (for example, Wayland does not do rendering on its own, rather it requires the client window do the rendering). The differences alone would take up an entire answer. Security-wise, Wayland is superior in that it provides confidentiality, integrity, and availability to a desktop full of untrusted graphical applications, and it runs using a simpler protocol, requiring fewer privileges to function properly.
Mobile operating systems
I know little about mobile computing. One big difference between mobile operating systems of all types and desktop operating systems is that mobile devices tend to be more monolithic and limited in their configurability. This makes security policies easier to design. As a result, inter-window communication becomes less important, to the point that Android can even run each individual application under its own UID and GID, completely sandboxed away from the rest of the system. iOS likely does something similar. If I discover more about Mac OSX (which is certainly not fully isolated from malicious applications) and Android/iOS graphical isolation, I will edit this answer.
To answer your question, many operating systems do have better isolation than Xorg (which has none), but not better than Wayland which, currently, is not known to be possible to bypass short of using novel exploits or hijacking the entire user. Wayland is a major improvement over the X11 model.


Unregister your device from a WiFi network

The wifi access point is probably recognizing your android device's MAC address, which normally remains constant, even throughout power-cycles.
If you want the wifi access point to 'believe you are a new user', you may be able to temporarily change your MAC address.  See https://www.techjunkie.com/change-mac-address-android/ for more info.


Why do you need to encrypt symmetric key?

Most asymmetric encryption algorithms are very slow while most symmetric algorithms are quite fast. When you want to encrypt a large file with asymmetric encryption, encrypting and decrypting will take a while. But when you only encrypt the symmetric key, you don't have much data, so it will be quite fast, and you can then use the symmetric key to decrypt the large message quickly.

Hybrid encryption also allows to encrypt the message efficiently for multiple recipients. With asymmetric encryption alone you would have to encrypt the whole message multiple times - once for each recipient. But with hybrid encryption you just need to encrypt multiple copies of the symmetric key while you only need one copy of the message.

Another advantage of hybrid encryption is that you never send the same cyphertext twice. A new symmetric key is (or should be) generated for each message. That means when the same plaintext is encrypted twice to the same receiver, the cyphertexts will look different. When you would use only the public key, both cyphertexts would be identical. This might be exploitable in some situations. For example when an eavesdropper suspects that you sent one of a limited set of known plaintexts encrypted with a public key they also have access to.


How to modify UDP packets in checksum field?

There are different options. The easiest would be using a tool like scapy.

  Scapy is a powerful interactive packet manipulation program. It is
  able to forge or decode packets of a wide number of protocols, send
  them on the wire, capture them, match requests and replies, and much
  more. It can easily handle most classical tasks like scanning,
  tracerouting, probing, unit tests, attacks or network discovery (it
  can replace hping, 85% of nmap, arpspoof, arp-sk, arping, tcpdump,
  tethereal, p0f, etc.). It also performs very well at a lot of other
  specific tasks that most other tools can't handle, like sending
  invalid frames, injecting your own 802.11 frames, combining technics
  (VLAN hopping+ARP cache poisoning, VOIP decoding on WEP encrypted
  channel, ...), etc.


No. Actually, most RoP attacks make use of existing codes (former return-into-libc-attacks). So, the RoP gadgets are snippets of existing code and have to be executable.


Will Enabling TLS 1.2 and disabling older protocols on Windows Servers have any impact on desktops?

If you only enable new protocol, then there is no impact for existing applications as long as you do not disable others. SSL/TLS protocols in Windows are implemented side-by-side and one protocol do not affect other protocols. But if you disable any other protocol, applications may fail if they explicitly rely on a disabled protocol.


How quickly can these password schemes really be beaten?

Assume you have no rainbow table (or other precomputed list of hashes),
and would actually need to do a brute-force or dictionary attack.

This program IGHASHGPU v0.90 asserts to be able to do about 1300 millions of SHA-1 hashes (i.e. more than 2^30) in each second on a single ATI HD5870 GPU.

Assume a password of 40 bits of entropy, this needs 2^10 seconds, which is about 17 minutes.

A password of 44 bits of entropy (like the one in the famous XKCD comic) takes 68 minutes (worst case, average case is half of this).

Running on multiple GPUs in parallel speeds this up proportionally.

So, brute-forcing with fast hashes is a real danger, not a theoretical one.
And many passwords have a much lower entropy, making brute-forcing even faster.

  If I use a truly random salt for each user, on what order of magnitude
  will this affect the length of time to crack my password?

The salt itself is assumed to be known to the attacker, and it by itself doesn't much increase the cracking time for a single password (it might increase it a bit, because the hashed data becomes one block longer, but that at most doubles the work).

The real benefit of a (independent random) salt is that an attacker can't use the same work to attack the passwords of multiple users at the same time. When the attacker wants just any user's password (or "as many as possible"), and you have some millions of users, not having a salt would could down the attack time proportionally, even if all users would have strong passwords. And certainly not all will have.

  As a bonus, which hashing algorithms are safest to use?

The current standard is to use a slow hashing algorithm. PBKDF2, bcrypt or scrypt all take both a password and a salt as input and a configurable work factor - set this work factor as high as your users just accept on login time with your server's hardware.

PBKDF2 is simply an iterated fast hash (i.e. still efficiently parallelizable). (It is a scheme which can be used with different base algorithms. Use whatever algorithm you are using anyways in your system.)
Bcrypt needs some (4KB) working memory, and thus is less efficiently implementable on a GPU with less than 4KB of per-processor cache.
Scrypt uses a (configurable) large amount of memory additionally to processing time, which makes it extremely costly to parallelize on GPUs or custom hardware, while "normal" computers usually have enough RAM available.

All these functions have a salt input, and you should use it.


How to run a Tor exit node securely on a vps

This is a really borad question. In essence you have said: "I am going to install a service on my Linux VPS that will make it a target to hackers. How do I secure my Linux server?"

All of the standard security measures should be taken. Most distro's have specific guides on hardening the OS as well. Of course follow the four basic rules:

Run all services and programs with lowest privileges.
Disable or delete any services not needed on the machine.
Ensure the system is up to date.
Employ a firewall and host based IPS.

With a little more info on specific threats you are worried about, or distro and software version I may be able to be more specific.


Mobile app vulnerability scanner for Android and iOS

Mobile Applications unlike web applications, are native apps which are installed on to the mobile operating system using a package. A mobile app is likely to follow a server client approach where the native app speaks to a server [eg: Facebook, Ebay]

Automated source code audit is possible on both the server side code and the client side code. Almost all the commercial scanners like IBM Appscan, HP Fortify and Checkmarx has modules which support such analysis for android native app code and the server side JAVA code and objective C.

However dynamic scanning of mobile applications is a lot more tricky. It will be almost impossible for a scanner to crawl though the API methods available. Manual testing would yield much more accurate results.


Heuristic evaluation in information security

This is not typical terminology or practice in the security space. The terms one would look for are in the vein of "requirements" or "standards" or perhaps "principles" and evaluations against which can be called "gap analysis" and similar.

The difference in terminology matches a difference in the actual work. In security the work against those standards or requirements is mostly about activities in the execution domain, while in usability the work is more in the discovery domain.

Note also that the most secure system by definition is one that has zero usability; and to some extent security and usability are conflicting goals. The emerging practice of "usable security" is one in which heuristics for discovery of securer patterns have more of a role to play.


Tracking information on HTTPS connection

Anything you do through http is obviously traceable. In addition, if your organisation uses a proxy/MITM  for looking at connections (ie you connect to the proxy over https and it connects to the site over https, but the data is in the clear on the proxy) then they can obviously see anything there as well.

In your specific case, your browser may pre-load links (for speed/performance) - this is most likely to be links to other pages, but could include images. If these are through http connections, then obviously they will show up in the clear.

Simple answer - do not do anything through your work connection that you would be concerned at your employer discovering!


If the browser enforces a Sandox, then why the infections by malware?

The sandbox enviornment in browser is designed to restrict the anything from within the browser to cause any harm to your computer. It gives the browser low rights, so that any malicious code(Javascript) cannot harm your system files. But, whenever you are explicitly downloading any files or giving explicit rights(by clicking on yes, when an alert appears), you are giving the malicious code access, to do anything with your files.

Bottomline: The sandbox env, protects the system unless you tell it to give rights to certain programs to do harm.


Is a company website secure against sslstrip if it doesn't use ssl on homepage but ssl everywhere else?

Checking correct usage of HTTPS is ultimately the sole responsibility of the user. The users need to look at at least 3 points when visiting a web-page:

Are they expecting HTTPS to be used (at least for this part of the site)?
If so, is the certificate valid (lock/green/blue bar, without warning)?
If so, is the host name in the address bar that of the site they intend to visit?

Answering yes to these 3 questions is required for HTTPS to be used correctly.

Not enabling HTTPS on the initial page isn't necessarily the end of the world. This page may be vulnerable to SSLStrip attacks, but what's on that page may not need to be transferred securely.

If there is a link to a "secure section", the user should check that it sends them to the site they expect (see 3 points above). That's the user's responsibility.
The secure section of the website shouldn't assume that what was done before entering the secure section (e.g. adding items to a basket) was done securely (the user should always confirm). The login landing page itself (if any) should also be served over HTTPS (so that the user can expect the login form to be sent to HTTPS too, see this OWASP rule). In addition, different session management should be used, and the non-secure session should be discarded, so as not to allow session theft. That's the web developer's responsibility.

Most websites may have a plain HTTP welcome page, if only to perform a redirection to HTTPS or send the first HSTS header. This may indeed be vulnerable to SSLStrip at this stage, but there needs to be a starting point if the user doesn't know what to expect (and most will use plain http:// URLs first). Automatic redirections can (only) mitigate the risk. The only way around this is either for the user to know that only https:// URI will work or for the site to be part of the pre-loaded HSTS list.

(No website is secure against SSLStrip if the user or the browser doesn't expect HTTPS to be used. This expectation can be activated automatically in the browser via HSTS, either via a first visit from a network where the attack hasn't taken place, or via the pre-loaded list.)


Level 3 DNS default response for invalid host names

You have discovered the evils of DNS hijacking. ISPs and others hosting DNS servers started abusing DNS in this way years ago to direct end users to search pages when they try going to a website that doesn't exist by returning their own IP rather than NXDOMAIN. It gets them a bit of extra advertising revenue, but as you've seen it's particularly annoying for anyone doing anything other than normal web browsing.

  Couldn't the host at 23.202.231.167 be doing all sorts of horrible spoofing things to people that made typos in their host names?

Absolutely. DNSSEC and DNS over TLS help here, but adoption is slow, and these won't fully solve the problem of typos anyway since typosquatters are the "legitimate" owners of their domains.

The best you can do is to configure your router or computer to use a DNS server you trust with DNS over TLS or DNS over HTTPS. Cloudflare (1.1.1.1) is a common choice as they helped kickstart encrypted DNS, and Google (8.8.8.8) and Quad9 (9.9.9.9) are other popular choices.


Anonymous tries to talk people into supporting their DDoS actions by installing a tool on their computer. It has a botnet-mode which allows the leaders to define the target for all the drowns. In other words: Anonymous uses social engineering instead of technical vulnerabilities to distribute their botnet client.

This tool just generates a lot of direct requests, so the IP-addresses will show up in the log files of the target. There has been a considerable number of arrests of people taking part in the attacks in a couple of countries in Europe according to media reports: e. g. England, Spain, France, Netherlands, Turkey. This is noteworthy because arrests normally get very little media attention in Europe compared to the USA.

In general there are roughly two types of DOS vulnerabilities:

The network connection or firewall may be too small to handle the number of packets
The application may require too many resources to handle specific requests.

Simple flooding

The first type is exploited by sending too much data for example using a botnet. Sometimes IP spoofing is used to send small requests to a large number of innocent third parties which will send a larger answer back. A commonly used example are DNS queries.

DoS vulnerabilities

The second type is more sophisticated. It exploits specific weaknesses.

On the network layer for example the attacker may send a huge number of "requests to establish a connection" (TCP SYN Flood), but never completing the handshake. This causes the target to allocate a lot of memory to stores those connections in preparation. Using SYN cookies is a countermeasure.

On the application layer there are usually some operations that take much more resources than average. For example web-servers are optimized to serve static content and they can do this really fast for many people. But a website may have a search function which is pretty slow compared to static pages. This is perfectly fine if only a few people use the search function from time to time. But an attacker can especially target it.

Another operation that is usually pretty slow are logins because they require a number of database operations: Counting the number of recently failed logins from the same ip-address, counting the number of recently failed logins for the username,  validating username and password, checking account ban status.

As countermeasure the application may support a heavy-load mode, which disables resource intensive operations. A famous example of this was Wikipedia in the early days, although the high load was caused by normal users because of it's sudden popularity.

PS: Please note that both of your examples, Sony and HBGary, suffered the most damage from targeted attacks, not flooding. It is unclear if those attacks have been done by the core anonymous group.

  I want to understand how Anonymous or LulzSec or anyone else does it and get an idea of their power.

I think their real power is based on fear.

In the German state Niedersachsen anonymous access to government websites is blocked now. According to the law it shall be possible to use online services anonymously. But the law goes on saying "as far as it is technical possible and feasible". The government claims that their desire to protect themselves is more important, pointing out that there is no right for citizen to demand access to the internet services of the state. (Source: Heise, German)


Potential consequences of using "Everyone" to manage permissions?

I highly recommend against using "everyone" as this grants permissions to users/people/entities who aren't even part of your domain or user base.

A malicious user can only do what your permissions allow (read, write, modify, etc) however, by using "everyone" you are inadvertently granting access to more people than you may realize.

I recommend creating a local users group and populating that local users group with your domain users group. Then grant the local users group permissions to the data.

Also, assuming this is IIS, the account that the application pool runs as and the account the users actually authenticate to the content as are two different things.


Methods to identify strange behavior when virus scan fails?

If I was you, I would just re-image it.

If you need to know what could be running, do a memory dump before you shut it off, and take a copy of the disk (using a live linux ISO and dd) for analysis.

Check any firewall logs you might have, and check for any strange outbound connections.

You don't mention you environment, but if you have domain admins, they could just be messing with you.

Updated:

A hack that had such 'obvious' symptoms wouldn't necessarily be as concerning as one that didn't (which is why I asked about your admins).

The real issue is that if you think you've lost control of your PC (and that does sound like it might be the case), then there is very little you can do to be sure you have addressed the issue, if you don't re-image.

An attacker with sufficiently high privileges can do a lot to mask and obfuscate their actions, and that ultimately means most of your diagnosis tools become less trustworthy: if you do see something, that's generally promising, but if you don't see anything suspicious, then you have no way of knowing what that means.

So, while I can understand you don't want to re-image, doing so is by and large the only way you can hope to have some peace of mind, and certainty about you system.

That doesn't mean you must or should do anything in particular - other than what you think is best.


If JWTs are used for authorization or authentication, they should be either signed or encrypted (which depends on your exact use case).  If you have one auth resource and multiple other resources that want to consume the JWT, signing with a private key (in the auth resource), verifying with a public key (in the other resources) is a good pattern.  If you have multiple servers all serving as auth endpoints and as resources, a shared encryption key can work well, as the token can be created and encrypted, then decrypted when it needs to be verified.

A JWT contains claims, but those claims, as you surmise, should not be manipulatable on the local side.

The folks at Auth0 (disclaimer: no relation to Auth0 at all) have a bunch more info about standard JWT signing algorithms.

One note - restrictions in Angular2 (like all client side pages) are only suitable for end user convenience - for example, hiding pages they can't access so they don't get confused.  You should NEVER count on these, as any restrictions in Angular2/JS can be trivially bypassed.  Before any restricted data is retrieved or restricted operations are performed, user authorization checks should be done on the SERVER.  In fact, authorization checks should be done for every operation - you never trust the client, ever.


Is there a strong reason to salt and hash passwords when password reuse is not an issue?

It's a fair question there are considerations you may not have thought of:

There are ways attackers can get access to parts of your database without accessing all of it, so your point 2 isn't quite correct. Coding errors can leak data, as can sql vulnerabilities. An attacker could get a dump of your passwords and nothing else
If you aren't storing your passcodes hashed then you probably are transmitting them in the clear in which case they could be sniffed if you are not correctly using SSL. Hashing these would provide defense in depth against attacks against transmission
Hashing stored passwords shows due diligence and a commitment to security. If you got breached and it became known that you weren't hashing your passwords it would look bad, even if your reasoning was sound. If you were audited it would look bad as well

My advice would be to hash your passwords, it's easy enough to do and the benefit is there.


How can I find out who owns a block of IPs?


A CRL has value, and is acceptable, by virtue of being signed. Since the CRL is signed, how you obtained it is of no consequence whatsoever on its acceptability. That's the point of certificates and CRL: they can be distributed over arbitrary networks, protected or not, even plain HTTP, email, avian carriers... it does not matter.

Conversely, that the CRL is "online" does not make it any better; you still have to verify the signature, dates and so on.

Thus, CRL (or certificates, or OCSP responses) can perfectly be embedded, transmitted along with the data they qualify, or whatever. For instance, a CMS (PKCS#7) SignedData object contains fields called certificates and crls precisely to embed certificates and CRL (and OCSP responses) that receivers of such an object may find useful for validation purposes. In a similar vein, when a SSL/TLS server sends its certificate, it sends also some extra certificates (a "chain") that the client may use (at its leisure) to validate the server's certificate.

When a CA splits the CRL into multiple sub-CRL, the scope of each CRL is explicitly indicated: a certificate is in the scope of a CRL if the certificate contains a (critical) CRL Distribution Points extension with a "Distribution Point" that matches the Issuing Distribution Point extension in the CRL. See RFC 5280, section 6.3.3, step (b).(2).(i). This CRL splitting is thus not a problem.

An even more extreme splitting is incarnated by OCSP. OCSP is both a format for signed objects (the "OCSP responses"), and a communication protocol to obtain an OCSP response from an online responder. Each OCSP response is functionally equivalent to a CRL that talks about a single certificate. Thus, this is like the most split CRL that you can imagine, and yet it does not create any ambiguous information because each OCSP responses designates explicitly what certificate it is talking about.

Therefore, that a CRL is split or not does not induce any weakness; and obtaining fresh CRL from the CA would not fix anything either, since the downloading process is not protected anyway.

As for your second question: indeed, revocation status is, by definition, a transient property. On the one hand, that the signer's certificate was unrevoked at some point in the past (that's the information provided by an old CRL) does in no way guarantees that the certificate is still unrevoked, and, in particular, that the private key was not compromised in the mean time. On the other hand, recent CRL don't talk about expired certificates (and that's the point of certificate expiration: to prevent CRL from growing forever).

The exit out of this conundrum is time stamps. With a time stamp, you can somehow "freeze" an object at a moment in time. The idea is that, at date T, you take the signed object, along with all certificates and CRL that can be used to validate the signature at that date. You put all of these in some archive format, then obtain a time stamp on the whole. At a later date T', you validate the time stamp; if the time stamp is valid (at date T'), then you know that all the archive contents already existed at date T, and you can then proceed to validate the signature and use the certificates and CRL as if the current date was still T. The concept is that IF you had done the validation at date T, THEN you would still remember it, and act upon it; with the time stamp, you know that at date T all the certificates and CRL existed as is, and thus you could have done that validation.

There are a lot of subtleties in that process, which is why some standards have been defined to support it properly. Look up CAdES (and possibly its brothers XAdES and PAdES, for XML-DSig and signed PDF, respectively).


Is there proof that a cloned SIM is usable and can receive calls & SMS?

You can find some information on this StackOverflow thread.

There cannot be two IMSI active at the same time, and the operator will not fork the communication to the two phones. So not eavesdrop.

Depending on the operator and contract, when a second phone shows up with the same IMSI, it may either be refused to connected the cell phone network, or be allowed but in this case it will be the previous one which will be disconnected (allowing to switch a single line over several SIM cards, for instance one for the cellphone and another for a phone installed in a car).


How serious is the Borgaonkar/Hirschi attack on 3/4g cellular security

First of all, from your own linked article -

  While this flaw doesn’t reportedly allow attackers to intercept calls or messages, it does enable them to monitor consumption patterns and track the phone location.

I.e. they can't see what you are sending or to who. But with several monitoring devices they could triangulate your phone location and know when you are on calls / sending messages. Its also worth noting that this attack tracks a counter managed by your phone. Before you could track a users device you would have to identify which counter is them.

There are also known flaws in 3G encryption - which I would view as more of a risk than this.

The main issue here is that to use this you only need passive monitoring equipment - so it is cheap. I'd argue if you're worried about a state actor you should also be questioning if you can trust your network provider.

So the real risk is stalkers and PI's - who will also usually have a better opportunity to identify which device is you. It is also easier for these parties to identify your device - A stalker can call you and watch for the device receiving a call at exactly that time and duration. The CIA is unlikely to risk doing the same thing with a suspect and tipping them off!


Burp relies on the underlying Java platform for all key handling algorithms and SSL ciphers/protocols, so Burp will be constrained by whatever is available in your installation.

Are you using the latest version of Burp (2.0.12)? We made some changes to try to ensure that all available SSL ciphers are made available to Burp. Also, if you are using the plain JAR file, please try the platform installer, which comes bundled with its own JRE.


Is IP spoofing possible in Windows Desktop with user privileges?

Mostly no. IP spoofing was disabled in XP and is still available on some server versions.

Limitations on Raw Sockets:
On Windows 7, Windows Vista, Windows XP with Service Pack 2 (SP2), and Windows XP with Service Pack 3 (SP3), the ability to send traffic over raw sockets has been restricted in several ways:
UDP datagrams with an invalid source address cannot be sent over raw sockets. The IP source address for any outgoing UDP datagram must exist on a network interface or the datagram is dropped. This change was made to limit the ability of malicious code to create distributed denial-of-service attacks and limits the ability to send spoofed packets (TCP/IP packets with a forged source IP address).
These above restrictions do not apply to Windows Server 2008 R2, Windows Server 2008 , Windows Server 2003, or to versions of the operating system earlier than Windows XP with SP2.

Source: https://msdn.microsoft.com/en-us/library/windows/desktop/ms740548(v=vs.85).aspx


Can I avoid storing data on the web by emailing it?

I am a strong proponent of "The best way to protect data at rest is not to store it in the first place"! Keep it in memory for only as long as you need it.

I like your approach of using encryption to achieve this; if your server only touches the encrypted version, that's equivalent to not touching it at all!

I do have one improvement to suggest though. First, let's take a tangent into forward secrecy; the idea is that every time you encrypt something, you use a temporary disposable key that you don't keep a permanent copy of (aka "one time use" or "ephemeral" key) so that it's very hard for an attacker after the fact to get their hands on the decryption key for some data that they intercepted.

The idea of embedding a public key into the app does not have forward secrecy because you're using the same non-temporary key for every encryption.

Improvement #1: forward secrecy

Phone requests a new ephemeral encryption public key from the server.
Phone encrypts the data using the ephemeral public key.
Phone sends the encrypted data to the server.
Server uses the ephemeral private key (which was only stored in memory as part of the session) to decrypt the data.
Server re-encrypts the data for the client.
Send the encrypted data to the client however is easiest.

Once the server forgets the ephemeral key from step 4, the encrypted data blob that was sent up from the Android device is unrecoverable, so you don't need to be too careful about whether it ended up in router logs, etc. It's only the key that you need to protect.

If step 4 is public key encryption (ie RSA, and not symmetric encryption like AES) and only the client has the private key, then you could even keep a copy of that encrypted data in case the client needs it re-transmitted. This would be sorta equivalent security-wise to not storing it because you don't have the key to decrypt it.

Note: We're basically inventing TLS here, so let's do another version that uses a standard TLS stack rather than inventing our own protocol. We'll find that steps 1, 2, 3, and 4 are all taken care of for us at the TLS (HTTPS) layer.

Improvement #2: TLS

Phone sends the encrypted data to the server over HTTPS.
Server encrypts the data for the client.
Send the encrypted data to the client however is easiest.

Again, so long as you are careful to re-encrypt the data for the client, and not keep a copy of the plaintext, you'll meet the requirement of "not storing it on the server".


Go to local events where you can get hands-on and watch others.

In the Phoenix area, we have

HeatSyncLabs
OWASP Phoenix
BufferOverflow
Arizona Security Practitioners' Forum (AZSPF)
Phoenix 2600

You will want to attend DEFCON in Las Vegas and probably Toorcon in San Diego, because both are 6 hours drive-time from Phoenix. There is also LayerOne in Anaheim.

Online, you can take the Offensive-Security course called Penetration-Testing with BackTrack Online. However, I warn you that it is very grueling to learn the material and apply it in the labs -- I would assume 5 or 6 months and 19 hours a day, everyday -- even with resources such as a full subscription to SafariBooksOnline, where you can search for more information and read books online.

I suggest that you purchase a separate laptop, specifically for Linux. Make sure to get one that is highly compatible with BackTrack Linux. You will want to purchase a separate USB WiFi adapter, such as the Alfa AWUS036H (which is not quite obvious yet, but it's useful to learn the MITM network architecture concepts). If you have Windows installed on a desktop, laptop, or whatever else device -- be sure to install and heavily use Cygwin and/or MinGW, although perhaps you can research those later, when you've already installed and used BackTrack. If you can specify the type (laptop) or graphics chipset options to support CUDA (both NVIDIA and Intel's as options would be nice). Your card will probably be listed on that self-referencing wikipedia article.


What ways are there to elevate from a non-priv account to system on windows?

Firstly, there's the runas application, which allows you to impersonate any user on a system. Just pass the call to the program you want to run through runas and it can be run with any user you like.

Secondly, there's the WindowsIdentity class for .NET which allows you to impersonate users if you have sufficient rights.

WinAPI also features some functions to create processes for a user different than the one executing the current process, see the CreateProcessAsUser function for further details.


What are the general security implications behind using a web app vs its equivalent desktop app?

Installing a desktop application implies 100% trust in the service provider. It is the hypothetical security equivalent of them gaining privileged remote code execution on your web browser--a vanishingly rare security event. Proof of security concept: the provider can do significantly more to your device with the desktop app.

Trust has many facets; Discord and Slack are well known public companies, so it is unlikely that they will do something directly malicious, but you are also placing absolute faith in their security engineering practices. For example, they are chat apps handling user-generated content, and therefore vulnerable to attack. Do you trust Slack or Discord to provide equivalent security investment as Google does with Chrome? If they use a framework like Electron, do you trust them always to use best practices?

As a point of reference; on the desktop, I always use the browser-based clients for Discord and Slack, because I do not feel that the native applications provide enough added value. On mobile devices, I use the apps because they are worth it, and the app security model is more nuanced/sandboxed.


Is there any architecture where the data storage is completely separate?

What you are asking about for your storage is often called Air Gap. You can build it quite easily in a number of ways. But there are plenty of drawbacks:

Whenever you want to do something with your data, you will have to connect your Memory. Anyone attacking you will simply wait for that moment. Stuxnet seems to have worked that way. Computer viruses generally know how to cope with this since the beginning, when they used to spread via floppy disks. I have not checked in detail, but I guess recent ransomware is hibernating some time on the victims computers to make sure that enough relevant devices are mounted (Neal Stephenson even wrote a novel around that plot: Reamde).
Additionally, if you need to work with the data on a regular basis, mounting and dismounting the device will be quite burdensome. So you, or whoever is supposed to use the system might get bored and stop disconnecting.

Still want to do it?

As mentioned by others, you can use a thumb drive, external hard drive, SD-card, etc. If you want to defend your data against destruction (e.g. ransomware), a device with write protection (e.g. SD Cards) might be preferable.
By the way, you can also physically disconnect an (additional) internal hard drive.
If you are not so strict about the disconnecting being physical, you can simply unmount your drive (please check the specific steps needed on your OS). A casual attacker might miss an unmounted drive, but I would not rely on that.
Last, but not least, you can put your data on an encrypted partition (e.g. using  VeraCrypt or BitLocker). Unmount the partition, when not in use. Actually, while this is not exactly what you asked for, it probably will be your best choice in most scenarios, as it protects against whole a number of attacks. You can put that encrypted partition on an external drive, if you still want your physical separation. Also, be sure to back it up frequently to prevent destruction by ransomware.


Risk of tampering when hardware shipment is delayed

If you don't want to be at risk, in the future get a third party to purchase stuff like this in cash, from a store not near your house or work.

You should see if you can download firmware for the drive from the manufacturer's site. Update the firmware on the drive, or at least check its signature.

Remember, it is near Christmas and shipping is likely to take longer than normal.


The simplest solution is to implement TLS encryption and use it when querying the server. TLS traffic between the server and the other server hosting your webapp is going to be encrypted and the authority of the server properly validated. Having SSL/TLS installed however, does not automatically mean your app is using it, you still have to change the endpoint URLs from http:// to https:// in your ajax requests.

Edit: pragmatically I recommend letsencrpyt if using linux, it's no more than 5 minutes to be installed for apache or nginx.


Save encrypted data in server . With no way for server to read actual data

The usual way is to use a two-level key.
You encrypt the data with key_data, which should probably be a symmetric key.
You keep a separate key-file where key_data is encrypted with the key from the devices (key_dev1, key_dev2, ...)
You do not know the key_data; it must be generated by the first access. You also do not know the key_dev1,... because they are on the device of the client.
The client can decrypt the key_data with an existing device, and pass it to a new device which encrypts it with its new device key before uploading it to your key-file.
Of course, something needs to be done with key management by your client; you may want to facilitate this. Be careful that you never get the decrypted key_data on your devices though.


How can I explain "zero knowledge proof" to an end user?

I heard this example during one of the guest lectures back in my grad school. I think it is simple enough since I've myself used it many times, to explain ZKP to people with almost Zero Knowledge of crypto/math.

Let's say that I want to convince you that I have a superpower to count the exact number of leaves on a tree, within a few seconds. I want to convince you without actually revealing that exact number and without revealing how my superpower works. I can devise a simple protocol:

I'll close my eyes and will give you a choice to pull off a leaf from that tree. Since it is just a choice, you will either pull it off or you wont. I have no other way of knowing whether you did it or not than quickly counting the leaves again with my superpower. Now when I'll look at the tree, you'll ask me if you actually pulled it off or not.

If I give you a wrong answer, you'll immediately know that my superpower is fake and so is my knowledge. However, if my answer is right, you might think that I just got lucky. In which case we can repeat the above steps. We can keep on repeating these steps to the point where you're satisfied with the fact that I actually posses the superpower and that I know the exact number.


Can an OpenPGP primary key revoke a subkey of a subkey?

It seems you mix up two concepts of OpenPGP: subkeys and certifications.

OpenPGP subkeys allow a primary key, which is used to create subkeys (technically, the subkeys are created independently but signed by the primary key using a binding signature). Such a set of keys (one primary key, an arbitrary number of subkeys) is considered a single trust unit in OpenPGP, ie. the subkeys are trusted if the primary key is trusted (trusting the subkey is not considered an additional step in the web of trust).

There is no such thing as "subkeys of subkeys", though -- only primary keys are allowed to bind subkeys. You may not construct multi-level subkey hierarchies.

On the other hand, there are certifications in-between primary keys. Using them, you can construct arbitrary trust networks (the web of trust) -- but each primary key is considered a single trust entity, and any other party would have to follow that trust chain and issue trust on each of the keys manually (in contrast to real subkeys, as soon as the primary key is considered valid, automatically the same applies to the subkeys).

Generally, consider a primary key to form an identity -- and (a single level of) subkeys can be used for key management and "keeping the primary key safe". You will have to use it from time to time -- creating and manipulating user IDs, subkeys and certifications on other keys is only allowed using the primary key. Certifications are used to provide trust statements among such identities. While you could of course use certifications to construct such a "two-level-subkey-hierarchy" technically, you are breaking the expected use of certifications and will have a hard time explaining third parties which key to trust (and use for what purpose).


How are exploits like Meltdown and Spectre noticed?

I think you might be confusing the terms exploit and vulnerability.

A vulnerability is a "hole" in the security, caused by a bug or poor implementation. They are detected by security researchers (white hat hackers), crackers (black hat hackers) or people in between (grey hat hackers). Those people are trying to break into the systems to either provide information about the vulnerabilities and ways to fix (patch) them, or to use these vulnerabilities for various purposes. Finding vulnerabilities is a very complicated process, requiring very high skills, and it often involves operating pretty much at the machine code level. The researcher runs pieces of code, while reading the contents of system memory with a debugger, trying to get the system to behave differently than it is expected (or designed) to. For example - a bug may allow a process to read an area of memory it is not supposed to read, as in case of recent vulnerabilities.

An exploit is a piece of software making use of the vulnerability. It's a lockpick of the IT world. Exploits are written by hackers (white, grey or black hats) to either demonstrate how a vulnerability can be used (such exploits are called PoC - Proof of Concept), or to use the vulnerability for gaining access to the system. Exploits are written for the detected vulnerabilities.


How To Securely Run PHP From A Mysql Database

General Thoughts

This seems like an awful idea for production. If you just want to try stuff out, that's another matter.

I also don't see how it is an advantage. Regarding your points:

Where is your db located? Why would you assume that it doesn't require hd reads? And if you think db results are stored in ram, why not php code from files? And have you actually profiled this? For a large scale? I would assume a large speed decrease (and that is not even considering things like not being able to use php caches).
Really? How? And couldn't you just use a library for that?
What? I don't think that this really counts as language neutral

You also need to consider that debugging will be quite difficult, which is probably the biggest downside. Developing and deploying new code will likely also be more difficult.

Threats

The things you need to worry about with your approach:

Being able to write to the code database will lead to code execution. Writes could take place via injection, or by reading out or bruteforcing the database password (if an attacker is able to connect to the database).
Being able to inject into the SELECT code database queries will lead to code execution.

Mitigations

Anyways, if you still want to do this (hint: don't), there are a couple of things you can do to make it a bit more secure:

Store your PHP code in a separate database, accessible with a different user. The user that retrieves normal data from the database should have no access to this database.
Don't allow remote access to the code database, and obviously use a secure password. Don't use things like phpmyadmin, which would in effect allow remote access to the database.
Don't put user input in queries running against the code database.
Ideally don't perform queries against this database all over the place. You probably only need one or two functions which select the code you want. Use prepared statements for those.
Think about only giving the code database user read access to the code database (if this makes sense in the context of your application).

Also, the proper defense against SQL injection is not input sanitation or filtering (it will go wrong), but prepared statements. Casting input to ints is great as defense in depth, but in practice, it is miserable as only defense. I have seen many application that take that approach (plus ecaping/filtering for non-int), and it never goes well.

I assumed that you store your PHP code in the db and execute it with eval, but most of the points will likely apply with other approaches as well.


Is TP-LINK TD-W8151N vulnerable to KRACK?

I can neither see support for 802.11r (fast roaming) nor support for repeater mode in the specification. Based on this the AP is probably not affected but probably only the vendor itself can you the ultimate answer about it. See also the statement of TP-Link regarding a specific type of routers and use case which is part of the vulnerability statment you've linked to:

  Unaffected TP-Link products:
  ...
  Routers and gateways working in their default mode (Router Mode) and AP Mode


What are some tactics to overcome the externality problem of developers not getting enough security training?

Great question, and highly relevant!

First, recognize that training is only one facet of maintaining and building secure systems.  Having the best app developers won't save you if an attacker enters through an unpatched server, or if your bookkeeper is hooked by a phishing email.  Your organization should have a security policy that spells out a full plan; one aspect of the plan would likely be to provide developer training.  This is where a CISSP could help you prepare yourselves.

That said, if you're in a regulated field (PCI DSS, HIPAA, GLBA, SOX, Healthcare, etc.) a security plan that features developer training is often a requirement to pass audit.  That's probably the easiest sell, although it may only get you a bare minimum of training.

Have your systems been breached?  You might be able to build a case that better software could helps prevent the next breach.

Look around your industry at similar solution providers: have they been breached?  Do some research and show your management what it cost them when they were breached, and how a focus on security (not just training) might help you avoid becoming the next victim.

Could your customers using your systems be breached as a result of your negligence?  A robust security policy is not cheap, but it is much cheaper than lawsuits.

Do you have a relationship with a tool vendor that might offer secure development training?  I know Microsoft offers such courses; I expect others do too.  Check with your compiler vendor, your static code analysis vendor, or other similar company.  Pluralsight, Safari, Khan, and many other training companies have on-line training resources.  There's probably a MOOC out there that would get you a proper security education for free.

Also, check with your government.  They may have "cyber defense resources" available that could include training.  In the USA, NIST has the National Initiative for Cybersecurity Education (NICE), which could help you jumpstart things.

Is there an OWASP chapter nearby?  Attend a meeting.  Perhaps networking with them could get you a consultant or instructor for a reasonable price.  Also, there are many fine regional security conferences, and they're much cheaper than the big-name national and international conferences.  If there's one near your city, your company won't even have to pay for hotel rooms.  With nothing to give management but a guess, they're going to imagine that a security program would cost millions that they don't have.  Having a cost estimate makes the discussion with management at least possible.

I'm guessing your organization doesn't have a budget for security at this time.  Have you considered volunteering to be your organization's Security Champion?  Even if you don't know everything about security policies and practices at this stage in your career, just getting people talking about security issues might spur management to act in the next budget year.


I have a decent background in computing and security legalities. While I agree with Steffen Ullrich that this is more of a legal question, here’s what I know. Just a disclosure, I am not a lawyer and I’m not responsible for any legal issues resulting.

Anyway, as long as your company owns their mail server’s in its entirety, and you have been granted root access to the machine, you are not gaining or exceeding your access as defined in the CFAA, and if your HR department is referring to the Freedom Act, this is applying to government surveillance to which your company is not subject to. Companies can make their own private terms of service and privacy policies. As long as it’s noted that the company email is subject to monitoring for malware and unapproved disclosure of sensitive material you should be in the clear.

In short, I’m not personally aware of any laws preventing this as long as your company owns the server entirely and you were granted root access. At that point it’s merely a matter of company policy. If I were you, I would comply with the request to halt auditing, find some case studies online and get a presentation going to give to HR and your manager to explain the benefit to the company from doing this. You may need to convince the company to hire outside legal counsel as HR doesn’t seem to be too knowledge in the subject (or maybe I don’t understand the situation fully).


Is it safe to store and replay user-provided mime types?

No, you shouldn't reply the user-supplied MIME type to the user. The simplest attack that you're exposing your users to would be to upload text/html file with arbitrary Javascript code e.g. in [script] elements. Users given the uploaded file URL would have the Javascript executed, resulting in XSS. This can be somewhat mitigated by serving the files with Content-Type-Disposition: attachment header, but there are ways around that.

Another vector would be storing malicious Java applets or Flash files and many other files whose MIME type make them relevant to web security (HTML5 offline manifest file, crossdomain.xml, various files executable on client - exe, vbs, ...).

While we're at it - be sure to serve the user-supplied files from a domain separate from your 'main' applications, to protect from XSS attacks (same origin policy will stop them if files come from a different domain).


How can I encrypt a password for storage without having to remember another password?

You cannot. But you can reduce the risk associated with the loss of this "master password".

Here are my private and professional method (which I wouldn't sell as perfect).

As the person in charge of some confidential information, I have to deal with the case I would die before being able to transmit everything to the next person in charge. Therefore, I made a printed copy of the master password of my software safe.

For my private use, this printed copy is in a closed envelope with the name of my wife on it as the unique person allowed to open it in this case.

For my professional use, this printed copy is in a closed envelope with the name of the persons allowed to open it in this case. This envelope is stored in my physical safe with a fully mechanical lock.

Concerning the choice of this master password, I printed a list of a few of them generated with a validated password generator, and then tested them on a validated  OS without looking at the screen (cat >/dev/null) to validate my memory error rate to select the best one.


How to insert custom packets into SSL handshake?

In a SSL handshake, the client and the server exchange handshake messages which are encoded in records. If your protocol variant consists in additional handshake messages then you have a problem: at the end of the handshake, two Finished messages are exchanged, and their contents are computed as a hash function over all previous handshake messages, therefore including your extra messages. Corollary: if you have extra handshake messages to insert, you MUST modify the SSL client tool, because that tool computes the hash and will compute a wrong value if it is not aware of your extra messages.

If your protocol variant consists in extra records of a type distinct from "record for handshake messages" (type 22 in the standard), and such that the extra records do not impact the computations of the handshake, then your filter strategy might work. You would have to:

Intercept connections; there are several ways for that, but the simplest is to change the configuration and/or DNS so that the source machine connects not to the target server, but to a server of your own, which itself connects to the rightful server, and relays data in both direction.
Parse the data so that you detect the handshake records, to know where and when your extra messages must be added in the flow (and, similarly, extra messages from the server must be analysed and removed, so that the SSL client tool does not choke on them).

So you are in for some programming. The record protocol of SSL is not complex, as long as you fiddle with the unencrypted records (those before the completion of the handshake); see the section 6 of the standard. Also, see this answer for a detailed introduction on the protocol (which I believe to be easier to read than the standard). For the relaying, the simplest implementation strategy would probably to launch two threads, each thread running in an endless loop of read-from-one-machine-write-to-the-other.


Cases of information stolen by eavesdropping due to non-use of TLS

Does anecdotal evidence count? Many, many people have done this before. One (comical) example is the DEF CON "Wall of Sheep", where the network at the DEF CON security event logs all plaintext logins and posts the information up on a public display. I even recall seeing a guy walking around with a hat covered in a PCB that had a tiny screen on his forehead, displaying in real-time the passwords that people were using over non-secured connections.

Another example is for proxies. It is not at all uncommon for public proxies to sniff for logins. Some such proxies are so blatant that they keep the "mitmproxy" header there, giving away that they are using software specifically designed for this purpose. Occasionally, people also see Tor exit nodes set up by malicious parties which try to steal information from people who are foolishly attempting to submit sensitive credentials over an insecure connection.

People stealing credentials over public, insecure Wi-Fi (at cafés, hotels, or airports, for example) is also a ubiquitous issue. I have seen people attempt this in real-time, and I have done it myself as well (not to steal credentials, but to obtain information on a specific target). There are also countless script kiddies who go to public hotspots (or break weak encrypted Wi-Fi) and simply perform a complete dump of all traffic going through the network for later analysis.


3rd party SSL security and having an extra layer of SSL

This depends on how the data is being transferred.

Here's the thing: unless the attacker forces the client to use a weak cipher-suite SSL is supposedly unbreakable for something like a bazillion years. So as long as there are not unencrypted connections in this chain you're all set, regardless of how often your data is encrypted.

So that's the upside. Here's the downside: if, as you say, "their site/service doesn't have a good security layer for data being transmitted," then no, your data is not truly secure. If they don't support a strong encryption you can pretty much expect to be screwed (if someone decides to screw you, that is). Of course, it's probably in the eCommerce company's contracts to be responsible for the security of transactions, etc., so you're legally pretty safe (Although I doubt your clients will be particularly happy with you).

Like I said though, it depends on how the setup works. If this is a simple <iframe> or something similar, they're actually connecting directly to the eCommerce site, so you can't guarantee any kind of security. On the other hand you have a degree of stability if the information is routed through you, because there is an excellent defense against sniffing attacks: using wired connections. Unless someone physically penetrates your company it will be impossible for them to sniff your connection. So yeah, it doesn't matter how you transmit the information to the eCommerce company because you can be rather confident that an attacker never sees it (he can't connect to your network).

But here's the bottom line: if any sender or receiver of data in a chain of communications does not support strong encryption, the privacy of the information sent along the aforementioned chain cannot be guaranteed.


Do i still need IP restriction on my server if I am using key based auth?

TBH, the IP restriction is crap in my opinion. Never used it in over 10 years I've been using Linux.

Just disable password authentication, root login and change the port. With these three things, you're 99.999999% safe from a SSH point of view, unless:

OpenSSH has a vulnerability.
You expose your private key.

Basically, just changing the port you will not receive any attack unless it's from someone that specifically wants to attack you.


Best practices to protect public/private SSH key pair in web interface?

You don't need too much protection for the public key. It's public after all. An attacker cannot do much harm if he gets his hands on a public key.

You can just compress the key and store on your filesystem, or your database.

What you need to protect is the interface for entering the keys. If an attacker can upload his own key in any user's profile, he can access the servers the user would have access.


How can we disable sudo on CentOS 6 to prevent CVE-2021-3156?

How to disable sudo on CentOS 6 to prevent CVE-2021-3156?

chmod 0644 /usr/bin/sudo will effectively disable sudo for non-root users. It removes the setguid bit, so sudo will work as epxected for scripts executed by root, but not for other users.

Do we have other fix for CVE-2021-3156 on CentOS 6 except disabling sudo?

Upgrade to a supported release. If you run CentOS 6 with untrusted local users, it's probably just a matter of time before a new local privilege escalation surfaces.

Will we be able to execute su - after disabling sudo?

Yes.


Are Thunderbolt-enabled computers without Thunderbolt ports vulnerable to Thunderspy?

Using a Thunderbolt adapter like an USB-to-Thunderbolt adapter on a computer without any Thunderbolt port

Probably not. The attack relies on the Thunderbolt controller's access to internal system buses, combined with custom firmware that lets it read and write data from memory at will. Going through another bus, such as USB, will probably break this chain.

  Temporarily replacing hardware (mainboard) with hardware that has Intel's Thunderbolt port

If you can convince anyone to use your hardware, the game is up anyway. What stops you from virtualizing the OS they want to run? This would give you access to read the memory at will, purely trough software.  This is often referred to as Blue Pill rootkit, after the Matrix movies.

Note that if the TPM is used as part of the protection scheme, the TPM is located on the mother board, and swapping this out will lead to a blank TPM.


Anyone heard of this site and was it safe?

VirusTotal inspects the files served by a website. If you look at the main analysis page you will see different scores for different files. This is not surprising as it is a file hosting site. The site itself might be fine, it's the files that are the problem.

This page lists the shutdown notice you refer to. The domain is still valid until: Sat Sep 08 23:59:59 GMT 2018.

Why it is still active is anyone's guess. The domain owner's email is listed on WHOIS, you could ask him.

All in all, there is nothing suspicious in any of this info.


How can I prove to users of the software that the binaries I post match source code that's been inspected and verified by a third party?

You cannot prove that the binary you provide really matches a given source code. It is not theoretically impossible but it would require substantial cooperation on the part of the compiler. Some researchers are working on that subject for some languages which are better suited to that task than C (mostly ML or Lisp derivative). In any case, there is no readily available product yet, and won't be for some time, so in practice, that's not an option.

Your best options are then:

Provide the source code (with proof that it is the same archive as the one used by the independent reviewer) so that the users may do the compilation themselves.
Ask the people who ran the "independent review" to actually do the compilation and provide the resulting binary.

In any case, users will have to trust someone: you, the independent reviewers... in as much the same way as they have to trust Microsoft, Intel, AMD and all other parties involved in the building of the computer. So maybe the question is not the right one. The compiler itself may push a backdoor on clean source code (there is a very classic example of that kind of trick). Instead of asking how you could prove that the compilation step did not include a backdoor, you should ask: how may I build enough of a good reputation so that people will trust me ?


Authenticating user in same sub-domain using cookies

You could generate a session token that is purely client-side using JSON Web Tokens.

The secret can be shared between your subdomains that authenticate and your app. The secret is used to generate a HMAC over the claims in the token - note they do not need to be encrypted unless you want to hide the data from the user themselves - the HMAC prevents parameter tampering because the end-user does not know the secret to regenerate the HMAC.

Note that sharing cookies over different subdomains can be insecure unless you completely trust every site that is running in a subdomain. This is because the Same Origin Policy for cookies is lax and does not consider a different subdomain or protocol as a different origin. This same "flaw" is what enables you to share authentication, however this might not be right for you if you don't control all sites or have the same security applied to each site (a weakness in one can undermine the security of them all). Possible exploits include session fixation and session hijacking should any vulnerabilities exist in any of the sites on the main domain (even XSS or CSRF).

If this is a concern, use OpenID or OAuth instead of this method.

It is also good practice to set the Secure flag on authentication cookies, and use HSTS to protect the cookies from insecure transport mechanisms (i.e. plain HTTP).

Also be aware that JWTs have the following weaknesses:

They cannot be revoked server-side because they exist purely client-side.
All a logout function can do is delete the cookie, it cannot prevent an attacker that has captured a cookie from continuing to use it to hijack a session.
Any change of password will not logout existing sessions for that user, increasing exposure in the event of any password breach.


How to check that passwords are not stored in a readable format

While cleartext storage of passwords is a bad thing, some kinds of "reversible obfuscation" (e.g. Base64 encoding, or ROT13 "encryption") are not much better, and should be detected as well.

The right way to audit the password storage and verification method is to look at the specification, i.e. the document that states what algorithm is used, and with what parameters. If that document exists, just read it. If that document does not exist, assume the worst; from an audit point of view, unspecified behaviour is as bad as weak behaviour.

Looking at the database is akin to reverse engineering: while it tends to work (you can indeed learn a lot of things through reverse engineering), it also indicates that the product designers are not collaborating with the auditors, and that will make the audit meaningless.

(In a hurry, as an auditor, you could make do with a copy of the source code, and see for yourself how the code processes passwords. Source code is not a good substitute for proper documentation, but it is still much better than inference from a cursory look at a database.)


Can IP address considered as a useful feature for intrusion detection?

I believe the IP address provides useful information.

IP addresses can be "spoofed" in the connectionless protocols like UDP and ICMP. If you're worried about DDoS attacks via traffic amplification, the spoofed address is almost critical to discovering what's going on.

Connection-oriented protocols like TCP or SCTP are far harder to spoof (though BGP hijacking means it happens surprisingly often).

Attacks I've seen from botnets often include a large number of compromised machines from some specific ISPs. In some attacks it was just easier to block entire /16s from the attacked services. Once I found the specific ISP it was easy to look up other netblocks they own and block those too, on grounds that either their CPE was hacked, or their users were insecure as a group. Tracking the IPs lets you find out if specific networks have poor security.


Is it a good idea to expire passwords after a time relative to their security?

No. Password expiration is not to protect against hashes to be cracked. Password expiration is rather to prevent that a hacker does not have unimpeded access to a previously compromised account - that was compromised lets say due to shoulder surfing.

If a hacker does have such a access to a system so he could obtain the password hashes, it often means the hacker has sufficent access to the system in question so the hacker wont need to authenticate.

I would suggest instead using variable expiration times that is in sync with access level. Eg, a regular user that does not have access to anything except a workstation with internet access, can have a password with less requirements and no expiration.
A medium user that has access to some confidential data, could for example have a stronger password policy and expiration lets say each 6 month.
And limited/local sysops/sysadministrators then have a even stronger password policy and password expiration after 90 Days.
And global administrators could simply have the strongest password policies and 30 Days of expiration.

If the system in question is custom one, for example a custom web interface or such, you could code that the password expiration and complexity requirements is directly derived from the encoded access level for the user in question.
(And of course, you could create a complexity factor out of password length and complexity, allowing a longer password to replace a complex one and vice versa)


safely changing distribution, is there a strategy to get an distro iso image untampered?

https://www.archlinux.org/download/ has the SHA1 hash for the ISO image as well as the distribution's PGP key. Use that to verify the authenticity of your Arch Linux download.

Since that page is hosted on an HTTPS site, that should be a reasonable guarantee that it comes from the organization to which the SSL certificate was issued. (It is possible that the website has been hacked and those checksums and signatures are false, but that would be a huge problem for The Arch Linux project.)


Tool to grab sensitive information from command lines

On Linux systems, all of this information is available through the proc interface, and as such is fairly easily scriptable. As a working example (coming from a RHEL6 system) let's look at the rsyslog process.

[user@node1 ~]$ ps aux | grep rsyslog
root      1105  0.0  0.0 248680  1460 ?        Sl   May29   0:42 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
user     26440  0.0  0.0 103236   824 pts/4    S+   11:38   0:00 grep rsyslog

Right, so the pid is 1105, easy enough. Since the proc system stores processes in the format of /proc/<pid> let's see what data is being presented.

[user@node1 ~]$ ls -l /proc/1105
ls: cannot read symbolic link /proc/1105/cwd: Permission denied
ls: cannot read symbolic link /proc/1105/root: Permission denied
ls: cannot read symbolic link /proc/1105/exe: Permission denied
total 0
dr-xr-xr-x. 2 root root 0 Jun 15 11:39 attr
-rw-r--r--. 1 root root 0 Jun 15 11:39 autogroup
-r--------. 1 root root 0 Jun 15 11:39 auxv
-r--r--r--. 1 root root 0 Jun 15 11:39 cgroup
--w-------. 1 root root 0 Jun 15 11:39 clear_refs
-r--r--r--. 1 root root 0 Jun 15 11:35 cmdline
-rw-r--r--. 1 root root 0 Jun 15 11:39 coredump_filter
-r--r--r--. 1 root root 0 Jun 15 11:39 cpuset
lrwxrwxrwx. 1 root root 0 Jun 15 11:39 cwd
-r--------. 1 root root 0 Jun 15 11:39 environ
lrwxrwxrwx. 1 root root 0 Jun 15 11:39 exe
dr-x------. 2 root root 0 Jun 15 11:39 fd
dr-x------. 2 root root 0 Jun 15 11:39 fdinfo
-r--------. 1 root root 0 Jun 15 11:39 io
-rw-------. 1 root root 0 Jun 15 11:39 limits
-rw-r--r--. 1 root root 0 Jun 15 11:39 loginuid
-r--r--r--. 1 root root 0 Jun 15 11:39 maps
-rw-------. 1 root root 0 Jun 15 11:39 mem
-r--r--r--. 1 root root 0 Jun 15 11:39 mountinfo
-r--r--r--. 1 root root 0 Jun 15 11:39 mounts
-r--------. 1 root root 0 Jun 15 11:39 mountstats
dr-xr-xr-x. 6 root root 0 Jun 15 11:39 net
-r--r--r--. 1 root root 0 Jun 15 11:39 numa_maps
-rw-r--r--. 1 root root 0 Jun 15 11:39 oom_adj
-r--r--r--. 1 root root 0 Jun 15 11:39 oom_score
-rw-r--r--. 1 root root 0 Jun 15 11:39 oom_score_adj
-r--r--r--. 1 root root 0 Jun 15 11:39 pagemap
-r--r--r--. 1 root root 0 Jun 15 11:39 personality
lrwxrwxrwx. 1 root root 0 Jun 15 11:39 root
-rw-r--r--. 1 root root 0 Jun 15 11:39 sched
-r--r--r--. 1 root root 0 Jun 15 11:39 schedstat
-r--r--r--. 1 root root 0 Jun 15 11:39 sessionid
-r--r--r--. 1 root root 0 Jun 15 11:39 smaps
-r--r--r--. 1 root root 0 Jun 15 11:39 stack
-r--r--r--. 1 root root 0 Jun 15 11:35 stat
-r--r--r--. 1 root root 0 Jun 15 11:39 statm
-r--r--r--. 1 root root 0 Jun 15 11:35 status
-r--r--r--. 1 root root 0 Jun 15 11:39 syscall
dr-xr-xr-x. 6 root root 0 Jun 15 11:39 task
-r--r--r--. 1 root root 0 Jun 15 11:39 wchan

I'm running this as a normal user, so some of the information is unavailable. No big deal, because what we really want is that there file called cmdline.

[user@node1 ~]$ cat /proc/1105/cmdline
/sbin/rsyslogd-i/var/run/syslogd.pid-c4[user@node1 ~]$

The arguments look like they're all run together. In fact, they are separated by null characters. You'll get a more friendly display by turning the null characters into newlines (but note this will drop the distinction between separations between arguments and actual newlines in an argument):

[user@node1 ~]$ tr '\0' '\n' </proc/1105/cmdline; echo
/sbin/rsyslogd
-i
/var/run/syslogd.pid
-c
4
[user@node1 ~]$

Granted, this doesn't really give us anything beyond what we got from the ps output. However, depending on what you want it may be more easily scriptable. If we wanted to work exclusively in bash, for instance, you could use this structure to iterate over all processes:

for p in /proc/[0-9]*/cmdline; do
  …
done

Then use that as a file list for processing.

If you are instead into Perl, there exists a module called Proc::ProcessTable that queries the proc system and exposes the same information as an object.

All that being said, if you want to look for passwords on the command line, you may sometimes be disappointed. Some applications somehow work to mask it out, for example MySQL:

[user@node2 ~]$ ps aux | grep mysql
user     7974  0.0  0.1 157116  2732 pts/0    S+   11:47   0:00 mysql -u root -px xxxxxxxxxx database
[user@node2 ~]$ cat /proc/7974/cmdline
mysql-uroot-pxxxxxxxxxxxdashboard[user@node2 ~]$


End-to-end encryption for localtunnel/ngrok setup

It would be possible to use ngrok or some other un-trusted source as long as you encrypt the traffic before you send it.  This isnt to say that ngrok is a bad service, simply that it is an unknown and thus un-trusted.

To encrypt this traffic you would need to setup your own key exchange ... both the Sender and the Recipient would need to create a pub/priv key pair and share the public keys with each other.  Once the public keys have been shared one or both parties can randomly generate a binary string to be used as the symmetric key for further communication.  If you want both parties to contribute to the key you can hash the binary strings together to create the final key. (it should be noted that these symmetric keys should be encrypted with the opposing parties public key before being exchanged).  Once the symmetric keys have been exchanged something like aes256 could be used to encrypt all further traffic.

This is a high level overview of how things like SSH handle key exchange and setup a secure tunnel. see also: https://security.stackexchange.com/a/73132/92213


Explanation
It seems that it is not a virus or a hack on your computer. The message that is shown can be set when you lock your device from iCloud (Find My Phone).
So it seems that Apple has an iCloud backdoor or something like that. Only with the password it would not be possible to login to iCloud, because of the activated two-factor authentication. So the attackers really have access to your iCloud, but not directly to your local computer.
The iCloud account of my mum is from April 2017, so it is not just an old iCloud hack.
Most likely it is because of the following iCloud hack:
Hackers: We Will Remotely Wipe iPhones Unless Apple Pays Ransom (Vice, Mar 21 2017)
Solution
If the same happened to you, you have to take your Apple device to the next Apple Store together with your receipt. The receipt proofs that you are the owner the device, so the Apple Store is able to unlock it.
For security reasons I recommend to reset your password and activate two-factor authentication.
If you have the a 2011 Macbook, the PRAM / NVRAM wipe could work for you too, but you have to do it on your own risk.


Safe to make a VPN connection over coffee shop WIFI?

Yes, a VPN connection encrypts the connection between your computer and the remote VPN host.  The connection would just look like gibberish to anyone sniffing the traffic, either in the coffee shop or on the Internet.  It is worth noting that the same applies to any content sent over HTTPS even if you aren't using a VPN.

It is also worth noting that if you are using the current version of Microsoft Terminal Services (ie remote desktop), the VPN connection isn't even strictly necessary (from a security stand point) as the remote desktop connection itself is also encrypted.  Note that this setting can be optionally reduced by administrative configuration on the network though, so the VPN still isn't a bad idea.


App permissions to access hardware "at any time without your confirmation"

the eprmission means just as what you think it means.
it may use the systems at anytime it wants to, so it can activate the camera anytime it wants too.

what i think of it? well, here in europe, privacydoesnt get as violated as in the USA when it comes to telecomunication and technology.

not saying we dont get it, but the USA laws on that area are not only smoother, but also more unfair


How do I secure my network with an open wifi?

If the subnet is logically separated from your business network using a firewall, then it will make your network more secure.

If it's just a separate IP subnet with full access into your business network, then it will no really make things any more secure.

This question has more details: Sharing wifi at a business - Bad Policy?


How does Android 6 full encryption work ... when it doesn't ask for the password at start time?

The method of encryption changed in Android 7 (Nougat).

In previous versions of Android, the OS used a simplistic full-disk encryption scheme, similar to that common for desktop and laptop computers. This required a password at boot to be able to access pretty much anything. A side effect was that the phone had to keep everything decrypted while the phone was locked, or else it couldn't do normal smartphone functions like receive push notifications.

This was a pretty major problem, so in Android 7 Google changed Android to use a more sophisticated (but still less sophisticated than iOS's) encryption system, in which files that are determined to be sensitive are individually encrypted. The effect you'll see as a user is that certain things will now work from a boot before you've given the OS the information necessary to derive your encryption key.


What does these warnings mean on an SSL connection by firefox (only)

Warning 1: Owner: This website does not supply ownership information

This means that the SSL certificate does not specify the organisation that owns it. This can be an important detail, especially in extended verification certs (EV), since it ties the certificate to a real entity.

Warning 2: Verified by: Not specified

This is a really important problem. The certificate does not specify which certificate authority (CA) has signed it. This might mean it's self signed, so you can only rely on the connection for security against passive attackers. An active attacker, i.e. one that performs a man-in-the-middle attack, could generate his own certificate and pretend to be the server.

Warning 3: Connection Partially encrypted - Parts of the page you are viewing were not encrypted before transmitted over the internet.

This means that elements in the page you are viewing are not transferred via SSL. This could mean images, scripts or even CSS files. The problem here is that some traffic will be sent in cleartext, potentially revealing what page you are viewing or more important details, such as cookies.

In summary, this is a very poorly secured SSL setup. You should certainly not use it to input any personal details or potentially sensitive information.