Are Windows Superseding Patches not fully securing my systems?

When doing patch enumeration, Nessus looks at the installed patch list and only understands patches that are in its database. If the rollup patches which supersede the original patches are relatively new, then Nessus may see that the old ones are not applied without knowing that there's a rollup in place, and may falsely report that the original patches are missing. When you apply the registry fix, Nessus identifies you as no longer vulnerable because you've applied a workaround that it detects is applicable.

Your first step here is to update your Nessus plugins to ensure they're current. This will help avoid this kind of problem, but Nessus will always be a short while behind the patch cycle on these.

Your second step should be to check which module reported the issues. If you're doing an authenticated or local scan and it's the patch plugin which reported them, then Nessus is simply failing to pick up the rollup patch. Verify that the patch is included in the rollup (which it looks like you have) and don't worry about it - it's a false positive. However, if you're doing a remote scan and the plugin which discovered it did so via the network (e.g. TCP port 123 has vuln xyz) then the vulnerability may well be present, and you should do further research.


Bots are using my own static IP to brute force DNS/Email server

Simplest solution for blocking spoofed IP addresses in this situation is to get your ISP to drop packets to your IP address which purport to be from your IP address.
If they won't/can't, you can buy DDoS mitigation services from various providers.
Failing that, why don't you drop anything at the interface on your server that has a spoofed address.


The easy way to handle your problem is to allow cookies only to stay during a session. Whenever you tear down your browser session, all cookies get purged.

Firefox at least has this feature built in, so you don't actually need any extension to do that for you. (Settings -> Privacy -> History -> drop down "with user specific settings" -> "accept cookies until" -> drop down "firefox is closed")

Given, this does not allow your cookies to be "unlocked" like passwords, but it removed the problem of being logged on.

Yet, such a plugin would be pretty neat. I can't believe there is none. If that is true: Go for it and make one - or a change request.


What are the risks of removing ISATAP from the default global block list?

Microsoft Dynamic DNS allows hosts to request a specific host name they would like to use. (That's what the dynamic means!)

As you'd expect, you can't use this feature to steal an existing host's name, but there's a related attack where you steal the name of a host that doesn't exist, but that clients look for as part of an autodiscovery protocol.

For example, when Internet Explorer starts up, it tries to discover if there is a proxy server it should be using. One of the ways it does this is to try to connect to a server called wpad and download a Web Proxy Automatic Discovery configuration file.

Similarly, if you have an IPv4 network, and a client application that wants to send IPv6 traffic to somewhere, the client needs to find an Intra-site Automatic Tunnel Addressing Protocol (ISATAP) router - the client then wraps the IPV6 traffic in an IPV4 packet and sends it to the ISATAP router, which unwraps the traffic and sends it on. You guessed it: one of the ways the client finds a suitable router is to try connecting to a server called isatap and downloading a list.

So if you don't have hosts called wpad and isatap, you need to make sure that a malicious client can't register these names, as otherwise they can deliver fake configuration files to clients and steal traffic.

You'd think you'd just tell the DNS server not to hand out those names, but that would be too easy. Instead, you use the global block list, which is a list of names that the DNS server will never resolve, whether it has records for them or not. By default this list has two entries, wpad and isatap.

This means, then, that if things change and you set up a real wpad/istap host, you need to remove their names from the block list before it will work.

In your specific situation, Direct Access is IPV6 based, and the hosts your clients connect to must all use IPV6. So, if they are on an IPV4-only network, you have to deploy ISATAP for it to work, and hence you have to remove ISATAP from the global blocked list.

Doing this shouldn't introduce a security problem, because once Direct Access is in place you'll have a real host called isatap and malicious clients will not be able to register that name.

One last note for those wondering why you say dnscmd /config /globalqueryblocklist wpad when it's isatap you're enabling, not wpad. This command sets the block list to the specified value.  i.e. by default the block list reads "wpad isatap" and the command changes it to just be "wpad".


what makes envirnments vulnerable/protected vs shellshock bug

It sounds as though your systems may have been patched already. If you want to perform more due diligence, you would have to check the version of bash against the patched versions. You can do this with the command bash --version or echo $BASH_VERSION. At that point I would consult your distro's documentation to ensure the version appears to match the patched version.


In "Promiscous mode", the driver still outputs standard ethernet frames belonging to the one wireless network you are currently associated to (identified by the BSSID). Possibly the device will only dump packets from the AP to wireless devices, but not packets from wireless clients to the AP, as receiving packets from non-AP devices is not used in AP client mode.

In "monitor mode", you capture packets from all the networks operating on a chosen channel (possibly even adjacent channels - there is a reason that 802.11 DSSS beacons contain the channel number in the payload), and the driver does not output plain ethernet, but needs to output more headers (there are 3 addresses in a 802.11 header, instead of just 2 addresses in the 802.3 ethernet headers). Only special wireless monitoring software is able to process packets in the format dumped by the driver in monitor mode.

So monitor mode is advantageous if you want to really see what's going on, while promiscous mode is there for compatibility with standard ethernet network sniffing tools that can't handle the extended 802.11 frame format. If the tool you want to use supports monitor mode, use it. Use promiscous mode only as backup.

Furthermore, some wirelesse driver/hardware allows your device to send completely arbitrary packets while in monitor mode - this is called packet injection.


Can I intercept DNS-over-HTTPS (DoH) or -TLS (DoT) in my home network?

Redirecting the requests to your Pi-hole so that they gets answered there is not possible since your Pi-hole DNS server does not have the expected certificate.

Blocking DNS over TLS can be done by blocking outgoing port 853. How this blocking can be achieved in your specific but unknown network is unknown but usually a perimeter firewall can do it.

Blocking DNS over HTTPS is much harder since it uses the same port as normal HTTPS traffic (443). If you know the target IP then you could block this, otherwise you might try to detect such traffic due to specific communication pattern.

  ... since some device do or may in the future use hardcoded DNS servers to bypass filtering.

If they do this they might also use something else than DNS to get there information or use DNS tunneled inside other protocols or on non-standard ports. You cannot reliably filter something here which explicitly tries to bypass any filtering.


Podman: What if user is member of docker group?

Yes, I'd say that your assertion here is correct. Gaining access to an account which is a member of the Docker group on a host (absent other custom protections) will allow the attacker to escalate their privileges to be root on the host.
Typically podman is used for developer systems rather than running production services, which would usually be done with something like CRI-O, in that kind of environment.
It's possibly worth noting that it is possible to run Docker in a rootless mode similar to podman, which may mitigate this kind of issue.


What is the difference between SSL vs SSH? Which is more secure?

SSL and SSH both provide the cryptographic elements to build a tunnel for confidential data transport with checked integrity. For that part, they use similar techniques, and may suffer from the same kind of attacks, so they should provide similar security (i.e. good security) assuming they are both properly implemented. That both exist is a kind of NIH syndrome: the SSH developers should have reused SSL for the tunnel part (the SSL protocol is flexible enough to accommodate many variations, including not using certificates).

They differ on the things which are around the tunnel. SSL traditionally uses X.509 certificates for announcing server and client public keys; SSH has its own format. Also, SSH comes with a set of protocols for what goes inside the tunnel (multiplexing several transfers, performing password-based authentication within the tunnel, terminal management...) while there is no such thing in SSL, or, more accurately, when such things are used in SSL they are not considered to be part of SSL (for instance, when doing password-based HTTP authentication in a SSL tunnel, we say that it is part of "HTTPS", but it really works in a way similar to what happens with SSH).

Conceptually, you could take SSH and replace the tunnel part with the one from SSL. You could also take HTTPS and replace the SSL thing with SSH-with-data-transport and a hook to extract the server public key from its certificate. There is no scientific impossibility and, if done properly, security would remain the same. However, there is no widespread set of conventions or existing tools for that.

So we do not use SSL and SSH for the same things, but that's because of what tools historically came with the implementations of those protocols, not due to a security related difference. And whoever implements SSL or SSH would be well advised to look at what kind of attacks were tried on both protocols.


There are a couple of possibilities, the more effective ones being more expensive.  I'll rate them from best to worst.

1) Get a DDoS mitigation service such as akami.  They will provide you will a lot of bandwidth and will block any DDoS attacks from getting to the lesser bandwidth of your own connection to your ISP.

2) Get a server hosted at a nearby datacenter to use as a VPN/Proxy.  They may be able to provide you with some help against the DDoS or may simply have good enough bandwidth to mitigate the DDoS

3) Get a VPN/Proxy from an existing company.  This will give you bad latency and bandwidth without even getting DDoS'd and may not hold against the DDoS.

*) Get two VPNs, one for your public address (skype or whatever) and one as your hangouts proxy.  Then if the skype vpn goes down your hangout one will still be up.  This is assuming they can't get your IP directly from the hangout.

akami ddos defender


How can Port Stealing be used as a MiTM attack?

The behavior you describe is true. However, the trick is that the attacker software will not keep the stolen port for itself, it will proceed in the following loop:

Steal the port,
Receive some data,
Give the port back,
Forward the data to the real destination,
Go back in step 1 by stealing the port again.

You can find more information in Ettercap documentation, which includes the excerpt below:

  Port Stealing

  This technique is useful to sniff in a switched environment when ARP
  poisoning is not effective (for example where static mapped ARPs are
  used).

  It floods the LAN with ARP packets. The destination MAC address of
  each  "stealing" packet is the same as the attacker's one (other NICs
  won't see these packets), the source MAC address will be one of the
  MACs of the victims.

  This process "steals" the switch's port of each victim.

  Using low delays, packets destined to "stolen" MAC addresses will be
  received by the attacker, winning the race condition with the real
  port owner.

  When the attacker receives packets for "stolen" hosts, it stops the
  flooding process and performs an ARP request for the real destination
  of the packet.

  When it receives the ARP reply it's sure that the victim has "taken
  back" his port, so ettercap can re-send the packet to the destination
  as is.

  Now we can re-start the flooding process waiting for new packets.


