That email seems legitimate.  You probably have cause for concern.

Contact their customer support as soon as possible.

However, do not click any links in that email. The email might be fake, and could be an attempt to get you to log into a fake version of their site so that they can steal your password.  The general rule is, unless you are expecting an email before you get it, verify that the email is legitimate before clicking on anything.

The next step to take is: change your password everywhere. If someone did log into your account, they probably got your username and password from a site with poor security.  Most people re-use their passwords, so malicious people will get these leaked passwords and try them out on other sites.

I strongly suggest starting to use a password manager to keep your passwords secure, and use random passwords that are different on every site.  If you can, set up 2-factor authentication on all sites, as well.  The time-based tokens (I.e., Google Authenticator) are great.  Better options are U2F devices, where you have to physically plug something into your computer's USB port or set up a Bluetooth connection.  Cell phone text message-based systems are better than nothing, but if someone is targeting you specifically, they can steal your phone number and it could be several hours before you learn that something is wrong.


What kind of IT security applications do you guys run on your laptop/desktop?

You mean in the background as a service?

Nothing. Bogs down the system for no useful result.


How to temporarily store data securely on a cache/relay server?

You do not need to store the PIN on the webserver database, you only need to store something that will enable you to tell (with very high confidence) that the user did input the correct PIN.  Assuming that the PIN is sufficiently long (a twelve digit PIN might work) you could do a classic salt+hash case.

Yet, most PINs are 4 digits, therefore rather useless as an authentication method.  Instead you can use a decent authentication method in addition to the PIN (making the PIN to be just a detail of the authentication).

A hundred thatnks to atk for chasing me on the fact on how much a 4 digit PIN is useless as an authentication and how easy it is to brute-force it.  Seriously, I learned a lot from writing and rewriting this.

Decent option: Add proper authentication

Add a login and password (passphrase) authentication for the users on the webserver.  This authentication can stay only on the webserver.

A user willing to interact with the frontend (at least with the part in which he can alter data) must login first.  Note that if the current webserver setup already performs this you can reuse it for this purpose.

Now that you have a proper authentication (the passphrase) you can store the PIN in the webserver's database based on it.  You can encrypt the PIN under a key generated from the passphrase.  For example using PBKDF2.  In other words, on the first request from a user, the webserver will need to talk to the control system and retrieve the PIN.  It will then store the PIN in the database as follows:

AES(pbkdf2(user_passphrase), PIN)

The user must provide both: his password/passphrase for the webserver and the PIN to perform the request.

On a following request, the user again needs to supply the passphrase and the PIN.  But the webserver can use PBKDF2 on the passphrase and use the generated key to decrypt the record from the database and compare against the provided PIN.

In summary, you add a better security feature (a proper passphrase) in addition to the (quite insecure) PIN.  You can (and probably should) allow the user to change his passphrase on the webserver but then you need a way to invalidate the cached encrypted PIN in the database.

Limited option: Trivial hash+salt

