Az FSF.hu Alapítvány június 8-án (most szombaton) ismét Szabad Szoftver Konferenciát szervez, ahol a hazai közösség ismert szereplői adnak elő. A belépés ingyenes. Jelentkezz már most! További részletek és regisztráció »
Buherator
Shared posts
DoS Attack Forces EVE Online Offline
Read more of this story at Slashdot.
Disposable VPN: Tor Gateways With EC2 Free Tiers
Read more of this story at Slashdot.
Delving Deeply Into a Bitcoin Botnet
Bitcoin is a virtual decentralized currency that was created in 2009 by developer Satoshi Nakamoto, who described the currency in a paper. Recently Bitcoin has gotten lots of attention. In early 2013, the prices reached a high of US$265 per Bitcoin. The following chart shows the currency’s historical price:
Because Bitcoin is a virtual currency and independent of any financial institution, many vendors accept Bitcoins as payments.
Bitcoins are generated through a process called mining. Every transaction is in the form of block that is broadcasted to all the nodes on the network. Nodes try to find a difficult proof of work that involves finding a value which when hashed with an algorithm such as SHA-256 gives output that contains a number of zero bits. Once a node finds such a hash, the user is rewarded with new Bitcoins.
Because mining requires enormous processing power, the concept of “pooled” mining allows lots of people to work together to find a hash value. They all work together by sharing their resources. Once a hash has been generated by any user, they all split the created Bitcoins.
The current jump in Bitcoin price suggests that cybercriminals are paying attention. With pooled mining, it is easier for botnet owners to install Bitcoin mining clients on various systems working together to generate Bitcoins for the botnet masters.
In our recent analysis of botnets, we found a couple of samples that were communicating to various online Bitcoin mining services over the Stratum protocol:
We also saw a couple of samples using JSON/RPC calls:
And communication with a control server:
It is clear that this bot is sending various information to the control server back and receiving commands from the server.
Our analysis found that this botnet uses ufasoft Bitcoin mining software. All the required files are embedded inside the resource section of the .exe, so unlike other botnets no extra download is required.
The following screenshot shows malicious files getting unpacked in memory and running there.
The botnet also dropped a couple of required files for Bitcoin mining under a temp/{random name} folder:
After that the botnet launches the file responsible for Bitcoin mining:
Note that the file has a fake description: “Malwarebytes Anti-malware.”
This bot can be installed on a victim’s system through various methods: drive-by downloads, download via botnet, etc. Once run, this bot registers with various online pooled mining services with the attacker-supplied user name and password, so the attacker gets Bitcoins credited to his or her own account:
We found one person selling an entire botnet kit on one of the underground forums for just a few dollars:
We also found that the sample we got is the same as shown in the preceding forum post.
Here are couple of screenshots showing the control panel of the bot.
Commands:
Bitcoin settings:
Botnet summary:
Statistics:
Bitcoin has recently gotten lots of media coverage because of the price it has attained during the last few months. We believe that this upward price trend will continue. With this bot, attackers are seeking new sources of income. They are quick to obtain the latest code as soon as it’s available.
McAfee customers are protected against this threat by IPS signature ID:0x4880b300_BOT_Bitbot_Activity_Detected.
I would like to thank my colleague Vikas Taneja for his help with this analysis.
[dos] - ModSecurity Remote Null Pointer Dereference
GCC 4.8.1
Jakub Jelinek tegnap bejelentette a GNU Compiler Collection (GCC) 4.8.1-es kiadását. Ez a point release az első hibajavító kiadás, amely a gcc 4.8-ban található regressziókat és komolyabb hibákat hivatott orvosolni. Több mint 90 javítást hoz az előző kiadáshoz képest. A kiadás további érdekessége, hogy megérkezett vele az utolsó hiányzó C++11 (ref-qualifiers) feature is. Ezzel a gcc "C++11 feature complete"-nek tekinthető.
[remote] - IBM SPSS SamplePower C1Tab ActiveX Heap Overflow
A few more days before EMET 4
On May 8th, we announced that EMET 4 would have been released today, May 28th. Since that day, we had additional feedback and we are working on a few things that are requiring a little bit more time than expected.
This considered, we are not releasing EMET 4 today, and we will take a few more days to have everything prepared for the final release. We are sure that you will not be disappointed by the additions we are working on before the final release.
Also, at this point we don’t want to give a new release date yet, but expect to see EMET 4 in the next few days.
Stay tuned!
- The EMET Team.
CVE-2013-3228: Linux kernel IrDA Information Leak
[remote] - Nginx HTTP Server 1.3.9-1.4.0 Chuncked Encoding Stack Buffer Overflow
[local] - AdobeCollabSync Buffer Overflow Adobe Reader X Sandbox Bypass
Amerikai hadiipari titkokat loptak el kínai hekkerek
Winners of the AusCERT 2013 #sophospuzzle (and how to solve it)
Australian Intelligence HQ Blueprints Hacked
Read more of this story at Slashdot.
[dos] - Trend Micro DirectPass 1.5.0.1060 - Multiple Software Vulnerabilities
[local] - Sony Playstation 3 (PS3) 4.31 - Save Game Preview SFO File Handling Local Command Execution
[local] - AdobeCollabSync Buffer Overflow Adobe Reader X Sandbox Bypass
[papers] - Blackberry Z10 Research Primer - Dissecting Blackberry 10 - An Initial Analysis
CVE-2013-1819: Linux kernel XFS _xfs_buf_find() NULL Pointer Dereference
On 21 January 2013 Dave Chinner of Red Hat committed a change that fixes a NULL pointer dereference vulnerability in XFS filesystem. The below routine is located in fs/xfs/xfs_buf.c file.
/*
* Finding and Reading Buffers
*/
/*
* Look up, and creates if absent, a lockable buffer for
* a given range of an inode. The buffer is returned
* locked. No I/O is implied by this call.
*/
xfs_buf_t *
_xfs_buf_find(
struct xfs_buftarg *btp,
struct xfs_buf_map *map,
int nmaps,
xfs_buf_flags_t flags,
xfs_buf_t *new_bp)
{
size_t numbytes;
struct xfs_perag *pag;
...
/* get tree root */
pag = xfs_perag_get(btp->bt_mount,
xfs_daddr_to_agno(btp->bt_mount, blkno));
/* walk tree */
...
return bp;
}
First of all, the xfs_addr_to_agno() C macro is the following as defined in fs/xfs/xfs_mount.h header file.
#define xfs_daddr_to_agno(mp,d) \
((xfs_agnumber_t)(XFS_BB_TO_FSBT(mp, d) / (mp)->m_sb.sb_agblocks))
As Dave Chinner pointed out, if we try to walk a filesystem and the extent map has corrupted block number (out of range address) the call to xfs_perag_get() above will trigger a NULL pointer dereference.
/*
* Reference counting access wrappers to the perag structures.
* Because we never free per-ag structures, the only thing we
* have to protect against changes is the tree structure itself.
*/
struct xfs_perag *
xfs_perag_get(struct xfs_mount *mp, xfs_agnumber_t agno)
{
struct xfs_perag *pag;
int ref = 0;
rcu_read_lock();
pag = radix_tree_lookup(&mp->m_perag_tree, agno);
if (pag) {
ASSERT(atomic_read(&pag->pag_ref) >= 0);
ref = atomic_inc_return(&pag->pag_ref);
}
rcu_read_unlock();
trace_xfs_perag_get(mp, agno, ref, _RET_IP_);
return pag;
}
The radix_tree_lookup() call will use the invalid block number ‘agblocks’ (size of an allocation group) as an index key to the ‘mp->m_perag_tree’ radix tree.
The fix to this bug was to add a new variable to the susceptible routine:
xfs_buf_t *bp; xfs_daddr_t blkno = map[0].bm_bn; + xfs_daddr_t eofs; int numblks = 0;
And write a check for the block number not being larger than the end of the filesystem.
ASSERT(!(BBTOB(blkno) & (xfs_off_t)btp->bt_smask));
+ /*
+ * Corrupted block numbers can get through to here, unfortunately, so we
+ * have to check that the buffer falls within the filesystem bounds.
+ */
+ eofs = XFS_FSB_TO_BB(btp->bt_mount, btp->bt_mount->m_sb.sb_dblocks);
+ if (blkno >= eofs) {
+ /*
+ * XXX (dgc): we should really be returning EFSCORRUPTED here,
+ * but none of the higher level infrastructure supports
+ * returning a specific error on buffer lookup failures.
+ */
+ xfs_alert(btp->bt_mount,
+ "%s: Block out of range: block 0x%llx, EOFS 0x%llx ",
+ __func__, blkno, eofs);
+ return NULL;
+ }
+
/* get tree root */
CVE-2013-1774: Linux kernel Edgeport USB Serial Converter NULL Pointer Dereference
This is a vulnerability fixed by Wolfgang Frisch and the buggy code resides in drivers/usb/serial/io_ti.c as you can see below.
static void chase_port(struct edgeport_port *port, unsigned long timeout,
int flush)
{
int baud_rate;
struct tty_struct *tty = tty_port_tty_get(&port->port->port);
struct usb_serial *serial = port->port->serial;
wait_queue_t wait;
unsigned long flags;
...
remove_wait_queue(&tty->write_wait, &wait);
...
tty_kref_put(tty);
...
}
If the equivalent /dev/ttyUSB device file is in use while the device is disconnected then any call to chase_port() (used to chase the port, close and flush it) will lead to NULL pointer dereference since there is no longer a ‘tty’ associated with it. The fix was to add a simple check for this case.
unsigned long flags; + if (!tty) + return; + if (!timeout)
CVE-2013-1848: Linux kernel EXT3 ext3_msg() Format String
Recently Lars-Peter Clausen committed a change on Linux kernel that fixes a format string vulnerability in the EXT3 filesystem code. The susceptible code resides in fs/ext3/super.c but to better understand it we need to have a look on how ext3_msg() is defined first.
void ext3_msg(struct super_block *sb, const char *prefix,
const char *fmt, ...)
{
struct va_format vaf;
va_list args;
va_start(args, fmt);
vaf.fmt = fmt;
vaf.va = &args;
printk("%sEXT3-fs (%s): %pV\n", prefix, sb->s_id, &vaf);
va_end(args);
}
So, it should be called passing the following three mandatory arguments:
– Pointer to the super-block structure
– Prefix string
– Format string
And of course, any variables to be printed. As Lars-Peter Clausen noticed, there were two cases where there was no prefix defined. This makes the format string argument to be passed as prefix and any variables to be processed as the format string. Here are these two cases:
/*
* Open the external journal device
*/
static struct block_device *ext3_blkdev_get(dev_t dev, struct super_block *sb)
{
...
fail:
ext3_msg(sb, "error: failed to open journal device %s: %ld",
__bdevname(dev, b), PTR_ERR(bdev));
return NULL;
}
And…
static ext3_fsblk_t get_sb_block(void **data, struct super_block *sb)
{
ext3_fsblk_t sb_block;
...
if (*options && *options != ',') {
ext3_msg(sb, "error: invalid sb specification: %s",
(char *) *data);
...
return sb_block;
}
The fix was to add the missing prefix argument to the function call like this.
@@ -353,7 +353,7 @@ static struct block_device *ext3_blkdev_get(dev_t dev, struct super_block *sb)
return bdev;
fail:
- ext3_msg(sb, "error: failed to open journal device %s: %ld",
+ ext3_msg(sb, KERN_ERR, "error: failed to open journal device %s: %ld",
__bdevname(dev, b), PTR_ERR(bdev));
return NULL;
@@ -887,7 +887,7 @@ static ext3_fsblk_t get_sb_block(void **data, struct super_block *sb)
/*todo: use simple_strtoll with >32bit ext3 */
sb_block = simple_strtoul(options, &options, 0);
if (*options && *options != ',') {
- ext3_msg(sb, "error: invalid sb specification: %s",
+ ext3_msg(sb, KERN_ERR, "error: invalid sb specification: %s",
(char *) *data);
return 1;
}
CVE-2013-2074: KDE kdelibs Password Exposure
This was a low impact vulnerability reported by m.wege. The issue occurs on “internal server error” and triggers the below code located at kioslave/http/http.cpp.
/**
* This function will read in the return header from the server. It will
* not read in the body of the return message. It will also not transmit
* the header to our client as the client doesn't need to know the gory
* details of HTTP headers.
*/
bool HTTPProtocol::readResponseHeader()
{
...
if (m_request.responseCode >= 500 && m_request.responseCode <= 599) {
// Server side errors
if (m_request.method == HTTP_HEAD) {
...
if (!sendErrorPageNotification()) {
error(ERR_INTERNAL_SERVER, m_request.url.url());
return false;
...
} else if (!isAuthenticationRequired(m_request.responseCode) && m_request.responseCode >= 400 && m_request.responseCode <= 499) {
// Any other client errors
// Tell that we will only get an error page here.
if (!sendErrorPageNotification()) {
if (m_request.responseCode == 403)
error(ERR_ACCESS_DENIED, m_request.url.url());
else
error(ERR_DOES_NOT_EXIST, m_request.url.url());
return false;
}
...
}
Clearly, error() could be called passing the error number along with a string which in all of the above cases is the result of m_request.url.url().
void HTTPProtocol::error( int _err, const QString &_text )
{
// Close the connection only on connection errors. Otherwise, honor the
// keep alive flag.
if (_err == ERR_CONNECTION_BROKEN || _err == ERR_COULD_NOT_CONNECT)
httpClose(false);
else
httpClose(m_request.isKeepAlive);
if (!m_request.id.isEmpty())
{
forwardHttpResponseHeader();
sendMetaData();
}
// It's over, we don't need it anymore
clearPostDataBuffer();
SlaveBase::error( _err, _text );
m_iError = _err;
}
The url() routine is part of kdecore/io/kurl.cpp file and it is being to used to dump the URL.
QString KUrl::url( AdjustPathOption trailing ) const
{
if (QString::compare(scheme(), QLatin1String("mailto"), Qt::CaseInsensitive) == 0) {
// mailto urls should be prettified, see the url183433 testcase.
return prettyUrl(trailing);
}
if ( trailing == AddTrailingSlash && !path().endsWith( QLatin1Char('/') ) ) {
// -1 and 0 are provided by QUrl, but not +1, so that one is a bit tricky.
// To avoid reimplementing toEncoded() all over again, I just use another QUrl
// Let's hope this is fast, or not called often...
QUrl newUrl( *this );
newUrl.setPath( path() + QLatin1Char('/') );
return QString::fromLatin1(newUrl.toEncoded());
}
else if ( trailing == RemoveTrailingSlash) {
const QString cleanedPath = trailingSlash(trailing, path());
if (cleanedPath == QLatin1String("/")) {
if (path() != QLatin1String("/")) {
QUrl fixedUrl = *this;
fixedUrl.setPath(cleanedPath);
return QLatin1String(fixedUrl.toEncoded(None));
}
return QLatin1String(toEncoded(None));
}
}
return QString::fromLatin1(toEncoded(trailing == RemoveTrailingSlash ? StripTrailingSlash : None));
}
Of course, this means that the same also applies when the URL includes username and password information such as http://username:password@example.com. To fix this the calls to url() were replaced by prettyUrl() with the following patch.
diff --git a/kioslave/http/http.cpp b/kioslave/http/http.cpp
index 2d139a9..129fc7b 100644
--- a/kioslave/http/http.cpp
+++ b/kioslave/http/http.cpp
@@ -3056,7 +3056,7 @@ try_again:
; // Ignore error
} else {
if (!sendErrorPageNotification()) {
- error(ERR_INTERNAL_SERVER, m_request.url.url());
+ error(ERR_INTERNAL_SERVER, m_request.url.prettyUrl());
return false;
}
}
@@ -3072,9 +3072,9 @@ try_again:
// Tell that we will only get an error page here.
if (!sendErrorPageNotification()) {
if (m_request.responseCode == 403)
- error(ERR_ACCESS_DENIED, m_request.url.url());
+ error(ERR_ACCESS_DENIED, m_request.url.prettyUrl());
else
- error(ERR_DOES_NOT_EXIST, m_request.url.url());
+ error(ERR_DOES_NOT_EXIST, m_request.url.prettyUrl());
return false;
}
} else if (m_request.responseCode >= 301 && m_request.responseCode<= 303) {
This routine among other things removes the password from the URL.
QString KUrl::prettyUrl( AdjustPathOption trailing ) const
{
// reconstruct the URL in a "pretty" form
// a "pretty" URL is NOT suitable for data transfer. It's only for showing data to the user.
// however, it must be parseable back to its original state, since
// notably Konqueror displays it in the Location address.
// A pretty URL is the same as a normal URL, except that:
// - the password is removed
// - the hostname is shown in Unicode (as opposed to ACE/Punycode)
// - the pathname and fragment parts are shown in Unicode (as opposed to %-encoding)
QString result = scheme();
...
}
CVE-2013-2007: QEMU Guest Agent Insecure File Permissions
CVE-2013-1798: Linux kernel KVM IOAPIC_REG_SELECT Invalid Memory Access
This was very nice vulnerability reported by Andrew Honig of Google. The bug is triggered when a user specifies an invalid IOAPIC_REG_SELECT value which is reachable via read KVM I/O device operation as you can see below.
static int ioapic_mmio_read(struct kvm_io_device *this, gpa_t addr, int len,
void *val)
{
struct kvm_ioapic *ioapic = to_ioapic(this);
u32 result;
...
switch (addr) {
case IOAPIC_REG_SELECT:
result = ioapic->ioregsel;
break;
case IOAPIC_REG_WINDOW:
result = ioapic_read_indirect(ioapic, addr, len);
break;
...
return 0;
}
...
static const struct kvm_io_device_ops ioapic_mmio_ops = {
.read = ioapic_mmio_read,
.write = ioapic_mmio_write,
};
Additionally, if a user makes a read by invoking IOAPIC_REG_WINDOW it will result in calling ioapic_read_indirect(). Here is what this function does.
static unsigned long ioapic_read_indirect(struct kvm_ioapic *ioapic,
unsigned long addr,
unsigned long length)
{
unsigned long result = 0;
switch (ioapic->ioregsel) {
...
default:
{
u32 redir_index = (ioapic->ioregsel - 0x10) >> 1;
u64 redir_content;
ASSERT(redir_index < IOAPIC_NUM_PINS);
redir_content = ioapic->redirtbl[redir_index].bits;
result = (ioapic->ioregsel & 0x1) ?
(redir_content >> 32) & 0xffffffff :
redir_content & 0xffffffff;
break;
}
}
return result;
}
It calculates and initializes the value of ‘redir_index’ from the user controlled ‘ioapic->ioregsel’ variable and then uses it as an index to ‘ioapic->redirtbl[]’ array. If this value is larger than IOAPIC_NUM_PINS it will result in invalid memory access. Here is how IOAPIC_NUM_PINS is defined in virt/kvm/ioapic.h header file.
#define IOAPIC_NUM_PINS KVM_IOAPIC_NUM_PINS
And this is because it is architecture specific. For IA64 is defined in include/uapi/asm/kvm.h as 48 and for x86 in arch/x86/include/uapi/asm/kvm.h as 24. As you might have noticed there is an ASSERT() call to make this check but of course, this will only take effect in the debug builds.
The fix was to replace that ASSERT() call with a range check like this.
u32 redir_index = (ioapic->ioregsel - 0x10) >> 1; u64 redir_content; - ASSERT(redir_index < IOAPIC_NUM_PINS); + if (redir_index < IOAPIC_NUM_PINS) + redir_content = + ioapic->redirtbl[redir_index].bits; + else + redir_content = ~0ULL; - redir_content = ioapic->redirtbl[redir_index].bits; result = (ioapic->ioregsel & 0x1) ? (redir_content >> 32) & 0xffffffff :
Happy Geek Pride Day!
Reports: Liberty Reserve Founder Arrested, Site Shuttered
The founder of Liberty Reserve, a digital currency that has evolved as perhaps the most popular form of payment in the cybercrime underground, was reportedly arrested in Spain this week on suspicion of money laundering. News of the law enforcement action may help explain an ongoing three-day outage at libertyreserve.com: On Friday, the domain registration records for that site and for several other digital currency exchanges began pointing to Shadowserver.org, a volunteer organization dedicated to combating global computer crime.
According to separate reports in The Tico Times and La Nacion, two Costa Rican daily newspapers, police in Spain arrested Arthur Budovsky Belanchuk, 39, as part of a money laundering investigation jointly run by authorities in New York and Costa Rica.
Update, May 28, 9:11 a.m. ET: Libertyreserve.com is now resolving again, but its homepage has been replaced by a notice saying “THIS DOMAIN NAME HAS BEEN SEIZED,” and features badges from the U.S. Treasury Dept., U.S. Secret Service, and the DHS.
Original story:
The papers cited Costa Rican prosecutor José Pablo González saying that Budovsky, a Costa Rican citizen of Ukrainian origin, has been under investigation since 2011 for money laundering using Liberty Reserve, a company he created in Costa Rica. “Local investigations began after a request from a prosecutor’s office in New York,” Tico Times reporter L. Arias wrote. “On Friday, San José prosecutors conducted raids in Budovsky’s house and offices in Escazá, Santa Ana, southwest of San José, and in the province of Heredia, north of the capital. Budovsky’s businesses in Costa Rica apparently were financed by using money from child pornography websites and drug trafficking.”
For those Spanish-speaking readers out there, Gonzalez can be seen announcing the raids in a news conference documented in this youtube.com video (the subtitles option for English do a decent job of translation as well).
Liberty Reserve is a largely unregulated money transfer business that allows customers to open accounts using little more than a valid email address, and this relative anonymity has attracted a huge number of customers from underground economies, particularly cybercrime.
The trouble started on Thursday, when libertyreserve.com inexplicably went offline. The outage set off increasingly anxious discussions on several major cybercrime forums online, as many that work and ply their trade in malicious software and banking fraud found themselves unable to access their funds. For example, a bulletproof hosting provider on Darkode.com known as “off-sho.re” (a hacker profiled in this blog last week) said he stood to lose $25,000, and that the Liberty Reserve shutdown “could be the most massive ownage in the history of e-currency.”
That concern turned to dread for some after it became apparent that this was no ordinary outage. On Friday, the domain name servers for Libertyreserve.com were changed and pointed to ns1.sinkhole.shadowserver.org and ns2.sinkhole.shadowserver.org. Shadowserver is an all-volunteer nonprofit organization that works to help Internet service providers and hosting firms eradicate malware infections and botnets located on their servers.
In computer security lexicon, a sinkhole is basically a way of redirecting malicious Internet traffic so that it can be captured and analyzed by experts and/or law enforcement officials. In its 2011 takedown of the Coreflood botnet, for example, the U.S. Justice Department relied on sinkholes maintained by the nonprofit Internet Systems Consortium (ISC). Sinkholes are most often used to seize control of botnets, by interrupting the DNS names the botnet is programmed to use. Ironically, as of this writing Shadowserver.org is not resolving, possibly because the Web site is under a botnet attack (hackers from at least one forum threatened to attack Shadowserver.org in retaliation for losing access to their funds).
Reached via Twitter, a representative from Shadowserver declined to comment on the outage or about Liberty Reserve, saying “We are not able to provide public comment at this time.” I could find no official statement from the U.S. Justice Department on this matter either.
Libertyreserve.com is not the only virtual currency exchange that has been redirected to Shadowserver’s DNS servers. According to passive DNS data collected by the ISC, at least five digital currency exchanges –milenia-finance
Assuming the reports at The Tico Times and El Nacion are accurate, this would not be the first time Mr. Budovsky has attracted attention from authorities for money laundering. According to the Justice Department, on July 27, 2006, Arthur Budovsky and a man named Vladimir Kats were indicted by the state of New York on charges of operating an illegal money transmittal business, GoldAge Inc., from their Brooklyn apartments. From a Justice Department account of that case:
“The defendants had transmitted at least $30 million to digital currency accounts worldwide since beginning operations in 2002. The digital currency exchanger, GoldAge, received and transmitted $4 million between January 1, 2006, and June 30, 2006, as part of the money laundering scheme. Customers opened online GoldAge accounts with limited documentation of identity, then GoldAge purchased digital gold currency through those accounts; the defendants’ fees sometimes exceeded $100,000. Customers could choose their method of payment to GoldAge: wire remittances, cash deposits, postal money orders, or checks. Finally, the customers could withdraw the money by requesting wire transfers to accounts anywhere in the world or by having checks sent to any identified individual.”
From the U.S. government’s description, Liberty Reserve sounds virtually indistinguishable from GoldAge, except for having been based in Costa Rica. If Liberty Reseve stays offline, this could cause a major upheaval in the cybercrime economy. I will be following this case closely, and would expect to hear more about this apparently coordinated takedown following the Memorial Day holiday in the U.S. on Monday.
For now, however, many in the underground would rather believe almost any other explanation than a law enforcement takedown. The administrator of cybercrime forum Carder.pro, for example, has been telling forum members that the entire incident is the work of professional hackers working for Liberty Reserve’s competitors.
Update, May 26, 10:45 p.m. ET: A competitor to Liberty Reserve, a virtual currency called Perfect Money, on Saturday posted a note to its site saying it would no longer accept new registrations from individuals or companies based in the United States. “We bring to your attention that due to changes in our policy we forbid new registrations from individuals or companies based in the United States of America. This includes US citizens residing overseas,” the company wrote. “If you fall under the above mentioned category or a US resident, please do not register an account with us. We apologize for any inconvenience caused.”
Update, May 28, 1:26 p.m., ET: I just filed a follow-up story which confirms that libertyreseve.com and other exchangers were seized by the U.S. government. The story also examines the impact of this law enforcement action on other digital currencies, including Bitcoin.


