Why isn't Internet DNS based on blockchain?

We already have such a system: DNSSEC, that allows precisely the control required.

The problem with using Blockchain with domains, is that theres no inherent link between the domain and the keypair using for signing.

So this information must be tied to each other somewhere. And somewhere would then be at the registrar, making the whole blockchain then useless as the registrar could then directly host the public key used for verifying - voilá - we reinvented the wheel: DNSSEC.

The blockchain is useful in 3 cases: Either, when you want to store public information, that can never be tampered with regards to time (time-stamping of information) or never be erased.

The third case would be where theres a inherent link between the domain and the key used for signing, thats whats makes the system truly decentralized. But then we would get web adresses that look like TOR onion adresses.
And TOR onion adresses is exactly this, hashes of public keys that makes it impossible to "forge" a site using a specific onion URL, and this can be validated without having to trust anyone.

To further illustrate the problem:

[secret data] = the private key
[public data] = the public key
[custom data] = your domain name or whatever name you want to associate with public key

There might be possible to create a process where you use some [secret data] + [custom data] to render a output of [custom data], but where [secret data] can be used in such a way that the corresponding [public data] can be programmatically related to [custom data] without having to trust anyone.

The only way I could come up with is a process like vanitygen, as if anyone can create a matching [secret data] for any [custom data], anyone could also "steal a domain name".

Thats why you need a trusted third-party, that will make this association, and make this association only for the person who owns the domain name in question, eg not allow this association for a domain name that is taken. So when it comes to domain names, you MUST trust somebody.

Because I bet you don't want a domain name like this:

Hey. I created a new website.
Here it is: l05gh64k3wghvsk7jfs09a07654354f7

Then we don't need any DNS at all, we could simply use the IP adresses.


Most browsers have a limit on how many cookies they'll store for a single TLD.  So, if the server is configured to allow a sufficiently large request to include all these cookies, the requests won't be rejected anymore.  Apache has options like LimitRequestFields, LimitRequestFieldSize, etc.  Setting these sufficiently high should allow the request to be processed with all the attacker-added cookies, though at a memory and processing time cost.

Of course, if you control the entire domain, there's other mitigations possible,
since it requires that an attacker is able to author content that sets cookies on *.targetdomain.com, it is only possible to exploit with attacker-controlled content on that domain.  So if attackers are not allowed to create server-side scripts (i.e., anything that can send Set-Cookie) or craft JavaScript (that can set cookies via document.cookie) then you'd be vulnerable.  So clearly, the mitigation is not allowing users to create content on those domains.


It sounds like the site you were testing doesn't use HTTP Strict Transport Security (HSTS), or at least doesn't pre-load it. However, it's entirely plausible that the CAPTCHA service is hosted on a site that does use HSTS (for example, Google does for most of its sensitive sites); if your SSL-stripping proxy blocked all HTTPS traffic, then that would simply break the CAPTCHA service. Simply allowing requests that go over HTTPS despite stripping to succeed would fix that. It's certainly not going to prevent MitM attacks from succeeding;

Alternatively, it's possible that your SSL stripping itself broke the CAPTCHA. SSLStrip by necessity modifies the HTTP responses; it's possible that it makes some modification which just breaks something (either accidentally, or because there's some explicit check for SSL stripping in the CAPTCHA's JS). It's not hard to detect SSL stripping. On the other hand, it's not hard to modify the stripping functionality to fool any particular instance of detection code, either.

Bottom line, CAPTCHAs do not protect against SSL stripping attacks, or any other kind of MitM. There's nothing, transport security wise, different about a CAPTCHA than about any other cross-origin (or, sometimes, same-origin) script-initiated request. They (like anything else) might accidentally or deliberately break in the presence of such attacks, but a competent attacker would be able to un-break them, and verify that they are unbroken, before targeting a victim.


Why does this Laravel CSRF vulnerability work?

chrismsnz here...

Long story short, DarkLighting is pretty much right.

Input::get() usually reads from request parameters, but if the request is JSON then it reads from the JSON body. JSON allows you to specify the type of data so instead of a CSRF token string, I sent an int(0) which will pass that loose comparison most of the time.

The other trick is that usually you cannot send JSON requests cross-site, due to the CORS check in browsers. However, Laravel has a very poor JSON check, it basically checks to see if the string '/json' is anywhere in the content type and if its there, runs the whole request through a JSON parser and feeds it into Input.

Therefore you can exploit it using something like this (jquery example)

$.ajax("http://<laravel app>/sensitiveaction", {
    type: 'post',
    contentType: 'application/x-www-form-urlencoded; charset=UTF-8; /json',
    data: '{"sensitiveparam": "sensitive", "_token": 0}',
});


Yes, this does look like a pretty good scheme for protecting cookies.

Another more recent scheme in this area is SCS: Secure Cookie Sessions for HTTP, which is a solid scheme, very well thought-out.  I recommend reading the security discussion of that document to get a good sense of what the security threats may be.

To help understand the purpose and role of the cookie scheme you mention, let me back up and provide some context.  It is common that web applications need to maintain session state: i.e., some state whose lifetime is limited to the current session, and that is bound to the current session.  There are two ways to maintain session state:

Store session state on the server. The web server feeds the browser a session cookie: a cookie whose only purpose is to hold a large, unguessable bit-string that serves as the session identifier.  The server keeps a lookup table, with one entry per open session, that maps from the session identifier to all of the session state associated with this session.  This makes it easy for web application code to retrieve and update the session state associated with a particular HTTP/HTTPS request.  Most web application frameworks provide built-in support for storing session state on the server side.

This is the most secure way to store session state.  Because the session state is stored on the server, the client has no direct access to it.  Therefore, there is no way for attackers to read or tamper with session state (or replay old values).  It does require some extra work to keep session state synchronized across all servers, if your web application is distributed across multiple back-end compute nodes.
Store session state on the client.  The other approach is to put session state in a cookie and send the cookie to the browser.  Now each subsequent request from the browser will include the session state.  If the web application wants to modify the session state, it can send an updated cookie to the browser.