The following is how you could perform this by using a sufficiently long PIN (e.g. an alphanumercial PIN of some 12-20 bytes in length would suffice against today's brute-forcing attacks).  Note that the hash function selection is important.

On a request from the webserver the control system, instead of sending the PIN, may create a salt concatenate to the PIN and use a cryptographic hash to generate a value.  For example the control system may perform something like:

Receives request from server for user Bob;
Generates a random salt (say, 012345667890abcdef);
Retrieves Bob's PIN (say, abdd);
Performs hash <- hash_function(abdd + 012345667890abcdef);
Returns hash and salt to the webserver.

The webserver will store both the salt and the hash in the database.  On a request from Bob to the webserver a PIN will be sent, let's call it reqPIN.  The server can perform the following to check that the PIN is correct:

Retrieve the salt and hash for Bob from the database;
Preform reqHash <- hash_function(reqPIN + salt);
Compare reqHash with the hash from the database.

If the hashes are equal Bob had input the correct PIN.

If the webserver is compromised, you can just boot another one and ask for new salts and hashes from the control client.  Nothing on the webserver database can be used to recover the PIN (not in less than a dozen years of extensive hash crunching at least).

Notes:

The hash_function can be any cryptographic hash and gives you a very small collision chance, which is pretty safe to ignore in practice
Hash functions as bcrypt or scrypt are needed (maybe even argon2), these hash functions are expensive computationally, making a brute-force attack much harder.  You may also perform the hashing several times, i.e. hash_function(hash_function(hash_function(...)))
The salt is needed in case two people have the same PIN and one of them is the attacker.  He cannot tell that the other person has the same PIN as himself even in the possession of all hashes.  He would need all hashes and all salts, and he still would need to recompute all hash iterations.


The operation phase is fine.

HTTPS should protect against MITM attacks in the operational phase.
Signing of the data is fully acceptable in the operational phase.

The installation phase is fine, although I suspect that you meant HTTP instead of HTTPS. This will work and the MAC's will protect from tampering. What I'm now proposing is a "could be".

You could use OpenSSL instead of OpenSSH for the server S.
You could formulate a CSR for a S/MIME and TLS client certificate and let it be signed by the master server M (acting as a CA). Both server could then afterwards connect via mutually authenticated HTTPS and you could use the S/MIME cert-part to authenticate output, as the master would be the only one that would need to trust himself.


How do hackers make the victim access an XSS attack URL?

the user did some actions that they won't do as usual

Clicking on a link does seem like a usual action for most users.

See for example this study, in which 56% of users clicked on links in E-Mails from an unknown sender, and ~40% clicked on links send via Facebook (despite 78% being aware of the possible danger). 50% said that they didn't click the link because they didn't know the sender.

That's already an impressive success rate. If the victim knows the attacker, or if the attacker spoofs the identity of someone they know, this rate could be increased even further.

On social networks, reflected XSS might also be wormable. In addition to the malicious action, the injected script could send messages containing the link to all friends of the victim (something like this eg happened to Twitter).

In addition to E-Mail, links could also be distributed in forums, blogs, issue trackers, and so on. This for example happened to Apache.


An oracle is an individual who knows the personal cell phone number of a god. This enables him (or her) to obtain some information which is usually considered as out of reach of mere mortals, such as glimpses of the future. In cryptography, that's the same, except that no deity is involved: an oracle is any system which can give some extra information on a system, which otherwise would not be available.

For instance, consider asymmetric encryption with RSA. The standard I link to states how a piece of data should be encrypted with a public key. In particular, the encryption begins with a padding operation, in which the piece of data is first expanded by adding a header, so that the padded data length matches the RSA public key length. The header should begin with the two bytes 0x00 0x02, followed by at least eight random non-zero bytes, and then another 0x00. Once the data has been padded, it is time to apply the mathematical operation which is at the core of the RSA operation (modular exponentiation). Details of the padding are important for security.

The encryption result is an integer modulo the RSA modulus, a big integer which is part of the public key. For a 1024-bit RSA key, the modulus n is an integer value greater than 21023, but smaller than 21024. A properly encrypted data chunk, with RSA, yields an integer value between 1 and n-1. However, the padding implies some structure, as shown above. The decrypting party MUST find, upon decryption, a properly formed PKCS#1 header, beginning with the 0x00 0x02 bytes, followed by at least eight non-zero bytes, and there must be a 0x00 which marks the end of the header. Therefore, not all integers between 1 and n-1 are valid RSA-encrypted message (less than 1 every 65000 such integers would yield a proper padding upon decryption).

Knowing whether a given integer modulo n would yield, upon decryption, a valid padding structure, is supposed to be infeasible for whoever does not know the private key. The private key owner (the deity) obtains that information, and much more: if the decryption works, the private key owner actually gets the message, which is the point of decryption. Assume that there is an entity, somewhere, who can tell you whether a given integer modulo n is a validly encrypted piece of data with RSA; that entity would not give you the full decryption result, it would just tell you whether decryption would work or not. That's a one-bit information, a reduced glimpse of what the deity would obtain. The entity is your oracle: it returns parts of the information what is normally available only to the private key owner.

It turns out that, given access to such an oracle, it is possible to rebuild the private key, by sending specially crafted integers modulo n (it takes a million or so of such values, and quite a bit of mathematics, but it can be done). It also turns out that most SSL/TLS implementation of that time (that was in 1999) were involuntarily acting as oracles: if you sent, as a client, an invalidly RSA-encrypted ClientKeyExchange message, the server was responding with a specific error message ("duh, your ClientKeyExchange message stinks"), whereas if decryption worked, the server was keeping on with the protocol, using whatever value it decrypted (usually unknown to the client if the client sent a random value, so the protocol failed later on, but the client could see the difference between a valid and an invalid padding). Therefore, with such an implementation, an attacker could (after a million or so of failed connections) rebuild the server private key, which is usually considered to be a bad thing.

That's what oracles are: a mathematical description of a data leak, to be used in security proofs. In the case of RSA, this demonstrates that knowing whether a value has a proper padding or not is somehow equivalent to learning the private key (if you know the private key you can attempt the decryption and see the padding for yourself; the Bleichenbacher attack shows that it also works the other way round).


How to detect if files were saved or copied to a USB drive?

This will depend entirely on what logging you have enabled. It it's easy after the event to tell you to log all file copies etc, but if you weren't logging it, you won't be able to retrieve that info.


You can safely remove the keys stored in /etc/ssh, generate new keys and restart sshd. There is nothing more to it than that.

But please note that every client that have the old key stored in their known_hosts file will complain. You will need to remove that record from your clients. This can be done using ssh-keygen -R <hostname>


How does client verify the certificate provided by the server which is signed by different intermediate CA

Will the client/server completes is certificate chain using trusted certs and extra certs?

Yes, SSL_CTX_use_certificate will load the certificate and SSL_CTX_add_extra_chain_cert will load the chain certificates and both are sent to the peer during the TLS handshake.

  During SSLHandshake what shall the peer present? Only the domain certificate or the whole chain?

Certificate and chain.

  Will the SSLHandshake succeed because peer's intermediate CA is not present in local certificate store?

Since the peer sends the chain certificates up to the trusted root it is not necessary to have the peers chain certificate known up front, i.e. the handshake will succeed without.

  Does only having the root CA in store enough to verify the certificate chain presented by the peer?

Yes, see last point.

  If I am to create multiple clients from the same application, can I use the same context initialized with set 2 to connect multiple servers which are signed by same root CA?

It is not really clear for me what this means. But the same context can be used for multiple peers, i.e. to create multiple TLS sessions.


ZAP: Can't Execute Scripts within Zed Attack Proxy

You don't execute Extender scripts, they're either installed (Enabled) or not (Disabled). Read through the code of the Message Logger, it's meant to write traffic to disk (in its default form, only JSON traffic).


Pros and cons of multitenant firewall provided by ISP

there is actually no way that other tenants can break my configuration, right?

No, you don't know that from the information provided, it is only implied.

Nor do you know what is between the firewall and your network.

But the question posed does not say what choices/questions your decision is supposed to address e.g.

does configuring a policy on the providers firewall pose any additional risk to your network?
does using the providers firewall make your own firewall redundant?
coke or pepsi?

  what can be some risks or pros/cons of this approach?

As per above, which approach? Assuming you mean retiring your local firewall, then (in addition to the to the previous points about config and what else is behind the firewall....

Management of the firewall platform (patching, monitoring, alerting)
Has the providers network design been audited to verify the firewall is effective (no back doors)
Do you want to be able to capture and analyze event information from the device? Can you? How is this provided?
Do you have the skills available to configure the providers firewall? Is it an off-the-shelf product you get training or independent consultancy for?
what is the SLA from the provider?

notification about scheduled maintenance
planned vs unplanned downtime

How much does it cost?
What would be the impact / likelihood of changing providers?
Is there automated change management around the configuration (e.g. notification of config changes, config version control at the provider)
are there routes into your network covered by current local firewall which are not covered by the provider firewall


Barracuda antispam access to active directory in dmz : opening port or not?

Like most such solutions, the Barracuda Antispam offers directory lookup (LDAP/LDAPS), SMTP "look-ahead" where each recipient is validated on the next SMTP hop before being accepted, and a manual recipient list -- see Solution #00003521. Only the directory lookup approach requires an additional port, you would need to permit LDAP/LDAPS (389/636) or more commonly the GC ports (3268/3269) from the Barracuda to a suitable AD server.

Domains > manage domain > Users > LDAP Configuration

You can configure a low-privilege AD user which only needs search access to user email attributes in your AD tree (then enable it for the domain on the Barracuda under the ''Valid Recipients'' tab). Assuming you do not permit anonymous search access to your directory (not recommended), you should use a dedicated search user and LDAPS, this will require a certificate on the AD server.

SMTP look-ahead only works if the next hop is able to authoritatively answer, i.e. it must reject invalid recipients (with an SMTP 550) or it will not be effective. You may need to configure it to do that (some SMTP servers inexplicably default to accepting anything, then generating a bounce for invalid recipients). Look ahead is implicitly enabled if LDAP is not used. If you're using MS-Exchange, this is quite likely what's preventing the default look-ahead from being effective, look at this approach first.

Otherwise, using LDAP is the next best approach, though not without some risk since you're allowing a device which accepts untrusted connections from the internet establish connections to your AD. More paranoid alternatives are an LDAP proxy in a DMZ (reasonably straightforward with OpenLDAP as a proxy); or a filtered replica in a DMZ (I believe this may not be easy to do with AD, though it's easy in a OpenLDAP environment).

(Also, if you're not using it already, try the Barracuda RBL, it's very effective at blocking unwanted connections, though expect a low number of false positives).


One of the way that I use to capture the network traffic from the java application using Wireshark. Refer the documentation to capture the traffic. Once the traffic is captured. Click Analyze -> Decode As -> Transport,select the port and the select SSL, apply and the save the settings. The captured traffic will be shown as SSL. Look for the response of the  "client hello" message in the captured traffic. This is where SSL/TLS handshake is done.

Refer the below image:


Can an attacker slow down my server without compromising it?

Have a quick read of the Wikipedia article on reflection attacks: http://en.m.wikipedia.org/wiki/Denial-of-service_attack#section_2

Using Internet Protocol address spoofing, the source address is set to that of the targeted victim, which means all the replies will go to (and flood) the target.

It's a relatively easy way for an attacker to launch a large scale attack from many IP addresses against one target.


Authorization with MD5 imlemented in Javascript

No, it is not.

First, because MD5.

Second, because an eavesdropper can intercept the hash just like it can intercept the password, allowing them to send the same hash to the server to impersonate the user ("replay attack").

What you could do instead is have the server send an unpredictable, unique string to the client for each login attempt. This is called a "nonce" in cryptography. The client then creates a hash of the password together with that nonce. When nonces do not repeat and each nonce can only be used once, the hashes will not repeat either and replay attacks will be impossible.

But even that will not help when the attacker can not just eavesdrop but also manipulate the traffic. That would allow them to replace your javascript code with their own which sends the unencrypted password to them.  No javascript-based scheme would protect you in that scenario.


To expand upon Rory's recommendations, you really need to ask yourself what is the driver behind your logging, and what information you need to accomplish those goals.
For example, if you need user attribution then you probably need

Username
Timestamp
Source IP
GET string and possibly POST variables
Session IDs
Cookie information (expirations, tokens if appropriate, chocolate/sugar/gluten-free, etc)

Are you looking for unauthorized access attempts?

Timestamp
Source IP
Action Performed (login, data query, etc)
Related information to action, (username, query string, etc)

Do you have policy/contractual/regulatory/etc. requiring full session reconstruction? Well, that's a lot harder and will require all kinds of scary data on every request. This will likely require deep app integration and possibly need things like stack traces, variable dumps, packet captures, etc.


How can one easily determine which IT Security related regulations apply?

Core questions you need to ask - and these are covered by some of the answers in the questions @AviD has linked to and at high level by @Beth:

Are you handling payment card data? If so, PCI-DSS
Are you handling medical info? If so HIPAA in the US, DPA in UK
Are you handling personal info? If so DPA in the UK
Are you handling the personal data of any European subjects? If so, GDPR from May 25 2018
Are you a financial org? GLBA in the US, FSA regs in the UK
Do you trade on NYSE? SOX in US, JSOX in Japan - but similar requirements globally
Are you a retail bank? BASEL II (soon BASEL III)
Are you a European Insurer? Solvency II

There are equivalents for these in many jurisdictions


Static MAC address on Switches and routers

Assigning a specific MAC address to a specific port guarantees that only a device with this MAC address will get connectivity on this port. This policy is usually done in combination with monitoring the port for policy violations to detect if somebody plugs in a device with another MAC address.

Thus an attacker has to use passive sniffing techniques to get the MAC for the device used on this specific port and then replace the device with its own. But with a simple replacement the other device will no longer work. Since this might get detected the attacker needs to employ a more intelligent solutions. At the end the knowledge and care needed by the attacker to be stealth is much higher than without static MAC assignment and the chance to get detected is higher too. This makes static MAC assigning not a 100% secure solution against MAC spoofing but makes spoofing considerable harder which is in most cases enough.


Standalone exe application - hide password

Use a salted hash, just like you would in a tool that is connected to the internet.

Clearly, if an attacker has the software installed on their own system, they can just modify it and remove the password altogether. But then they're only hacking it on their own system.

If the password is a salted hash, they will only know the salted hash, not the actual password.
There should be implementations for calculating a salted hash in C++, that you can use to verify the password that the user types in. So you don't have to write it yourself. This is still a thing to consider even if your application does not connect to the internet. Your application may not go to the internet, but the computer on which it runs probably does have a connection, and is liable to attack - it is only as safe as the computer on which it runs.


Estimating Password Cracking Speed Based on GPU?

As was mentioned, getting exact number of hashes per second is impossible, but some benchmarks should give you an idea of scaling if the coolling and other variables are equal or adequate.

Now I would avoid mentioning precise numbers and keep in mind that while comparing NVIDIA RTX 2060 and 2080 sgould give you a decent idea, comparing NVIDIA and AMD or RTX vs Titan or even across generations can be widely off if you use different hash algorithm than the benchmark.

https://tutorials.technology/blog/08-Hashcat-GPU-benchmarking-table-Nvidia-and-amd.html


Redirection HTTP to HTTPS, can I prevent giving away the URL?

If you need to protect against a MITM then full-on https+HSTS is the only way, no working around that.

Regarding the 301 redirection giving away that the article exists that's not really true. The redirection can (and usually does) happen before additional actions are taken on the request. If the article doesn't exist you can send the 404 reply after the redirection.


How will IPv6 affect DDoS mitigation techniques?

Remember that IPv6 is not that different than IPv4.

Layer 2 is still the same, as is Layer 4 and above. Routing protocols also remains the same.

So a good old "lets fill the victims internet link" attack, works similar in IPv6, but with different tools.
What one could hope, is that ISP's does a better job stopping spoofed adresses from leaving their network when they implement IPv6.


Overwriting only Free Space with rubbish data to prevent data recovery?

Yes, it is a good strategy if a disk has held sensitive data and may be accessible by others.  A Google search for "wipe disk free space" finds numerous such tools.

There are a couple of other considerations.  One is "slack space."  That's the unused space in the last cluster of a file.  It's not part of free space, so it won't get wiped by many disk wiping utilities, but it will contain whatever was there before.  If your operating system uses 32K clusters, on the average, each file will have 16K of "old" data at the end.

The other consideration is the directory structure.  Deleting a file releases its space, but often the directory entry is just marked rather than overwritten; it depends on the operating system.  So, if I delete "breakingbad.dat" some or all of the file name is likely to remain in the directory structure.  It can be even worse for NTFS.  Very small files are stored entirely within the master file table (MFT) so a file of size less than about 1K may not get wiped when you clear free space.  That's the file contents, not just the directory entry.

What this means is that you will want to choose your wiping tool carefully.  For general cleanup, just clearing the free space may be enough.  For sensitive data, you need to clear slack space and directory entries, too.


Why wireshark source ip tab lists other ip as well

The source-address tab represents the address the packet claims it is coming from. Be adviced that this can be easily spoofed so it may in fact not be the actual sender of the packet.

In your case it may not be trivial to know who all the IP addresses are. However if they are not RFC1918 (private IP addresses) you can run them through a geoip service to learn more about the addresses coming to you.

If they are in fact RFC1918 addresses I would take a closer look at your network to find out who the machines are. In some cases a reverse DNS lookup may help you in identifying the machines.

Geoip using netcat:

ip.txt format:

begin
verbose
<ip address>
<ip address>
end

Build your file and do the following command:

netcat whois.cymru.com 43 < ip.txt > result.txt

Sample output:

Bulk mode; whois.cymru.com [2012-07-20 08:28:50 +0000]
8542    | xx.xx.xxx.xxx     | xx.xx.xx.xx/18      | NO | ripencc  | 2002-04-02 |
Internet service provider

You can read more about the service here: http://www.team-cymru.org/Services/ip-to-asn.html

Reverse DNS lookup with nslookup:

nslookup -type=PTR <IP in question> <IP to DNS server>


Being a mail system administrator, I suppose you know that email messages do not contain anything that would allow you to identify whether they are sent by a human or a machine.  The BOT will certainly not indicates that it's a BOT in the message or even the headers.

Common SPAM detection methods apply to any messages whether sent by a BOT or not.

I suggest you look at existing SPAM detection solutions such as SpamAssassin along with the different plugins available for it.  As you will see, with proper training, it actually does a very good job.


Value of using passphrase on private key

Common production environments allow unattended restart. That means that the ultimate secret will have to be present on disk in plain text or in an invertible form.

So the only 2 ways are either to accept it and in your use case just install an unprotected copy of the key, and rely on the infrastructure security to protect it, or use obfuscation and try to hide the password elsewhere.

The only alternative would be the use of HSM. Unfortunately I could not find any indication on how a HSM could be used to hold the private key for nginx. A blog article from 2016 says:

  Sadly, both Apache and NGINX do not support PKCS#11 in their ssl module.

Maybe someone will be able to find a newer reference saying that it is now possible

However, it looks that Apache already has some support through an external module. Same blog says:

  For Apache you can use mod_nss to use the certificates from the HSM.


What is the difference between a hash table and a rainbow table, and how are they both used?

Both hash tables and rainbow tables store precomputed hash values. Rainbow tables are a computing power vs storage tradeoff compared to hash tables.  They are used because hash tables can grow very large especially as the throughput of cracking hardware has improved. You can brute force more combinations but now you need to store more.

How much space are we talking about?  There are common password lists (taken from previous hacks) with tens of millions of known passwords and that is usually where crackers start.  This can be supplemented by hundreds of millions of permutations of those weak passwords (if someone used password1111 someone else probably used password2222). Then lastly for good measure the gaps can be filled in with an exhaustive search of all possible combinations of passwords up to a certain length.  Take 1 billion passwords, with an average length of 8 characters, and a 32 byte hash. That is 40GB of storage space to store the hash table.

A rainbow table is a way to store the same information using less space.  There is no free lunch though in computing you can always trade storage for computing power and that is what you are doing.  To build a rainbow table, a traditional hash table is first constructed.  Starting with those hash values a hash chain is constructed using alternating hashing and reduction functions.  The reduction function maps the hashes back to different passwords in the list.  The length of the chain is determines how much of a tradeoff is used (longer = more space saved but more work to perform a search).

Only the chain beginning and end are saved and the rest is discarded so the final table is much smaller.  Locating a match now required multiple lookups which means it takes longer than a hash table.

Both hash tables and rainbow tables are used to save the results of a precomputation attack.
Lookups in a rainbow table are slower*, but require less space to store the precomputed results of a given number of passwords.
Lookups in a hash table are faster*, but requires more space to store the precomputed results of a given number of passwords.
Both hash tables and rainbow tables are equally and totally defeated by using a pseudo-random salt per record.

*This assumes equal hardware response time which may not be the case (i.e. rainbow table can fit in main memory but hashtable requires a read from slower disk because it is too large to fit in main memory).


Is using trim on a ssd with LVM LUKS safe?

From what I understand about the information betrayed by observing results of TRIM operations on LUKS encrypted volumes, actual plain-text data is not likely to be recovered. As you say, filesystem and data layout information can be inferred. Rather, details on the crypto implementation could help an attacker reduce the key space in a brute-force attack.

Conversely, there are security implications from not enabling TRIM where if your passphrase is compromised and you decide to re-encrypt the header, there is no guarentee the original header is overwritten. This would mean that later attainment of your disk could mean an attacker using the compromised password could forensically locate the old encrypted header, get the master password and decrypt data despite the change of passphrase. I would consider this scenario more of a concern for the average user than a third-party being able to forensically determine where unused blocks are and/or the filesystem.

A great analysis of the kind of information and other concerns regarding TRIM implementation on dm-crypt'ed devices can be found here:

http://asalor.blogspot.co.uk/2011/08/trim-dm-crypt-problems.html


Allowing the public to generate a CSR from your private key

In theory, provided a system was secure enough and you only ever signed the CSR on a separate server, keeping that key damn secure, there would be no issue with this.

However,

What happens in the event that you do somehow have that private key compromised?
What's your plan in the event of a breach?
Will you have that private key for your TLS certificate on the same server as the signing server?

Ask yourself: is there any benefit to using the same key for 1000+ domains? Can you explain the single point of failure to your customers?

In addition, RSA (at least) has no currently known attack on being used for signing repeatedly that would give away the key. That one's reserved for DSA with a dodgy PRNG.

Still, it's a bad idea.

Update

The system you want in this case would be as follows:

Every customer is jailed (via chroot()) into their own directory on the server
For every CSR generated, a private key is generated in the user's jail, but outside of the webroot.

e.g. /jail/customername/private/server.key
/jail/customername/domains/<domain>/subdomains/<subdomain>/public
/jail/customername/domains/<domain>/public
/jail/a/domains/a.com/public/, etc.

The webserver must respect jails, and scripting languages must run as a user that cannot access the private folder in every user's jail.

There would be no issue with this system; I'm assuming you are running a shared host system, and that you want an easy way to generate a CSR for each customer to enable TLS.

This way, you have correct and enforced separation of privileges for each customer and in the event a customer is compromised (barring any local privilege escalation exploits), the rest of your infrastructure is sound and you can just revoke the TLS certificate from the user who was exploited.


Investigating header and cookie flag issues

There are web proxies and packet sniffers that allow you to inspect traffic. You send traffic to the ports then inspect the traffic.


How do you get Geolocation information from the CellID field in the herrevad database from Google Mobile Services?

You have to input the herrevad.fb file to a online site like cellid and they will return to you decoded entry with the exact location shown on a satellite map and you will be able to track the android location history.


So, first things first, your last sentence is self-contradictory. If you don't trust the server for site B, you can't and mustn't trust any content from B, including scripts. If B is malicious or compromised, when you visit B you will get either an altered script that does something malicious, or just get an extra script that tacks malicious behavior onto the normal operations. For example, the malicious code could trivially retrieve the secret after you decrypt it, or just retrieve the secret and its decryption key directly.
What you're trying to do is impossible.

With that said, if you have some way to ensure that the client code is trustworthy - perhaps the page and all of its scripts are loaded from a browser extension or local app, rather than from the server - this is pretty easy.
The simplest approach would be to use CORS. A script on B would make an authenticated cross-origin request (using XHR or Fetch) to A, requesting the data. The server at A would check that the user is authorized, and return the appropriate data, along with the Access-Control-Allow-Origin: B and Access-Control-Allow-Credentials: true headers necessary for the script to see the response.
Slightly more complicatedly, you could do this using the Window.postMessage API. You'd create a listener for window messages in a script on B, and then open a window (iframe, popup, maybe even separate tab) to a page on A. The page on A would have (or retrieve) the secret, and then call postMessage to send it to B.
In both cases, the secret never actually hits the server at B - it's entirely client-side, and could be stored in local storage or whatever might be needed on B - but of course you have to trust that the code on B isn't going to just make a same-origin XHR or Fetch to send the secret down to the server (or something similarly unfortunate). As mentioned above, if you can't trust the server at B, you can't trust any code that runs on B's origin (unless, somehow, none of that code actually comes from the server and you can be sure of that).


Can someone get my WPA2 password with honeypots?

Yes and no. They may not have your password in plaintext, but they have enough to potentially guess it and verify that guess (i.e. offline brute forcing).

WPA2 authentication is performed through a four-way handshake. Instead of just sending your password in plaintext to any access point you connect to, this handshake ensures that unless both parties already know the password, the password (or any attempt at it) is not revealed. However, enough of that four-way handshake can be recovered to make offline password cracking possible.

Please understand you risk this every day. The network manager on your computer/device is probably configured to automatically 1) search for familiar access points by sending out beacons (thus advertising what is familiar to it and essentially how to mimic it) and then 2) automatically connecting to any familiar access points that responds. Even if you are currently connected to a wireless network, an attacker could disconnect you via a deauthentication attack and then lure your device into connecting to their honeypot.

What can you do to protect yourself?

Chose a password that is tough to crack.
On your device, disable automatic connections to so called "familiar devices".
Refuse to connect to wireless networks with weak passwords.

Friends don't let friends chose weak passwords.

Stay away from any WEP or unencrypted networks. Seriously.

If you are interested in 802.11 (aka WiFi) security, check out Vivek's "WLAN-Security-Megaprimer" on SecurityTube. There is a lot of FUD and misinformed articles on wireless security, but the material of Vivek Ramachandran and (when you're ready to try attacking yourself) the documentation on the aircrack-ng wiki are solid. I can not recommend Vivek's material enough. Also, this article on the security of WEP, WPA, and WPA2 seems promising.

You are doing a great job thinking about security and asking the right questions. The next step is to attack yourself. Remember to stay paranoid.


Are password reset links that don't expire a security risk?

For example: if I remember my password, then don't reset it.

Now, if my email account is later compromised (or if I visit the link and anyone decides to peruse my browsing history), they can change my password at will and there is no way I can prevent it except to change my own password.

Unless, of course, you meant the token is only good for one page visit.  That's certainly secure, but also inconvenient if I close the page, my session expires, etc.


From where is the "previous 15" requirement coming from?  That seems unlikely to actually improve security much - my first step would be to reduce that if it's not coming from a legal, regulatory, industry, or auditing requirement.