If done naively, this is a massive security hole, because it allows a malicious client to view and modify the session state.  The former is a problem if there is any confidential data included in the session state.  The latter is a problem if the server trusts or relies upon the session state in any way (for example, consider if the session state includes the username of the logged-in user, and a bit indicating whether that user is an administrator or not; then a malicious client could bypass the web application's authentication mechanism).

The proposal you mention, and the SCS scheme, are intended to defend against these risks as well as possible.  They can do so in a way that is mostly successful.  However, they cannot prevent a malicious client from deleting the cookie (and thus clearing the session state).  Also, they cannot prevent a malicious client from replaying an older value of the cookie (and thus resetting the session state to an older value), if the older version came from within the same session.  Therefore, the developer of the web application needs to be aware of these risks and take care about what values are stored in session state.

For this reason, storing session state in cookies is a bit riskier than storing it on the server, even if you use one of these cryptographic schemes to protect cookies.  (However, if you are going to store session state in cookies, I definitely recommend you use one of these two schemes to protect the values in the cookies.)

Why would anyone store session state in cookies, given that it can just as easily be stored on the server side?  Most of the time, there is no reason to.  However, in some exceptional cases -- such as a HTTP server that is extremely constrained in the amount of storage it has, or in load-balanced web applications that are distributed across multiple machines without good support for synchronized session state -- there might be justifiable reasons to consider storing session state in cookies, and then using one of these schemes is a good idea.

P.S. A related topic: if you use ASP.NET View State, make sure you configure it to be encrypted and authenticated: i.e., configure ViewStateEncryptionMode to Always and EnableViewStateMac to true; if you use multiple server nodes, generate a strong cryptographic key and configure each server's machineKey to use that key.  Finally, make sure you have an up-to-date version of the ASP.NET framework; older versions had a serious security flaw in the ViewState crypto.


Encrypt files securely on remote server?

This approach could have implementation issues, and there are already solutions to what you want.

It's simple; make an assymetric keypair (say PGP) on another server:

gpg2 --full-gen-key

Export the public (decryption) key:

gpg2 --output public.gpg --export me@mymail.com

Import the public key on the VPS:

gpg2 --import public.gpg

Use it to encrypt data on the VPS:

gpg2 --recipient me@mymail.com --encrypt my-file.txt

The result will be a file that is only decryptable on your local machine containing the other private part of the keypair. Be careful not to leave the file on the disk unencrypted, the VPS provider will make backups of the HDD.


Password seal by paper or by password manager?

This is not unusual for core passwords. Storing them in a digital password manager means that the password manager now has a password that needs to be protected. What do you do with that? Often through a paper process like you described. This type of paper process is normal.

What is unusual is the number of systems involved. A paper process works for a handful of core passwords.

What you might want to suggest, instead of a password manager, is a Privileged Access Manager tool. This will manage root and admin passwords in a variety of useful ways, like changing them every time they are used, etc.


Securing communications in decentralized network of servers

In light of the broad question I will concentrate on answering your more specific one regarding full access to the centralised server. I'll refer to said server as a CA because this is essentially what you are describing.

TL; DR it depends

Let's presume that full access means knowledge of the CA's private key. This may not always be the case if we consider HSMs as against a simple server, but that makes this a boring question. Such access to the private key will then allow an adversary to sign arbitrary certificates which are automatically trusted by all network members regardless of their false claims of ownership.

Eavesdropping implies passive listening on the network. Even with CA compromise only ciphertext is visible to the adversary as individual servers have never published anything beyond their own public keys. They are assured of communications with the true owner (whomever that may be) of a specific public key; being passive implies that there is no such change of end-point keys.

An active involvement as a MITM would allow both eavesdropping and tampering through impersonation.

As a side point; in the case of (EC)DHE usage, even knowledge of individual server private keys would be protected against passive eavesdropping as a MITM would have to intervene to establish shared secrets with each party.


Mechanisms to prevent error propagation in wireless networks with respect to the avalanche effect

Wireless protocols, or even wired protocols, are based on packets, often called frames. A typical frame will have a checksum, that is used to detect whether the frame was damaged or not. If the frame is detected as damaged, it is dropped altogether; it is up to the upper layers to provision for acknowledge and reemission of missing frames (that's what TCP does). Then still upper layers (SSL/TLS) employ cryptography to detect remaining alterations, that can be assumed to be malicious.

When encryption is applied at the frame level (at "layer 2" in the (in)famous OSI model), each frame is encrypted and decrypted independently of the others; thus, no decryption error "propagates" to other frames. The so-called "avalanche effect", a concept in cryptographic algorithm designs, does not imply that subsequent frames will be garbled; in fact, in most cases, that effect is limited to one or two block. This can be viewed in the CBC mode of encryption: if you modify one encrypted block, then the modification alters only two blocks after decryption.

There are some protocols that do not drop modified frames; typically, GSM (for voice calls) will try to recover from transmission errors. GSM uses the A5/1 stream cipher, so that encryption is XORing with a key-dependent stream. If a bit is flipped in the encrypted frame, then the corresponding bit will be flipped in the decrypted data, but other bits will be unaffected. Since this is voice, slight alterations don't make the words unintelligible, so GSM chooses to keep such partial frames. In fact the receiver will not even know that the data was altered in transit.

Note that this does not mean that A5/1 has no avalanche effect. In fact it still has a lot; if you change a single bit in the key, then the whole internal state of A5/1 (and the subsequently produced stream) is completely modified. A5/1 has other shortcomings (that all boil down to a way too small internal state), but not a lack of avalanche effect.

(Basically, "avalanche effect" does not mean "change 1 bit of encrypted text and the whole plaintext is turned into junk". That expression is a concept which makes sense only within a specific context of internal cryptographic primitive design.)


Are T4 and/or T30 fax protocols secure/encrypted?

No. The facsimile protocols T4 (Modified Huffman) and T30 (ITU-T T.82) are primarily compression algorithms there is no encryption involved.

https://en.wikipedia.org/wiki/Fax#Compression

Regarding the "Networked" component that primarily refers to newer fax machines which have wireless or Ethernet connectivity so that a group can send documents over the network to the fax. This is also very common for the multifunction (fax-printer-copier) devices.

Per the question you raised keep in mind that any given telecommunications circuit is also likely to traverse the Internet in an unencrypted state. Many of the telecommunication providers leverage a variety of third-parties to transport telecom connections. In the U.S. the phrase "dedicated connection" frequently means allocated to you the customer and does not mean that there are copper wires connecting two different locations. Given the owners of various metropolitan fiber-rings and long-haul fiber carriers your communications could easily traverse a dozen different companies networks where, potentially, it could be intercepted.

Note: Some regulatory requirements treat facsimiles as protected and not having the same requirements as data sent over the Internet. If your organization is looking to secure their faxes due to a regulatory requirement you may want to verify if the requirement states anything about their use first. That said it may also be worth considering that those regulations may themselves change in the future and not allow the use of facsimile for regulated data records.


How does Jami (formerly Ring.cx) really work, and how secure is it?

As a Jami (formerly Ring) developer I will try to answer this. Of course this answer is inevitably biased and incomplete, but it might answer some concerns or misunderstandings about how Jami works, and help to understand its architecture, and the limits of this architecture.
Building a secure distributed real-time communication platform is often a trade-off between ease of use, performance and privacy. Jami' security model is not perfect and will likely evolve, and we are open to comments, suggestions, and criticism. I will try to edit this answer to add more details if requested.

It does not look like they offer perfect forward security for either voice or chat conversations. ... They are not using a protocol
like OTR or Axolotl that is designed for real time communications. ...
Their description of their encryption confirms my concerns. They are
not using a protocol like ZRTP to prevent MITM attacks.

Jami establishes an authenticated peer-to-peer TLS 1.3 session (using GnuTLS) with PFS cypher suites enforced, typically (TLS1.3)-(ECDHE-SECP384R1)-(RSA-PSS-RSAE-SHA384)-(AES-256-GCM) is used.
This P2P authenticated TLS channel is used for SIP signaling, and temporary SRTP media encryption keys are negotiated with SIP on this  channel. This means that real-time communications on Jami (audio and video) are PFS and end-to-end encrypted. However Jami doesn't offer other guarantees like repudiation.
In "classic" (server-based) SIP, negotiating media keys in SIP is an issue because SIP servers can see those keys in plain-text, breaking end-to-end encryption and allowing MITM attacks. That's what ZRTP solves, by performing DH key exchange on the RTP (media) channel. Using SIP on an authenticated P2P channel makes using ZRTP unnecessary.

"Ring" is using SIP protocol, which is
very old and not P2P friendly.

The SIP protocol can be used for P2P just fine, in a similar way that one can use HTTP for P2P communications, and it's an established and robust telephony protocol, even if it's not perfect and some people prefer XMPP or others.

They claimed it as a "decentralized"
software, and it's bulls***.

Jami is fully distributed, which is stronger than decentralized, by using OpenDHT (a Kademlia distributed hash table similar to what's used by Bittorrent) to find contact IP addresses, which are stored on the DHT in the form of encrypted ICE candidates, used to establish the authenticated TLS P2P channel. Usernames (name<->public key mappings) are registered on a distributed blockchain (Ethereum contract). To my knowledge, no other real-time communication system provides that level of distribution.

Ring developer here. Ring is a distributed communication platform, its
nodes are part of a DHT network, so their IP are indeed exposed.

That's a downside of using a distributed network: DHT nodes IP addresses are exposed on the distributed network, which is a valid privacy concern. The current design doesn't allow to cryptographically link DHT nodes with Jami public keys and we work to make this separation as strong as possible.

Also they're patching their crypto lib – there's something deeply wrong
if you have to patch the crypto lib you're using..
Isn't it build on top of broken stuff? Namely, TLS/SSL. ... It's a
matter of complexity – the more complex something is to work with, the
more bugs there will be as a result. Using something as complex as
TLS/SSL really helps to have buggy crypto code. IMO anything using
SSL/TLS is going to be broken, be it sooner or later. One of reasons
why Tox uses NaCl/libsodium.

(comment above made by a Tox developer)
We don't "patch our crypto lib"; when a bug or vulnerability is found, the library is updated.
We live in the real world where no crypto library (and no library in general) is perfect. With time, every crypto ends up being broken - that's not a prediction but an observation.
TLS complexity is a downside, however an advantage is the ability to negotiate cyphersuites, so when a cyphersuite begins to be considered weak, transition to new cyphersuites can be done gracefully, without breaking existing implementations.
Libsodium (NaCL) is a great, high quality library but is not directly comparable to TLS. NaCL provides elementary crypto building blocks, while TLS is a protocol that performs the whole thing: authentication, key exchange, encryption etc. in a way that is standard and very well reviewed.
When building Jami we tried to not reinvent the wheel as much as possible, to avoid the risk of adding vulnerabilities.
Instead of building our own protocol using libsodium, we preferred to rely on TLS, and focused on using it the best possible way.


There’s an old joke variant that runs something like this:

A major newspaper had a sudden problem with their normally reliable high speed
printer. When they couldn’t quickly fix it, someone said that “Charlie” was the master of that particular printer.

“Well where’s Charlie?”

“He retired last week.”

“Bring him in under special contract!”

Charlie came in, walked around the machine staring at it for 10 minutes then put a chalk “X” at one spot. “Hit it with a hammer right there.”

They hit the “X” and everything began working.

Charlie said, “That will be ten thousand dollars.”

“What, that’s outrageous! All you did was make a chalk mark. I want an itemized invoice.”

  Chalk –   $1.00

  Knowing where to put the “X” –   $9,999.00

               ----------------------

In short, it’s not the tools, it’s the expertise.


Win10 Group Policy - Allow specific programs to run: Protection from malware?

Generally, using an application whitelist will not only restrict what apps the user can directly launch, but also what apps the whitelisted apps can launch (after all, explorer.exe - the Windows graphical shell, which hosts the desktop, Start menu, taskbar, file browser, and so on - is itself just a process that launches other processes when told to do so). Also, hopefully you wouldn't allow a process to launch other processes if it could be used to launch arbitrary other processes (the way a shell can).

Also, application whitelisting is frequently combined with library whitelisting. After all, libraries also contain executable code. This makes it a lot harder - though not impossible - to inject malicious code into another process (since the usual way to do that is to dump a malicious library on the disk and get the process to load it).

If the attacker can compromise some process (like a browser or document reader) and get arbitrary code execution within it, they can do anything the process can do. Even if the process isn't allowed to launch arbitrary apps (because of whitelisting) it can probably use the debug APIs to take over running ones and achieve persistence (until you log off / reboot) that way. They can also read your files and transmit them to the attacker's computer, or launch network attacks against servers inside your firewall, or so on. If the attacker has code execution in one process, they don't need to launch another one (though it's usually more convenient to do so).

One solution to this is sandboxing, where you restrict what an at-risk process can do. Most desktop web browsers, Adobe Reader, and a growing suite of other software (including most things in the Windows or Mac App Stores) use sandboxing these days. A compromise is still bad - if somebody compromises your browser, for example, they can see what you're doing with that browser, and possibly steal information or hijack sessions that way - but they can't do things like attack other processes.


Linux Kernel ROP - Returning to userland from kernel context?

I ended up writing my shellcode in a different way. As I could not figure out how to return, I let the kernel do the heavy lifting for me, in returning to userland. The idea was to execute my privilege escalation bit, and jump back to where the vulnerable function was supposed to return, with the registers and stack fixed up.

As soon as the kernel returned from the vulnerable function (when it was not overflowed), I noticed something via gdb. (The addresses are imaginary, but explains the concept anyhow.)

(gdb) x/i $eip
0xadd1: ret
(gdb) x/xw $esp
0xadd1: 0xadd2
(gdb) x/6i 0xadd2
0xadd2: add esp,0x40
0xadd3: pop ...
0xadd4: pop ...
0xadd5: pop ...
0xadd6: pop ...
0xadd7: ret

So, immediately after the return, 0x40 bytes of stack is unused and would simply vanish with the add esp instruction. Thus, taking advantage of this fact, I constructed an ROP chain (I had already constructed it while writing this question, its job was to disable SMEP and jump to my userland shellcode), which was 24 bytes long. 4 bytes would overwrite the EIP at the time of return, and the remaining 20 (0x14) would follow it right into the unused stack. This leaves us with 0x2c bytes of unused stack still.

But if we returned back to 0xadd2, we would risk losing a further 0x14 bytes of valuable register information from the stack, and filling up the registers with invalid data. We could add 0x2c to esp in our userland shellcode, and directly jump to 0xadd3, skipping the actual add instruction.

Also noting from the debugging session, everything except eax and ebx were being restored properly. As my overflow had trashed both of them, I had to restore them with values similar to cases when the function made a clean return. (Doing this was simple: I set a breakpoint at 0xadd2, and extracted the values from info reg)

So, my final userland shellcode was this:

Execute privesc payload -> add esp,0x2c -> register fixup -> jump to 0xadd3

Doing this, the code path returned perfectly clean, and the kernel did the task of jumping back to user-mode for me.


Is HTTPS as secure or more secure than SSH if both have an IP address whitelist?

Is HTTPS's detection of IP address as reliable as how SSH does it?

Both are protocols over TCP, where you verify the IP address when the TCP handshake is completed.  (With a completely fake IP address the packets likely would not be routed to you, so you couldn't complete the TCP handshake (or more accurately have a 1 in 4 billion chance of guessing it) which requires replying back with a random 32-bit sequence number that the server directed to you).  A powerful adversary who has control over a server on the network between the client and server can fake your IP address and collect and not forward packets intended for a faked IP address, but it requires them to have full control of a server on the actual route chosen through the network.

  I believe that SSH has a built in mechanism to prevent rapid retry attempts

It doesn't really, you really need to setup fail2ban to do this.  (Yes there are some options to insert delays within repeated password attempts within a ssh session, but they aren't that great).

I still don't understand the setup.  Both SSH and HTTPS encompass a wide variety of setups.  E.g., using self-signed HTTPS connection where you do no checking of untrusted certificates will be vulnerable to man in the middle attacks (at least with SSH it warns very loudly when host certificates change).  Similarly there are some weak HTTPS protocols -- you shouldn't use SSLv2 or weak ciphers.

Is the HTTPS/SSH connection using a client certificates?  Isn't this supposed to be automated?

If you have an API that needs to be run from a webserver, doing this securely with HTTPS is the natural route.  SSH is intended for remotely connecting to another computers commandline.  Yes, you can use it for other things like remote-command execution or tunneling network traffic, but if you want to offer a secure web-based API it makes much more sense to use TLS with checking client and server certificates (even if they are self-signed).


Does letsencrypt.org support non-default ports, i.e. ports other than 443 for SSL certificates?

Yes you can use non-default ports and it's recommended for compability with browsers and firewalls to use port above 1024 like 8443. You do not need to specify port when obtaining certificate. You just do it as usual and then you can experiment with changing ports.

Some configurations and software may refuse to pass HTTPS traffic to ports below 1024 other than default 443. For example, some corporate firewalls.


What is the differerence between virtualization and sandboxing

Sandboxing is a high-level concept that can be implemented in several ways.

Virtualization in practice is a specific type of sandboxing - usually by emulating of "the system", i.e., the CPU and the related hardware.

So there is a large overlap between sandboxing and virtualization; as well as virtualization and emulation. Yet they are different in design intent and/or technique.

Sandboxing is the effect you want. You could achieve it in many ways - either by building around your system (protecting it), or around your runtime environment (restricting it). Either way, it is important to know the problem in its entirety - and what it is an unknown program that you are trying to sandbox, it is simpler to use Virtualization (as in VMs) since it has the broadest scope of isolation and software is freely available.

e.g., to implement a behavior-based (dynamic analysis) of JavaScript, security devices need a sandboxed environment to run the incoming JS and observe "what it changes" (file system, registry, etc.). Either the security device vendor can use a sandbox (probably needs fewer resources when running; but would take more resources to develop) or use an existing environment such as a stripped down dynamically provisioned (and deprovisioned) VM in combination with in-browser sandbox.

Some (most?) "anti-APT" devices that boast this capability choose the latter because it is easier to develop and deploy. i.e., It cuts down on R&D costs (initial & ongoing) as well as time to market - while at the same time layout out the broadest possible net (scope) to limit the impact of evasive malware while still giving maximum detection ability.


Is it possible for someone to send messages from my phone and seem like if I send it to them?

Yes this is very possible it's called sms spoofing. I have done it once before using a company such as txtNation. Companies like txtNation allow you to send sms from pretty much any phone number or 5 letter name. I will also add that sending a sms from a phone number you don't own is illegal in most countries


Who is responsible for the strength of user's passwords?

You cannot answer this question without answering the following question

  If a user's password is compromised, does that only put that user/that user's data at risk, or does it also put other users at risk?

If the system does not compartmentalize accounts, then a user cannot keep their data safe by choosing appropriate credentials, so administrators must be responsible, in part, for the overall security of the community.

If the system does compartmentalize accounts, then a user can only harm themselves by choosing weak credentials, so shifting responsibility to the user can be appropriate.

For example, email mailboxes are well compartmentalized; compromising one account does not compromise others much.  Some accounts might be set up to not treat as spam mail from other accounts, but there are many other ways to impersonate email senders so the ability to send email as a user is not often a huge escalation of authority.  An administrator can abdicate responsibility for password strength without compromising the security of the system.

But file systems and source code repositories are not well compartmentalized. Compromising one account whose ~/bin directory is on other users' PATHs, or which has commit access to a vital source code repository can lead to the compromise of many other accounts and systems via trojans.  In this case, compromising one account escalates authority system-wide; administrators cannot abdicate responsibility for password strength because they cannot abdicate responsibility for system health.


How to securely send bank details to someone?

He would be fine with emails and password protected zip file/google
  drive text file

Firstly, you need to take into consideration the level of security you want vs practicality. In this case, you have mentioned that your employer is comfortable with emails and password protected zips. So, why not do that?

Without being overly complex, how you can do it is:

Type your bank details in a text file and ZIP it up with encryption (you can use AES-256 bit encryption which I believe offers a good enough protection)
Send your password to the ZIP file in a separate email

What I am proposing above protects the transmission of the file. Of course, if you decide that the email service cannot be trusted, there are many ways to make it more secure. You could further:

Encrypt your ZIP file password with another key which is already known to your employer (e.g. your name)
Skip step 2 and call your employer and tell him the password over the phone
Send the password using another email service

To me, even if your bank account details (I supposed that is only your bank account number, bank name and your name) are exposed, there are no severe risks. There is no need to make it overly complex.


Does OpenID, SAML pose a threat to Tor's anonymity? How can I protect from a compromised .exit node?

I don't fully understand your question, but there are 2 ways of interacting with TOR users

1) They reach the Internet through TOR. This should utilize SSL/TLS. As a TOR user who connets to the global Internet, I often utilize an SSL/TLS Proxy, such as CGIProxy or PHProxy on Apache with valid PKI (e.g. SSL certificates). I also often specify an exit node with .exit -- often selected by sorting country-of-origin and performance lists in Vidalia. The reason for this is because exit nodes do not encrypt your outgoing traffic by default, so the only safe web destinations are SSL/TLS destinations (unless you use an SSL/TLS Proxy).

2) They are trying to reach a TOR hidden node on the .onion hierarchy. If this is the case, you don't really need SSL/TLS because the traffic is encrypted. However, in order to maintain sessions, you will want to lean on the typical HTTP mechanism: cookies (or similar such as hashses of Panopticlick-like data if it is disparate enough). This would be completely independent of the TOR network, so I don't see any reason why you can't use any of the technologies you mentioned to produce valid cookie-based sessions.