An attacker doing an online attack won't notice at all
An attacker with your PW database doing an offline attack against just the current passwords won't care during the attack
More complex pattern-noticing analysis on the attackers part is too complex to go into here, but imagine a user who uses football1, then football10, football100, etc.  The pattern's obvious if you have a few passwords, even if football100000000 might not be tried until until a very late stage of password guess (if at all, given how many hundreds of thousands of iterations you must be using)

Also note that trying N different PBKDF2 values at once means you can use multiple cores; i.e. for 15 PBKDF2 runs at 1s each, if you had 10 cores, this could take as little as 2 seconds (10 in the first second, 5 in the second second).  You will be using the same (or slightly more) CPU time, though - watch out.

Reducing PBKDF2 execution time decreases security significantly, since at attacker has to do less work in the same proportion you do less work.  If you can afford to target 1s of CPU time (presumably for fairly infrequent logins, or for a very hoss server farm), keep it!  That will dramatically increase an attacker's workload at the same level it reduces yours; I don't recommend it.

If you're targetting one second of PBKDF2 work per login, then 15 users logging in at about the same time is exactly the same workload as any 15 other unique salt PBKDF2 operations - make sure you can afford your current target times under your expected peak load for the next 2-3 years.  Also, how often will users be changing their passwords?

One other alternative:

Don't change a user's salt every time.

This is not a great idea, but can be done, and will solve your performance issue.  However, offline attackers with the full password list will have 16x the chances to guess passwords for each try.
Only changing the salt every 2 to 6 password changes would strike a middle ground - it would be less bad if you have very, very frequent password changes.

P.S. You know you're going to get users using P@$$w0rd1, P@$$w0rd2, P@$$w0rd3, P@$$w0rd..., P@$$w0rd999, don't you?


For a computer client, is physical security the most important measure?

Being online at any time is the problem, not being online most of the time - though that does, of course, increase the risk. Try putting a brand new computer online for the first time without the benefit of the firewall in your router. It takes no more than 30 seconds to start seeing automated hacking attempts to commonly used ports.

The only way to be safe is to have a never connected system. This is known as an "air gap". However, even this isn't that safe as the US Airforce found out when some of their UAV systems got infected after someone had opened an infected file. They were not ever connected to the Internet. Of course, in that case no damage occurred other than embarrassment and the time/energy required to cleanse all the PC's. But a targeted attack might have caused serious damage.

In your example, your supposed safe computer is actually very vulnerable (though not as vulnerable as the connected PC of course) due to you exchanging information with it from the online PC. To reduce this vulnerability, you would need to ensure that any data you passed from one to the other was carefully cleansed of any possible infection. The use of a Live CD would be sensible and would limit any infection of the connected PC. But you would not want to use a network file system to connect unless you had good protection of the network & even using USB would require very good anti-malware on the unconnected PC.

Then you have added a massive overhead to your computing environment so you would need to ask yourself if it was worth it. You would need to be working on very sensitive information, working on high-risk web sites, or be at high risk of attack to warrant that kind of overhead I would think.


Is SSH security necessary on an internal network?

In general any authentication with empty password is a bad idea.

  My office network doesn't allow SSH access from outside the local network.

SSH is not the only way an attacker might gain access to the internal network. A password means enhanced security and security means that when a system fails it fails gracefully or at least as gracefully as possible. If the VM is not designed to be a honeypot then in any other case a password is necessary.

  I would like to remove the password with the NOPASSWD flag to make it easier to run sudo commands and for my coworkers to use it.

Then consider using ssh-keys for authentication, it's considered more secure way to login and you don't have to type the password every time.


Password protection of encryption and signature keys

Don't try to come up with your own encryption scheme. The one you propose is vulnerable to a known plaintext attack, which makes key material trivial to recover if any bits of the original file are known.

For example, if I know that the first byte of plaintext is always 0x4B, and I can see that the first byte of ciphertext is 0xC7, I can compute 0x4B ^ 0xC7 and get the first byte of the key, which would be 0x8C. From there I can skip ahead 32 bytes and decrypt that byte of ciphertext, and again, and again. Using that information I might discover more information about your plaintext, and use that to decrypt more of the data.

Encrypt your key file with a block cipher (e.g. AES) using an appropriate mode of operation (e.g. CBC), with a key derived using a proper key derivation algorithm, such as PBKDF2. Using a plain hash function for key derivation is a bad idea, as it's extremely fast and allows an attacker to crack the password efficiently. If your mode of operation requires an initialization vector (IV) it should be random and unique, but is not secret information.


Are Ad-hoc security testing beneficial to small business?

I would argue that any testing is better than no testing. The problem with ad hoc testing is it runs the risk of creating a false sense of security or is not targeted at the right level. The business feels it has overall increased security due to the ad hoc testing. This may be true, but at the same time, due to the nature of this type of testing, it is quite possible that a major security hole has not been identified.

Security for small business is extremely difficult. In addition to the lack of staff resources available to perform the work, you frequently have a low level of security awareness as well. Getting basic technical configurations right is relatively easy compared to ensuring the users of the system are informed and don't do silly things, such as click on bad links in suspicious emails. It really doesn't matter how much testing of the software and infrastructure you have in place if one of the users is going to accidentally bring malicious code into your network and bypass all your measures put in place to protect the systems.

One of the largest challenges in small businesses is getting the owners to realise that information technology investment is different to other infrastructure investment. When you invest in new physical assets, such as a building, updated furniture and fittings etc, once that investment is paid for, you normally won't need much on-going investment/maintenance. With IT infrastructure, the on-going maintenance and need for on-going investment tends to be much higher. Too often, small business think they can buy a server, possibly pay someone to develop a little bit of specialist software and their done. They fail to recognise the on-going investment required to ensure the server is patched and up-to-date, the maintenance for the simple bit of software to ensure it stays current, is compatible with later versions of supporting software and operating systems and is patched against evolving threats etc.

My approach is to actively discourage small businesses from running infrastructure where possible. I encourage small businesses to take advantage of SaaS and cloud services. As far as possible, limit what IT they are actually responsible for maintaining to the absolute minimum. This can be a challenge as they don't understand all the hidden costs - it looks cheaper to do it yourself. You need to expose the hidden costs to allow them to make a fully informed decision and ensure this includes some basic regular testing/checking, reliable automated backups etc and ensure there is a plan for when things fail. The plan needs to include how to recover from the failure i.e disaster recovery as well as how to continue business while you are recovering i.e. business continuity.

In those situations where the business has no choice other than to run/develop their own software, look for solutions which will limit their need to invest in security. For example, a hosting provider where the hosting company takes care of hardware and operating system security and the business only needs to worry about application security. Work to help the business develop procedures which facilitate good practices and understanding of the risks and try to ensure these actually reflect the real risks faced by the business (rather than just implement good practice, assess the risks specific good practice is designed to protect against and determine if that really is a risk for that business) and recognise you cannot eliminate all security risks - there is never enough resources. You need to identify exactly what the real risks are for the specific business and prioritise them so that whatever resources are available for ad hoc testing are targeted at the highest priorities. Clearly communicate the risks which are not being addressed and what their likelihood and consequence is so that the business can make an informed decision as to whether they need to invest in additional resources.


Can I change my public IP address to a specific one?

You can send out a packet with whatever IP address you like.
Then, one of the routers along the way might decide the packet makes no sense (it is a "martian packet") and discard it. Consider this:
                                                       | 192.1.1.1
                                 +------------------- GW4
                                 | 192.168.1.1
             +----------------- GW2------+
             | 192.168.16.1              | 192.168.33.1
      +---- GW1 -----+             ---- GW3 ----
      |              |
192.168.16.15   192.168.16.243
     YOU           ALICE

You send out a packet with a source address of 10.0.0.36 and directed to, say, 172.16.16.172. GW1, serving your network which is 192.168.16.0/24, only expected to receive packets matching 192.168.16.0/24, and your packet doesn't match, so it is dropped. You could spoof a connection coming from your "neighbour" Alice, but no more.
Even if GW1 did not complain, it would forward the packet to the next hop, which serves the whole 192.168.0.0/16 branch and also would ignore your packet.
And so on and so forth (the IP I used are actually not all that routable, but it's an example).
Granted, many routers won't do "ingress filtering" because they'll be obsolete or will believe it unnecessary and not cost-effective. But it only takes one hop to wreck the transmission.
Even without this hurdle, the difficulties are not over, because let's say you succeed in delivering to your target a packet coming from 10.0.0.36. The target will reply -- and will reply to 10.0.0.36, so the reply packet will never get back to you. Indeed, should the reply packet arrive to 10.0.0.36, the latter would simply reset the connection as unsolicited.
This is a problem, because most protocols where you "only need to issue a request" are in fact sent over TCP, which requires a handshake between the communicating parties before any data can be sent. The major exception is HTTP/2,
And without that first reply packet you have precious little chance (not the same as zero chances, but still) of establishing a full TCP connection, without which you probably won't be able to send your request.
You might be able to do this using UDP, or other protocols which have no handshake, if the target application uses UDP (it probably doesn't).


Linux/LUKS/Full Disk Encryption: How can I mitigate SSD/flash media security security risk caused by unreliable physical deletion?

Withdrawn in favor of better information
Edit for additional Research
I went looking for some more detail and found some interesting results.
Discard/TRIM support for solid state drives

Solid state drive users should be aware that, by default, TRIM
commands are not enabled by the device-mapper, i.e. block-devices are
mounted without the discard option unless you override the default.
The device-mapper maintainers have made it clear that TRIM support
will never be enabled by default on dm-crypt devices because of the
potential security implications.
Minimal data leakage in the form of freed block information, perhaps
sufficient to determine the filesystem in use, may occur on devices
with TRIM enabled.
By default the LUKS header is stored at the beginning of the device
and using TRIM is useful to protect header modifications. If for
example a compromised LUKS password is revoked, without TRIM the old
header will in general still be available for reading until
overwritten by another operation; if the drive is stolen in the
meanwhile, the attackers could in theory find a way to locate the old
header and use it to decrypt the content with the compromised
password.

Milan Broz's blog (2014)

Ciphertext device without using TRIM from Figure 2 would be just black
box (all sectors have random data characteristic, disk was wiped
before use).
Conclusion?
If there is a strong requirement that information about unused sectors
must not be available to attacker, TRIM must be always disabled.
TRIM must not be used if there is a hidden device on the disk. (In
this case TRIM would either erase the hidden data or reveal its
position.) If TRIM is enabled and executed later (even only once by
setting option and calling fstrim), this operation is irreversible.
Discarded sectors are still detectable even if TRIM is disabled again.

In specific cases (depends on data patterns) some information could leak from the ciphertext device.
(In example above you can recognize filesystem type for example.)
Encrypted disk cannot support functions which rely on returning zeroes of discarded sectors (even if underlying device announces such
capability).
Recovery of erased data on SSDs (especially using TRIM) requires completely new ways and tools.
Using standard recovery tools is usually not successful.
If you decided to turn on TRIM for your device... You have been warned
;-)

Luks, Issuing & Allowing Discards (2017)

The first thing to check is that discards are enabled on your
encrypted device. If don't see allow_discards on your encrypted device
fstrim will not work on any volume within that device.
Example encrypted device missing the discard option:
dmsetup table --showkeys
cr_ata-XXX-YYY-partZ /dev/disk/by-id/ata-XXX-YYY-partZ: 0 12345 crypt aes-xts-plain64 XXYYZZ 0 8:3 4096

Assuming you've encrypted root ("/") we'll check if the fstrim command
works:
fstrim / /: 185.6 MiB (194564096 bytes) trimmed
If there's stdout indicating there's some number of bytes being
trimmed, it's working.

My take on this is that the SSD encryption risks are quite different as a function of whether TRIM is used or not.
Keep in mind that there will be other variables depending upon which SSD manufacturer, model, and interface.
Personally I'm inclined to stick with an HDD for encryption and avoid the issue entirely.
Thanks for the question, I learned some new things!


connect to another ip address remotely via tunnel can be traced?

The problem with this scenario is that you are relying on Network Address Translation (NAT) to hide your physical location.

This assumes that IP Address = Physical Location.

Large IP address sets like 34. *. *. * are owned by top tier providers, who usually sell an address range like 34. 138. *. * to local providers, who assign ranges like 34. 138. 17. * to a business.

Since there are limited IP Addresses most businesses have an internal network IP Address assigned to their employees separate from any Internet public IP addresses. Then the business keeps track of what internal IP address did which request out to the Internet and routes the response to the internal IP address.

This is called Network Address Translation or NAT for short.

Your friend's work most likely has a log of who logged in over the LAN VPN connection. Therefore the government can ask or serve a warrant to your friend's company to see who was on at a specific time. The trail will lead back to your friend. And because his work likely knows where he lives. It won't be hard to find you.

Also depending on the capabilities of the government, they might have physical address location capabilities that don't require the cooperation of your friend's company.

In order to protect yourself from government spying, try a network anonymizer like Tor ( https://www.torproject.org/projects/torbrowser.html.en ).


It's more efficient.
Your device can either perform an active or a passive scan. In a passive scan, the device waits until it captures beacon frames from access points that advertise themselves. In an active scan, you are sending probe requests yourself and wait for APs to respond - this is what most smartphones do.
Passive scanning should be the preferred method in terms of security since it is entirely anonymous, not broadcasting any information about the device. But it also has a negative impact on performance and latency:

The beacon (by default) is only transmitted every 100TU (102,400μs). To have some hope of hearing most Access Points, you’ll need to wait for 2 beacon intervals – say 102,400μs x 2 per channel. We have 12 (or 14 in some areas) channels in the 2.4Ghz band, so a full scan would take 102,400μs x 2 x 12 = 2,457,600μs or about 2.5 seconds.
During this time, the receiver is in a high power usage mode – so battery life is negatively impacted and power usage for a wifi adapter sky-rockets. Sure, you can only run a scan lets say, every 30 seconds – but that still means you have the receiver powered up for 5 seconds out of every minute.

Active scanning is more efficient:

The power requirements are much lower – after the initial probe request, the adapter only listens for a fraction of time compared to a passive scan (although this varies per manufacturer and driver).

(Source)
Besides performance problems, hidden networks that don't send beacons regularly also wouldn't be picked up at all. For devices that use wifi information to enhance the location services (like Android does), active scanning presumably also increases the accuracy.


What are the risks for putting bank account details on a website?

Assuming you are talking about personal accounts not company accounts here. It's part of your identity and you should protect it as much as possible, risk is greater if they can find your address (fairly easy - online address finders, whois records if you  own the website) or your date of birth.

There was a case a few years ago where a UK celebrity claimed nothing could be done with their acct no / sort code and published them in the press - a stranger used their details to set up a direct debit to a charity. link to source (BBC)

Although you might have a number of trusted customers - your details will be available to anyone who can get to your site and some of those may be malicious. If you are in the UK, the direct debit guarantee may cover you if any one set up anything like that but your bank may consider it reckless to post your details in public. I certainly would be very uncomfortable doing so and would consider a payment gateway instead.


RSA vs PBKDF2 for password storage (theoretical)

The two situations are not comparable. Indeed, RSA encryption, like all other asymmetric encryption algorithms, is a randomized process: if you encrypt the same data twice, with the same public key, you do not get the same encrypted message twice. This is by design: since asymmetric encryption uses the public key which is, yay, public, everybody can encrypt data with that key. Since we want to avoid exhaustive search on the data itself, we need this non-deterministic behaviour. As described in PKCS#1, at least 8 random padding bytes are appended to the input data before applying the modular exponentiation which is at the core of RSA encryption.

This has two consequences:

This may not be cracked by enumerating possible passwords. If the attacker "guesses" the right password, he still cannot know that the password matches the encrypted one.
Nobody can tell whether a given password matches what has been encrypted. Therefore, a RSA-encrypted password cannot be used to verify passwords (if the private key is lost), contrary to a hashed version of the password. Your passwords are as good as lost, and no server will be able to tell whether a given password is correct or not by using these RSA-encrypted passwords.

So it does not really make sense to compare "cracking times" between RSA and PBKDF2.

Now, of course, some wannabe programmer might have imagined something which vaguely looks like RSA, but without the random padding, and thus can be used as a password hash. This would indeed be a (homemade) password hash. Assuming that the said programmer did not botch it too thoroughly (an already quite optimistic assumption), then brute forcing would apply, with as much efficiency as the algorithm allows: this is simply a matter of trying passwords, a process which goes as fast as the algorithm is fast. Also, possibly, this not-quite-RSA password hashing would be unsalted, allowing for parallel attack of multiple passwords with cost sharing. PBKDF2 includes salts and also configurable slowness (with an iteration count), precisely to better resist such attacks.


If I run an infected DOS .COM file in DOSBox on C: directory will my main OS be damaged?

DOSBox does not isolate your main computer contents from the files run within it. Thus, it could indeed damage the host.

Probably, it will only affect the files on already-mounted drives, so if you didn't mount any folder with non-discardable contents, you may be fine.

However, a malicious program could clearly run mount drive: <folder> and access <folder> of your computer from inside DOSBox.

You should instead use full virtualization for running your DOS virus (VMWare, VirtualBox…)


Testing a black-box for sound authentication session config

This can include many test cases. Go through OWASP link on this.
However, I want to discuss a few cases.
1) Session Fixation: Ensure that the session ID is set to a new value after successful authentication takes place.

2) Session ID length: Must be of at least 16 bytes. (This is from OWASP page)