Is it safe to concatenate non-input session variables into a SQL string?

Presuming that prepared queries are easy to use and don't cause performance issues here, then you should just use prepared queries.  All else being equal, I prefer to do things the secure way by default.  In other words, instead of asking "Should I do this the secure way?" (which is what you are asking) try approaching from the opposite perspective: "Is there any reason not to do this the secure way?".  Unless you have a good reason to do it without prepared queries, just always use them.

For session variables I think it is especially important to always use prepared queries, because their nature makes it easy to lose track of where they came from.  It is true that given your current use case there is no immediate risk of an SQL injection vulnerability (but note that session data and cookie data can be easily confused, and the latter are not secure).  However business needs often change and this can generate a large risk when the creation of data is not easily "visible" from where it is used.  What happens if on the next iteration of the application one of these pieces of data now comes from user input?  You'll probably remember to convert your query into a prepared query when you first store the user input.  But will you remember to follow that same data through your entire application and make sure you aren't using it without prepared queries in a later place?  If you end up inserting the data into the database securely, but later fetch that data from the database and use it in another insecure query, then you can still end up with an SQL injection vulnerability.

So don't ask "Should I use prepared queries?".  Instead start from the other end: "Is there a reason why I shouldn't use prepared queries?".  If you don't have a compelling reason to skip the prepared queries, then use them.  If you think you have a good reason to do it insecurely, then at least you are at a good starting point for a thorough cost/benefit analysis.