3) Session ID Entropy: Must be unpredictable (random enough) to prevent guessing attacks. You can use Burpsuite or other tools to check randomness.

4) Secure and HTTP Only Attribute: These need to be set for the session IDs.

5) Check whether session IDs are cleared from both the browser and the server side( and not only browser) after logout.

6) Ensure the response from the server in which "Set-Cookie" header is present and set the new value of the session ID, this page should not be cached. As then, it will be cached at all the intermdediate proxy and gateways.


String-handling functions aren't the only way to perform a buffer overflow.  If you find a vulnerability in how a program handles binary data (eg. a missing bounds check on a call to memcpy()), there's no problem putting null bytes on the stack.


How does ASLR work if in the assembly code the addresses are the same

The addresses are translated
Unless you are working on firmware or maybe hypervisor code, the addresses in your assembly are not physical but virtual. The lower ring levels (kernel, hypervisor, firmware) have Page Tables in their own memory space to map the virtual addresses into physical ones (or at least corresponding to their own address space when the hardware supports nested paging) and the Memory Management Unit keeps a cache of those mappings to make memory accesses as fast as possible.
When ASLR is active, every time you run an executable the kernel allocates the stack, the heap and instructions into new randomly generated memory offsets so the attackers have no way to be certain about the exact address the overflown buffer is at. Thus, they cannot feed it to the Instruction Pointer when RET is executed and, if by chance they managed to reach it, with W^X they still would have to find out the right instruction addresses of the functions they want to return to to avoid segmentation faults. The same applies to object pointers on the heap.
Attackers usually use NOP slides and Heap Sprays in order to deal with address uncertainty, or either try to to access them on the Global Offset Table or find other leaks instead.

How can the address change each time it is executed? is it require
change that the compiler do to allow it

It needs to be a Position Independent Executable: the addresses need to be defined as offsets rather than absolute inside the executable and linked library files, and that is done by the compiler. When the Dynamic Linker loads them and allocates them what it's basically doing is generating a different random base to multiply against those offsets.


Why is a link in an email more dangerous than a link from a web search?

The results of a search engine are based on previously collected data, i.e. the engine does not starts to scanning the whole internet when doing a search but it looks through an index of seen and stored sites. The results are also ordered, i.e. the sites which fit the query best and which also have the highest reputation for good answers in general are at the top. Thus, as long as fairly common search terms are used the top hits come from sites with a high reputation.
There are attempts to pollute search engines by returning different results to the search engines web bot than to the normal user. This is not new, so search engines partially try to detect such pollution by simulating normal users. They also include historic reputation information, i.e. sites which behaved shady in the past are considered shady for some time in the future too. New sites also have less reputation than established sites etc.
This together makes search engines results fairly good (but not perfect) curated data. Links in mails are the opposite of this: No up-front checks and curation are done to these links and it is all to the end user (or some security software in the path) to decide if this link is safe or not. That's why these links are far more dangerous.


Are reCAPTCHA enough to prevent brute-force password guesses?

ReCaptcha is great from a client side point of view, but it's not perfect.

The mail technique that you mention is called account lockdown, and is a very effective deterrent against brute force attacks. I would implement it because it's an added layer independent of the client side completely.

Another measure you can implement is throttling. It's unrealistic for a human to send 2 requests within 1 second (or any value you consider appropriate), so you limit the frequency of accepted connections. In iptables you would do something like this:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

(Example taken from debian-administration.org.) This will limit requests to port 22 to 3/minute, any other request will be dropped. This can be useful for other operations besides log-in routines.


Unmodified MAC address lists are useful when discovering the type of hardware used on the network. MACs contain the vendor info and can be used to narrow down into the types of hardware used (iPhone, Laptop, etc.).

For me, this is useful to know if an employee has hooked up their personal mobile device on the company network instead of the guest network (as per policy). Although MAC addresses can be spoofed, it's a little harder with things like phones and tablets, and is reliable enough for my purposes.


Add Cipher Suite support to Chrome/ Chromoium?

Cipher suites are removed or added by Google through software patches or updates.  You can blacklist cipher suites by adding a command-line argument to Chrome's startup; as shown in this answer.  Hexadecimal values for each cipher suite can be found here.

There isn't any functionality for enabling non-default cipher suites.  I believe you might be stuck with changing your application's cipher suite to a newly supported cipher suite.

Here is the most recent issue I could find.


OAuth: how to prevent phishing with malicious redirect URIs

In this case, it's up to Example.com to decide whether it wants to allow arbitrary users to create applications and use it as an OAuth2 provider.

Typically there is some kind of approval process for your app to go "live", and part of that process should be vetting the legitimacy of the application, and hopefully malicious uses like this would be prevented.

Facebook is an example of a OIDC/OAuth provider that allows anybody to register any application, but requires approval before your application can be accessed by other people. I don't actually know if approval involves manual review for things like the phishing attack you describe, but it probably should.

To directly answer your question,

  What steps can an OAuth provider take against such an attack?

Example.com should recognize that allowing users to register arbitrary applications exposes them to this kind of attack, and mitigate it by requiring all applications go through a review process. A portion of that review process could be automated by checking whether there is a high degree of similarity between the registered application's redirect URI, and the provider's own domain.


The native rsync protocol does not encrypt anything. It is meant only for trusted networks.

To use rsync in a secure way, use it with SSH (see the "-e" command-line option) or over a VPN.


Relatively simple OTP code generated by SafeNet MobilePass

0.0064% (that's .2^6) of the numbers in a random 6 digit string will only have 0's and 1's. You got one. No big deal. It's only a problem if those numbers occur more than  0.0064% of the time or you can predict when they will occur.

If you pay attention, and wait long enough, you'll see that 1 in 1,000,000 of the random numbers will be your birth date in the form DDMMYY. You can reduce your expected wait time by half by also looking for your birthday in the form MMDDYY. In general, if you treat enough numbers as significant, you're bound to see them all the time.


WHY the VPN crackdown by China, Russia etc when traffic analysis is possible?

The aim of these restrictions is probably not traffic analysis but traffic restriction. With a VPN it is impossible to know and to restrict which web sites somebody visits. Without VPN this is possible, even if the transferred content is protected by HTTPS. Also, without VPN it is possible to deny access to specific web sites even if HTTPS is used. With VPN you can only block the full VPN but not parts of the sites visited using the VPN.

China and Russia are both censoring some sites for a variety of reasons. Since VPN work around this censorship it makes sense to forbid the use of a VPN. The USA and most western countries currently don't censor web sites and thus there is no need to restrict usage of VPN currently. But, given the current discussions about the advantages of encryption for privacy and disadvantages when tracking of "bad people" (terrorists, ...) is needed, things might change even in these parts of the world.


Restricting user sign-in on Chrome for Business

My org agreed chrome extensions and syncing were high risk. The main concern was extensions due to the fact they can control all web traffic in the browser thus need to be patched and whitelisted to run. We have syncing accounts disabled.


Insisting on frequent key renewal is an old tradition but is not mandatory. In older times, when cryptography was something for armies and spies, keys had to be renewed because spies were spied and soldiers were made prisoners in the course of their daily operations; it was thus unreasonable to believe that a secret value known to field agents could remain indefinitely secret. Thus came the habit of regular (and frequent) key renewals. This does not map well to Internet servers, for the following reasons:

Actual intrusions on your servers are rare events. The normal situation is that none occurs. You still want to use detection mechanisms, but you can expect that, on average, no intrusion occurs for months at a time.
When an intrusion occurs, the attacker enacts his main mischief immediately. This is a computer world; within the 10 seconds following the intrusion, the attacker has installed his rootkit, downloaded all the data which he is interested in, modified some records, and left. A daily renewal of keys will "kick him out" (i.e. make obsolete all fake cookies that the attacker could come up with using the stolen key) only long after the damage has been done. The key renewal dogma has been enshrined at a time when the average processing of data was a matter of days or weeks, not seconds. The time scale has changed a lot since these days.

Therefore I would say that a long-lived MAC key is not a crucial problem. Of course, you should mind all the details on how that key is generated, stored and shared between your servers; it is an important secret element with a high value for the attacker. However, renewal is mostly pointless, and can be dangerous, since it impacts the way the key is stored and shared. With a fixed, static key, you can store the key as an OS-protected file on each server, and shared with a one-time manual procedure under controlled conditions (e.g. before the servers are actually put online). If you want to renew keys automatically on a daily basis, then you will need some shared storage or network protocol, which inherently increases the exposure of that secret value. For instance, if you use some database scheme to generate and share the key-of-the-day, then the key can become an easy prey to a SQL injection attack, whereas a simple file would have remained confidential.

For these reasons, I recommend that you abstain from key renewal. It makes the problem much more complex to analyse, with higher exposure, for a gain which is, at best of times, highly questionable.

(Note: This "signature" is more correctly named a MAC. The term "signature" is, in cryptography, reserved for algorithms of the asymmetric persuasion, e.g. RSA, whereas HMAC is part of "symmetric cryptography", meaning here that the same key is used to generate the MAC value and to verify it.)


Can't connect to fake AP with airbase-ng

Yes, work on switching from monitor to managed mode:

Stop your AP
Type sudo airmon-ng stop wlan0mon
Start it again


In general, in order for there to be a problem on your computer,

some piece of executable code (instructions) needs to get downloaded to your computer,
and then it needs to get executed.

(Of course problems on other people's computers can hurt you in a great many ways, and a problem on your co-worker's computer can easily segue into a problem on your computer if, for example, that co-worker is in charge of pushing OS updates out to the whole team.)

Part #1 happens all the time.

Depending how your email is set up, I may be able to put arbitrary files on your machine just by sending you an email. This is less common these days, but it's still a valid example.

Every time you view a website, your browser downloads many files from that remote server so it can show them to you. That's what a website is.

Part #2 takes some work or luck.

So far in the two examples I've given (email and websites), your computer may not have executed any of the malicious instructions I'm sending you (but it probably has, I'll explain).

In the case of an email, the files (attachments) are completely inert until you tell your computer to do something with them. Typically, if you click on an attachment in an email, your computer will assume that you want to view that file, so it will ask your operating system for a program that can display files of that type (signified by the .xyz extension), and then it will tell that program to open the file. At this point the only thing keeping me from executing code on your machine is the program that was chosen to open the file, and I have some control over what program that is.

For websites, in practice, most people have their web-browsers set up to automatically executed any JavaScript included in websites the user visits. That's great for me, if I can get you to visit my website. I have a couple good options:

I can email you a link. If you click it, your computer will assume you want to view that website, and will use your browser to load it up. JavaScript on that page will get executed.
I can put links to my malicious website all over the internet, either by buying ad-space, or by having bots or sweatshop workers post links on various web-forums (including social media).

I may also be able to get someone else's website to run my code, either by hacking that website somehow, or by embedding my code in an advertisement. Both of these happen, they're just a step more difficult.

In short, "don't click stuff" is the stupidest accurate security advice possible.

If you never "click" anything (or equivalently activate it some way the doesn't use your mouse), then your computer won't do anything, which is safe. the threat-model that "don't click stuff" is supposed to protect against is people being tricked into executing code they didn't mean to on their computers.

Email attachments, links from emails, and online advertisements are the mainstream ways that such attacks occur. A lot of work has gone into making these types of attacks harder to pull off:

Email servers will typically screen attachments or even links to try to detect if they're malicious.
Both the programs on your computer that might be charged with opening an email attachment, and the OS that administrates them, have gotten better over the decades at sand-boxing processes and safely handing the files they read from.
Ad networks are still a common malware vector, and you should use an ad-blocker for that reasons alone, but they have gotten better than they used to be. Most of the big networks now do some level of vetting of the ads themselves, so it's harder to push malware or malware-links over them.
Our web-browsers have gotten better at limiting what code on websites is allowed to do. For example it used to normal to have your browser set up to run Flash programs or Java programs; these days it's basically unheard of because everyone knows it's dangerous.

TLDR: "Don't click stuff" is just shorthand for "People online will lie to you to get you to run their malware".


Is there a compelling reason to ssh tunnel RDP connections?

Update: The question has since it was originally posted been edited to highlight one difference, namely that RDP v6 over TLS is used. While the answer may still be considered "okay", I must now argue that tunneling TLS over SSH is unnecessary due to a lack of relevant and likely threat-scenarios - assuming correct configuration of TLS certificates etc.

In an ideal world security decisions should always be supported by data, factual and objective data. Determining whether or not it's "worth the effort" to tunnel RDP through SSH would be done by combining knowledge of known attacks, classification of the information accessed (from a confidentiality, integrity and availability perspective) and the "cost" of implementing countermeasures.

Fact - There are a number of issues with protocol versions < 6.0 of RDP, such as MiTM-attacks (weak authentication, as briefly described here).

While I'm not aware of any real attacks leveraging the above mentioned vulnerability one clearly can't exclude the possibility of that happening, or to have happened. There are however a number of demonstrations scattered around the web illustrating how it could be exploited.

There are a number of things you need to figure out to make a "good" decision.

"Sensitivity" of the information accessed
The effort (time) of implementing the countermeasure (SSH-tunneling)
Likelihood of someone intentionally targeting you to leverage the vulnerability to realize the threat. (Unfortunately very difficult, since data sharing within the security community of past incidents are few and far in between!)

If the effort for tunneling the connection over SSH is not overly costly and time consuming it would be a reasonable countermeasure to use as it would mitigate the above threat entirely.


getting an error in aireplay-ng in kali linux

From the kali forum: run it with --ignore-negative-one or --ig


How antivirus companies create virus defnitions for new outbreaks

Various methods can be used:

Samples are sent in by customers
Malware detected by heuristic scanners (i.e. stuff that behaves like a virus) is further analysed
Mail blocked as spam can be analysed for malware attachments.
"honeypots", which are public servers or email addresses designed to collect malware
going undercover in malware writers communities


Is OSX/MaMi a real malware or a simple filtering software?

This might be new on Mac but seems to be older on Windows. See for example this analysis from 2015 about some malware which changed the DNS settings to ones from the same owner and which also talks about the same silently installed root CA certificate. To cite "Given the above I would say this is a potentially legitimate company (in the past) turned rogue.". See also this article about the DNSUnlocker adware family which uses also DNS servers in the IP block owned by GreenTeam Internet. Also,  the way it is distributed does not really look like some benign software.


There is a very good chance that this is a botnet looking for SQL injection. Even if the bot's goal isn't SQL injection,  it will get a ton of SQL errors by adding 'A=0 to parameter names. The first attack string is shown below:

"GET /xxx.cgi?id=1160'A=0 HTTP/1.1"

If the ID parameter is used in a query,  it will produce a syntax error:

select * from `table` where id = '1160'A=0'

The above query has unbalanced single quotes which may produce an error message. Adding A=0 will never be valid syntax because there will always be an odd number of single-quotes, and there is no comment terminator.  This maybe by design, because it is a string that always errors.


Personally, I do not recommend using the Referer header to stop CSRF attacks.  It has two issues:

First, it is fragile.  There is a long past history of attacks on the Referer header, involving (variously) exploits on plugins (e.g., Flash), bugs in browser APIs (e.g., XHR), and redirection.  To be clear, I'm not saying that checking the Referer will necessarily be insecure; I'm just arguing that I think it's more fragile, and I would have more confidence in a solution that uses CSRF tokens.
Second, some browsers and corporate firewalls block the Referer header for privacy reasons, meaning that you'll be forced to block legitimate users.  So the Referer header is simply not a good solution.

Instead of using the Referer header, I would recommend that you use CSRF tokens.


At times bettercap ARP sniffing works great and at times not at all, what would be the reason?

To sum up the comments, you don't even need to use ARP spoofing since all of the network traffic is already passing through your server. At this point, you can passively sniff any unencrypted traffic, and may be able to determine what hosts are being contacted by using the TLS SNI value, which is unencrypted. If you want to monitor and control HTTPS traffic further, you would need to set up a TLS interception proxy and install your root CA on client machines.
If this were truly a scenario where an ARP spoof attack was needed, these attacks aren't always reliable due to their nature; mainly caching issues and conflict with legitimate ARP requests.


Secure way to send files to server, store, then retrieve

I'm doing the exact same thing already but the contest of my encryption is different. I will give you my view.

You have server A.
The third party service host Server B.
User(n) is user[n].

You will create a random key, with this, you will encrypt your file X.
You will encrypt the random key with your public-key.
You will create a HASH that links the encrypted file with the random-key.
You will send only the encrypted file X from A to B using HTTPS (use a second certificate, of course).

B will store your encrypted until the user[n] will download it with the HASH file.
User[n] will reach your server A through a webgui (why not), after a login(why not..) and after he uploads the HASH file, your system can decrypt the file and let the user download it.

No one will know your private-key, of course, and no one will be given the public key file.
Even if they will, you will store in A the random key you used to encrypt the file.

This pretty much sums up my idea, and 80% of it is applied in my environment (the 20% rest is other checks).

Sure there is some work to do, but not even so much. I built this in 1 day and I'm not even that good at it.

EDIT:
I recently finished my script for backing up and encrypting a postgresql database.
Here you will find everything you need but creating the HASH.
At least the part of encryption/decryption is what you may want.
https://github.com/Nihvel/Backup-Scripts/blob/master/postgresql_database_backup


what are the differences between TLS and SSL?

SSL is the code name for three successive protocols that were designed by Netscape, back in the 1990s. The acronym stands for "Secure Sockets Layer". The three protocols are very different from each other (SSL 1.0 was never published but has been described as "embarrassing"; SSL 2.0 was published as draft; and SSL 3.0 was considerably modified to try to fix a number of shortcomings in SSL 2.0).

Then the whole concept was given to the IETF, who became responsible for maintaining the SSL 3.0 protocol. The subsequent protocols were called TLS, starting with TLS 1.0, then 1.1 and 1.2. The name change was partly meant to convey the idea that the protocol could be applied to any bidirectional transport medium, not just Internet sockets; and partly to avoid any potential issues with the reuse of the "SSL" acronym which might have been a Netscape trademark.

In any case, TLS 1.0, 1.1 and 1.2 are quite similar to SSL 3.0 in their definition and functioning; there is a much larger gap between SSL 2.0 and SSL 3.0, than between SSL 3.0 and TLS 1.2. Thus, trying to keep "SSL" and "TLS" apart from each other does not make a lot of technical sense. The difference in terminology relates to administrative concepts.

Personally, I tend to use "SSL" as a designation of the whole concept (thus encompassing all versions, from SSL 1.0 to TLS 1.2), and "TLS" only to designate the IETF incarnations of that concept. In many cases, I write "SSL/TLS" when I want to avoid any vain debate.

See also this answer.


How do I ensure that my Ubuntu download has not been tampered with?

You can find all of the MD5 hashes here:

https://help.ubuntu.com/community/UbuntuHashes

Now all you have to do is compare the MD5 hash of your download with the hash on the page. You can generate an MD5 hash in Ubuntu by using:

md5sum <file>


The naming conventions of computers has long been a divisive topic and often the security of a network needs to be put up against the manageability of an environment. I have worked in environments where the server names dictated exactly what that server did, and I've worked in networks with weird naming conventions that did nothing else than tickle the SysAdmin's fancy.

As a Penetration Tester I will tell you that there are a number of trivial ways for me to glean what Operating System a computer is.

Nmap does a very effective job of "guessing" what OS a computer is. Try for yourself nmap -A <IP ADDRESS>
The MAC address of a computer can be a giveaway in the example of Mac's
The services running on a machine can provide you with a good clue as to what OS the system is running (Banner grabbing)
If you can get a user on that system to navigate to a website with a BeEF hook embedded or other mechanism to enumerate the machine then you'll easily identify the OS running.

Typically speaking, the Operating System itself isn't of too much interest to me. I'm more concerned as to what the patch level is like of a specific machine, what services are running on it that might be vulnerable, etc. I personally don't think that putting the operating system in an A name is a security risk in and of itself and I know plenty of organizations that utilize a similar naming convention.


If I'm understanding you correctly and you want to get all files in Linux and their associated timestamps:

find / -printf '%Tc %p\n'

beware of date stomping tho.


Why is the public key in a certificate not signed?

For any message that is signed with a digital signature, it is standard to take a hash of the message first, then apply the digital signature algorithm to the hash.

Without applying the hash function first, the message would have to be split into blocks small enough for the digital signature algorithm to act on each block separately.  This would complicate not only the signing process, but the verification process as well.


A stranger asks for my delivery address, how much information should I give?

In the end, it all comes down to trust and risk. How much do you trust this person and how much do you want to give as far as details goes, what can someone do to harm you when they have your data? That you're asking here tells me you're not really sure if you can trust this person. There are risks involved (such as real life threats or maybe a possible scam) but it is not easy to identify risks without knowing the full situation, as you explained it rather vaguely.

To me the whole situation sounds kinda phishy to be honest. Are you sure you didn't fall for a phishing or scam attempt by helping this other person?

Most countries do have PO boxes and other rent-able post solutions such as Poste Restante (as suggested by Molot in the comments) so you don't have to give out your own personal details.


Is my ISP doing a port scan on my computer?

Which version of linux are you using and how is your iptables configure that is causing these messages to be logged?

I can offer an alternative possible explanation.

In the packets there seems to be the RST flag being set.

  11:45:26 my.com kernel: IPTABLES: SRC=220.255.XX.XXA DST=192.168.1.2
  LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=49687 PROTO=TCP SPT=443 DPT=54100
  SEQ=21106 ACK=0 WINDOW=0 RES=0x00 RST URGP=0

This means that from 220.255 you get a RST answer back from their port 443. The increasing number of ports on your side make me assume that what you are seeing here is that the 220.255 host(s) are rejecting tcp/ip connection attempts.

Your firewall configuration is likely not relating them correctly to the syn packets you are sending out. Depending on your iptables configuration this is "normal" or the cause of a bug in older versions with the ESTABLISHED/RELATED state of connection tracking.

To investigate this further I would recommend running a tcpdump for port 443 on the respective interface and have a look if this is indeed the case, or if someone is sending unsolicited RST packets.

As a side note, I am seeing such behaviour too on some of my servers with certain ip ranges. They are all RST packets that are sent because the DNS rotation of some commonly used webservice is containing ip addresses that do not actually have a service running.


What security settings is Yahoo Mail looking for to consider IMAP client secure?

That setting is used to block (or permit) password auth to Yahoo's POP3/IMAP/SMTP servers. They want you to use OAuth tokens instead.

The advantage of OAuth is that the app itself doesn't actually store your password - in fact, needn't ever even see your password - and has only an app-specific access token and refresh token. The use of those tokens can be tracked individually, and revoked at need, without impacting other apps (unlike a password). The token also can't be used to sign into the web portal and do things like change settings, again, unlike a password.

Still, the way they will prompt you every single time you log in to "disable insecure access" is intensely irritating, especially because they don't know how the clients are storing those passwords (for example, if I don't have Outlook store the password and just enter it every time I sign in, then most of their concern is irrelevant) and also because training people to click through scary-looking warnings is a TERRIBLE thing to do.


How are USSD messages used and who could send them?

I work in a telco and can tell you that we do use USSD messages. As far as I know, users can't generate them on their own, it has to be the provider.
So it's either your provider that's compromised, or your phone. I'd send an e-mail to your provider (look it up on their website, it's probably 'abuse@providerx.com' or something like that).


Should stored XSS prevention be client or server-side?

Normally for XSS prevention we use html escape character in order the validate the input character or input. According to OWASP here are some of the things that you must follow:

For client side and server side:

Escape character before processing the given input.
Better use security encoding library.
Do not enter untrusted data except in allowed location.
HTML Escape Before Inserting Untrusted Data into HTML Element Content
Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
HTML escape JSON values in an HTML context and read the data with JSON.parse
CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values
URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
Sanitize HTML Markup with a Library Designed for the Job
Prevent DOM-based XSS

For server side:

Use HTTPOnly cookie flag
Implement Content Security Policy
Implement and configure WAF like Mod security.
Use the X-XSS-Protection Response Header

There are other prevention measures. You can check this link to get more detailed information.

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet


Is the process Wslxrqjet.exe, tagged 'Google Chrome', malicious?

Removing the process should be pretty easy: change the security on the EXE to deny the Execute permission (this can be done on a file with running processes), and then run taskkill /f /im Wslxrqjet.exe to terminate all instances of the running process as simultaneously as possible. New instances won't be able to start (unless something reset the permissions on the file). You can then delete the EXE.
Another option would be to create a new user with admin rights, log out of your account, log into the other user, and delete the file out of your usual account. You could also shut down and boot the machine off different media (such as a Linux live image on Windows install/recovery disk), mount the C: drive, and delete the file from there. There are lots of ways to handle this.
You can also try investigating the process while it's running. See which process launched each instance, who it's running as, and more by using a tool like Process Explorer (free download, part of Microsoft's Sysinternals suite). See what the process is doing by checking its network activity, file handles, and so on using Resource Monitor (built into Windows, gives more details than Task Manager) or - for tons of detail - Process Monitor (also free, part of Sysinternals). Even if it is malicious - not guaranteed - it's had long enough to run that it's probably done it's harm at this point. However, if you want to prevent it from doing anything while you examine it, use Resource Monitor or Process Explorer to "Suspend" the processes.


These kinds of requests are commonly used for server fingerprinting. By sending a request that is likely to trigger an error other than a common 403, 404, 500, etc. they hope that the site operator did not set a custom error page, and that it will return a default error page with server type and version information. You'll often see really long URLs used to force a HTTP 414 response for the same reason.

As to whether it's malicious; it's probably an automated bot rather than a targeted attack. What they do after scanning is what determines whether it's malicious or not. A lot of the time it's just internet survey bots like Shodan which you don't need to worry about.


RANDFILE is used by OpenSSL to store some amount (256 bytes) of seed data from the CSPRNG used internally across invocations.  This is particularly useful on low-entropy systems (i.e., embedded devices) that make frequent SSL invocations.

The file is loaded via the function RAND_load_file.  Looking at the source, we see that the contents of the file are added to the RNG via RAND_add, so they are in addition to any existing entropy in the RNG.

Since the RNG loads some entropy from system-specific entropy sourcess at the time it is initialized, it seems that RANDFILE is definitely not the only source of entropy used for the RNG state.

  Would it confer any security advantage to save output from openssl rand to this file?

That's essentially what OpenSSL does when it says "at exit 256 bytes will be written to it".  If you'd like to seed it from something initially, I recommend /dev/urandom, like so:

dd if=/dev/urandom of=randfile bs=256 count=1


How to sniff a data from an upstream router?

You cannot passively sniff packets that aren't passing through the part of the network you control, no.

However, attackers sometimes use a related kind of attack, where they compromise either the router or the hosts in the target network to make them send packets where they shouldn't. Then they can be passively sniffed.


Can my work computer sniff my home network?

If your employer has set up your work computer to create a security hole in the network you are connected to (like installing a remote access trojan or other reverse shell backdoor) then your work computer could allow your employer to access the work computer as if they are sitting at it. Once they have access, they can attempt to traverse the network that computer is on by exploiting vulnerabilities in services and applications running on other networked hosts. If your employer manages to log into your home router, they could download logs of all host requests on your network (what sites every host has requested). Also, once someone is backdoored into a system, they may be able to run wireshark or a tcpdump to sniff traffic to/from that host, depending on their access level. So, it's possible, but is a multi-step process.

If you suspect something like that may be happening on your work computer, open a terminal or command prompt on your work computer and try a netstat command with different flags (like "nestat -an") to see what your work computer may be communicating with and on what ports. You can also run Wireshark to see a stream of network-based communication that your work computer is doing.