Prepared queries with variable column names

Please note that this syntax is not actually allowed for prepared queries:

$editSQL = "UPDATE myTable SET ? = ?,  ? = ?,  ? = ? WHERE ID = ?"

Column names cannot be provided with place holders.  As a result you actually can't build prepared queries like this.  Instead you have to provide the column names as variables into the query building, which means that it can be vulnerable to SQLi vulnerabilities.  Therefore, the way you protect against SQLi in cases like this is by whitelisting the variable contents to make sure that it is exactly something that it is supposed to be.


Multiple outbound TCP/8333 connections containing the EICAR test string

What's the traffic? The TCP port 8333 is used by Bitcoin cryptocurrency and VMware Server Management User Interface. Of these two, Bitcoin is the suspect as it's a peer-to-peer network.

Why would Bitcoin send out EICAR strings? The Bitcoin blockchain is distributed to every full nodes. In addition to money transfers the blockchain can contain messages and files. Someone indeed have uploaded the EICAR string to blockchain lately, and that wasn't even the first time:

Jan 26, 2019 9:16:13 AM, block 560154, transaction f842b99ae150...
Nov 27, 2016 2:13:13 AM, block 440742, transaction 4a3282204dc3...
EICAR is not the only virus signature that have caused false positives and harm.

Because the information on the blockchain is public, the messages aren't encrypted for confidentiality, but signed for integrity. That's why the string was sent out in plain text, exposing it for detection.

Probably the detections centralized within half an hour because the node had just downloaded the block 560154 and, therefore, became a source for other nodes downloading the same height of the blockchain. This will happen again occasionally, when someone requests for block 560154 or 440742. Or when someone repeats the prank.

Why IPS detected it while virus protection didn't? EICAR test file has a strict specification:

  Any anti-virus product that supports the EICAR test file should detect
  it in any file providing that the file starts with the following 68
  characters, and is exactly 68 bytes long:

  X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

In the Bitcoin blockchain this string is in the middle of a huge file: it's not starting the file and the file is not exactly 68 bytes long. An IPS system on a firewall on UTM monitors the TCP packets instead of files. If there is a signature to detect this string, it can be anywhere in the TCP stream.


While that is what many password policies attempt to do, moving the user passwords from dictionaries and into a form that can only be brute forced, they're forgetting the most insecure part of the password: The human mind.

Human minds are terrible at generating true randomness.  They're even worse at memorizing random values.  If there's a pattern that they can follow to help them remember it, they'll use it.

And, most damning of all, humans will reuse passwords.

Attackers have caught on and, rather than making their dictionaries based on words found in various languages, they make their dictionaries based on previously leaked passwords.

The current advice to users is to remember two passwords: The one to log into your computer, and the one to log into your password manager. Never try to memorize any other passwords, and never try to generate a password on your own. Let your password manager make truly random passwords, as these are the only ones that are guaranteed to not have shortcuts like dictionary attacks, keyboard pattern attacks, and the like.

The current advice to people setting up authentication systems is to follow the NIST standards.  Specifically,

Do not force users to use different character classes like at least one of each upper, lower, number, and symbol characters.
Check that the password hasn't been leaked before when the user sets or changes their password (i.e., use the Pwnd Passwords API).
Do not force users to change their passwords for arbitrary reasons, such as periodically.
DO force users to change their password for specific reasons, such as a suspected leak of your database (and be honest when such a leak happens).

etc.


Transforming keystroke dynamics raw data

As you mention, if you gather enough data, each key-feature pair will be well approximated by a gaussian distribution. In that case, instead of storing the timing counts ([(64,1), (169,2)]) or even the histograms ([("60-70",1), ("160-170",2)]`), you might want to consider storing the parameters of the inferred distribution - the average and the variance. Of course, that only works if your model can still work correctly from the inferred distribution.

Another thing to take in mind is to avoid storing short runs. Even if you store it in aggregated form, if you capture the moment when a user is typing a password, and the only keys that have valid distributions are 1, 5, 3, 4 and 2, that's not really ideal!


What is the diffference between HSM and PTS-approved point-of-interaction device?

Very, very simple and in very simple words:

HSM: is an appliance that manages keys.

PTS: is basically a card reader which allows you to enter a PIN number.

I forgot to "actually" answer the other two questions but I guess that an image is worth a thousand words =)


Running windows in virtual machine, should I bother with security?

Your virtual Windows is on the same network with your OSX, so the same threats of having an infected device on a network applies to this VM. Your VM is equivalent to a PC in your network its not much different. The same security practices that apply to your PC also applies to your VMs.

Although OSX does not run the same malicious apps that run on windows machines, that VM can still be a threat to rest of the devices on the network.
It can also consume your machine's resources in case it becomes infected and make your host machine slow too.
At times you may login to your email/cloud account on the VM to download something and in case the VM is infected with a keylogger, your data can be stolen.
You may connect a USB Flash drive to the VM to transfer files elsewhere and infection can spread this way.

Try to keep the guest operating system along with softwares used in it updated at minimum. If you use it moderately get a free antivirus like microsoft's Windows Defender.

One other threat is Ransomwares, Parallels Desktop has a feature that shares some of your OSX folders with windows. If your windows VM gets infected with a ransomware, it can possibly encrypt your shared files causing damage to your important data.

Looking at Virtualbox's manual chapter 13, Security guide. Other than the points mentioned above plus the clipboard which SilverlightFox mentioned, it says:

13.3.4. Potentially insecure operations

  Enabling 3D graphics via the Guest Additions exposes the host to additional security risks; see Section 4.5.1, “Hardware 3D acceleration (OpenGL and Direct3D 8/9)”.
  ...
  When Page Fusion (see Section 4.9.2, “Page Fusion”) is enabled, it is possible that a side-channel opens up that allows a malicious guest to determine the address space layout (i.e. where DLLs are typically loaded) of one other VM running on the same host. This information leak in it self is harmless, however the malicious guest may use it to optimize attack against that VM via unrelated attack vectors. It is recommended to only enable Page Fusion if you do not think this is a concern in your setup.
  ...

While you're using a different hypervisor, it is imaginable that same type of risks also apply to that.


User Credentials Android. Who can read the web traffic?

Are User Credentials on Android such as "user key", "user certificate", and "CA certificate" only used to connect to a single specific network?

A user certificate is used to authenticate a user against an HTTPS website and is totally agnostic of the network used to access this website.

A CA Certificate is used to ensure that the certificate provided by an HTTPS server has been signed by a legitimate authority and is also totally network-agnostic.

  In other words, will the network admins be able to see my web traffic if i'm using cellular data and or a different WiFi network that doesn't use those certificates?

As said previously, a CA certificate is used system-wide.

So let's say that:

Your boss requested you to install the CA certificate Toto.pem.
Your boss is able to run a MITM attack between your device (regardless the network used) and an HTTPS website you're visiting.

Then your boss just have to build a certificate for the website you're visiting and sign it with the CA certificate that he made you install on your device.
The connection will be reported as "secured" most of the time in basic HTTPS server setup. (exception are if more clever methods are used by the targeted website, such as HTTPS pinning, etc...)


Security implications of exposing payment gateway secret API key

It is really important to start with the mindset of an attacker, rather than an engineer. As an attacker there could be a litany of reasons I may want to leverage your private key to meet my own desires. Lets start with your eCommerce information.

By having your eCommerce information, I can start racking up a bill on other people's accounts. I can even create my own form to order what I want, use someone else's card, and have it shipped to a location I choose. The best part is you don't have to be in this conversation at all so you wont even see the activity occur.

Going even further, say I have this person I REALLY hate because they keep waking me up in my apartment in the middle of the night with loud music. If I happened to get their payment information, I could make a bunch of bogus purchases that will cause them to cancel their card, deal with fraudulent activity, and it will look like your commerce account is to blame. I feel happy knowing they've been inconvenienced and you might not ever figure out it was me. Win win.

Lastly, many API keys perform more than just eCommerce approvals. Account changes can be made through many APIs so changing the business name, address, even customer information. Worse, you can start stealing client information through an API so I could start spamming your customers with viagra ads or worse; and again still be connected to your service. It's a big security risk.

Your secret, be it a password, certificate, or API key must ALWAYS be protected. You should never underestimate the lengths people will go to screw other people over. As a developer or systems administrator, it is your responsibility to think about this and ensure that your clientele are protected.

Finally, I never advise to do anything illegal, amoral, or otherwise maliciously. However, it can be a very good practice to look at anything you build and see how you could misuse it. View your work through an attackers eyes and try to exploit the very tools you create. The attackers mindset is best learned through application, and if you're attacking your self you will learn more about your own projects than you would have ever known otherwise.


Adding to what Chemical Engineer said, IPv6 does have other advantages too, such as:

Native support for end-to-end encryption: This was a feature that was added much later to IPv4, but comes as a standard for IPv6.
Secure neighbor discovery: The improved protocol (SEND) for neighbor discovery in IPv6 actually confirms the identity of the other party during host discovery, using a cryptographic method.
Larger address space: More time needed to bruteforce through addresses (3.4 × 1038 vs the older 4.3 × 109)

But as in most cases, misconfiguration will only make you more vulnerable.

Scott Hogg wrote a brilliant article a while ago here. It covers these points in much greater detail.


What are the security benefits to a separate user database?

Rather than two separate connections working together, you can use separate user accounts with access to specific columns. Most of your statements can use the user account that has access only to the username (not password) column of the users table, and the less important data from your main db.

In MySQL, you can do this with nice granularity. This will allow you to show everyone's usernames, and only access passwords in login pages, and only access sessions in session management, only access email addresses in notifiers, etc.

With this model, SQL Injections will generally be limited to the public info, or the single section that they reach.

Of course, what is public, how your users are set up, how many, what they get is all specific to your use case.

Check the GRANT documentation for your version of MySQL.

Disclaimer: This is not a fix to SQL Injection, only an effort to help minimize the impact.


Does the amount of bandwidth available on a network determine how strong a DoS attack should be?

Imagine a post office.

It has an entrance, a counter with a clerk who deals with the customers and their packets. The clerk is a multi-tasking talent with a lot of arms to deal with packets on the counter.

The counter has a certain width, so only a certain number of customers can be processed at the same time.

The clerk has a small address book with addresses of where to send the packets. Some pages are blank, and he can input new addresses.

Behind the counter and the clerk are a certain number of shelves, where the assistant of the clerk puts packets until they can be further processed and sent.

There are now several cases for a DDOS / DOS attack in this metaphor.

Case 1 - SW Bug

One mean customer steps forward, leans over to the clerk and shows the clerk the packet with the address "Vietnam" on it - which triggers the clerks PTSD1. This is something only a few people knew about. The clerk starts sobbing uncontrollably, sits in a corner and is of no further use to the post office. It has to close early, until the owner of the office comes, says some magic words and restarts the office.

The word "Vietnam" in this case stands metaphorically for a bug that the mean customer abuses. Since usually only one packet is needed to freeze the office, this might not count as a DDOS, but certainly a DOS.

Case 2 - Bandwidth

The post office has only one door, through which all the customers and the packets have to squeeze themselves, incoming and outgoing ones alike.

If an attacker wants so abuse this, he might gather a lot of unusually big customers and/or packets to enter the post office all at the same time. Now the doors are too tight and new customers can't enter while other customers can't leave the store. This halts the post office, until the clerk puts down a rule at the entrance: "You must be smaller than this to enter".

Everyone trying to enter the office while being too big won't be allowed to enter the office.

The doors here stand for the bandwidth; the more bandwidth you have the more customers can enter / leave at the same time. Since this is pretty dynamically, it's sometimes hard to find the exact point at which the store has to halt.

Case 3 - CPU Load

Whenever a customer comes to the clerk, he has to greet them, take the packet and process it. Usually he has to check if the address is correct, the packet is not purple (purple packets are not standardized packets and therefore bad!). If the clerk is really paranoid, he has to open the packet, look to make sure that no contraband is inside, test if the packet smells like Anthrax, etc.

So depending on the rules for the post office, the clerk has to check a lot of parameters. If an attacker wants to abuse this, he can gather a lot of people with a lot of small packets. The clerk has to process EVERY packet, which can create a lot of overhead.

Because of this, the customers outside start to pile up, and some even start to curse and leave the line, since they don't have all the time in the world to wait in this line forever.

So CPU load usually has to do with processing in this metaphor.

Case 4 - Memory

The clerk works for quite some time in the post office, so he has memorized several addresses. He also has some addresses written in his address book.

A attacker can abuse this by gathering a lot of people and tell them to write unusual addresses on their packets.

So each time the clerk processes one of those mean customers, he has to write down another addresses into his book. This soon gets filled and now he is in trouble. How should he process new addresses? Kick out old ones? He has no idea and maybe stops his processing altogether.

The address book stands for the memory, which is finite.

Case 5 - Connections

The counter has a mentioned width. Since the clerk is a multi-tasking talent, he can deal with 3000 customers at once, but not more.

The attacker can abuse this fact by gathering a lot of people and tell them to try to rush to the counter. Now there are 5000 people, demanding to get their packet processed, causing a lot of stress for the clerk with his just 3000 arms.

Case 6 - Disks (and other resources)

The clerk has to store the packets into a shelf behind his counter. This is the job of his assistant. Some assistants are faster than others, so sometimes it can happen, that the clerk can deal with 3000 customers at once, while the assistant has to slowly move himself and the packet to the correct part of the shelf.

So while the clerk certainly is fast enough, the poor assistant is not. The assistant in this case can be the server disks or other components.

Conclusion:

DDOS / DOS attacks can use a lot of different methods and parameters to stop or slow the service of a server / server-cluster. Therefore it depends on a lot of factors: Which software you use, how much bandwidth you have, the CPU, memory etc.

[1] PTSD is no joke, but it fits this metaphor nicely. I apologize for using it in a jokingly fashion.


How to incorporate the man-in-the-middle

This is what oAuth is for. oAuth lets a third party service request to do certain operations on behalf of a user with the users consent, For example read access to a users contacts.
The third party receives a token which allows it to perform these actions and it is the back end responsibility to validate the token and the actions it is allowed to perform. The token can be time limited and hence even if the third party keeps the token, it becomes useless after it has expired.


User-friendly public/private manual authentication protocol

I guess you use SSH-keys as authentication? Reauthentication and key exchanges happens all the time during the SSH protocol, so having a Active session is secure enough.

Another thing is confirmation, eg, you want that the user really wants to commit a action that might be irreversible. Lets say deleting something.

To solve this problem, I would suggest you simply show a random 6 digit code on screen and ask the user to retype it to signify a "YES". (and treat as "NO" if the 6 digit code was incorrect or no code is written.)

Like this:

Are you really sure you want to delete the database records_2013.db?

If NO, just press ENTER now.
If YES, type the following code - 193619 - here, and press ENTER: _

This then solves your problem perfectly, since the SSH server/client would make sure it has a valid authenticated Connection to the server, which means a malicious user cannot hijack a authenticated SSH session, and the random confirmation code, then ensures the user does not, by mistake, commit to a dangerous operation.

Note that this code is not considered to be a captcha, so it wont hinder automatic submissions. But reauth by ssh-keys wont solve that either.
The code is just there so the user stop and Think really carefully if he want to proceed Before proceeding.

The reason banks use some reauthentication scheme, is that sessions can be hijacked since HTTP/HTTPS is a stateless protocol (Connection are closed after the page are sent, making it hard to use the underlying protocol to do session authentication), but also for the second reason, to prevent users from by mistake, sending Money somewhere they did not intend.


Can a file named "agreement.execds.pdf" really contain an executable file?

I've seen this before, and it is a result of an unintelligent filter. It is picking up on the ".exe" in the middle of the file name.

agreement .exe cds.pdf

If you rename the file it should pass through easily.

It might seem silly that these filters will happily allow a real .exe to come through as a .jpg or whatever else, however they do still provide a level of protection. Your regular everyday user will still be largely protected because their attempts to open an exe with .jpg extension won't execute the exe, and will just give them an error.

The reason it plays safe and sill picks up the .exe in the middle of the filename is because users are dumb. They might realize that in order to view cool_cat_picture.exe.jpg they just have to rename it themselves. Without any .exe at all there is no prompt for the user and significantly lower chance of it being run.


X-Frame-Options HTTP response headers  are useful in that they tell the browser to not allow framing from other domains so that it protects against clikjacking.
For your second question,  you can read from here:

Sending the new X-Content-Type-Options response header with the value
nosniff will prevent Internet Explorer from MIME-sniffing a response
away from the declared content-type.


According to this issue: https://github.com/vanhauser-thc/thc-hydra/issues/612
Hydra 9.1 has a bug that affects that command... even though version 9.2 only says about an http-post-request buxfix
Kali does not install 9.2 version and says 9.1 is the latest when doing sudo apt install hydra


What are the dangers of a firmware malware in 2021 and is it possible?

Now if this firmware is somehow hacked or infected and if you take it to another PC, is it possible for this firmware to infect other hardware on this new PC?

Yes, certainly. This could be done by supplying a custom boot sequence, or supplying altered information to the boot process (the malware does not need to integrate in the boot process: it can boot itself, do its thing, then reboot and allow the process to repeat, this time undisturbed.
The greatest hurdle in this would be the great variety of available hardware and firmware programming interfaces. The malware would need to run a very detailed diagnostic, and chances are that it couldn't, or it would be detected - come on, a system cold boot taking five full minutes?!?
The malware might, however, be able to detect special circumstances (i.e. a true firmware or software update), and hijack those. I.e., nothing happens normally; then you receive an authentic firmware or BIOS or OS update; you are used to those taking time and rebooting multiple times and so on. So you start the update, see the real message "OS update may take some time", then the PC remains blank and whirring for five minutes, then the BIOS update starts and finishes successfully. In those circumstances you might maybe worry that the BIOS update isn't working, but you would probably try and wait and see, as I myself did any number of times.
Then, the disk malware would need to detect when the system requires loading a specific executable, one that perhaps is executed every so often (it can do so by recognizing it is an executable from its header, and timing its activation). When it happens, it will reply with a different binary, executable on the appropriate platform. To the user, the binary (e.g. a cron job or scheduled task) will appear to have not been executed that one time. That binary would be the second stage, designed to propagate some other way (infecting USB or through the network).


Should I store my update files with their signature included?

As always, it depends on what you want to protect against.

If the threat is an attacker hijacking your domain name in some way and distributing malicious updates, your protection is good, signing files on your server does prevent that.

However, talking about the threat that an attacker compromises the update server itself, there is no protection in place currently. As the key must be accessible to the process that actually signs and sends out files, an attacker would also have access and could distribute signed, malicious content. In a sense it's even worse than if updates were not signed, because in such a scenario users would be assured by your signature that updates are in fact authentic when in reality they are not.

So yes, as you suggested, you should definitely keep signing keys offline (or at least well protected, not on the update server), and only upload already signed distributable updates. This would protect against the second threat mentioned above as well.


Client identity other than URL/DNS name in certificate

we'd like to use some value from certificate to perform authorization

You use the certificate for authentication and once you authenticated a user you can do authorization.

Sounds like hair splitting but it helps improve design.

Additionally, according to rfc3820 you can use the extKeyUsage to store some basic authorization data on the certificate itself.

For identification purposes, use of CN/SAN is fine, but you might want to use subdomains of a domain you own for them.

  But maybe we should generate two certificates for each component and
  use one for presenting to connecting clients (so DNSname in both SAN
  and DN/CN) and the other one to authorize ourselves to components that
  we connect to?

You can use the same certificate for both purposes. If the server is compromised you'd need to revoke both keys anyway.


Is there always a user notification when smartphones record audio?

It's best practice to show when a device or application is actively listening, but it's by no means guaranteed. There's a lot of debate about which apps may or may not be listening - Facebook and Instagram, for example, come up a lot - but at the end of the day, clandestine recording is just that: clandestine. So, it's hard to know what's happening for sure.

By the way, I think this question might be a duplicate of another recent one. :)


What are the purposes of these security policies?

Here are my thoughts on this:

Somebody could hide something--a flashdrive with malicious content, for example--in an unlocked drawer. An employee could find that flashdrive and plug it in to his computer, putting the computer at risk of compromise. Also, it's easier to modify the locks of unlocked drawers than it is to modify the locks of locked drawers. By modifying a lock, a malicious individual could make it easier for themself to gain access to the drawer in the future.
If the media is blank, somebody could put malicious contents on it. If the media's filesystem is "empty" but the media has been used in the past, somebody might be able to recover fragments of old data from it.
It wouldn't be difficult for a janitor (or somebody posing as a janitor) on a night shift to take pictures of a white board, potentially stealing secrets. During the day, the white board is more likely to be surrounded by trusted individuals, making it more difficult to covertly take pictures of it or even get a decent look at it.
Black notebooks are less noticeable than white notebooks. Hardcover notebooks are less likely to lose their covers than softcover notebooks. Covers are important for notebook security. They make it just a bit more difficult to quickly and covertly obtain information from a notebook. They also prevent notebooks from flailing open when they are dropped. Hard covers are better preventers of flailing than soft covers. Also, notebooks with soft covers may be more likely to get misplaced than notebooks with hard covers.
Some sorts of health information are extremely valuable to social engineers. It is common for malicious social engineers to plan attack vectors around employees on leave. For example, if a certain employee is on sick leave, a social engineer might pose as a friend of the employee and gain access to the employee's office by telling somebody he has to bring his friend an item from the office.


Changing private key in asymmetric encryption and recovering data

If the private key is compromised the whole key pair is compromised, i.e. the public key should not longer be trusted too. This means that you cannot simply change the private key but must change the whole key pair.
You can still keep the old key pair though in order to deal with the old messages. But given that this key pair is considered compromised nobody should send or accept message any more which are protected by this key pair, i.e. the key has to be revoked for all future use except for dealing with the old messages.


My confusion stems from reading that TLS handshake uses some kind of Diffie Hellmann, when I was certain that the symmetric key was generated by a digest of earlier packets encrypted with clients public key and safely decrypted with servers PK.

The key exchange is used to generate the symmetric key (or at least the pre-master secret which the keys are derived from). There are two major types of key exchanges: Diffie-Hellman and RSA key exchange. What you refer to in the first part is Diffie-Hellman, what you refer to in the second seems to refer to RSA key exchange, although with many details wrong. RSA key exchange is considered obsolete and is no longer supported by TLS 1.3.


Usually, the  TOTP server is configured with an NTP server for accurate time.  Each time the token authenticates to the server, the server adjusts for the drift of the token. As you have mentioned if a token is not used often, the amount of drift can surpass the synchronization window.

To solve this problem most of the time, TOTP servers provide a re-sync option. For example, using a software from the TOTP service provider installed on the user machine can allow the token to obtains the server time and re-sync its clock.

Here are some links to shows examples of the re-sync option

http://support.nordicedge.com/nsd1326-how-to-re-synchronize-oath-tokens-with-oathresyncwebapp/

https://kc.mcafee.com/corporate/index?page=content&id=KB76278

Some other TOTP service provider will do it manually through a help desk like http://www.mideye.com/support/users/token-card-users/

Of course, there are some other methods, but in general, all of them allow one way or another the token to know the server clock.


What exactly is meant by serverAuth and clientAuth

Theory
This is the usual process in theory:

Your client establishes a connection to the server. The server presents its certificate. The client then makes sure that:
(1) the cert is valid,
(2) the server is in possession of the matching private key via a challenge and response mechanism,
(3) that "serverAuth" is set in the certificate.

Then the server may or may not ask the client for a certificate of its own. And it's pretty much the same in this direction again.
The client presents its certificate. The server then makes sure that:
(1) the cert is valid,
(2) the client is in possession of the matching private key via a challenge and response mechanism,
(3) that "clientAuth" is set in the certificate.
Otherwise the server drops the connection.

Practice
Now whether your software actually enforces step 3 is a different matter altogether.
So, how do you find out what works?

(1) Thorough way: Read the manual, do some experimentation, contact software support.
(2) Lazy way: Just set each and every usage flag on the certificates.

Standard RFC 5280
Now RFC 5280 describes the EKUs in section 4.2.1.12 but is not very verbose.


I believe this refers to malicious redirects.  Let's say that E. Vildoer has been phishing and sending people to evil.example.net.  If E. Vildoer then manages to put malicious code on your site, such that your pages are redirecting visitors to evil.example.net, then Chome should trigger on that.  It's not the code on your site per se that triggers the block, it's where the code would be sending the visitor.

Of course, I believe Chrome browsers report such incidents back to Google, leading to a scan of your site, leading to you being added to the Safe Browsing blacklist, so it's kind of a short window where you're not on the blacklist but trying to send visitors somewhere that'll get you on the blacklist.


LetsEncrypt / Exim4 / GnuTLS / cert chaining: "The provided X.509 certificate list is not sorted" error

You got the wrong certificate. Check the graph at the Let's encrypt site and you will see that a leaf certificate is not signed by the X1 certificate you've downloaded but by  X3. If you would look at the certificate details (with openssl x509 -text or similar) you would also see the issuer of your certificate and you could check that it matches the subject of the issuers certificate.


The key would be to firewall off the infected computers from the good computer, so if your routers provide firewall capabilities, I'd recommend that you ensure that traffic can't go from "good LAN" to "bad LAN" and vice versa. Also ensure that the router management interfaces are only available on the "good LAN".

If you think about it, in principle you're just treating the "bad LAN" like the Internet (e.g. a network that you don't trust). so if you have your second option there, just make sure that any traffic leaving "good LAN" is encrypted and that there's no management interfaces visible on the "bad LAN" side of the router separating them.


What are the risks of making a mobile phone an access point for non-trusted users?

The main attack vector that has been opened up is that you are now on the same LAN. I don't know how your smartphone implements some security measures so i'll assume it behaves like a PC. Being on the same LAN means that he could read sensitive information not sent over https. He could also perform standard network attacks like ARP spoofing between you and anyone else on the network to intercept and block traffic.  Apart from network manipulation, if you phone has services exposed that contain exploits, they could now be attacked while before they could not.


What security features should a PHP framework have?

Well, building security into a framework is not an easy task. Take for example XSS protection you mentioned. Current trend in Web Application security states that three things are required for dealing with injection-flaws:

input validation
output validation
context-aware output escaping (not an easy task)!

Even when handling all the above server-side, you could still be vulnerable to DOM XSS attack when vulnerable Javascript code has been introduced to the application (and, for example, jQuery might introduce DOM XSS as well).

Personally, I think the most important, and often neglected features of the frameworks are secure defaults and secure code examples. Developers often copy&paste the code or leave settings as default. So if you're introducing tokens as a CSRF protection, add them to every form by default and allow that to be toggled off in code/config.

If you're looking for some kind of a checklist for secure frameworks, there once was an OWASP project (now closed) - Web Application Security Manifesto. It aimed to provide such a testing and is currently the best checklist there is. Also browse through various OWASP cheat sheets to help you with implementing each security controls.


What does a signed Linux kernel image get me?

With your unencrypted boot partition, malware could theoretically replace your unsigned kernel with its own (say, a hypervisor running your original kernel).  This malware would then be undetectable by your system, while having full access to it.

A signed kernel closes this hole, at least in theory: since the malware hypervisor isn't be signed, a EFI BIOS that requires a signed OS would refuse to load it.

The problem with this is that while a random malware author isn't likely to have a signing key recognized by your BIOS, a state-level actor is, and there's a decent chance that an author working for organized crime will.


Technical description of a self-signed certificate

RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

The end of section 3.2 states:

  This specification covers two classes of certificates: CA certificates
  and end entity certificates.  CA certificates may be further divided
  into three classes: cross-certificates, self-issued certificates, and
  self-signed certificates.

  Cross-certificates are CA certificates in which the issuer and subject are different entities.  Cross-certificates describe a
  trust relationship between the two CAs.
  Self-issued certificates are CA certificates in which the issuer and subject are the same entity.  Self-issued certificates are
  generated to support changes in policy or operations.
  Self-signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into
  the certificate.  Self-signed certificates are used to convey a
  public key for use to begin certification paths.

  End entity certificates are issued to subjects that are not authorized
  to issue certificates.


Is it possible to separate DRA decryption abilities?

Yes this is possible, but I do not believe EFS directly supports it. There is a secret sharing technique called Shamir's Secret Sharing which provides information theoretic secure sharing of a given secret where an arbitrary number of individual parties are required to calculate the original secret. From the Wikipedia article, one of the properties provided seems to describe what you want perfectly:

  In organizations where hierarchy is important, we can supply each participant different number of pieces according to their importance inside the organization. For instance, the president can unlock the safe alone, whereas 3 secretaries are required together to unlock it.

In your situation, you would want to use the secret as the file encryption key. You could split the secret so two any two DRAs are required to decrypt a file, but the owner of the file has enough "parts" of the secret that they can derive the final secret required to decrypt it without any other information from the outside. A simple implementation would the open source ssss or sss utilities.


You need to supply the text that's returned upon an incorrect response.

From hydra -U http-get-form:

Syntax:   <url>:<form parameters>:<condition string>[:<optional>[:<optional>]

"Condition string" needs to be populated. This is something the site returns when the password is wrong and is site specific. e.g. "Incorrect password".


You're probably fine, this was likely an automated scan searching for WordPress installations across the Internet. If that's the only log entry, I'd ignore it.


For an application scoped assessment, I would begin with the obvious tools that are specific to that application, such as WPScan (which you mentioned).  Beyond the findings there, I would look at your goals, objectives, access, and likelihood of finding types of vulnerabilities.

Wordpress core is relatively well hardened today.  It's unlikely you'll have findings there.
Wordpress plugins are a potential cesspool.  Many of them have no maintenance and were written by people as one of their first programming projects.  Look at the interfaces these provide.
Custom themes, since they can contain PHP, are particularly a source of vulnerabilities, including XSS.  Look closely if your friend has a custom theme.

I would use mostly Burp Suite in the evaluation of these areas.  If you have reason to believe SQLi exists, then consider also sqlmap.

I wouldn't bother trying to brute force credentials at all -- what's the point?  If you want to check whether passwords are strong, you could dump the password database and do an offline attack with JTR or Hashcat, but if the number of users is small, just make them have good passwords.  :)


What is the difference between a data leak and a data breach?

"Breach" has a specific meaning: existing controls were somehow broken or bypassed. This could have been accidental or malicious. Outside or inside people could breach controls. Hackers who manipulate a system to gain access to data they are not authorised to access is a data breach, as is an employee going against policy/procedure which exposes data.

"Leak" is a more general term and simply refers to the outcome that data was made available to unauthorised people. This could have been caused by a breach (broken or bypassed controls) or through other means. If there was no control in place, then unauthorised access is merely a "leak".


What pros and cons are there to a one-time random salt between client and server?

Indeed, this approach does not help against the theft of the password database. It's easier to see why: it concerns only the exchange of data, and does not impact the database format. Since the database stores direct hashes of passwords, it is vulnerable to a rainbow table attack, making all but the highest-entropy passwords breakable.

This one-time random value is a nonce, and such values are indeed commonly used in communication protocols to avoid replay attacks. Without a nonce, an attacker could eavesdrop on a legitimate conversation and replay later the login phase with the server. You might find such implementations because it is useful under the following hypotheses:

the communication uses HTTP;
the attacker can passively listen to all TCP/IP communications but cannot directly talk to any client, only to the server.

There are old web applications designed under these hypotheses. Adding a nonce to the login phase was a significant burden to attackers in the days when they were mostly bored college students on university campuses. In today's world of ubiquitous advanced networking tools and computing devices, assuming that TCP connections cannot be hijacked is not realistic. Such a protocol is vulnerable to a man-in-the-middle attack where the attacker provides a fake DNS response to the client or hijacks the TCP connection. Using HTTPS (with proper authentication of the server, i.e. proper validation of the certificate) makes the addition of a nonce to the login protocol itself redundant (HTTPS itself contains a nonce so that connections cannot be replayed).


Can someone explain in simple steps how WPA2-Enterprise authentication and encryption happens?

Below is the information on frame exchange which happens between Supplicant and NAS (Server)

The cipher suite is the algorithm or hash technique which is accepted by both STA and AS used for generating MSK.


How can a VPN use a virtual router and not send encrypt traffic and still be safe?

There do seem to be these two uses of the term VPN.

Obviously the most important bit is Privacy - and many people (myself included) can only accept privacy exists if there is encryption, but as R15 mentioned, MPLS providers typically call their service VPN but rarely have encryption enabled. They rely on routing segregation.

It can be safe for some communications, but it presents a couple of key risks:

data in the clear could be intercepted anywhere along the route, including in the MPLS provider's network
routing failures could expose your traffic to other customers of the MPLS provider


Using airolib-ng with crunch and then using the file using aircrack-ng gives unexpected result

The purpose of using airlib-ng is to speed up things, computing in advance all the possible PMK (pair-wise master key) combination used during the handshake, which are derived from the password and the ESSID.

So you'll need to perform some additional steps:

1) Import a list of ESSIDs:

$ airolib-ng testdb --import essid your_essids.txt

2) Compute the PMKs using all possible password+ESSID combinations:

$ airolib-ng testdb --batch

Your code should work afterwards.


How does Google detect new devices for two factor authentication

It uses cookies (more specifically, the SMSV cookie h/t @Tomer). Use chrome in normal mode and login with 2FA. Open an incognito session* of Chrome and it will be a "new device". The only difference between the two is that the latter doesn't have any cookies (maybe it also has a different set of extensions, but it is unlikely that Google is using browser fingerprinting*)
In fact, I am under the impression said cookie only lasts for 30 days.
*make sure that if you have any extensions, they are ALL allowed in incognito mode, and you will see there is no "browser fingerprinting", as per @David Houde's answer.


Why would it be a good idea for someone to get a YubiKey?

I bought, and enthusiastically use, my yubikey.  The way it stores two OTP profiles is particularly useful: with one set of keydata (short-press-the-button) I kept the secrets close, and use it for sudo (and, one day for straight ssh login) access on my colo'ed box.  The other (long-press-the-button) I shared with Clavid, who offer an OpenID authentication service which allowed me to properly tighten my whole OpenID authentication loop [1].

As others have pointed out, unlike a number of other hardware-authentication-dongle services, you control your own keying material, and don't have to trust any third party to get things right if you don't want to.

One of the biggest wins with it is being able to use untrusted endpoints to authenticate via the 'key, because the password so disclosed is useless as soon as it's used.  The biggest problem with that, however, is that many classically-insecure endpoints (eg cybercafe PCs) disable their USB ports, which can make finding somewhere to plug the Yubikey in quite hard.

On the whole, though, I think they're a big win.

[1] I'm a big fan of OpenID.  The thing that originally brought me to server fault, the SE site where I do most of my posting, was its offering OpenID authentication.


Does a network behind a NAT\modem firewall need a firewall?

Routers are, internally, computers. They run an operating system (often a Linux or VxWorks derivative), with code. Like any substantial piece of software, they have bugs, some of which being remotely exploitable. However, unlike computers, they are rarely updated, so whatever security holes they have tend to be long-lived. And that's without counting more basic issues like default admin passwords.

While, conceptually, the router can be your firewall and thus any other firewall would be redundant, you would be well-advised to run an additional protection layer, such as a small PC with two ethernet interfaces, acting as a router/firewall, with a Unix-like operating system (some Linux or BSD flavour, for instance). The important point here being maintenance: don't consider the box as an opaque appliance to be installed and then forgotten. You have to check for security updates, preferably daily.

I thus recommend installing another firewall in addition to your SOHO router, not because the router would structurally be bad at firewalling, but because adequate security is reached only if proper system administration is applied, and you cannot really do that with a SOHO router; whereas you can with a PC and an open-source, maintained operating system.


Clarification needed on CSR signing process

The CSR is checked for validity. If it is valid, then the old signature is stripped out and a new certificate is built.

The ingredients for the new certificate are as follows:

Info from CSR (Plus some fields added/changed/removed. Whatever your CA feels is best.)
Typically some basic constraints (Such as the statement: "What I'm signing here is (or is not) supposed to be a CA itself." )
Info about who is signing.
And then the signature itself.

All the pieces that are To Be Signed make up a set. This set is called "TBSCertificate".
And TBSCertificate + signature-parts make up what is then called "Certificate".

RFC 5280 breaks this down like so:

Certificate  ::=  SEQUENCE  {
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
    version         [0]  EXPLICIT Version DEFAULT v1,
    serialNumber         CertificateSerialNumber,
    signature            AlgorithmIdentifier,
    issuer               Name,
    validity             Validity,
    subject              Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version MUST be v2 or v3

    subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version MUST be v2 or v3
    extensions      [3]  EXPLICIT Extensions OPTIONAL
                         -- If present, version MUST be v3
    }

There is an excellent blog post that goes into more depth about what is and what isn't actually inside a certificate: Morgan Simonsen, 2013-04-16, Understanding X.509 digital certificate thumbprints (Archived here)


Received SMS/MMS with suspicious link - what to do now?

You are not yet infected, but opening the link will most probably infect you (or attempt to).

What you should do open and analyze the link from a secure container (this is how you find more info on what's there and what the purpose of it is) and delete it from your device.